17 ms·

Why HTTPS Everywhere isn't on addons.mozilla.org

186 points by sinak 12y ago

mtmail 12y ago
Would addons.mozilla.org really have to store the private keys of the developers as the discussion on bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=999014 https://bugzilla.mozilla.org/show_bug.cgi?id=999014 (closed as 'invalid' 4 month ago) implies? How does the Chrome store do it?
- jessaustin 12y ago
  Only if that service intended to do some signing on the developers' behalf, which could make sense for cases like this in which app data would be updated more often than app code.
blcknight 12y ago
Old... but interesting, I guess. From the bug report: > We don't require update.rdf files to be signed when they're served over HTTPS, since HTTPS provides the same level of verification as an updateKey, and we don't see significant benefit to the additional level of verification. I'm kind of confused by that comment - Mozilla are saying that signing the software itself is somehow the same as serving it over HTTPS? Think about other software repositories. That's like saying serving Fedora packages over HTTPS is the same as signing the RPM's... it's not, and it's kind of an absurd thing to suggest. You can independently verify the signature of the RPM itself, offline, outside of the browser. I can't see how that could be considered anything but a significant benefit.
- fastball 12y ago
  I think the idea is that you don't need the extra security of signing, because if the file was served over HTTPS then you can be secure in the knowledge that it has not been modified. The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that.
  - throwawayaway 12y ago
    A MITM attack? What then? Seems you need signing then.
    - Iburinoc 12y ago
      Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
      - holdenk 12y ago
        So with the system of mirrors that is in place with distributing some open source software (e.g. debian, ubuntu, etc.) this is less true. A local mirror could selectively serve bad packages (and serve the correct packages to the verification bots).
        ckuehl 12y ago
        Debian has a pretty nice mirroring system. Not only are all packages signed, but the Release file (which includes checksums of package lists) is also signed, preventing a mirror from omitting packages. For repositories which receive security updates (say, wheezy-updates), the index is valid for only few days in the future, which helps to prevent mirrors from withholding security updates [1]. If a mirror isn't updated, the user is eventually warned during updates: > E: Release file for http://mirrors/debian/dists/wheezy-updates/Release http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied. It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this. [1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates/Release https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
        Xylakant 12y ago
        Actually, there's no requirement that .deb packages are signed. The system still provides a strong guarantee, because the releases file contains a list of checksums for each package, so it's impossible to tamper with the package, even though it's unsigned. However, if you manually download the package, all bets are off. RPMs are usually signed directly.
justcommenting 12y ago
and yet: https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/?src=search https://addons.mozilla.org/en-US/firefox/addon/privacy-badge... Given the inconsistency of EFF and Mozilla's "policy" on this issue, plausible context to what's written might include something like an inability to upstream HTTPSEverywhere into Firefox by default due to political pushback from large advertising sponsors of Mozilla. EFF certainly resolved these issues for PrivacyBadger, which nevertheless has problems of its own. Similarly, working with Mozilla to make AMO more secure for everyone by default seems like a pretty straightforward and desirable option for EFF. it's unclear why that hasn't happened here..and perhaps having useful code upstreamed into a larger project doesn't earn people enough credit and recognition. maybe we'll see a BetterAMOEverywhere extension that would enable EFF to integrate HTTPSEverywhere into AMO. ;-) Yet here we are in 2014 with HTTPSEverywhere not baked into Firefox by default default and a world in which non-techies can't even find what should be browser-integrated functionality in the same place they find most other extensions. Awesome. The effect for most users is not unlike the the sort of bikeshedding over GPL vs. BSD licenses that has kept so much of the internet in plaintext [0]. [0] as mentioned in phk's 'operation orchestra' talk
- edraferi 12y ago
  ...working with Mozilla to make AMO more secure for everyone by default seems like a pretty straightforward and desirable option for EFF. it's unclear why that hasn't happened here. The bug report [1] was closed as WONTFIX. Essentially, AMO is more worried about malicious updates by extension authors than hijacking of legitimate extensions: The "hijacking" we worry about is from the addon authors themselves: we review and OK a benign add-on and then it self-updates into malware or adware. This is not a hypothetical worry. The EFF isn't going to do that, obviously, but the number of entities we trust to that extent who cannot simply host on AMO is so small that we can't spare the coding resources to create an exception mechanism. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=999014 https://bugzilla.mozilla.org/show_bug.cgi?id=999014
  - justcommenting 12y ago
    to me, WONTFIX is just a signal that personal conversations with Mozilla devs as humans--or at least a more subtle understanding of why Mozilla's not budging--are that much more important as next steps. and i don't necessarily disagree with the technical merits of EFF's position, either. but what does it say about EFF if they don't feel the same way about PrivacyBadger being available through AMO? seems inconsistent, if we're to take the given rationale at face value. and more broadly, it seems clear that if EFF's goal is to maximize the number of people using HTTPSEverywhere, the status quo for providing access to their code is not optimal. i hope Mozilla/EFF will be able to work out a solution that increases the availability of HTTPSEverywhere's functionality.
