1399292 - add network.websocket.allowInsecureFromHTTPS as devtool option

Status: UNCONFIRMED

(DevTools :: Netmonitor, enhancement, P3)

Description

[post]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170826053331

Steps to reproduce:

connect to unsecure websocket from secure page with devtools open.


Actual results:

security warning


Expected results:

connect

Comment 1

[post]

Please add an option similar to "network.websocket.allowInsecureFromHTTPS" to be used when in dev mode / devtools.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I think we need the Options drop-down menu in the Network panel first.

Honza

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Harald do we want this now when we have the Settings menu?

Honza

Comment 4

[:Harald Kirschner :digitarald]

This would be applied to all tabs and even without DevTools open; so we probably want to be more considerate (as with other things in bug 1569964).

devtools.serviceWorkers.testing.enabled and devtools.cache.disabled all seem to map back to browser-context and not some browser-wide preference: https://searchfox.org/mozilla-central/rev/41c3ea3ee8eab9ce7b82932257cb80b703cbba67/devtools/shared/specs/targets/browsing-context.js#47

Comment 5

[:Harald Kirschner :digitarald]

It looks like we have 2 related prefs in play here, network.websocket.allowInsecureFromHTTPS (controlled by necko) but also security.mixed_content.block_active_content (controlled by security).

Johann, can you clarify if allow insecure websockets would part of a developer pref to circumvent 1) secure context, 2) mixed content, 3) generally disabling web security or 4) something different?

Comment 6

[Johann Hofmann [:johannh]]

That's a good question. It could be part of any of them 🙃. It depends on which you want to expose?

What I don't understand: there is a possibility to disable mixed content protection per site, though we were hoping remove that eventually. In the identity popup, click on the "Connection Secure" sub-item and disable protection. Does this mechanism not affect websockets? If not, then maybe we should fix that?

Relatedly, maybe we could move this entire mechanism to disable mixed content protection to devtools and remove it from our identity UI?

Comment 7

[Anne (:annevk)]

1. It seems dubious that mixed content WebSocket and blockable mixed content are controlled differently. They ought to be controlled by the same flag.
2. I was hoping that we could consider blockable mixed content an error and not have to go further than to explain the error to web developers. I.e., remove all UI and configuration around it.
3. Failing that, letting developer tools (when open) configure it seems reasonable. This might be a bit tricky with Mixed Content 2 where non-blockable mixed content will be automatically upgraded, but I guess we would not upgrade that either then. Developer tools should maybe be involved in the design of that to some extent to see how many options we need code-wise.

Comment 8

[:Harald Kirschner :digitarald]

I was hoping that we could consider blockable mixed content an error and not have to go further than to explain the error to web developers. I.e., remove all UI and configuration around it.

Would your assumption even apply for local testing? This is what bug 1569964 is focussed on. Use cases we see are non-HTTPS requests, secure context APIs, etc on local/staged projects on custom hosts.

Comment 9

[:Harald Kirschner :digitarald]

Relatedly, maybe we could move this entire mechanism to disable mixed content protection to devtools and remove it from our identity UI?

Happy to take that on in the tools, if testing is the only remaining use case we are seeing for this pref.

Comment 10

[Anne (:annevk)]

I think the correct long term approach for local testing is what I mentioned in bug 1220810 comment 44. Use localhost or *.localhost domains or get a proper domain name and a certificate. Until that bug is fixed that approach is hard to promote. And even if that bug is fixed it's not clear to me if that is sufficient and you may well be correct that at least in the short-to-medium term it would help a lot to have overrides available (with the appropriate mitigations in place, such as developer tools being open or only on Nightly/Dev).

I think I saw mixed content differently as you need something over HTTPS for that to even be an issue, but it is the scenario OP had and it might well be common enough to warrant addressing I guess.

Comment 11

[:Harald Kirschner :digitarald]

I think the correct long term approach for local testing is what I mentioned in bug 1220810 comment 44.

Was there some validation done that *.localhost is something a lot of developers do or that it is a long-term solution? If users would have the technical choice to just use localhost then there would be much less threads about disabling web security for local development. I have to dig a bit deeper to research what developers expext and where this is going.

I think I saw mixed content differently as you need something over HTTPS for that to even be an issue, but it is the scenario OP had and it might well be common enough to warrant addressing I guess.

That is true. CORS and Secure Context are probably higher on the list than mixed content.