Open Bug 1409841 Opened 8 years ago Updated 1 year ago

Consider devtools checkbox for Secure Context features

Categories

(DevTools :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: jkt, Unassigned)

References

(Blocks 2 open bugs)

Details

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.
Product: Developer Documentation → Firefox
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".
Blocks: dev-https-everything
No longer blocks: https-everything
This bug should also give developers the ability to remove isSecureContext from exempted domains like localhost etc.
See Also: → 1410369
Priority: -- → P3
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?
Product: Firefox → DevTools

I believe such option should only be available on nightly and on firefox developer version.
I've seen too many crazy things people who don't know what they are doing, disabling security stuff over and over again just to later come and complain they had a security breach they themselves created.

IMO,
Only people who know what they are doing should be able to do this kind of thing, for the most part, it's who downloads the Nightly version and the developer version.

Along with that, I am missing such feature in my day-to-day web development work and I am using a proxy to mitigate the limitation.

Anne, pinging you as we chatted last about this. Who would be a contact on the platform side to expose this as setting in DevTools?

As discussed, we would only offer this on Nightly and DevEdition, only working with DevTools is open (like the current Service Worker HTTP pref).

Open questions are how we name the option but also hpw we expose this in the right places, like when a SW fails to load because of HTTP or other secure context warnings triggered by DOM APIs.

Flags: needinfo?(annevk)

I'll leave the needinfo for Anne in case he wants to add something but this would probably need to be done by someone in Ethan's team. CC'ing a few folks in case there's interest.

Note that we're definitely stretched thin at the moment so I would assume this is more of a backlog-thing for us.

Flags: needinfo?(annevk)

Not to be "that guy," but I was just wondering what sort of timeline we might be looking at for resolving this? This issue has essentially led our team to take a "cross your fingers and hope for the best" approach with regard to Firefox support, because this issue is currently blocking us from testing in development.

The closed down bug 1464998 led me here. How is this coming along? I see the last post was from 6 months ago; this feature has been available in chrome for a couple years now, how is this not a feature in FF?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.