{"action":"reopened","issue":{"url":"https://api.github.com/repos/canton7/SyncTrayzor/issues/39","labels_url":"https://api.github.com/repos/canton7/SyncTrayzor/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/canton7/SyncTrayzor/issues/39/comments","events_url":"https://api.github.com/repos/canton7/SyncTrayzor/issues/39/events","html_url":"https://github.com/canton7/SyncTrayzor/issues/39","id":63993188,"number":39,"title":"COMMENTS WANTED: Automatic Updates","user":{"login":"canton7","id":568104,"avatar_url":"https://avatars.githubusercontent.com/u/568104?v=3","gravatar_id":"","url":"https://api.github.com/users/canton7","html_url":"https://github.com/canton7","followers_url":"https://api.github.com/users/canton7/followers","following_url":"https://api.github.com/users/canton7/following{/other_user}","gists_url":"https://api.github.com/users/canton7/gists{/gist_id}","starred_url":"https://api.github.com/users/canton7/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/canton7/subscriptions","organizations_url":"https://api.github.com/users/canton7/orgs","repos_url":"https://api.github.com/users/canton7/repos","events_url":"https://api.github.com/users/canton7/events{/privacy}","received_events_url":"https://api.github.com/users/canton7/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/canton7/SyncTrayzor/labels/discussion","name":"discussion","color":"d4c5f9"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-03-24T13:21:25Z","updated_at":"2015-05-09T22:26:57Z","closed_at":null,"body":"Right, time for a braindump around auto-updates.\r\n\r\nThe current auto-update stretegy is effectively but fairly crude. On every startup / resume from sleep, we check the Github API to see if there's been a new release. If there has, we show the user the changelog and ask them if they want to upgrade now, later, or never. If they select 'now', we take them to the release page, where they can download the installer and run it. If they select 'later', we'll try again on the next startup / resume from sleep. If they select 'never', we'll skip this version.\r\n\r\nIdeally we want something a bit slicker. There are some thoughts:\r\n\r\nUAC Prompts\r\n-----------------\r\n\r\nDo we want to bring up a UAC prompt? If not, we have two options: either install into AppData, or run an update service (modelled on [Mozilla's Silent Update](https://wiki.mozilla.org/Windows_Service_Silent_Update)).\r\n\r\nI'm not a fan of installing into AppData. It:\r\n - Sidesteps UAC completely, which is a Bad Thing from a security point of view. Something malicious can pretend to by SyncTrayzor.\r\n - Prevents you from backup up AppData. You have to blacklist all applications which have snuck in there.\r\n\r\nHowever, an update service has some downsides as well:\r\n - Slightly fiddly to get working\r\n - I'd want to give people the option to not install this (think of portable users, too), but then we need two upgrade mechanisms....\r\n\r\nFor most people, a UAC prompt is a simple yes/no checkbox, and for the people for whom it isn't, they're probably either under the control of a sensible Sysadmin (who installed SyncTrayzor, and will be responsible for updating it) or they're paranoid and wouldn't like us \"bypassing\" it anyway.\r\n\r\nAnother consideration is that I already have an installer infrastructure in place - Inno Setup - and this gives me a lot of control to tweak/move/do custom stuff on installation. Users also already have stuff installed into `Program Files`, and I'm not keen to duplicate SyncTrayzor around their systems!\r\n\r\nPrompt the user?\r\n---------------------\r\n\r\nDo we prompt the user before installing an update, assuming we've automatically detected and downloaded it?\r\n\r\nOn the one hand, silent updates are nice. They force everyone into using the same version with zero effort. On the other hand, SyncTrayzor runs *all the time*. There's no chance for us to sneakily update when starting / stopping (as your browsers do). We could stop ourselves, update, start, and hope the user doesn't notice - but they might, and they'll be confused.\r\n\r\nNot prompting the user will require a UAC bypass - users panic if they get a random UAC prompt, as well they should.\r\n\r\nAnother option is to show a little tray notification (we can show arbitary stuff as toast from the tray) saying \"Hey, I've got a update, apply?\" with \"Yes\", \"Later\", and \"No\" buttons. The \"Yes\" button could have that little UAC sheild on it, so the user isn't surprised when they get a UAC prompt. \r\n\r\nThis is slick and avoids the \"What happened there\" factor, but we run the risk of being too similar to Java. Users might be conditioned to ignore update requests from the Tray, because Java does it constantly and annoys everyone. However, we could style it to be sufficiently different and friendly-looking....\r\n\r\nWhat to download?\r\n-----------------------\r\n\r\nAny of the approaches described above will require SyncTrayzor to download a new installer from Github. Hower, knowing *which* file to download is actually tricky, and the reason I link to the release announcement rather than the actual file. When moving from 64-bit-only to 64-bit/32-bit I needed to rename the files available for download. I may need to do the same again in the future for another reason. This means I can't simply rely on the download file's name being something pre-determined.\r\n\r\nOne solution might be to create a little service hosted elsewhere. SyncTrayzor goes \"Hey, I'm verison XXX on platform YYY - give me a new download link\", and it gets one. That would also allow us to control the upgrade path to a degree. However, it does rely on a bit of extra infrastructure to work, which is something I try and avoid if I can.\r\n\r\nSecurity\r\n----------\r\n\r\nIn any approach where we automatically download something and effectively promise the user that it's legit, we run the risk of being hijacked, and having some mailicious party abuse the user's trust in SyncTrayzor to sneak something nasty onto their system. This is particularly true for the installation service scenario, but also true if we're prompting the user to accept a UAC prompt.\r\n\r\nOne solution would be to sign the installer, then SyncTrayzor would verify that the key used to sign it is one that I own. This wouldn't require buying a cert from a root authority (although I'm not sure how Windows behaves if you ask it to install an exe signed with an unverifyable cert, as opposed to not signed at all) - we're verifying that it was signed by *me*, not by anyone trusted by a root authority.\r\n\r\nAnother approach would be to provide the signature separately to the exe, and download both.\r\n\r\nUpdate frequency\r\n----------------------\r\n\r\nI think it makes sense to move from \"check on startup\" to \"check regularly, starting a suitable period after logon\". When users turn on the computer, they normally want to do something. Upgrading random tools isn't one of those things. Prompting them when things are a big quieter would make sense.\r\n\r\nOf course, this only applies if we do prompt them. If we silently update, this isn't so much of an issue.\r\n\r\nUpgrading Syncthing\r\n--------------------------\r\n\r\nSyncthing currently auto-updates, which is why it's stored in AppData. I want to keep it auto-updating (I don't want to have to release a new version every week to match Syncthing's update schedule).\r\n\r\nHowever, I am uncomfortable with sticking it in AppData, for the same reasons that I don't want to put SyncTrayzor there. If we run an update service we can use it to silently let Syncthing auto-update as a privileged user, and keep it in `Program Files`. If we go with prompts, we can still prompt users to allow Syncthing to auto-update.\r\n\r\nPortable\r\n-----------\r\n\r\nThe portable users form about 1/4 of installed users, so we can't ignore them. How to handle updates for them? The current system works - we could just keep it.\r\n\r\nSummary\r\n-----------\r\n\r\nLet me know your thoughts! You're the people using SyncTrayzor, and I'll ultimately do what you want. Ping @jaredthirsk."}}