W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: Privileged context features and JavaScript

From: Mike West <mkwst@google.com>
Date: Fri, 17 Apr 2015 08:44:48 +0200
Message-ID: <CAKXHy=cjO3Vdm48nDXj2+AGiPsRspuvLS9g0BTTO_UoQfcxLCA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Webapps WG <public-webapps@w3.org>, public-webappsec@w3.org, public-script-coord <public-script-coord@w3.org>
I'd be fine with this, if it's what folks end up preferring.

That said, throwing/rejecting gives us the opportunity to explain to a
developer _why_ her favorite API isn't available. It's not clear how we'd
help them understand what's going on if we just remove the API entirely.

Consider Geolocation, for instance: users can disable the API entirely in
Chrome (and, I assume, other browsers). Should we remove the API in these
cases as well?

Either way, expressing the constraint via IDL seems totally reasonable.

-mike
On Apr 17, 2015 07:19, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> Soon there will be a number of features that are restricted to
> privileged contexts. Most prominent one being service workers.
>
> Within user agents the prevailing pattern is that privileged APIs are
> not available in unprivileged contexts. However, both Firefox and
> Chrome currently expose the service worker API everywhere, it just
> happens to reject.
>
> Should we change this and simply not expose the API in unprivileged
> contexts? E.g. through IDL syntax? That way we don't have to carefully
> secure all access points.
>
>
> --
> https://annevankesteren.nl/
>
>
Received on Friday, 17 April 2015 06:45:16 UTC

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