You are here

Proposed Feature: Individual App Update Checks

15 posts / 0 new
Last post
John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 5 min ago
AdminDeveloperModerator
Joined: 2005-11-28 22:21
Proposed Feature: Individual App Update Checks

Hey gang. I'm considering implementing a new feature into the app launchers and wanted to get feedback and suggestions. The idea is to let the individual app launchers be able to check for updates of their apps independently of the PortableApps.com Platform. This would be designed for folks that use the apps outside the platform and would automatically be disabled when the launcher is used in conjunction with the platform.

The actual check would be much lighter weight than the PortableApps.com Platform's updater. Instead of a full 40K app database to download, it would just be downloading a single two line file for just that app that would just check the PackageVersion. And it wouldn't handle the download and automatic update to the app, which would introduce a ton of support headaches especially if a bug is found.

Here's how it would work. When a user launches, say, 7-Zip Portable directly without using the PortableApps.com Platform, the launcher will run a parallel process that will hit the PA.c web server and pull 7-Zip's version file. It would compare the PackageVersion within it to the PackageVersion of the app. If there is a new version, a message box would be displayed to the user saying that 'a new version of 7-Zip Portable is available, would you like to visit the app's homepage to download the update?' or similar. If the user clicks Yes, the browser is opened to the 7-Zip Portable homepage. If the user clicks No, a second messagebox would appear saying 'Would you like to be notified when updates to 7-Zip Portable are available?'. If the user clicks Yes, the parallel process exits. If the user clicks No, the parallel process will save the user's preference to a settings file within the Data directory and exit. The user would also be able to disable the update check without triggering it by manually setting an INI preference themselves. The check mechanism would just use the same settings Windows is already configured with (same as the PA.c Platform's automatic connection setting) and there would be no options to set proxies or anything like that to minimize code complexity and support. If the update check is unable to connect due to a Windows issue, software firewall, etc, it will just silently fail and exit without alerting the user.

The goal here is to ensure users know when updates are available for the apps they use even if they don't use the PortableApps.com Platform, particularly since security issues can come up and be exploited quickly. The example app we use here, 7-Zip, recently had an exploit like this which got me thinking about non-platform users. And I've got a plan on how to implement this on the server side so everything is fully cached and served to the checking launchers in about 500 bytes rather than pulling the full 40K app database or worrying about database hits.

So, I'm wondering what thoughts other folks have on this? Ideas, improvements, comments?

Thanks in advance for your input.

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 9 hours 12 min ago
DeveloperModerator
Joined: 2008-07-24 18:46
Useful

This sounds like an excellent idea, certainly useful for those users not utilizing the platform.

I don't have any further thoughts at this time, however will update if I think of anything.

Ken Herbert
Ken Herbert's picture
Offline
Last seen: 5 hours 45 min ago
DeveloperModerator
Joined: 2010-05-25 18:19
Sounds great

So the version info on the server that the Launcher will grab: I'm guessing this would be an endpoint that pulls the value out of the existing updater DB, to minimise your future effort applying updates and to minimise the number of places things can go wrong with a release?

the developer formerly known as winterblood

John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 5 min ago
AdminDeveloperModerator
Joined: 2005-11-28 22:21
Auto-Created

I'm doing a massive update behind the scenes to the app directory to allow automated creation of other resources. In addition to the full updater database INI which is then 7-zipped for consumption, I'll also have it create a series of small files, one per app, that just contain the PackageVersion of the current release. This would be built from the master updater database so there would be no additional files to maintain. The files would be as small as possible without requiring any kind of compression container necessitating a bundled helper app (so no 7zip requirement like with the updater). And all these files would be created as updates happen, static, and cached for maximum performance at each end.

Sometimes, the impossible can become possible, if you're awesome!

Ken Herbert
Ken Herbert's picture
Offline
Last seen: 5 hours 45 min ago
DeveloperModerator
Joined: 2010-05-25 18:19
Excellent

Sounds like you have it all in hand. That is better than a bit of code pulling from the main updater DB file with the benefits of it being static.

the developer formerly known as winterblood

Bart.S
Offline
Last seen: 1 month 3 weeks ago
Developer
Joined: 2008-07-23 07:56
Phoning home...

...on every app launch? No
So you know I've launched 7-Zip 10 times, Firefox 5 times, LibreOffice 15 times ... in the last hour?
Another reason to avoid PAL.

John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 5 min ago
AdminDeveloperModerator
Joined: 2005-11-28 22:21
Optional, All Launchers

It would be optional and could be disable via the INI as well as a likely system wide (or process wide) environment variable. And by 'phoning home' it's not like I could even implement tracking today anyway even if I wanted to. It would overwhelm our humble server. Hence the whole pre-generated static cached super-tiny files thing.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 4 months 3 weeks ago
Developer
Joined: 2006-12-29 23:48
Could it be opt-in instead of opt-out?

I understand what you're going for here, but even if you're not using it to track anybody, there are a lot of people out there who tend to freak out when a feature like this that 'phones home' is added.

My suggestion to deal with this is to make it an opt-in feature instead of an opt-out feature: e.g. first time you run AppNamePortable.exe it asks 'Would you like AppName Portable to check for updates?' and have options for 'Yes, Once', 'Yes, Always', 'No, Once' and 'No, Never' (or something like that) and if they choose the 'always', or 'never' options, save their preference, otherwise leave it undecided so next time it'll ask again.

~3D1T0R

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 9 hours 12 min ago
DeveloperModerator
Joined: 2008-07-24 18:46
Like, 2-button

I like this idea, although I propose using only two buttons, with a single checkbox, something along these lines: https://imgur.com/a/FhfLC

It would be possible to set this up using the nsDialogs plugin.

John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 5 min ago
AdminDeveloperModerator
Joined: 2005-11-28 22:21
After First Check

If it's opt-in, every app that does it will ask the user on first launch. If it's opt-out, the user will only have to make the decision when there's an update for the first time. As a large percentage of apps automatically check for updates by default with no prompt to the user until there is an update (the only exception I can think of being VLC which asks first), I'm fine letting those that worry about phoning home shut it off. I'm definitely not going the four option route where there's an option the user could be prompted on every single launch.

Keep in mind this is running a secondary process in parallel to launching the app handled by a small EXE that's separate from the main launcher.

Sometimes, the impossible can become possible, if you're awesome!

3D1T0R
3D1T0R's picture
Offline
Last seen: 4 months 3 weeks ago
Developer
Joined: 2006-12-29 23:48
I'm just trying to protect PA.c from potential backlash.

I understand your thoughts, however something you need to understand about the kind of people who make a deal out of the 'phoning home' issue, is that they're often more worried about the fact that they didn't know when the app started 'phoning home' than the fact that it's happening. I've seen this issue come up a number of times in other projects (which I was less involved with), and when the app has been 'phoning home' forever, there's usually only a few people who complain and a media outlet or two that write a little article about it, whereas an app that historically hasn't been 'phoning home' and starts, especially one with as large a user base as PA.c, will suddenly garner a bunch of bad press from people saying that 'it never used to', and 'I had no idea', totally blowing the issue out of proportion. By making it an opt-in feature, then most press about it will mention that it doesn't phone home without first asking for permission, and that can make all the difference between simply gaining some press and getting a bunch of unnecessary FUD among your users along with that press.

I'd hate to see PortableApps.com look bad in the media, especially over such an easily mitigated issue.

If you're worried about it asking too often, you could make it save the date of the last time it asked, and have it only ask if it hasn't been given a permanent answer, and hasn't asked in some time.

~3D1T0R

ottosykora
Offline
Last seen: 1 hour 30 min ago
Joined: 2007-10-11 17:48
causing traffic

I am not very keen of such mechanism.
We are using portable apps a lot on our sticks and we use them really portable, meaning also in operations when we have just very expensive and slow data connection. Something like 6.80 $ /MB

We are trying to block any automatic updates, windows updates blocked completely, other updates as well. If we now have additinal automatic updates without clearly defined target, it will just create extreme costs when such stick is inserted.

Otto Sykora
Basel, Switzerland

John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 5 min ago
AdminDeveloperModerator
Joined: 2005-11-28 22:21
Platform, Disabling, Update Size

If you use the PortableApps.com Platform, there will be no additional update checks and you can continue to disable automated update checks in the platform and only manually update when on a less expensive connection. If you don't use the PortableApps.com Platform and wish to disable these checks, you can. Even if you somehow forgot on a single app, as you see above, the update file will be under 500 bytes aka 1/2 a KB. Or about 1/3 of one penny on your extreme metered connection. And the user would be prompted to disable future update checks when they refuse.

Sometimes, the impossible can become possible, if you're awesome!

ottosykora
Offline
Last seen: 1 hour 30 min ago
Joined: 2007-10-11 17:48
still better opt in

I think such features should be just an option for those who want it , but should be disabled by default.
To go and check all programs for potential self-update being switched on gives rather a workload.
We already stopped to use the current platform, as someone playing could simply go for update there.
No, update feature being build into the individual programs and being on by default is almost a horror scenario.

Otherwise if all those contacts go to the same site, we could block this in our routers as well, but is this all going to the same point?

Otto Sykora
Basel, Switzerland

gmbudwrench
gmbudwrench's picture
Offline
Last seen: 2 hours 38 min ago
Joined: 2007-06-25 05:00
Sounds good

Sounds good because I run some apps right on my laptop without the platform. They have replaced some crudware applications that came preinstalled. I have a folder C;/portableapps so they install like usual, then I create a desktop icon.

Log in or register to post comments