johannh 12y ago
> AMO doesn't do any code signing for extensions, so they're only protected by HTTPS. As we saw with Heartbleed, SSL private keys can be compromised. I find it quite ironic that HTTPS Everywhere is arguing HTTPS is not safe enough to offer them a reasonable guarantee of integrity.
- kofalt 12y ago
  Shouldn't be terribly surprising: http://dayswithoutansslexploit.com http://dayswithoutansslexploit.com HTTPS might be better than getting a website in cleartext, but you'd have to be a madman to claim that HTTPS is safe, sane, or secure.
  - johannh 12y ago
    True, I'm not surprised at all. HTTPS Everywhere-like functionality should be integrated into browsers and not a downloadable extra, tricking people into feeling fully secured.
    - toomuchtodo 12y ago
      While not "everywhere"... Force SSL only: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Have site preloaded in Chrome: https://hstspreload.appspot.com https://hstspreload.appspot.com
      - mbrubeck 12y ago
        Firefox also has a built-in HSTS preload list, which I believe uses the Chrome list as one of its inputs: https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
- geofft 12y ago
  HTTPS is a lower bound of reasonable security, not an upper one. The argument for HTTPS _everywhere_ is that it's the smallest possible thing you can do to make yourself slightly secure. Would you find it ironic that someone selling combination locks for gym lockers wants a better lock on their storefront?
anonfunction 12y ago
> Once public key pinning lands in Firefox (supposedly scheduled to happen this summer) Since this was from April, I wonder what has happened since then? Has Firefox added public key pinning or the other option presented?
- reedloden 12y ago
  Yes, Firefox has supported public key pinning for a while now. You can check the latest status at https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
  - anonfunction 12y ago
    Thanks.
Steko 12y ago
"main reason I haven't put it in AMO yet is because AMO offers less security to users than EFF self-hosting it" Another pointless crusade. Aren't there many ways you could make it safer still? Wouldn't some of those be really dumb because they would prevent many people from accessing the add on? How many people are you making more secure? Close to no one because 98% of Firefox https everywhere users have some other add on from AMO. Weigh that against the many thousands more that might be experiencing the benefits of your add on if it were hosted where 99% of add ons people use are hosted.
- n09n 12y ago
  It's almost as if their priorities aren't the same as yours.
  - Steko 12y ago
    My priorities are completly irrelevant here, I've been a happy user of https everywhere since idk since I heard of it (years? idk). My criticism is that their own stated priority is being crippled by a self-imposed and arbitrary rule.
    - cbr 12y ago
      It looks to me like they're trying to use not being in AMO as leverage to get Mozilla to implement additional security features. If they said "we'd like these features, but we're ok being in AMO in the mean time" Mozilla would probably mostly ignore them, and these are generally useful features that should help others if developed.
- Confusion 12y ago
  Aren't there many ways you could make it safer still? None that are necessary and relevant for the plugin to be offered via AMO. Should we trial this medicine on humans? No, that's another pointless crusade. Aren't there many other ways you could make it safer still? Your argument applies to any requirement and thus to none. Weigh that against the many thousands more that might be experiencing the benefits "Many thousands more: of whom you don't know whether they are experiencing any benefits, because you don't know whether they are actually using the code you published, instead of a compromised variation.
