Support

Last Wednesday updated Backup Pro to 4.2.3. Found new notices in OSX Safari advising that [my joomla/backend?] was trying to push notifications. This was new and hence concerning... but since found recent ticket 22801 advising how to disable this (via Options in Akeeba Backup) and have just done so.

Two different things. The one Safari is bugging you about is called Desktop Notifications and it's implemented with Javascript. When you accept the desktop notifications Akeeba Backup will issue a desktop notification (upper right hand corner of your screen) when the backup starts and stops. These are only shown on the computer running the backup and only for backups started through the back-end.

I hadn't found this before (not having seen it in the documentation, probably my error) and I certainly haven't acquired a Pushbullet access token. Pushbullet was listed in the Notifications drop down menu. Is it right then that a 'push' was still trying to happen, even when the update has happened?

And that's an entirely different feature called Push Notifications. Push notifications are implemented using a third party service called Pushbullet. Akeeba Backup sends the notification text for backup start and end to Pushbullet. Pushbullet then "pushes" it to all your devices connected to the Pushbullet account: Mac OS X, Windows, Linux, iOS, Android, Windows Mobile. This feature works for all types of backups, NOT only back-end backups.

Due to a default configuration error if you haven't set it up it will still try to connect to Pushbullet's server. Since you don't have an API token the connection fails and you get a warning. No harm done.

One file (Pushbullet/Connector.php) was listed with a 232 score, but the rest as 0. Again expected as there had been a change.

Perfectly expected.

Today's report (covering Thursday) show a further 46 files as modified and suspicious, all seemingly from Akeeba or libraries/f0f/... I HADN'T logged in at all on the Thursday and so am confused or concerned how these modifications might have happened.

You may have updated any of our software in the meantime. We did include a new version of the library with Akeeba Backup. Maybe you missed those files the first time you checked the scan logs?

I hope this is just because I am new still to Akeeba... but I prefer to check. I will re-post if necessary to Admin Tools support. And if necessary attach a zipped logfile.

No need. Everything you said is expected and nothing to worry about.

However the attempted notification to Safari happens whenever I log in to the backend, now. It didn't use to.

I think I need to explain some things again:

A. This feature (Desktop Notifications) is new in Akeeba Backup 4.2. This is why it "didn't use to" show you this popup: the old versions simply lacked this feature.

B. This feature (desktop notifications) only applies to back-end backups ONLY. It does NOT apply to the automated backups. Therefore whether you've set any scheduled (automated) backups or not is totally irrelevant. You are still confusing desktop notifications with push notifications. Please read my previous reply again a couple of times. Desktop = back-end backup, notification to your browser. Push = any kind of backup, notification to Pushbullet client application.

C. Desktop notifications are implemented via Javascript. Your browser asks you for permissions when it sees a piece of Javascript code asking it whether it's allowed to send desktop notifications. This is what you see. Your browser asking you if you want to allow Akeeba Backup to send you desktop notifications. The permission is granted per exact domain name. If you have multiple subdomains e.g. example.com, www.example.com, foo.example.com, bar.example.com, you'll see one permission popup per domain. Even if you access the same site through four different domains you'll see four different permission popups. The reason is that the permission is stored in your browser (NOT your site's database!) per domain name. And it goes without saying that if you use ten different browsers to access your site you'll see ten different popups, one per browser since the permissions are stored in the browser, by the browser itself.

D. As item C above implies, there is nothing on your site interfering with your browser in any way. When a back-end backup starts and stops the Javascript in your browser used to run the backup sends the following information to your browser:

• Message title (Backup started / Backup stopped)
• Icon image file to show (ignored by Safari!)
• Message content (the date and time of the backup starting/stopping)

The Desktop Notification API in Javascript is VERY strict and limited. This is by design, ensuring that it cannot be used to compromise your browser / computer.

So, as I already said, what happens is 100% straightforward, 100% expected and nothing to worry about. I don't know why you don't believe me. I wrote the code and I know how it works. If you don't want to believe me you're free to examine the code yourself and make sure I'm not lying and I'm not doing anything funny with your browser. That's why it's called open source software after all: since you can see the source code you don't need to blindly trust the developer, you can examine the code and decide if you want to trust the developer or not. I'm cool with that because I know that my code –which you can read and examine in any possible way– proves beyond any doubt that you can trust me :)

2) Further modified 46 files mostly Akeeba.

Based on the content of your question you have not read or at least have not fully understood the documentation of the PHP File Scanner feature. Please read it again. You'll see that you need to mark files as safe manually to stop them from appearing in the report. Nothing is changing on a daily basis. It is the same files being reported again and again, until you finally mark them as safe. Let me paste the relevant bit:

Marked Safe. All files with a non-zero threat score will appear on each and every scan as Suspicious. Obviously, you don't want to go through the tedious task of manually verifying files as described above for each and every scan. Marking a file as safe tells Admin Tools that this particular file, in its current state, is not suspicious and should not be reported again as suspicious unless it's modified. Unmarking the file (default) will report this file as suspicious during the next scan.

As you see in the documentation this is by design. I can explain why since the explanation was left out of the documentation to reduce complexity. Imagine being away for two days and a file is changed with potentially malicious content during your absence. If we did not show the changed file in every report you might have missed the report of that day you were absent and have no clue that there's a potentially malicious file on your server. That's about as useful for protection as a condom with a hole, if you don't mind my simile. So I chose to show you the files with a non-zero threat score (i.e. potentially malicious files) in every single scan until you do check their authenticity and mark them as safe per the documentation instructions.

Finally, please note that the differences shown for these files are against their last state before their modification, i.e. the previous version of Akeeba Backup. Yes, there are very few lines changes in these files. They are mostly documentation blocks, copyright headers and tiny bits of code.

Therefore I'll have to insist that nothing strange is going on your site after all :)

No problem :) As I said, it's open source for a reason. Even if you can't read the code, other people do. That's how the good reputation is built ;)