Open Bug 1409841 Opened 2 years ago Updated Last year
Consider devtools checkbox for Secure Context features
To assist developers when more features are removed/implemented behind secure context we should allow them to assume that the page is secure. We could consider renaming "Enable Service Workers over HTTP" to "Enable Powerful Features over HTTP" or similar wording and change how that works. I hear reports of developers that find HTTP easier to prototype on, which makes changes in Firefox to secure contexts harder for them as we make more of them.
Adding :annevk to the cc. I hear you are going to be working on Secure Context stuff, so wanted to bring awareness of this and also the https-everything meta bug.
How do you want to prevent Oil and Gas International coming up with things like: "To work around the Firefox bug that makes this page insecure/prevents this page from working, press F12 and check 'Enable Powerful Features over HTTP'" I'm sure there are ways to make this unattractive, such as clearing this setting on tab close/reload/session end, I just wanted to mention it.
(In reply to Johann Hofmann [:johannh] from comment #2) > How do you want to prevent Oil and Gas International coming up with things like: > "To work around the Firefox bug that makes this page insecure/prevents this page from working, press F12 and check 'Enable Powerful Features over HTTP'" :'D You could restrict this feature to: http://test http://example http://localhost http://local (and subdomains) http://127.*.*.* http://[::1] http://192.168.*.* (and 172.16.0.0 – 172.31.255.255 ?) http://10.*.*.* http://[fd00::] https://tools.ietf.org/html/rfc2606#section-2 https://en.wikipedia.org/wiki/.local https://en.wikipedia.org/wiki/Private_network https://en.wikipedia.org/wiki/Unique_local_address > I'm sure there are ways to make this unattractive, such as clearing this setting on tab close/reload/session end, I just wanted to mention it. +1
This is related to bug 1039678, which discusses the --disable-web-security startup flag Chrome offers for bypassing various security checks.
See Also: → 1039678
Johann, I'm of the opinion we should not have developer tools in release (stable) builds. Having said that, when this is in use we should also consider clearly indicating in the UI that this is not secure.
> I'm of the opinion we should not have developer tools in release (stable) builds I think there is a bug for this already right? Even just to make it off by default etc. > clearly indicating in the UI that this is not secure. Agree yeah, I think it likely should keep the same restriction of needing the inspector open too which will reduce the appeal for websites to say "Keep x open whilst using our whole site".
This bug should also give developers the ability to remove isSecureContext from exempted domains like localhost etc.
Is the intended use case of this request solely for development? Or is it also intended to address the use case of a private production server on a home LAN, such as the router or printer use case described in "Deprecating Non-Secure HTTP Frequently Asked Questions", or another service discovered through multicast DNS? https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf If FQDN-less production servers on a private network are not in scope, then for the benefit of others reading comments to this bug, what bug does discuss this case?
You need to log in before you can comment on or make changes to this bug.