-
-
Notifications
You must be signed in to change notification settings - Fork 385
✨ Feature Suggestion | HTTPS Everywhere: recommend enabling EASE mode / CSP warning for Firefox webextensions #1292
Comments
This will use a CSP header injection that may or may not work: depending on your other extensions. Since web extensions, when two or more extensions use CSP header injection, only one will win: meaning the other extension(s) will fail to work as designed some examples: some functions in : uBO, uMatrix, CanvasBlocker
|
Dawidpotocki mentioned that in team chat last night and I have two open questions about it:
https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions Edit: see also EFForg/https-everywhere#17735 via ghacks-user.js/664 ? |
I don't think so: but I'm not an expert on chromium. See https://bugzilla.mozilla.org/show_bug.cgi?id=1462989#c20 gorhill:
|
maybe we can add this with a trade off warning? I can see quite a few people not using umatrix, and i think most of what canvas blocker does can also be done by turning on resist fingerprinting. |
Perhaps you could make an argument for uMatrix and Canvas Blocker, but not uBO. Most people are using uBO and uBO should have priority with CSP. I do not want to encourage undefined behavior with seeing which add-on wins the race. This is especially true in the case with NoScript since it could compromise user security. |
How do you know which one wins then? I have uMatrix, uBlock O and HTTPS E, with EASE mode activated and uM on hard mode, if there's going to be a trade off warning then it should be explained a bit more on that, not simply, "One might win over the other, bye". |
There is no such simple answer as to which one wins. It depends on which order they were loaded by Firefox, and if an extension is updated, it is reloaded, potentially changing the order. Not to mention if a user toggles their extension on/off. Not everyone will get the same results, nor will their results always be consistent. To add to this mess, NoScript should win, because it uses a never ending loop of checking and retrying to make sure it does (just be glad no one else did this) Feel free to write up a simple explanation for first time users |
@Thorin-Oakenpants I have been thinking we might stop listing HTTPS-Everywhere or extensions like this and just instruct people to turn on Firefox 76 gets optional HTTPS-only mode (ghacks). What are your thoughts on this? It would allow us to also easily close https://github.com/privacytoolsIO/privacytools.io/issues/1326 |
No, https-only-mode is not ready. Maybe it could be ready for ESR78 edit: we were discussing it at |
ty, we will keep that in mind. |
Now that 78 is out have you any new thoughts on this? |
it's nowhere near being ready: still experimental. They only just landed the ability today to use the UI to allow site exceptions (permanent or session only) see arkenfox/user.js#1003 (comment) And then I'm not sure what happens with insecure downloads on secure sites (if you allow an exception and continue on) - I think downloads are treated as a separate item since they're user initiated - but IDK for sure: not deep dived it all (yet) Also, read this -> https://github.com/arkenfox/user.js/issues/1032#issuecomment-704479070 <-- that's my story/experience - i.e HTTPS-E is fast becoming redundant (but note that I don't allow mixed content: active and* passive) |
That was a concern is that if someone wanted to temporarily undo this setting, editing about:config is fiddly and annoying. Maybe for the time being we should continue to recommend https-everywhere (fortunately functional on Fenix builds). |
I was conducting research on HTTPS Only today, so: First off there is no supplied UI for users, at least for the latest stable FF. Recommending HTTPS Everywhere is the best option until stable Firefox has a built in UI for HTTPS Only. When HTTPS Only mode is enabled, only HTTPS connections are made on mixed content websites (from the testing I conducted via badssl.com), and non-HTTPS capable connections are simply dropped after attempting several times to connect via HTTPS. No data is sent via POST until the connection is secure, even after acknowledging the warning displayed to the user. I have not tested all cases (e.g: downloads), but it appears that HTTPS Only works well, with the exception of providing UIs. I could only recommend it as defense in depth for advanced users. With all of that said, I don't believe you should remove HTTPS Everywhere, especially if adversaries willing to serve you malicious payloads via intercepted non-secured HTTP traffic are part of your threat model. |
playing devils advocate: unless using EASE mode, HTTPS-E doesn't preclude that That said, it certainly can't hurt, and the internet has a long way to go, and a very long tail. So yeah, keep it listed. But I think once HTTPS-only mode is done, that it's a more efficient and effective solution - but you need to think of ESR users, so at the earliest, you can't do anything for a year ESR78 is EOL... next ESR is ESR91 and the old one lives for three releases in tandem (4 week cycles) .. so when FF94 lands in about Oct 2021, you can revisit it !remind me in 1 year :) |
Looks like this feature is now in stable Firefox with UI elements. https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ I think we could safely assume that it works stably now? We could put a note next to HTTPS-Everywhere that it is only necessary if you have an ESR version of Firefox, and link to that blog article as it is now a part of Firefox. |
Or you could wait a month and see what happens with the outstanding bugs now it has a UI in stable, and more people will use it. Generally, it should be pretty good to go, but why put some of your readers through hell if say for example, latestsocialmedia craze broke, or lots of times they hit the I see on reddit, lots of people were pointing out that they didn't know how to make an exception permanent - so it needs work IMO |
Agreed. It was just released to the public, and should be given some time before being recommended over HTTPS Everywhere. |
Also I don't see the option to do this on mobile, so I'm guessing this is desktop only for now so HTTPS Everywhere still should be listed for such platform for now. |
It looks like Arkenfox has enabled it. arkenfox/user.js@91cbc1e |
I happened to notice that I was accessing some sites, even ones that have HTTPS and even on Brave getting, over HTTP.
HTTPS Everywhere has opt-in mode Encrypt All Sites Eligible that seems useful that we could potentially recommend enabling?
The text was updated successfully, but these errors were encountered: