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

Re: Privileged context features and JavaScript

From: Richard Barnes <rbarnes@mozilla.com>
Date: Fri, 17 Apr 2015 10:04:44 -0400
Message-ID: <CAOAcki-ZPh9jEcKUiOAeSxM+YX+=JUxz+Mqki1Wpp+S6KfMbFA@mail.gmail.com>
To: Ashley Gullen <ashley@scirra.com>
Cc: Elliott Sprehn <esprehn@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, public-webappsec@w3.org, public-webapps <public-webapps@w3.org>, public-script-coord <public-script-coord@w3.org>
On the one hand, I like the idea of giving developers and users better
information about why things are failing.

On the other hand, it seems unpleasant to make every API that is so
restricted accommodate a "failing because of non-privileged context"
modality, which they will undoubtedly do in different ways.

On Fri, Apr 17, 2015 at 7:58 AM, Ashley Gullen <ashley@scirra.com> wrote:

> I think the existence of the API functions should indicate the browser has
> the capability, and then the API returns an error if it's not allowed to be
> used in the current context. I think this would improve the quality of
> messages seen by users, since for example removing the Geolocation API
> entirely could result in a web page message like "sorry, your browser does
> not support Geolocation, try updating your browser" - which is incorrect,
> it really should say something like "geolocation permission denied".
>
>
> On 17 April 2015 at 08:38, Elliott Sprehn <esprehn@chromium.org> wrote:
>
>> It's preferable not to do that for us because you can then create a
>> static heap snapshot at compile time and memcpy to start JS contexts faster.
>> On Apr 17, 2015 12:03 AM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
>>
>>> On 4/17/15 2:52 AM, Boris Zbarsky wrote:
>>>
>>>> If that preference is toggled, we in fact remove the API entirely, so
>>>> that "'geolocation' in navigator" tests false.
>>>>
>>>
>>> Oh, I meant to mention: this is more web-compatible than having the API
>>> entrypoints throw, because it can be object-detected.  Of course we could
>>> have made the API entrypoints just always reject the request instead, I
>>> guess; removing the API altogether was somewhat simpler to do.
>>>
>>> -Boris
>>>
>>>
>>>
>
Received on Friday, 17 April 2015 14:05:20 UTC

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