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: Tue, 9 Jun 2009 10:18:28 +0200
To: "marcosc@opera.com" <marcosc@opera.com>, 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: <FAA1D89C5BAF1142A74AF116630A9F2C0A26ED9269@OBEEX01.obe.access-company.com>
>>Yes, that was the design. If requestFeature() is introduced, <feature>
>>is basically useless.
Not necessarily. There can be different security aspects for both.
The basic idea is to make requestFeature() also to be a feature.


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: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Monday, June 08, 2009 8:34 PM
To: Jonas Sicking
Cc: Marcin Hanclik; Scott Wilson; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API

2009/6/2 Jonas Sicking <jonas@sicking.cc>:
> On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
> <Marcin.Hanclik@access-company.com> wrote:
>> Hi Scott,
>> In BONDI we have discussed the (has/request)Feature() for some time.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3
>> A few points for further discussion:
>> 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well.
>> 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by <feature>.
>> http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details.
> Doesn't the requestFeature() make at least the security benefits of
> <feature> moot? In Another thread Marcos stated that one of the
> benefits of <feature> was that if a widget gets exploited, the
> exploited code couldn't get access to any features that the widget
> hadn't enabled using <feature>. However this does not seem to be true
> if the exploited code could simply call requestFeature() first, and
> then use the feature.

Yes, that was the design. If requestFeature() is introduced, <feature>
is basically useless.

Marcos Caceres


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


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 Tuesday, 9 June 2009 08:19:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC