Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Fri, Jun 6, 2014 at 10:37 PM, Katharine Berry <katharine@getpebble.com>
wrote:


> A sizeable chunk of our developer community has never previously written
> code, and most likely would continue not writing code if they had to go
> through the somewhat painful toolchain setup process -- and we view getting
> them into development as a good thing! Those with significant experience
> (and not using Windows) do tend towards the locally installed solution.
> This effectively creates a filter where the people who want to use this are
> biased towards those who are *less* capable of fiddling with their
> computers.
>

That's a difficult audience to address. We want to protect the large number
of folks who aren't capable of fiddling with their computers, and need to
be careful about workarounds that target the subset of that group who also
have reasonable requirements for otherwise dangerous activity.

I also see it as a good thing to make coding more accessible to everyone;
my goal in this conversation is to find a way to open up your platform in a
way that doesn't also imply opening up folks' routers, etc. I think we can
do that.

RFC1918 simply defines their existence. The current versions of Firefox,
> Safari, Opera, Chrome (and Canary) and IE do not currently enforce any
> restrictions on this whatsoever (avoid conflating with the unrelated TLS
> issue). The code we currently have, which basically just opens a websocket
> to a private IP, works fine from a public origin. Given this, I don’t think
> it’s fair to say that “it wasn’t well-supported by the platform”. No
> existing specification or browser prohibits it.
>

Hrm. Ok, then I'm simply wrong. Based on some comments I've read, Opera
throws up interstitial for access to private IP ranges, and IE blocks
access based on security zones. If that's not the case, then I apologize
for suggesting that you should have known better.

Going forward, I'll simply argue that a historical ability to do X doesn't
imply that X is a thing that we should support as part of the web.


>
>  If not, I think it would be ideal to avoid breaking something that was
>> historically legal and has (at least what we believe to be) legitimate use
>> without providing any recourse.
>>
>
> With the caveat that I haven't given a lot of thought to the impacts, a
> CORS-like approach with a preflight request to a `/.well-known/...` URL
> sounds like a possible way of enabling these kinds of connections.
>
>
> A preflight request sounds reasonable (but what form would it take?).
>

I'd suggest something like a non-authenticated CORS preflight request to a
fixed URL that isn't likely to be responded to by existing devices (perhaps
`/.well-known/publicly-accessible`?). We'd need to extend the concept to
encompass the upgrade request, but that might be a reasonable thing to do
anyway.


> I do feel that there is some weirdness in changing tack from the previous
> position where all WebSocket servers were assumed to be written with CORS
> in mind, handle the Origin header, and therefore did not require
> browser-enforced restrictions. What concerns would the preflight request
> address that existing Origin mechanism does not?
>

`Origin` requires devices to opt-out of access from the public web by
checking the header and verifying it's validity. Given the generally lax
nature of security for devices that aren't meant to be exposed to the
public, I don't think that's a high-enough bar.

I'm suggesting that devices should instead opt-in by positively responding
to a "well-known" request.

-mike