W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: Limiting requests from the internet to the intranet.

From: Mike West <mkwst@google.com>
Date: Mon, 4 Jan 2016 20:44:37 +0100
Message-ID: <CAKXHy=dRRk+A=S_o1a=96QO6z9p4hgRVdfDhDs--5AcY_C0-Ww@mail.gmail.com>
To: Chris Palmer <palmer@google.com>
Cc: Richard Barnes <rbarnes@mozilla.com>, Erik Nygren <erik+w3@nygren.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Brian Smith <brian@briansmith.org>, Ryan Sleevi <sleevi@google.com>, Justin Schuh <jschuh@google.com>, Devdatta Akhawe <dev@dropbox.com>, Anne van Kesteren <annevk@annevk.nl>, lee@asgard.org
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
Received on Monday, 4 January 2016 19:45:26 UTC

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