Discussion about out-of-band ruleset updates

[jeremyn]

(@Hainish, @cowlicks:)

There's a code branch https://github.com/EFForg/https-everywhere/tree/sign-rulesets that is intended to allow ruleset updates out-of-band from regular version updates. The idea is that HTTPS Everywhere will request ruleset updates from a central EFF server periodically with the effect that rulesets will update from time to time without the version year.month.day changing.

Privacy Badger does something similar for a whitelist it uses. Recently there were some problems with the updates which lead to a frustrating experience for me, see EFForg/privacybadger#1466. After I understood what was happening, I argued against it, see for example EFForg/privacybadger#1466 (comment) and the related discussion.

I think this is also a bad idea for HTTPS Everywhere and I'd like to understand why this change is being made. I would at least like to avoid the user experience of things cycling between breaking and working for no apparent reason that I had with Privacy Badger.

I am not sure why do you ask to not update rulesets outside of extension update mechanism. The current update mechanism is secure enough to not be the weakest link. The weakest link is the browser extension update mechanism, since Chrome uses SHA-1 and Firefox uses both SHA-1 and MD5 (!!!) for extension update verification, while we use SHA-256. I guess this may be closed. Thanks for letting others hear your opinion though.

uBlock Origin and Privacy Badger both update their data out of the band, I am not sure if anyone sees this as a problem. Maybe the extension "phoning home" may be a concern, but that can be fixed by out of band updates being optional, regular extension updates still including the default ruleset library. This "phoning home" is also not a concern for Tor Browser users since Tor anonymizes the update downloading.

[jeremyn]

@koops76 My concerns aren't about the crypto, it's about the surrounding user and maintainer experience. You can read through EFForg/privacybadger#1466 to get an idea of what I mean.

In any case I would specifically like to hear from the EFF why they are doing this so I understand the motivation.

[Bisaloo]

@jeremyn, I know you are mainly waiting about the EFF answer but if I may chime in:

I understand and I agree with your concerns. On the other hand, separating the rulesets updates from the core updates has several upsides in my opinion, which would still make this change a positive move for our users.

Right now, when a ruleset fix is pushed on master, we have to either:

