On Mon, Jan 4, 2016 at 11:44 AM, Mike West <mkwst@google.com> wrote:
> 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.
>
OK that sounds pretty good to me.
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?
>>
>
Looks like Spotify, Dropbox, and a lot of unspecified applications from
people who don't understand we're planning to offer an opt-in via ACAO or
the like. Spotify and Dropbox, at least, are modern software projects that
can add the header in an update (and have updates). But:
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.
>
I'm somewhat confident that SAR 2000 is developed by people who will not
opt into internet communication, and will instead leak what it knows by
more mundane means. :)
But, all that having been said, if we are going to prompt people *after *the
internal origin has already opted in, then it will (I believe) still be
rare enough to not be too much of an annoyance.