wireguard inclusion policy violation (auto-updates w/o explicit user consent)
-
- View options
Per https://f-droid.org/en/docs/Inclusion_Policy/
The software must not download additional executable binary files (e.g. addons, auto-updates, etc.) without explicit user consent. Consent means it needs to be opt-in (it must not be harder to decline than to accept or presented in a way users are likely to press accept without reading) and structured in a way that clearly explains to users that they’re choosing to bypass F-Droid’s checks if they activate it.
The screenshot below shows the message "An application update is available. Please update now.", which does not comply with the inclusion policy as specified above.
IMO it makes little sense for the APK installed via F-Droid to self-update, so I would be in favour of not having the update check; unfortunately detecting it's installed from F-Droid is essentially impossible, and with RB upstream would need to provide an APK without the update check, so adding the required explicit user consent seems like the best choice here. I am of course open to better suggestions.
Also: I think the string resource updater_avalable should be updater_available? :)
screenshot
Attributes
Status
Assignees
Labels
Parent
Weight
Milestone
Iteration
Dates
Start: None
Due: None
Health status
Time tracking
Activity
You cannot meaningfully consent to getting updates directly from the upstream developer(s) if you are not informed that is what happens when you press the button. And when installing apps from F-Droid, the reasonable assumption is that updates will be provided by F-Droid, unless one explicitly chooses to get them elsewhere.
But regardless of how you or I define "consent" in general, our inclusion policy is quite clear on what we mean by "explicit user consent" and that merely providing a button clearly does not meet our criteria.
Please note that we made an explicit exception for automatic updaters to accommodate developers like you: until recently any downloading of additional executable binary files was simply prohibited.
In addition, if the updater connects to your servers without asking the user to opt in, the app probably qualifies for the tracking anti-feature.
We would be happy to resolve this issue with you, to find the best way for wireguard to comply with our inclusion criteria, to make sure wireguard users that installed the app from F-Droid are informed and able to meaningfully consent to getting updates from you directly, without adding more friction than necessary to achieve that goal.
And we would be happy to help find the best UI/UX and wording for the required opt-in, or consider alternative solutions that meet our criteria. Sadly, as mentioned, detecting whether the app is installed from F-Droid -- to e.g. disable the updater or only show an extended opt-in message in that case -- does not seem to be something that is possible to do reliably, but we are happy to explore all possibilities to resolve this.
However, if you insist that your users do not need to be informed as required by our inclusion policy you are or course free to request removal of your app from F-Droid instead. This is of course not the outcome any of us desire.
All that's required for "explicit user consent" is that users are clearly informed where they're getting updates from and explicitly choose to bypass F-Droid. That should not require much more than a simple addition to the existing message to make it clear where the update comes from and that is was not reviewed by anyone else. You don't need to explicitly mention F-Droid if you'd prefer not to. We're happy to help consider appropriate wording you'd be okay with.
I hadn't realized that the update wasn't through f-droid, so I pressed 'Download & Update'. I cancelled the installation and wireguard reported 'Update failure: Ignored by user. Will retry momentarily...'. Then I got stuck in a loop where wireguard kept downloading the update and I cancelled the installation. The only way out was to uninstall wireguard and install it again from f-droid.
- Edited by Licaon_Kter
If that's still a problem for you, just remove wireguard from fdroid.
Not sure what's going on here exactly, I mean you've worked to get it into F-Droid, reproducible, even more to be the first (and only?) VPN app to be repro.
I thought F-Droid contribs helped (or at least not hindered your efforts lol) and while you threaded carefully around Play's opaque requirements, with emails and hopes, all you can say to F-Droid is "f-it, burn it all down"? Really?
😕
Not sure what's going on here exactly, I mean you've worked to
Indeed I've put a lot of work into F-Droid. A while back I dove head first into F-Droid with a few goals, two of which were 1) improve what I could and 2) assess the health, security, stability, and long term viability of the project.
The conclusion I came to was that F-Droid is basically rotted and requires changes from the leadership on down to get back on good footing. I don't feel good about the ability of the F-Droid project to deliver updates of apps, not have its build infra hacked, stay updated with a good pace of development, attract new contributors, or even exist in the next N years. Since WireGuard is an app that must have a reliable means of staying updated, my conclusion about F-Droid led me to an obvious conclusion about WireGuard in F-Droid, which is that I should treat it the same way as I would somebody downloading an APK directly from wireguard.com. In other words, I don't find it wise to rely on F-Droid to do anything at all, especially because doing so means its dysfunctionality holds my app users hostage.
So, having reached that conclusion, I immediately got to work on removing any path dependence or user reliance on F-Droid for anything at all. I wrote an updater, stood up infrastructure for it, got an HSM situated for it, set up direct APK downloads from wireguard.com, and then announced this on the mailing list, stating that "the new direct APK download and the Play Store are the only two supported installation sources." All mentions of F-Droid were removed from wireguard.com and various README files as well. This was back in May. Since then, I would imagine nearly all F-Droid users have updated to a WireGuard install that has the updater in it, making this initiative successful in removing any F-Droid dependency.
So, if you want to continue mirroring the APKs that I ship on download.wireguard.com, that's fine. If you don't want to mirror those APKs, you can remove WireGuard from F-Droid without a problem - the app's users have a path forward now regardless.
removing any path dependence or user reliance on F-Droid for anything at all
What you did is not removing path dependence, but providing less choices to your users by violating the policy of F-Droid explicitly and deliberately.
or even exist in the next N years
You don't worry that Google Play stops supporting a phone in the next N years, which is ironic.
@zx2c4 I'd suggest to make the update checker opt-in (i.e. disabled by default). That should be easy to accomplish, and would solve the issue. If you insist, you can have a popup at first start to prompt whether the user wants to check for and retrieve updates from your site (make clear that those updates do not come via F-Droid, so our checks are bypassed) – or integrate that with the onboarding activity if you have one. Then give the option in settings to toggle that should one re-decide – and everyone is happy.
As you see by the example given above, not everyone is aware that this kind of update does not come from F-Droid – and when noticing even go through uninstall and re-install to rectify the mistake. That's not how it should be.
As Fay wrote, it's of course up to you to request removal. But would you really want to do that just because of an option where you could simply toggle the default? Do you think you'd do the community a favor with that? I guess many would be disappointed. And how would that look, requesting removal because of a security feature you don't like
😉