On Fri, Jan 8, 2016 at 1:14 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
>
>
>
>> I think Richard is on a pretty good path -- expose the primitives that we
>>> have reasonably easy access to, and figure out reasonable default
>>> behaviours for each.
>>>
>>
> I still don't follow Richard's proposal. What do you think he's
> suggesting? :)
>
> I would also be interested to know what Erik thought I was suggesting, but
> let me try to explain what I meant:
>
> - Spec defines a few categories of address space / source ("global",
> "private", "loopback", "link-local", "dot-local")
> - A CORS header like Access-Control-Allow-Network can allow access from
> any of these tokens
>
> I'm not sure I really think this is the best idea, but in any case, wanted
> to be clearer.
>
Something very much like this but thinking through the "private" case a
little bit more. For example, allowing SoHo routers or network/server
administrators to define address space realms. For example, SoHo routers
could include extensions to what is defined as "private" or configure an
additional "behind-the-firewall" to include the local network space behind
the firewall, regardless of what address block(s) were included.
Another somewhat related idea we've discussed some in this space is whether
HTTPS with in-URL certificate fingerprints could help with many of these
cases. For example, if the admin interface to a home router generated its
own key pair and on connections redirected you to (the unfortunately ugly):
https://cert=rsa:07801f1b0d01...e786c2dac60bcb5a@192.168.1.1/
then that provides a vaguely reasonable TOFU interface for accessing local
resources over HTTPS without needing to tie into a global CA hierarchy that
doesn't make as much sense in a local/SoHo environment. This potentially
makes drive-by CSRF attacks harder (well, until we provide a javascript API
to get the cert fingerprints).
Erik
Erik