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

Re: Request for input on Foreign Fetch

From: Ben Gidley <ben@gidley.co.uk>
Date: Thu, 28 Jan 2016 11:33:38 +0000
Message-ID: <CALM79eKPD0BxRRCXLUX7sKE-SOPAtM8-AqbCdeXzNMcfabS4zA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mkwst@google.com>, WebAppSec WG <public-webappsec@w3.org>, Marijn Kruisselbrink <mek@google.com>
Hi,


It may be already dealt with - but I can see 2 concerns

1) How do you know who is asking for the resource - these isn't an obvious
way to identify them. What data will be passed into the event that allows
that? I can see it would be useful to have some caller identification.

2) If I've been hacked 'once' and a bad guy installs a service worker does
this let them mess with my traffic for an extended period.

Ben Gidley

On Thu, 28 Jan 2016 at 05:18 Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 28 January 2016 at 06:08, Anne van Kesteren <annevk@annevk.nl> wrote:
> > I meant the latter. We would not issue an OPTIONS fetch. CORS OPTIONS
> > is a check to see if the server is CORS-aware. Here the service worker
> > obviously is aware of cross-origin fetches.
>
> Ack, thanks.  That leaves the question of ambient authority and I
> think for that you already have your answer and you just aren't happy
> with it :)
>
> Namely, opting in to foreign fetch for a given path prefix (or scope)
> is an implicit acceptance of the use of ambient authority for all
> those intercepted requests.  Suppressing credentials and reducing
> visibility would be the responsibility of the SW using explicit
> controls, not the browser using implicit inference.
>
> Ultimately, I think that's a nice outcome.
>
> Can then we reduce this problem to one of developer education?
>
> --
Ben Gidley
ben@gidley.co.uk
Received on Thursday, 28 January 2016 11:34:21 UTC

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