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

Hi Scott,

>>If a Widget requires shared state and participant features (e.g.
>>Google Wave), then we inject our reverse-AJAX JS, which triggers
>>either polling, comet, or piggyback synching (depending on server
>>configuration). So we wouldn't want to do this for every widget,
>>especially when many of them are single-user/ single-state and don't
>>need it. I can imagine other features implemented by Widget UAs that
>>might have resource implications if not selectively applied using
>><feature>.
I hope I understood your point correctly.
This seems for me also to be an implementation detail.

In general it is also possible that the "feature" is attached by requestFeature() in already some pre-initialized state.
Resource constraints would suggest requestFeature() instead of <feature>, IMHO, since the features could be attached only when needed.
To further optimize e.g. the memory management, we could have something like unloadFeature().
But this is out of scope for the security discussion.

Thanks.

Kind regards,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Marcin Hanclik
Sent: Thursday, June 04, 2009 5:19 PM
To: Scott Wilson
Cc: Jonas Sicking; Henri Sivonen; public-webapps
Subject: RE: [widgets] What does it mean to have an unavailable API

>>We inject JS into the <head> of the Widget HTML, including the Widget
>>API object, before sending it to the client browser; it automatically
>>initializes itself.
As for me this is just one of the possible implementations and the spec should not mandate how the additional API is made available.
The "client browser" term should be replaced by "rendering engine" in this context, IMHO.
Browser is something bigger for me.

As for your other comments, I have to grasp it deeper first.

Thanks.

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
Sent: Thursday, June 04, 2009 3:50 PM
To: Marcin Hanclik
Cc: Jonas Sicking; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API

We inject JS into the <head> of the Widget HTML, including the Widget
API object, before sending it to the client browser; it automatically
initializes itself.

If a Widget requires shared state and participant features (e.g.
Google Wave), then we inject our reverse-AJAX JS, which triggers
either polling, comet, or piggyback synching (depending on server
configuration). So we wouldn't want to do this for every widget,
especially when many of them are single-user/ single-state and don't
need it. I can imagine other features implemented by Widget UAs that
might have resource implications if not selectively applied using
<feature>.

For this reason alone the <feature> element gets a +1 from me :-)

S

On 4 Jun 2009, at 10:30, Marcin Hanclik wrote:

> Yes, one of the differences between <feature> and requestFeature()
> is the time when the actual API gets available.
>
> What is the automatic polling?
> Do you assume that the "loaded feature" is initialized by a kind of
> "onLoad" method?
>
> Thanks.
>
> Marcin Hanclik
> ACCESS Systems Germany GmbH
> Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@access-company.com
>
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: Thursday, June 04, 2009 10:58 AM
> To: Jonas Sicking
> Cc: Marcin Hanclik; Henri Sivonen; public-webapps
> Subject: Re: [widgets] What does it mean to have an unavailable API
>
> 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
>
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5  |  D-46047 Oberhausen
> HRB 13548 Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that
> is privileged or confidential, and is intended for use only by the
> individual or entity to which it is addressed. Any disclosure,
> copying or distribution of the information by anyone else is
> strictly prohibited.
> If you have received this document in error, please notify us
> promptly by responding to this e-mail. Thank you.


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Friday, 5 June 2009 09:58:23 UTC