Re: Limiting requests from the internet to the intranet.

On Mon, Jan 4, 2016 at 1:31 PM, Justin Schuh <jschuh@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.
>

I don't think Mike meant to say that the remote site requests the pop-up,
per se. Here is what I imagine happening, and what I think (?) Mike meant:

* public-origin.com tries to make a request to internal-origin.localdomain
* Browser fires off CORS preflight check to internal-origin.localdomain
* If the check fails, browser throws error to public-origin.com as normal
* If the check passes, browser raises dialog to the person

The dialog names public-origin.com; we can bikeshed whether the dialog
should name internal-origin.localdomain or just vaguely "resources on your
internal..."

Either way, I don't think the spec should call for specific strings/string
patterns, including requiring naming or not naming the public or the
internal origin. That's an implementation decision.

However, if the UA does name the public origin, I don't think it makes
sense to name a specific non-secure public origin. If the UA says that
public-origin.com will do the accessing of internal resources, and if
public-origin.com is well-authenticated, then that statement has some
meaning. But if public-origin.com is not authenticated (e.g. plaintext
HTTP), then a good UA should say something to the effect of, "
http://public-origin.com and whoever can poison DNS or JavaScript or...
wants to access resources on your internal..."

Because I doubt all UAs would really use such wording — although I think
they should, because it's honest — I lean toward specifying that only
secure public origins to even try to access internal stuff. Now, I know
CORS doesn't currently require HTTPS (even though it should have, to start
to enforce what it claims), but I don't see why we can't start doing things
right now that we are inventing new things. It's a new year, we can try new
things... :)

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

Agreed.


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

Sometimes, yes. As long as the prompts aren't frequent — I am satisfied
they won't be if they don't even happen until both sides opt in — then they
are/can be a gesture of respect for the person's control over their stuff.


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

Agreed.