On Mon, Jan 4, 2016 at 8:11 PM, Chris Palmer <palmer@google.com> wrote:
> Often: http://goat.com wants to contact http://192.168.0.1. Allow?
>
> Sometimes: http://goat.com wants to contact http://[hargbargleipv6wumble-geeeee:%^/??::)]:8080.
> Allow?
>
> Once in a blue moon: https://pebble.com wants to contact
> http://watch.localdomain. Allow?
>
I was thinking something more like "https://pebble.com/ wants to access
resources on your internal network." rather than an origin->origin mapping.
That seems like the right granularity for the user-side of this kind of
decision, assuming that the devices themselves have to opt-in as well.
> I'm dubious about the comprehensibility of IP addresses, especially IPv6
> addresses. One can easily imagine simplifying the origin representation (as
> we advocate here:
> https://www.chromium.org/Home/chromium-security/enamel#TOC-Presenting-Origins),
> but IP addresses will always look "syntaxy" and baffling. In a Yes/No
> permission 'dialog' context, muscle memory is likely to kick in where
> understanding is missing.
>
> So, how often does the Pebble-like scenario happen in practice? We'll be
> able to get telemetry in the abstract, but Chrome at least does not measure
> specific origins. So we're going to get an aggregate along the lines of "x%
> ignored the dialog; y% said no; z% said yes", and we won't know what
> percentage of the time saying Yes had been a good idea or served a real use
> case.
>
Based on the discussion at https://crbug.com/378566 and the conversation(?)
at https://news.ycombinator.com/item?id=9210484, there are several large
services using this kind of scheme, and innumerable small/enterprise
versions of various sorts. I don't know how we'll get reasonable aggregate
metrics beyond
https://www.chromestatus.com/metrics/feature/timeline/popularity/530 (which
shows ~0.5% of page views being public sites which include private
resources). Those numbers might be big enough for rappor
<https://www.chromium.org/developers/design-documents/rappor> to help?
> So, as long as the mechanism is default-deny — as long as my
> instantly-EOL'd router and printer don't opt in — it's safe and I
> think/hope we can breathe relatively easy with no permission dialog, just
> the CORS preflight. The Pebbles of the world can opt in specifically to
> https://pebble.com, and the person updating their watch will be happy.
>
I'm dubious about the trustworthiness of devices, and I imagine that Super
Awesome Refrigerator 2000 is more likely to want to be chatty about its
contents than I am. I'm not sure that abdicating that decision to the
device manufacturer is a good idea in general.
-mike