W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2015

Re: Privileged context features and JavaScript

From: Ashley Gullen <ashley@scirra.com>
Date: Fri, 17 Apr 2015 12:58:58 +0100
Message-ID: <CAABs73jCJRne6Sa_Gv0gDv6bGECHpP+xgGGspPO229OkD8EBrw@mail.gmail.com>
To: Elliott Sprehn <esprehn@chromium.org>
Cc: 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>
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 11:59:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 17 April 2015 11:59:27 UTC