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

Let’s move away from the TLS discussion - it’s there, it has been for a long time, it’s not absolutely impossible to avoid (though no workaround really seems to offer anything much better than pseudo-security), and it’s probably not going away. It’s also not the topic of this thread.

On 6 Jun 2014, at 04:42, Mike West <mkwst@google.com> wrote:
> On Fri, Jun 6, 2014 at 11:14 AM, Katharine Berry <katharine@getpebble.com> wrote: 
> More generally, we can’t do USB (the device has no USB port), and bluetooth pairing with computers tends towards painful – especially since it requires repeatedly switching paired host for testing.
> 
> The phone has USB though. Rather than routing requests through a WebSocket server on the phone, you could poke at the app via USB in some vague, hand-wavey way (I know next to nothing about the APIs offered via https://developer.chrome.com/apps/app_usb; I just know that they exist).

I suspect that this isn’t a viable option; Apple doesn’t tend to like unauthenticated devices talking over USB (see: MFi). We would also really like to keep the wireless solution and, ideally, work cross-browser (despite our historically poor performance we do actually fully support Chrome, Firefox, Safari and Opera at the moment).

> Again, we are trying to offer a seamless experience as much as possible.
> 
> Understood, but remember that seamless developer experience can't be an overriding concern. When defining the security parameters within which user agents operate, developers are a) a vanishingly small group, and b) the single group that's _best capable_ of finding their own workarounds that change the default behaviors (installing local proxy servers, for instance).

Your definition of “developer” features a vastly more capable person than what we experience in practice. :)

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.

> I was specifically referring to the public->private connections; I’m aware that the the TLS->non-TLS connections have been banned forever. If something has actually called public->private websockets out as being illegal I haven’t run across them previously – have they?
> 
> Probably not WebSockets in particular, but RFC1918 defined private networks in the mid 90's. User agents like IE and Opera ran with those definitions to block access to private networks from public networks. The fact that none of this worked in browsers like Firefox or IE probably suggested to you that it wasn't well-supported by the platform. :)

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.

> 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 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?

– Katharine