On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Part of the trouble in relying upon the name alone is that on many OS's
> (maybe all -- at least all the ones that matter for client side work) can
> have localhost overridden to mean other things.
>
>
The main issue I see is that it effectively breaks SOP. It's not reasonable
to expect a user to know what app is listening on what port whenever a
browser connects, or to ensure that only Battle.net could listen on 28866.


> ...



If I recall correctly, this is actually more of a thing for WebSockets.
>
> If my recollection is correct, Chrome already considers http://localhost
> or
> is it http://127.0.0.1 to be a secure origin in nature.  Thus, code which
> arises from a request to localhost is treated as running within a secure
> context, even if it is not wrapped in a TLS connection.  (You can run
> javascript and access APIs in such circumstances on localhost via HTTP when
> ordinarily Chrome would require HTTPS to enable that access.)
>
> However...  That doesn't help the web developer who is trying to access a
> WebSocket service on localhost.  While Chrome regards the localhost as a
> secure origin, WebSockets in Chrome (and every other mainstream browser?)
> require the connection to be a TLS wrapped one, regardless of whether or
> not it's from a secure origin.
>
> (I wonder if they even wrote a protocol handler for non-secure web
> sockets?  At the moment, it's Christmas and I'm being too lazy to look.)
>
>
If by non-secure websockets you mean ws://, then yes, and Chrome is lax
here in that it allows access to ws://localhost from https:// without
logging a Mixed Content warning (Firefox only allows ws://localhost from
http://).

I think the real issue is (anticipated) fallout of the move to HTTPS by
default, possibly along with the deprecation of Flash. I don't think
there's a clean solution for creating a socket from a website to an app on
the local machine, except maybe via WebRTC?


Mark
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to