- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Wed, 3 Jun 2009 12:23:19 +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>
Hi Marcos, requestFeature() from BONDI 1.0 is an asynchronous API that follows API design pattern: http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#asynchronicity requestFeature() is described in detail in: http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf section 4.3.2 "A call to the successCallback Function signifies that the request has been satisfied and that the corresponding JavaScript API is immediately available." It means basically that you can directly use the requested API if the request to have it was successful. You do not have to perform any further checks and there is actually a bunch of interfaces that are available, not just a single object. 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: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres Sent: Tuesday, June 02, 2009 7:50 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 On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking <jonas@sicking.cc> wrote: > 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. > I don't know what the BONDI doc says, but this is certainly not what should happen (unless something changed since I stopped working with Bondi on this). The idea with getFeature, IIRC, is that you first declare a feature, e.g., <feature name="foo:bar">, and then you can ask for an pointer to it at runtime: <script> var foobarator = Bondi.getFeature("foo:bar"); foobarator.crush().kill().destroy(); var barfoo = Bondi.getFeature("bar:foo"); barfoo === underfined; // true </script> -- Marcos Caceres http://datadriven.com.au ________________________________________ 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 Wednesday, 3 June 2009 10:24:55 UTC