W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

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

From: Chris Palmer <palmer@google.com>
Date: Wed, 11 Jun 2014 10:58:21 -0700
Message-ID: <CAOuvq23djX7zqC879mY7g_4hc3uF0bfX6s=EkjHtxdw67gQueA@mail.gmail.com>
To: Katharine Berry <katharine@getpebble.com>
Cc: Mike West <mkwst@google.com>, Zack Weinberg <zackw@cmu.edu>, Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 11, 2014 at 5:32 AM, Katharine Berry
<katharine@getpebble.com> wrote:

> As a minor addendum, I would like to step back from “developers”; this
> use case is more broadly something like “webapp on a public site would
> like to configure a user’s private, network-accessible devices.”

The generalization of your developer use-case to an
internet-of-private-things-controlled-by-public-code use-case is not a
good idea.

We are currently in the process of every Tweetdeck user having their
account hijacked (https://twitter.com/Tom/status/476766568102113280);
CSRF of wifi APs is still endemic; and so on. It should definitely
remain difficult for public web sites/code to contact private service
endpoints. Especially, but not only, because the commodity service
endpoints are (in general) extremely poorly implemented and
essentially never updated. I really don't want my fire alarm to be
permanently Tweetdecked when BoingBoing.net gets hijacked for 15
minutes.

(Random citation:
http://www.cnet.com/news/top-wi-fi-routers-easy-to-hack-says-study/)

In general, I expect client-side platform vendors, including Chrome,
to increasingly enforce the public/private boundary. Not to relax it.

> > Manually installing a certificate that Pebble provides seems like the
> > right solution for the TLS side of the problem. That was rejected as
> > being too much work for the developer. Personally, I'd prefer that we
> > reevaluate that objection.
>
> I’m not actually rejecting it as “too much work” so much as some
> combination of “they probably can’t do it” on their side and
> “demanding this is embarrassing” on ours. At least anecdotally, I have
> seen (proportionally) many users struggle with certificate
> installation in an environment where an organisational root CA was
> used universally, and few succeed.

If there are usability problems in our certificate import UX (and,
there surely are), they are bugs that we (Chrome, IE, Firefox, et al.)
should fix.

And, I don't see that it necessarily should be embarrassing for Pebble
to say, "Install this certificate to establish a secure relationship
between your computer and your cool new watch. Here's how: ..."
Received on Thursday, 12 June 2014 09:30:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC