Re: Limiting requests from the internet to the intranet.

On Mon, Jan 4, 2016 at 12:07 PM, Chris Palmer <palmer@google.com> wrote:

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

I don't think this can ever be something that a remote site should be able
to request. First off, I don't think we can devise a prompt or chooser that
presents a meaningful security distinction to the user (my parents don't
have the slightest clue what "resources on your internal network" means).
But more importantly, the CORS opt-in is part of how local/private apps
convey that they're sufficiently robust to accept this increased exposure
from the public Internet. So, if the app can't be updated to send this new
CORS header, then it's pretty clear that it hasn't met the bare-minimum
safety bar.

Independent of this, I do think browser implementers should provide for
legacy and testing bypasses via their own mechanisms. In the case of
Chrome's implementation, I'd always intended that this would land with
enterprise policy and command line support for manually adding
private/local hosts for public access.


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

I don't see a point in prompting at all (once again, for my parents' sake).
If we've gotten to the point of the private/local origin opening the hole,
then I think it's safe to just silently let it work. I mean, both sides
have already opted in, so do you really think the average user is better
qualified to make the decision at this stage? That stated, I think more
narrow scoping is a good reason to have the private/local host explicitly
specify an allow list for public origins (although they can manage that
logic on their own using the origin header).