W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [widgets] What does it mean to have an unavailable API

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Thu, 4 Jun 2009 09:57:51 +0100
Cc: Marcin Hanclik <Marcin.Hanclik@access-company.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>
Message-Id: <A96882B9-A530-4F86-87BE-8FF086377EF5@gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Security is on UC; another is resource use. If the UA only needs to  
inject the modules needed by a Widget this can have a positive impact  
on downloading and processing Widgets.

For example, if you have a lot of optional features, each of which is  
another 12k of injected JS...  well, you get the idea. You don't want  
to have those downloaded every time if they aren't needed.

Also, if any of those modules do automatic polling then you only want  
to load them for Widget instances that  really do need to use them.

S

On 4 Jun 2009, at 08:25, Jonas Sicking wrote:

> On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik
> <Marcin.Hanclik@access-company.com> wrote:
>> Hi Jonas,
>>
>> requestFeature() is mainly (still debated, though) for websites,  
>> i.e. online content where the <feature> is not present.
>> <feature> is for packaged widgets only.
>
> Ah, so requestFeature() is a BONDI spec, not a widget spec?
>
>>>> However this does not seem to be true
>>>> if the exploited code could simply call requestFeature() first, and
>>>> then use the feature.
>> Calling requestFeature() does not mean that the security aspects  
>> are omitted.
>> The check against the security policy happens when requestFeature()  
>> is called.
>
> As it was described to me by Marcos earlier in this thread, <feature>
> was used so that a widget could statically declare which security
> sensitive features it desired to use. This added security because if
> the widget was hacked, it could never use more security sensitive
> functionality than what had been statically declared using <feature>.
>
> So for example a widget that displays the current time would not need
> to claim access to any security sensitive APIs like camera or network
> access. This way it wasn't such a big deal if someone managed to hack
> the camera widget and get malicious code to run in the widgets
> security context, since that malicious code would not have access to
> camera or network.
>
> But if the malicious code could simply call requestFeature to gain
> access to camera, the above description no longer holds true.
>
> / Jonas



Received on Thursday, 4 June 2009 08:58:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT