Privacybadger: Merge Privacy Badger and HTTPS Everywhere into one?

[bcyphers]

It would be great if EFF had just one extension, giving users the best privacy + security we can offer all at once.

It would also be great to avoid issues like this: https://github.com/jparise/chrome-utm-stripper/issues/13, https://github.com/EFForg/privacybadger/issues/681#issuecomment-418866833

As we add more aggressive ways to block trackers in Privacy Badger, we'll probably want to start rewriting requests for a variety of reasons, and that will lead us to conflicts with HTTPSE (and other extensions -- but we can't control those). As it stands, PB will have to err on the conservative side, since blocking HTTPSE rewrites could have pretty awful consequences in certain situations. If we merged HTTPSE's functionality into PB, we could do TLS rewrites and anti-tracking rewrites all in one shot.

I have a hard time imagining anyone who uses PB today objecting to us adding in the features of HTTPSE. The other way around is probably different. We could start by creating a unified version of HTTPSE + PB that still goes by the name "Privacy Badger," and leave HTTPSE as its own thing. Down the road, we can make it easy for users of Privacy Badger 2.0 to turn off all the tracker-blocking features of the new extension, leaving just the https-rewrite portions working. Eventually, we might be able to phase out the separate HTTPSE extension altogether. Alternatively, since HTTPS Everywhere has more users, we can start adding features of PB to it on a totally opt-in basis. Either way, the goal would be to move towards a single EFF extension to protect users browsing the web.

Opening this for discussion: @ghostwords @jgillula @andresbase @Hainish @alexishancock. Any thoughts?

[jgillula]

Random thoughts in no particular order:

I definitely see this as the end-game for both browser extensions--I'm just not sure about the timeline. I'm thinking maybe we should see how it goes with our Android app first, to see if we learn any lessons there.

Also, it might be worth doing more cross-promotion first, to get more people used to the idea of having both extensions installed.

Regardless, it seems like in the end game we have another option Bennett didn't mention: create a new, separate extension that combines both, and continue to support all three extensions. (Or create a new extension, and deprecate the other two, and encourage people to switch.)

Either way, a major question is how we'll get people who are currently on one or the other to install the new one (or to install the other one).

Also worth considering: HTTPS Everywhere has a special place in Tor Browser, and we probably want to continue supporting it. So even if we merge, there might still be a need for a separate HTTPS Everywhere extension, unless Tor Browser is OK with us adding PB features.

I'm sure there's lots more to think about it--this is just what immediately springs to mind!

[ocdtrekkie]

I am specifically in favor of the behavior of Privacy Badger (a tool that reveals otherwise hidden website misbehavior), and specifically opposed to the behavior of HTTPS Everywhere (a tool that pushes Google's corporate agenda), so I'd be pretty annoyed with one suddenly starting to act as the other.

[Hainish]

Hey @ocdtrekkie, I don't mean to bring this off-topic, but I'd like to address your concern with the HTTPS Everywhere add-on if you're open to it. You can email me - [email protected].

[Hainish]

Here are some comments that I've made elsewhere:

I think this would be tricky. Privacy Badger can't be included in Tor Browser because the heuristics at play damage anonymity guarantees. Also Tor Project has kind of landed on not blocking trackers and ads and instead immunizing your browser from trackers by eliminating fingerprinting vectors. A change here would be a political decision I don't think we want to make for Tor.

I can see two possibilities short of combining the extensions. One is to use chrome.runtime.onMessageExternal to indicate to the user that the other extension is not installed, and by the way, would you like to install it? (this could be in the popup, for instance)

Another possibility is having Privacy Badger generate its own ruleset update channel (https://github.com/EFForg/https-everywhere/blob/master/docs/en_US/ruleset-update-channels.md) that redirects requests from trackers to an unroutable address, effectively blocking them. This wouldn't be using the heuristics, this would have to be for a predefined set of hosts / urls.

[ghost]

@ocdtrekkie How does it matter what Google's "corporate agenda" is when HTTPS demonstrably provides better security than HTTP? Just because Google wants or appears to want something does not automatically make it bad.

[zero77]

@Hainish

I think this would be tricky. Privacy Badger can't be included in Tor Browser because the heuristics at play damage anonymity guarantees. Also Tor Project has kind of landed on not blocking trackers and ads and instead immunizing your browser from trackers by eliminating fingerprinting vectors. A change here would be a political decision I don't think we want to make for Tor.

You make a good point but, why not combine the to but require users to enable the Privacy Badger part, and just leave the HTTPS Everywhere part enabled by default.

[pipboy96]

Personally, I'm 50/50, hence the +1 and -1 at the same time.

[colinje]

What if instead of an HTTPS list, you follow PB's learning approach and attempt https connections, and if it works, a local rule is added. From the performance stats I've seen of HTTPSE, having a smaller, local list could be better.

[pipboy96]

@colinje I will attempt implementing that in my fork and doing local tests on viability of this approach. Multiple factors should be taken into account, such as whether website itself makes such redirect and whether it is serving HSTS headers.