zobzu 12y ago
Im all for signing stuff but: - amo wasnt affected by heartbleed - signatures arent foolproof either - HTTPS everywhere.. is supposed to advocate for TLS being safe ? So the criticism seems quite misguided in this case.
- Confusion 12y ago
  - amo wasnt affected by heartbleed If you only address issues that have already happened, you will never provide adequate protection. The point is to ensure sane behavior when AMO is affected by some exploit. - signatures arent foolproof either Yeah, and actually, why bother with HTTPS at all: it's not foolproof, is it? - HTTPS everywhere.. is supposed to advocate for TLS being safe ? No, it advocates for TLS being safe if used with HTTPS everywhere. So before you have HTTPS everywhere enabled, you need an additional measure.
  - zobzu 12y ago
    you contradicted yourself here - or voluntarily misunderstood the point.
joshAg 12y ago
> Why wasn't HTTPS Everywhere affected by Heartbleed? Because we sign updates with an offline signing key that EFF keeps on a dedicated airgapped machine. So even if SSL is totally broken, the integrity of updates is guaranteed. Yay! WHY IN THE WORLD AREN'T YOU USING AN HSM!?!?! If you're at the point where you feel the need for a dedicated airgapped machine to hold the signing key, then you are at the point where you need an HSM.
ck2 12y ago
You should be using the hsts policy list in firefox anyway. HTTPS everywhere has way too much overhead. There should be a built-in hsts editor.
passfree 12y ago
HTTPS is a good idea but it really doesn't work for me. I am one of those paranoid people who want full end-to-end SSL without exceptions. HTTPS Everywhere doesn't fill the bill. This is why the company I work for created PanicMode (https://chrome.google.com/webstore/detail/panic-mode/lamdafciglhnjofdfejeepoemldmblkb https://chrome.google.com/webstore/detail/panic-mode/lamdafc...). PanicMode is ridiculously simple extension. Once activated, it will swap HTTP for HTTPS without leaking even a single packet. Not even pre-flight requests are spared. PanicMode is not good for general purpose browsing mainly because 99% of the site break badly, i.e. they do not support SSL at all. That is very telling and sad reality. The way I use it is with profiles. I have a bunch of chrome profiles that I use for different purpose. One of my profiles is just for social browsing - facebook etc. I have another one for company stuff. Those profile have panic mode installed and activated. Because I care about security in those profiles I don't mind if I click on a facebook link and it doesn't open up because at least I know that I am protected against side-channel attacks. It is a very simple mechanism but works well when used effectively.
- goblin89 12y ago
  > PanicMode is ridiculously simple extension. Once activated, it will swap HTTP for HTTPS without leaking even a single packet. Not even pre-flight requests are spared. Sounds pretty cool and useful to me. As it tends to happen, though, all promises of additional security a Google Chrome extension makes are invalidated by a single notice— > Panic Mode can read and change all your data on the websites you visit As a side note, I noticed that lately my sensitivity to these kinds of threats has come down significantly due to multitude of useful extensions and apps requiring ridiculous permissions. Seems like a dangerous trend: not knowing that an app is going to do sneakily collect your data is one thing; knowingly and willingly grant every little extension wildcard access time after time is quite another. I was very happy to ditch Android because of that. Perhaps I’m too paranoid, of course.
- JetSpiegel 12y ago
  Looks interesting, but what's the purpose of the button? Also, any interest in porting it to Firefox?
joelthelion 12y ago
What a great way to make sure no one uses their add on. -- an HTTPS everywhere user
JBiserkov 12y ago
Even better, why HTTPS everywhere is not a default, in all browsers?
Animats 12y ago
HTTPS Everywhere is security theater. Encrypting everything creates pressure to cache encrypted content, using "caching services" such as Cloudflare. If it goes through Cloudflare, it's decrypted at Cloudflare. Cloudflare is a man-in-the-middle. HTTPS Everywhere means MITM Everywhere. It makes interception easier.

186 points by sinak 12y ago

Would addons.mozilla.org really have to store the private keys of the developers as the discussion on bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=999014 https://bugzilla.mozilla.org/show_bug.cgi?id=999014 (closed as 'invalid' 4 month ago) implies? How does the Chrome store do it?

jessaustin 12y ago
Only if that service intended to do some signing on the developers' behalf, which could make sense for cases like this in which app data would be updated more often than app code.

blcknight 12y ago

Old... but interesting, I guess. From the bug report: > We don't require update.rdf files to be signed when they're served over HTTPS, since HTTPS provides the same level of verification as an updateKey, and we don't see significant benefit to the additional level of verification. I'm kind of confused by that comment - Mozilla are saying that signing the software itself is somehow the same as serving it over HTTPS? Think about other software repositories. That's like saying serving Fedora packages over HTTPS is the same as signing the RPM's... it's not, and it's kind of an absurd thing to suggest. You can independently verify the signature of the RPM itself, offline, outside of the browser. I can't see how that could be considered anything but a significant benefit.

fastball 12y ago
I think the idea is that you don't need the extra security of signing, because if the file was served over HTTPS then you can be secure in the knowledge that it has not been modified. The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that.
- throwawayaway 12y ago
  A MITM attack? What then? Seems you need signing then.
  - Iburinoc 12y ago
    Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
    - holdenk 12y ago
      So with the system of mirrors that is in place with distributing some open source software (e.g. debian, ubuntu, etc.) this is less true. A local mirror could selectively serve bad packages (and serve the correct packages to the verification bots).
      - ckuehl 12y ago
        Debian has a pretty nice mirroring system. Not only are all packages signed, but the Release file (which includes checksums of package lists) is also signed, preventing a mirror from omitting packages. For repositories which receive security updates (say, wheezy-updates), the index is valid for only few days in the future, which helps to prevent mirrors from withholding security updates [1]. If a mirror isn't updated, the user is eventually warned during updates: > E: Release file for http://mirrors/debian/dists/wheezy-updates/Release http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied. It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this. [1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates/Release https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
        Xylakant 12y ago
        Actually, there's no requirement that .deb packages are signed. The system still provides a strong guarantee, because the releases file contains a list of checksums for each package, so it's impossible to tamper with the package, even though it's unsigned. However, if you manually download the package, all bets are off. RPMs are usually signed directly.

justcommenting 12y ago

and yet: https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/?src=search https://addons.mozilla.org/en-US/firefox/addon/privacy-badge... Given the inconsistency of EFF and Mozilla's "policy" on this issue, plausible context to what's written might include something like an inability to upstream HTTPSEverywhere into Firefox by default due to political pushback from large advertising sponsors of Mozilla. EFF certainly resolved these issues for PrivacyBadger, which nevertheless has problems of its own. Similarly, working with Mozilla to make AMO more secure for everyone by default seems like a pretty straightforward and desirable option for EFF. it's unclear why that hasn't happened here..and perhaps having useful code upstreamed into a larger project doesn't earn people enough credit and recognition. maybe we'll see a BetterAMOEverywhere extension that would enable EFF to integrate HTTPSEverywhere into AMO. ;-) Yet here we are in 2014 with HTTPSEverywhere not baked into Firefox by default default and a world in which non-techies can't even find what should be browser-integrated functionality in the same place they find most other extensions. Awesome. The effect for most users is not unlike the the sort of bikeshedding over GPL vs. BSD licenses that has kept so much of the internet in plaintext [0]. [0] as mentioned in phk's 'operation orchestra' talk

edraferi 12y ago
...working with Mozilla to make AMO more secure for everyone by default seems like a pretty straightforward and desirable option for EFF. it's unclear why that hasn't happened here. The bug report [1] was closed as WONTFIX. Essentially, AMO is more worried about malicious updates by extension authors than hijacking of legitimate extensions: The "hijacking" we worry about is from the addon authors themselves: we review and OK a benign add-on and then it self-updates into malware or adware. This is not a hypothetical worry. The EFF isn't going to do that, obviously, but the number of entities we trust to that extent who cannot simply host on AMO is so small that we can't spare the coding resources to create an exception mechanism. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=999014 https://bugzilla.mozilla.org/show_bug.cgi?id=999014
- justcommenting 12y ago
  to me, WONTFIX is just a signal that personal conversations with Mozilla devs as humans--or at least a more subtle understanding of why Mozilla's not budging--are that much more important as next steps. and i don't necessarily disagree with the technical merits of EFF's position, either. but what does it say about EFF if they don't feel the same way about PrivacyBadger being available through AMO? seems inconsistent, if we're to take the given rationale at face value. and more broadly, it seems clear that if EFF's goal is to maximize the number of people using HTTPSEverywhere, the status quo for providing access to their code is not optimal. i hope Mozilla/EFF will be able to work out a solution that increases the availability of HTTPSEverywhere's functionality.

johannh 12y ago

> AMO doesn't do any code signing for extensions, so they're only protected by HTTPS. As we saw with Heartbleed, SSL private keys can be compromised. I find it quite ironic that HTTPS Everywhere is arguing HTTPS is not safe enough to offer them a reasonable guarantee of integrity.

kofalt 12y ago
Shouldn't be terribly surprising: http://dayswithoutansslexploit.com http://dayswithoutansslexploit.com HTTPS might be better than getting a website in cleartext, but you'd have to be a madman to claim that HTTPS is safe, sane, or secure.
- johannh 12y ago
  True, I'm not surprised at all. HTTPS Everywhere-like functionality should be integrated into browsers and not a downloadable extra, tricking people into feeling fully secured.
  - toomuchtodo 12y ago
    While not "everywhere"... Force SSL only: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Have site preloaded in Chrome: https://hstspreload.appspot.com https://hstspreload.appspot.com
    - mbrubeck 12y ago
      Firefox also has a built-in HSTS preload list, which I believe uses the Chrome list as one of its inputs: https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
geofft 12y ago
HTTPS is a lower bound of reasonable security, not an upper one. The argument for HTTPS _everywhere_ is that it's the smallest possible thing you can do to make yourself slightly secure. Would you find it ironic that someone selling combination locks for gym lockers wants a better lock on their storefront?

anonfunction 12y ago

> Once public key pinning lands in Firefox (supposedly scheduled to happen this summer) Since this was from April, I wonder what has happened since then? Has Firefox added public key pinning or the other option presented?

reedloden 12y ago
Yes, Firefox has supported public key pinning for a while now. You can check the latest status at https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...
- anonfunction 12y ago
  Thanks.

Steko 12y ago

"main reason I haven't put it in AMO yet is because AMO offers less security to users than EFF self-hosting it" Another pointless crusade. Aren't there many ways you could make it safer still? Wouldn't some of those be really dumb because they would prevent many people from accessing the add on? How many people are you making more secure? Close to no one because 98% of Firefox https everywhere users have some other add on from AMO. Weigh that against the many thousands more that might be experiencing the benefits of your add on if it were hosted where 99% of add ons people use are hosted.

n09n 12y ago
It's almost as if their priorities aren't the same as yours.
- Steko 12y ago
  My priorities are completly irrelevant here, I've been a happy user of https everywhere since idk since I heard of it (years? idk). My criticism is that their own stated priority is being crippled by a self-imposed and arbitrary rule.
  - cbr 12y ago
    It looks to me like they're trying to use not being in AMO as leverage to get Mozilla to implement additional security features. If they said "we'd like these features, but we're ok being in AMO in the mean time" Mozilla would probably mostly ignore them, and these are generally useful features that should help others if developed.
Confusion 12y ago
Aren't there many ways you could make it safer still? None that are necessary and relevant for the plugin to be offered via AMO. Should we trial this medicine on humans? No, that's another pointless crusade. Aren't there many other ways you could make it safer still? Your argument applies to any requirement and thus to none. Weigh that against the many thousands more that might be experiencing the benefits "Many thousands more: of whom you don't know whether they are experiencing any benefits, because you don't know whether they are actually using the code you published, instead of a compromised variation.

zobzu 12y ago

Im all for signing stuff but: - amo wasnt affected by heartbleed - signatures arent foolproof either - HTTPS everywhere.. is supposed to advocate for TLS being safe ? So the criticism seems quite misguided in this case.

Confusion 12y ago
- amo wasnt affected by heartbleed If you only address issues that have already happened, you will never provide adequate protection. The point is to ensure sane behavior when AMO is affected by some exploit. - signatures arent foolproof either Yeah, and actually, why bother with HTTPS at all: it's not foolproof, is it? - HTTPS everywhere.. is supposed to advocate for TLS being safe ? No, it advocates for TLS being safe if used with HTTPS everywhere. So before you have HTTPS everywhere enabled, you need an additional measure.
- zobzu 12y ago
  you contradicted yourself here - or voluntarily misunderstood the point.

joshAg 12y ago

> Why wasn't HTTPS Everywhere affected by Heartbleed? Because we sign updates with an offline signing key that EFF keeps on a dedicated airgapped machine. So even if SSL is totally broken, the integrity of updates is guaranteed. Yay! WHY IN THE WORLD AREN'T YOU USING AN HSM!?!?! If you're at the point where you feel the need for a dedicated airgapped machine to hold the signing key, then you are at the point where you need an HSM.

ck2 12y ago

You should be using the hsts policy list in firefox anyway. HTTPS everywhere has way too much overhead. There should be a built-in hsts editor.

passfree 12y ago

HTTPS is a good idea but it really doesn't work for me. I am one of those paranoid people who want full end-to-end SSL without exceptions. HTTPS Everywhere doesn't fill the bill. This is why the company I work for created PanicMode (https://chrome.google.com/webstore/detail/panic-mode/lamdafciglhnjofdfejeepoemldmblkb https://chrome.google.com/webstore/detail/panic-mode/lamdafc...). PanicMode is ridiculously simple extension. Once activated, it will swap HTTP for HTTPS without leaking even a single packet. Not even pre-flight requests are spared. PanicMode is not good for general purpose browsing mainly because 99% of the site break badly, i.e. they do not support SSL at all. That is very telling and sad reality. The way I use it is with profiles. I have a bunch of chrome profiles that I use for different purpose. One of my profiles is just for social browsing - facebook etc. I have another one for company stuff. Those profile have panic mode installed and activated. Because I care about security in those profiles I don't mind if I click on a facebook link and it doesn't open up because at least I know that I am protected against side-channel attacks. It is a very simple mechanism but works well when used effectively.

goblin89 12y ago
> PanicMode is ridiculously simple extension. Once activated, it will swap HTTP for HTTPS without leaking even a single packet. Not even pre-flight requests are spared. Sounds pretty cool and useful to me. As it tends to happen, though, all promises of additional security a Google Chrome extension makes are invalidated by a single notice— > Panic Mode can read and change all your data on the websites you visit As a side note, I noticed that lately my sensitivity to these kinds of threats has come down significantly due to multitude of useful extensions and apps requiring ridiculous permissions. Seems like a dangerous trend: not knowing that an app is going to do sneakily collect your data is one thing; knowingly and willingly grant every little extension wildcard access time after time is quite another. I was very happy to ditch Android because of that. Perhaps I’m too paranoid, of course.
JetSpiegel 12y ago
Looks interesting, but what's the purpose of the button? Also, any interest in porting it to Firefox?

joelthelion 12y ago

What a great way to make sure no one uses their add on. -- an HTTPS everywhere user

JBiserkov 12y ago

Even better, why HTTPS everywhere is not a default, in all browsers?

Animats 12y ago

HTTPS Everywhere is security theater. Encrypting everything creates pressure to cache encrypted content, using "caching services" such as Cloudflare. If it goes through Cloudflare, it's decrypted at Cloudflare. Cloudflare is a man-in-the-middle. HTTPS Everywhere means MITM Everywhere. It makes interception easier.