intika / Librefox

Librefox: Firefox with privacy enhancements
https://librefox.org
Mozilla Public License 2.0
1.72k stars 89 forks source link

Why "Unrecommended HTTPS-Everywhere" ? #23

Closed Kcchouette closed 5 years ago

Kcchouette commented 5 years ago

Hello Can I know why do you say in your README: "unrecommended https-everywhere"? You should instead recommend it, no? Thank you

Atavic commented 5 years ago

I use the webext smart https revived: https://addons.mozilla.org/en-US/firefox/addon/smart-https-revived/ https://mybrowseraddon.com/smart-https.html https://github.com/ilGur1132/Smart-HTTPS

It is much simpler: a user's click avoids the load of thousand of rules, as in https everywhere.

Marc05 commented 5 years ago

@Atavic HTTPS Everywhere supports complex redirects, whereas other extensions like Smart HTTPS don’t. Hence, a site that supports HTTPS through a sub domain at secure.example.com but not at example.com can still work.

dimqua commented 5 years ago

@Marc05 yes, but only if this site is supported by HTTPS Everywhere.

Atavic commented 5 years ago

For me it is too heavy, YMMV.

Thorin-Oakenpants commented 5 years ago

IMO, there is nothing "smart" about Smart HTTPS. It's just a blanket "upgrade everything to secure" approach. In addition to what @Marc05 said, I suggest reading https://www.eff.org/deeplinks/2018/12/how-https-everywhere-keeps-protecting-users-increasingly-encrypted-web to get a better picture of what HTTPS-E actually does

As for Smart HTTPS (I haven't looked at in a long long while), it also stores persistent local data in the form of whitelists (mind you, lots of extensions do that, eg all your uMatrix rules) and connection information to speed up subsequent visits - granted, it's a computer forensics/hacked issued, not a web browsing one. I just find it ironic that no one complains, but some people get all bitter and twisted over HSTS information stored in SiteSecurityServiceState.txt :)

Anyway, just my two cents

intika commented 5 years ago

Here is why HTTPS-Everywhere is unrecommended in Librefox:

  1. Back when i reviewed HsE it did not block HTTP request every where, as the name could suggest, now it does over the settings (but not by default).

  2. It does not work for unknown site by default (site that are not in HsE data base) and there are a lot of them.

  3. The extension have way too much authorizations than what it needs (for its purpose).

  4. Its code makes it a huge resources eater, how web extensions works to monitor/filter traffic is in itself a resources eater method, try browsing an hour or two without it you will notice a huge difference in speed.

  5. The extension is sized 1.7 Mo (compressed).

  6. The extension connect to its own server for regular updates.

  7. Any simple JS script that would just check if httpS request version exist and then redirect the connection to it would never exceed 5kb and would not need a database nor a remote connection (HsE is kind a broken by design).

intika commented 5 years ago

I am planning to do something for this issue on future release because NoHTTP needs too much interaction in its current state

Marc05 commented 5 years ago

I understand where you’re coming from @intika. I had removed this extension for some time for the same reasons, but I now have it installed again so I’d like to discuss why.

  1. Outright blocking HTTP by default at this point would likely mean slower adoption given that it would no longer be a set-and-forget extension which is what I’d wager a significant portion of the userbase does. Having it opt-in is the way to go, though perhaps it’d be beneficial to prompt the user to enable this after installing it.

  2. I think this point is covered by the 1st.

  3. The permissions listed on AMO seem reasonable to me as they seem to be essentially the same for other similar extensions. But I haven’t looked that closely to it, and perhaps you’ve noticed something I haven’t.

  4. I’d like to see some benchmarks on this. It would be interesting. However, I’d wager that the performance loss is not significant enough to disregard the security benefits of the extension which are outlined in the article @Thorin-Oakenpants mentioned.

  5. Same reasons as above for this point. Perhaps the code could be refactored or other efficiencies taken. Maybe you could help? ;)

  6. I don’t think this is an issue given ease of use and practicality. If it were an issue, we’d have to apply the same logic to uBlock Origin.

  7. This point essentially summarizes the previous ones, so see my respective responses.

dimqua commented 5 years ago

a set-and-forget extension which is what I’d wager a significant portion of the userbase does

Right, but it does not mean that this type of extensions are better for others, and do their job better in general.

we’d have to apply the same logic to uBlock Origin

Yes, but uBO is useful even without third-party filterlists.

Marc05 commented 5 years ago

Fair enough. I still think it’s worth including and possibly enabling the block HTTP option by default.

As for the uBO point, a browser is useful even without internet :p

elypter commented 5 years ago

but some people get all bitter and twisted over HSTS information stored in SiteSecurityServiceState.txt

the problem with stored hsts information is that a website can detect the redirect and thus determine its state. if you do this with 20 subdomains you can store 20 bits of information. hence why it is possible to use it as a super cookie.

intika commented 5 years ago

Extensions recommendation will be dropped any way on next release only Librefox extensions will be kept, most of the security/privacy thing will be grouped on a single extension... then the user will choose what to install... the main important scope here is the next version to make Librefox evolves as a browser.