• rush an update because it concerns a high traffic website (Urgent: fix redirect loops for meta.*.stackexchange.com #9110)
• tell the users to wait a month for this change to reach them (and we know this is problematic because it's common to have reports saying "X is broken" when a fix has been pushed for weeks but hasn't been released yet)

In short, I think this could be a net gain depending on how frequent the rulesets updates would be. So I guess my follow-up question is: how often do you plan to push the rulesets updates @Hainish?

In any case, this change and this behaviour should be made very clear at different places (changelog, add-on description, FAQ, etc.) to alleviate some of the concerns raised by @jeremyn.

(As a broader point, I think it would be really helpful if you kept the community in the loop when you are making big changes like this one. Not necessarily to argue but at least to inform so we can prepare for what's coming. This was already an issue in #10538.)

[cschanaj]

So I guess my follow-up question is: how often do you plan to push the rulesets updates

AFAIK, we make a release every 2 weeks with exceptions when there is blocking PRs. The benefit of out of band updates is not obvious unless we are pushing much more frequent than that.

Unlike uBlock, HTTPSE and PB are privacy focused extensions. We should avoid phoning home while leaving the users unnoticed (as they are privacy/ security conscious). IMHO, out of band ruleset updates should be made on request (require user interactions) or on a opt-in basis.

Besides, we rarely make core code changes. @Hainish How often are we going to make core releases when we have out of band ruleset updates? We should make the (ruleset & core code) release policies clearly documented.

@jeremyn thanks for bringing this issue to the discussion!!

Unlike uBlock

uBlock Origin is a privacy focused extension, since blocking ads also decreases the amount of tracking and there are also lists (some enabled by default) specifically made to block trackers, even if they are not showing any ads.

Besides, we rarely make core code changes.

Exactly the reason why out-of-band ruleset database updates are desired.

IMHO, out of band ruleset updates should be made on request (require user interactions) or on a opt-in basis.

Privacy Badger already pings to EFF for updates and I'm not sure if it can be disabled. I guess this is OK since if the user does not trust EFF they would have not installed the extension. I'm not sure if the option should be opt-out, or opt-in, with the extension asking the user when first installed. Opt-out seems better since the user may close the tab the extension opens on startup without paying any attention to its content, resulting in them not getting the ruleset updates quickly.

[Hainish]

There are a number of reasons for out-of-band ruleset updates.

1. Lax security of AMO updates
   A year ago today, Ryan Duff posted about a vulnerability discovered accidentally in the way Mozilla does key pinning in Firefox. This would allow anyone granted a misissued certificate for addons.mozilla.org to update extensions arbitrarily. Given the broad permissions traditional extensions are granted, this is a serious issue that is mitigated in part with the XPCOM deprecation. But it's a troubling sign that the security of AMO was circumvented by pure happenstance, and does not engender confidence in the Mozilla addon update infrastructure.
2. Waiting for code review
   On the topic of AMO, we have in the past had to wait up to a couple of weeks before a new release is reviewed and published. In communication with Mozilla, we've been able to have them prioritize review, and this time span has shortened. But occasionally we'll observe that a new version will again be taking a long time for review. Of course, this is not a problem for the self-hosted version. But if there is a critical site that is in need of an update, the process of fixing it is made more difficult.
3. Reliance on AMO, Chrome Webstore, Opera Addons
   This is related to but not the same as the above. The release process is simply made more difficult and cumbersome by having to upload to the various browser addon stores every time a release is made. This is also the case for the self-hosted Firefox version, since a signature is required by Mozilla before posting. It makes the release process much more laborious.
4. Keys we control
   Given (1), Tor Browser is readying itself to disable the update channel for extensions.
   In order to ensure ruleset updates are reliably delivered, we have to move to an out-of-band delivery channel. With the sign-rulesets branch merged, updating the rulesets will be possible using keys that we control. This will rely on our own infrastructure and keys that are pinned in the extension itself.
5. Multiple update channels
   Moving in this direction also makes the extension more modular. With update_channels.js, we allow the extension to specify multiple update channels. This will facilitate, for example, an intranet to deliver another rulset bundle to its constituents without publicly divulging secret FQDNs. This will also allow the Tor Browser to deliver its own ruleset bundle, with its own pinned key, via HTTPS Everywhere. This possibility is powerful for the reasons Paul Syversion, Tor creator, describes in this whitepaper.
6. Possibility of granular updates in the future
   Currently, the rulesets comprise the vast majority of the extension download size. Of the 1.7M compressed xpi, a mere 421K is left to everything else - mostly translations. This means that delivery of the rulesets will be roughly equivalent to delivery of the extension itself, currently. But this transition opens up the possibility of delivering granular ruleset updates to extensions, which will vastly lower the total size of downloads in a unit time.

In the future we may also expose the update channel to users, so that they themselves can compile ruleset bundles. But this will require us weighing the costs and benefits of adding an additional maintenance burden.

[jeremyn]

@Hainish Thanks for the detailed response.

I would say that my concerns could be met by adding the following:

• Inform users of the auto-update mechanism and allow them to enable/disable it. The Observatory UI is an example of what this might look like.
• Allow users to reset the rulesets to the "stock" set that came with their current version of the add-on.
• Version the ruleset updates and display this version to the user somewhere.

Optionally:

• Publish information somewhere about the EFF infrastructure responsible for serving updates, to give confidence about its reliability. Maybe a status page/dashboard would be good here.

The motivations for all of these are, I hope, obvious, but I can elaborate if needed. None of these should interfere with the reasons you've given.

Also, to repeat, my experience with similar functionality in PB was that the update target (the whitelist) was repeatedly and quietly wiped. If we move to this update model for HTTPS Everywhere then I consider it a more-than-theoretical possibility that the rulesets could be similarly wiped or broken. The above items give users the ability to lock down or reset HTTPS Everywhere to a known-good version.

[Hainish]

@jeremyn

Also, to repeat, my experience with similar functionality in PB was that the update target (the whitelist) was repeatedly and quietly wiped. If we move to this update model for HTTPS Everywhere then I consider it a more-than-theoretical possibility that the rulesets could be similarly wiped or broken. The above items give users the ability to lock down or reset HTTPS Everywhere to a known-good version.

This bug was due to the fact that the whitelisted resources in Privacy Badger were not being verified before being applied. When the website had a bug, the whitelist would return a blank result. In this unfortunate edge-case, Privacy Badger happily applied this whitelist, thus causing the extension to malfunction.

This will not happen with the ruleset updates, since every ruleset update is cryptographically signed by the extension developers, then verified in each users' extension before being applied.

Given this, in what case would you envision the auto-update mechanism causing a fail case so large that we should expose extra options to the user? If privacy is the issue, we should keep in mind that already the users browser pings the extension store every day to check for new updates. EFF has a more stringent privacy policy than AMO or Google, so that shouldn't be a concern.

[Hainish]

This being said, I do think you're right in this:

Version the ruleset updates and display this version to the user somewhere.

[Hainish]

The ruleset updates will already have a timestamp associated with them, when applied. This is to keep track of whether we need to update the rulesets upon subsequent checks. We can simply use this timestamp, formatted as YYYY-MM-DD, as the version that is displayed to the user.

[jeremyn]

The problem isn't with a specific bug, it's about the process. It's like your criticism of Mozilla in "Lax security of AMO updates": a bug was found, Mozilla fixed it, but now you're uncomfortable with their update process. Same thing here, right? A bug in the EFF update process was found, the EFF fixed it, but now a reasonable person could be uncomfortable with the EFF's update process. This reasonable person should have the ability to disable or revert EFF updates.

For privacy, it's not about the privacy policy. It's about giving users control over outbound network requests and software updates. To quote myself from EFForg/privacybadger#1466 (comment):

...there is an endless list of software creators who want to build in quiet, uncontrollable update processes to their software. They always think they are justified. Users complain because they feel a loss of control over their system and because it causes unexpected breakage. This is no different. The EFF heavily criticized Microsoft for this sort of thing during the Windows 10 rollout.

[HTTPSNowhere]

@Hainish

There's still the issue of the need of a fallback mirror; For example, in China EFF infrastructure is blocked there, so people with HTTPS Everywhere installed there can't benefit from this feature. Is there anyway to add some fallback mirror to for example directly from Github (which is thankfully not blocked there)?