RE: [widgets] What does it mean to have an unavailable API
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. 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.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@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 jo...@sicking.cc: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@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 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.
RE: [widgets] What does it mean to have an unavailable API
Ok, that makes sense; but I have serious doubts anyone will implement that. Why? You mean because it would not sell, because it is bad by design or any other reason? Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 8:34 PM To: Marcin Hanclik Cc: Scott Wilson; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API 2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com: Hi Scott, I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. There is an ongoing debate about requestFeature(). BONDI spec is approaching both widgets and websites and basically requestFeature() is planned to be primarily used only by websites. Ok, that makes sense; but I have serious doubts anyone will implement that. -- 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.
Re: [widgets] What does it mean to have an unavailable API
2009/6/9 Anne van Kesteren ann...@opera.com: On Tue, 09 Jun 2009 01:38:14 +0200, Marcos Caceres marc...@opera.com wrote: On 6/8/09 11:20 PM, Anne van Kesteren wrote: On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceresmarc...@opera.com wrote: Yes, that was the design. If requestFeature() is introduced,feature is basically useless. Now I'm confused. hehe, join the club:) But seriously, requestFeature() is some BONDI thing so we should not be discussing it here. Web Apps does not specify this anywhere: It has no bearing on the work Web Apps is doing and should not be discussed in the context of Widgets or within this working group. It may, however, become a topic of discussion for DAP in the future; but, again, it has absolutely nothing to do with W3C widgets. You said it might influence whether or not feature stays in the specification so it seems it does have something to do with W3C widgets. And if that is indeed the effect of requestFeature(), removing feature seems like the best course of action. Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres marc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makes feature useless. You claim requestFeature() is irrelevant with respect to feature. And now you claim requestFeature() is less secure than feature. I do not get at all the feeling that this feature is ready for standardization. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] What does it mean to have an unavailable API
On 6/9/09 11:58 AM, Anne van Kesteren wrote: On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceresmarc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() underminesfeature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makesfeature useless. You claim requestFeature() is irrelevant with respect tofeature. And now you claim requestFeature() is less secure thanfeature. I do not get at all the feeling that this feature is ready for standardization. How about instead of taking little fragments of conversations out of context you actually go and read the two specs? I don't see how you can assess the how ready for standardization anything is based on the conversation we have been having here. That's just trolling. Until you go and read both specs and make comments against the specs, I'm not continuing this discussion.
Re: [widgets] What does it mean to have an unavailable API
On Tue, Jun 9, 2009 at 10:19 AM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Ok, that makes sense; but I have serious doubts anyone will implement that. Why? You mean because it would not sell, because it is bad by design or any other reason? It's a bad design, IMO. However, we will discuss this as part of DAP. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
Making a static declaration of a feature to indicate to the UA which APIs to make available to a widget is already used in existing widget and gadget implementations; requestFeature() isn't. For example, here is the definition used by Google, and implemented in Shindig: Gadget Features. A list of all gadget features that are either required for the gadget to operate, or may optionally be utilized if available. Gadget features are the primary extensibility mechanism employed by gadgets. They often direct a gadget server to make new JavaScript APIs available to rendering code, but may also manipulate the gadget's contents, for example to add extended syntax. Examples of gadget features include OpenSocial (provides gadgets with a rich set of social APIs), dynamic-height (enables gadgets to resize themselves to an appropriate height), and tabs (a UI library facilitating tabular navigation). We use a similar definition in relation to Widgets. We specifically use feature for indicating to the UA to make shared state handling available and active, and plan to use it to indicate whether we should provide oAuth capability for a given widget. If this element were not in the specification, we'd have to create an extension that did the same thing anyway. The BONDI requirement is to dynamically add APIs once a Widget has already been instantiated. This may not suit some implementations. For example, our implementation has no way of dynamically injecting APIs into a Widget instance while it is already running; if BONDI wishes to require this capability of implementations this is not in the scope for Widgets. Currently the Widget AE spec makes no claim that Widget UAs must be able to dynamically load additional functionality on request. If a given UA implemented BONDI and a Widget chooses to use its requestFeature() method, then in that instance for that Widget, feature may be redundant. However, for Widgets not created specifically for BONDI that are used in a BONDI UA, this is not an issue; feature works fine and is not affected by the existance of the BONDI getFeature() extension. Also for UAs that support Widgets but not BONDI extensions, it is not an issue that the extension exists. Personally I don't really see a good UC for requestFeature(), but its proposed as a BONDI extension and not a W3C Widgets AE feature, so I support Marcos' position that we let it be. S On 9 Jun 2009, at 10:58, Anne van Kesteren wrote: On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres marc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makes feature useless. You claim requestFeature() is irrelevant with respect to feature. And now you claim requestFeature() is less secure than feature. I do not get at all the feeling that this feature is ready for standardization. -- Anne van Kesteren http://annevankesteren.nl/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] What does it mean to have an unavailable API
2009/6/2 Jonas Sicking jo...@sicking.cc: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@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 http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com: Hi Scott, I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. There is an ongoing debate about requestFeature(). BONDI spec is approaching both widgets and websites and basically requestFeature() is planned to be primarily used only by websites. Ok, that makes sense; but I have serious doubts anyone will implement that. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com: 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. Ok. 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. Right. However, I don't know why we are discussing this if, as you said before, it has no relevance to widgets. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
2009/6/4 Scott Wilson scott.bradley.wil...@gmail.com: 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. Understood, but isn't there some way to load them dynamically even if they are declared? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
On 6/8/09 11:20 PM, Anne van Kesteren wrote: On Mon, 08 Jun 2009 20:34:14 +0200, Marcos Caceresmarc...@opera.com wrote: I still have no clue what requestFeature() does/means. The again, I have not read the Bondi spec regarding that. On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceresmarc...@opera.com wrote: Yes, that was the design. If requestFeature() is introduced,feature is basically useless. Now I'm confused. hehe, join the club:) But seriously, requestFeature() is some BONDI thing so we should not be discussing it here. Web Apps does not specify this anywhere: It has no bearing on the work Web Apps is doing and should not be discussed in the context of Widgets or within this working group. It may, however, become a topic of discussion for DAP in the future; but, again, it has absolutely nothing to do with W3C widgets.
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.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@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
Re: [widgets] What does it mean to have an unavailable API
On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@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
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.hanc...@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 smime.p7s Description: S/MIME cryptographic signature
RE: [widgets] What does it mean to have an unavailable API
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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@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.
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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@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. smime.p7s Description: S/MIME cryptographic signature
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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@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.hanc...@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
RE: [widgets] What does it mean to have an unavailable API
Hi Scott, I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. There is an ongoing debate about requestFeature(). BONDI spec is approaching both widgets and websites and basically requestFeature() is planned to be primarily used only by websites. requestFeature() is present in general WebIDL, we may need some prose in case its use is constrained. The next debate on this topic in BONDI is planned to happen soon. The output will definitely by provided to this mailing list asap, I assume. 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.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Tuesday, June 02, 2009 5:41 PM To: Marcin Hanclik Cc: Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Hi Marcin, Yes, on (1); the Google example I was referring to does the same. So, for example, analytics is the feature name, but this means the whole module, which includes a couple of JS libs and a range of functions. For hasFeature() the only UC I can see is if your Widget declares a Feature, but doesn't require it (REQUIRED=false), but can make use of it for added functionality if it is available. (Sorry Marcos, just remembered this one - don't get rid of hasFeature() yet!) I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. S On 2 Jun 2009, at 15:28, Marcin Hanclik 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. 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.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Scott Wilson Sent: Tuesday, June 02, 2009 3:18 PM To: Henri Sivonen Cc: public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API I think in such a case the UA should not be expected to make frob() available, and the Widget should not expect frob() to be present. For example, in the Shindig opensocial runtime, client JS is injected based on the require elements of the gadget. If it isn't declared, it isn't injected, and if you try calling those functions they just aren't there. What this does make less clear for me is in W:AE why you'd ever want to call hasFeature()? S On 2 Jun 2009, at 13:51, Henri Sivonen wrote: Ok. I see what you mean. Widget.hasFeature has slightly different semantics (in widgets, it means did that feature I requested load and become available? Which brings up the issue that it's unclear what it means for an API to have latent support but not having been activated with feature. If a widget UA has an implementation for window.frob() and frob() requires feature activation, what should happen when frob() hasn't been activated with feature? Should there be no function object for frob()? Or should it be there but throw upon calling? Or something else. Please specify this. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ 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
RE: [widgets] What does it mean to have an unavailable API
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. 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. 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.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, June 02, 2009 7:19 PM To: Marcin Hanclik Cc: 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:28 AM, Marcin Hanclik marcin.hanc...@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. / 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.
RE: [widgets] What does it mean to have an unavailable API
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.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@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 jo...@sicking.cc wrote: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@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.
RE: [widgets] What does it mean to have an unavailable API
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. 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.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Scott Wilson Sent: Tuesday, June 02, 2009 3:18 PM To: Henri Sivonen Cc: public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API I think in such a case the UA should not be expected to make frob() available, and the Widget should not expect frob() to be present. For example, in the Shindig opensocial runtime, client JS is injected based on the require elements of the gadget. If it isn't declared, it isn't injected, and if you try calling those functions they just aren't there. What this does make less clear for me is in W:AE why you'd ever want to call hasFeature()? S On 2 Jun 2009, at 13:51, Henri Sivonen wrote: Ok. I see what you mean. Widget.hasFeature has slightly different semantics (in widgets, it means did that feature I requested load and become available? Which brings up the issue that it's unclear what it means for an API to have latent support but not having been activated with feature. If a widget UA has an implementation for window.frob() and frob() requires feature activation, what should happen when frob() hasn't been activated with feature? Should there be no function object for frob()? Or should it be there but throw upon calling? Or something else. Please specify this. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ 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.
Re: [widgets] What does it mean to have an unavailable API
On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@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. / Jonas
Re: [widgets] What does it mean to have an unavailable API
On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@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
