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

Hi Katharine, thanks for your feedback!

On Fri, Jun 6, 2014 at 7:13 AM, Katharine Berry <katharine@getpebble.com>
wrote:

> The key part here is that CloudPebble must be able to contact the
>  watch; hence, it must be able to communicate with the websocket server
> on the phone.


I don't understand this point: why do you need to be able to access the
watch/phone from a public website? This sounds very much like it would be
better suited to an application that's installed to the local machine,
perhaps as part of the SDK you're already requiring? If you spawn a web
server at 127.0.0.1:8080, then connecting to private IP addresses from a
page hosted there wouldn't be a problem.

Alternatively, you could use some of the platform features certain browsers
offer. Chrome apps and extensions(?) have access to Bluetooth and USB APIs,
for instance, which sound like they would suit your use-case well. I assume
Firefox offers similar capabilities.


> The current standards already effectively forbid this on the basis
> that a secure origin may not create a websocket to an insecure
> endpoint. This is enforced by Firefox and IE, but currently ignored by
> Chrome, Safari and Opera. Given that most of our users apparently use
> Chrome anyway, we have thus far mostly ignored the issue and not had
> any proper Firefox support (sorry Mozilla!).
>

I have bad news for you: Chrome considers this a bug, and we've fixed it.
https://codereview.chromium.org/222153002/ landed about a month ago,
meaning that mixed WebSockets will be blocked as of (I think) version 36.
There's been a deprecation warning on the console since at least Chrome 34.
Opera will likely follow suit, and (if they ask) we'd encourage Safari to
do the same.

There's a flag in
chrome://flags/#allow-insecure-websocket-from-https-origin to temporarily
reenable mixed WebSockets, but we're certainly going to remove that at some
point in the relatively near future.


> Firstly, to the best of my knowledge we cannot reasonably provide
> a valid certificate from our websocket servers, as explained above.
>

This should be resolvable. If the user already trusts Pebble to installing
applications on their computers, asking them to trust a Pebble-signed
certificate isn't a huge step.


> Secondly, the change being discussed here is explicitly designed to
> break this use-case. I do understand why this is a desirable change.
> However, it breaks our app and ruins an experience that currently
> works well for many of our developers.


The problem, as I'm sure you understand, is that it's very difficult to
differentiate "good" public->private connections from "bad" ones. My
suspicion is that the former group is vastly outweighed by the latter.

Zack's suggestion to have some sort of CORS-like preflight request makes
sense to me. There's some discussion of exactly that sort of capability in
the Network Service Discovery API spec (
https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html#dfn-preliminary-cors-check),
but I don't believe any user agents yet implement that capability.


> It was also, as far as I'm
> aware, legitimate functionality to have used up to this point.
>

The RFCs have been around forever; Chrome has done a bad job following
them. :/

-mike