6 ms·
HTTPS Everywhere Version 5: Sixteen New Languages and Thousands of New Rules
- higherpurpose 12y ago> and support for "Block All HTTP Requests" in Chrome Great, I've been waiting for that (they call it "HTTP Nowhere" in the extension). Once it appears on the Firefox version, too, it should be automatically enabled in Tor.
- ToastyMallows 12y agoSecond this, great feature. I've been waiting for a fork of Chromium or Firefox that will refuse to load http links, although in retrospect an extension would work better for that anyway.
- deleted 12y ago[deleted]
- Syrup-tan 12y agoThere would have to be an exception for *.onion addresses in TBB, as they are already end-to-end encrypted over HTTP.
- jmgrosen 12y agoIt's already in the Firefox version. (At least, I have HTTPS Everywhere 5.0.1 and there is a "Block all HTTP requests" menu option.)
- DINKDINK 12y agoIf you're having a hard time finding the "Turn on HTTP Nowhere" option: In a normal tab, left click the HTTPS Everywhere icon in the top right of the browser and click the "Turn on HTTP Nowhere" checkbox.
- Karunamon 12y agoAnnoyingly, this results in an error rather than an attempt to redirect to the https version of the same site.
- cottonseed 12y agoHTTP Nowhere has an option to redirect.
- Karunamon 12y agoWhere? At least in the Chrome version, all you get is the single button settings UI, and there's no redirect option. Toggling the experimental rules has no effect.
- Teapot 12y agoHow about a 'Block all downgrade Redirects' feature. Many sites supports HTTPS but forces a downgrade redirect, 301 or 302, to http.
- JeremyBanks 12y agoHow would that work? If the site is sending you a redirect, then they aren't sending you the content.
- Animats 12y agoAll those "rules", centrally stored. "HTTPS Everywhere tries each rule in those rulesets against the full URL. If the Regular Expression, or regexp, in one of those rules matches, HTTPS Everywhere rewrites the URL according the the to attribute of the rule." Now there's an attack surface. If you can put a rewrite to a fake site into the EFF's database, what happens?
- extrapolate 12y agoGood point! It looks like all of the rules are here[1], so as long as there is oversight by the EFF, their repo isn't compromised, someone doesn't put out a fake build, etc., we should be safe. Also it looks like[2] some rules are built in such a way that only the protocol is changed and the domain is left as-is. [1] https://github.com/EFForg/https-everywhere/tree/master/src/chrome/content/rules https://github.com/EFForg/https-everywhere/tree/master/src/c... [2] https://github.com/EFForg/https-everywhere/blob/master/src/chrome/content/rules/Archive.org_Way_Back_Machine.xml#L18-L19 https://github.com/EFForg/https-everywhere/blob/master/src/c...
- schoen 12y agoHTTPS Everywhere has a few important precautions in place, and would welcome suggestions or code contributions for others. One of these is reproducibility of the package build, so you can check out the source tree, verify the signed tag, and build the same byte-for-byte identical XPI file that is being distributed from EFF's web site. (I just did this for the 5.0.1 XPI and the files were the same, although my colleague who made that release notes that there is a still-incompletely-documented dependency on the libsqlite3 version.) There are also scripts that indicate whether rules redirect to non-HTTPS targets and whether the rules contain non-ASCII characters (to avoid homoglyph attacks, like <rule from="^https?://www\.paypal\.com/" to="https://www.pаypаl.cοm/"> https://www.pаypаl.cοm/">). Because of the challenges of parsing PCRE with backreferences, there are no scripts that check whether the target domains are the same as the source domains (and there have been a small number of rules that did intentionally rewrite to a different domain). These do get read by human beings before being included in the project, and traditionally new rules are included for months in the development release before being migrated into the stable release, but it would be a great thing if more human beings would check them, or help develop scripts that do so in new ways. One idea that we've talked about in the past is to divide rules into simple and complex, and then single out only the complex rules for extra human auditing. (Simple rules would be syntactically constrained not to rewrite across domains.)
- rt897 12y agoDoesn't firefox already has the block HTTPs feature?
- jgome 12y agoIt bothers me that "HTTPS Everywhere" calls https://check.torproject.org https://check.torproject.org to check for tor: https://github.com/EFForg/https-everywhere/blob/master/src/components/ssl-observatory.js#L85 https://github.com/EFForg/https-everywhere/blob/master/src/c... I don't want my browsing calling random websites at any moment... whatever the reason for it. Can this be made optional, please? Also, slashdot (the desktop version) has problems with this browser extension :( Other than that, thank you very much for your great work, to everyone involved in the project :)
- middleclick 12y agoThis is for the SSL Observatory, a feature you can turn off and about which HTTPS Everywhere asks you at startup.
- amelius 12y agoCan't we just have encryption inside the TCP/IP stack?
- novaleaf 12y agoI had to disable Https Everywhere because it makes a lot of sites silently fail in various ways. (loading ajax) a bummer for sure, i like it in theory.
- tyho 12y agoI am suprised to see EFF using a tracking bug on that page: https://piwik.org/docs/tracking-api/ https://piwik.org/docs/tracking-api/
- mike_hearn 12y agoWhy? Would you be surprised if they outsourced hosting to Amazon or uploaded their Apache logs to some third party service? Outsourcing of website analytics is hardly some major evil.
- tyho 12y agoYes, and yes. This IS the EFF we are talking about. I didn't say it was a major evil, just that I was surprised that the EFF was using a tracking bug.