Re: Origin-scoped cache/cookie/storage context

I like the concept very much. I'm unclear as to the practical
implementation you're proposing. How do sites opt-in to this sort of
treatment? How do you determine when a site ought to get credentials and
when it shouldn't?

+nasko, who did some work in a related area a little while back in
Chromium. He probably has opinions.

-mike


--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Thu, Jan 9, 2014 at 12:17 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Currently within browsers the HTTP cache is shared across origins.
> E.g. nsa.gov can do timing attacks on a resource hosted on
> notforthensa.org. Similarly when evil.com fetches a resource on
> authenticated.com, credentials will be included in the request if I
> was in fact authenticated to authenticated.com through a cookie or
> HTTP authentication.
>
> Outside of the browser context, means have been provided to not share
> these things. E.g. a Firefox OS hosted web app has no shared context.
> If you are authenticated to Facebook, you would need to
> re-authenticate within the app. Opera Widgets had the same back in the
> day (primarily because you could do cross-origin XMLHttpRequest
> without CORS).
>
> It might be worth giving this feature to web pages.
>
> It would provide defense-in-depth and has some similar capabilities to
> From-Origin in that you can no longer do timing attacks or test
> whether a fetch returns an image or an error depending on whether you
> are authenticated.
>
>
> --
> http://annevankesteren.nl/
>
>