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

Re: Restrict loopback address to Secure Contexts?

From: Richard Barnes <rbarnes@mozilla.com>
Date: Wed, 19 Oct 2016 18:46:38 -0400
Message-ID: <CAOAcki9rcjsvNL8kk5kEResz89J-S7JYDCVu7LAEO5qW8yoY3A@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "wilander@apple.com" <wilander@apple.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Crispin Cowan <crispin@microsoft.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Anne van Kesteren <annevk@annevk.nl>
This seems like a pretty obviously good idea.  I haven't looked at any
telemetry (don't know if we have anything appropriate), but if there's no
obvious blockers, I would say full steam ahead.

On Wed, Oct 19, 2016 at 1:07 PM, Mike West <mkwst@google.com> wrote:

> This thread got pulled off in a slightly different direction than John
> started in.
> I'm still interested in deprecating access to loopback resources from
> non-secure contexts. I plan to add some metrics to Chrome to see how much
> of the ~1% of "private IP resource in public IP page" page views
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/530>
> (!!!) that Chrome users report would fall into this bucket so that we can
> start to judge the impact.
> If the numbers aren't too terrifying, we'd likely send an "Intent to
> Deprecate" to blink-dev@ to get approval from the Blink community.
> On today's call, John suggested that this might also be reasonably added
> to the CORS-RFC1918 draft <https://wicg.github.io/cors-rfc1918/>: as it
> turns out, it's already there (search for "secure context" in
> https://wicg.github.io/cors-rfc1918/#integration-fetch). :)
> -mike
> On Wed, Sep 28, 2016 at 10:17 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> On Wed, Sep 28, 2016 at 12:18 AM, Crispin Cowan <crispin@microsoft.com>
>> wrote:
>> > On the perfect being the enemy of the good: you are quite right, I am
>> > describing an idealized world. I thought that’s what Standards are for,
>> and
>> > we then work towards them? Conversely, it seems like it would be bad to
>> > standardize on “good enough for now” and then need to change it.
>> We standardize what ships or we estimate we can ship within a short
>> amount of time. It's not at all that aspirational as you make it out
>> to be. E.g., in some idealized world I might have wished there would
>> be no need to have written https://encoding.spec.whatwg.org/ but the
>> fact is that there's more than UTF-8 in use. Ignoring that leads to
>> issues for users and is also anti-competitive to some extent as it
>> hinders new browsers from entering the market.
>> > Edge can’t do an effective job of CORS Preflight right now due to
>> > architectural issues which we hope to address in the future. Meanwhile
>> we
>> > keep Edge users safe from loopback attack with a different mitigation
>> that
>> > is not worthy of floating as a standard.
>> Why not? If it works and is deployed today...
>> > What is “happy eyeballs”?
>> https://en.wikipedia.org/wiki/Happy_Eyeballs
>> --
>> https://annevankesteren.nl/
Received on Wednesday, 19 October 2016 22:47:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:58 UTC