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: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 4 Jun 2009 10:55:30 +0200
To: Jonas Sicking <jonas@sicking.cc>
CC: Scott Wilson <scott.bradley.wilson@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C0A26ED9100@OBEEX01.obe.access-company.com>
Hi Jonas,

>>Ah, so requestFeature() is a BONDI spec, not a widget spec?
Well, currently yes.
The whole BONDI spec was contributed to WebApps recently, as a joint input.
It is up to this WG whether there will be substantial changes or not.

>>But if the malicious code could simply call requestFeature to gain
>>access to camera, the above description no longer holds true.
"simply" seems not to fit here, IMHO.
It is still debated whether the usage of requestFeature() in widgets should not also be protected by security policy.

The arguments are that Web developers may not want to develop content twice, once to be available as widget and the second time as webapp. So if someone develops a JS library that uses requestFeature(), this library should be usable without changes both in widgets and webapps. The only difference would be in the security aspects.

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: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Thursday, June 04, 2009 9:26 AM
To: Marcin Hanclik
Cc: Scott Wilson; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API

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.
Received on Thursday, 4 June 2009 08:57:16 GMT

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