- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 1 Jun 2009 15:44:09 +0200
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: public-webapps <public-webapps@w3.org>
Hi Henri, On Mon, Jun 1, 2009 at 1:25 PM, Henri Sivonen <hsivonen@iki.fi> wrote: > Regarding http://dev.w3.org/2006/waf/widgets/#the-feature-element > > I don't understand the purpose and utility of the <feature> element. Ok. >> Using a feature element denotes that, at runtime, a widget may attempt to >> access the feature identified by the feature element's name attribute. > > Why is this useful to denote? What happens if a widget doesn't denote that > it'll attempt to use a feature but does so anyway? Then it will fail as the feature will not have loaded. Feature loading has to be explicit (unless the feature is enabled by default, as might become the case eventually with, say, Geo-location). >> Using a feature element denotes that, at runtime, a widget may attempt to >> access the feature identified by the feature element's name attribute. > > > Why aren't all the implemented features simply available like in a Web > browser engine? Feature is for proprietary extensions: BONDI makes extensive use of this element. There are also security considerations: Members of the WG have asked why would you want the contacts API, for example, to be enabled by default? if you don't enable it and make it available, then malicious injected code cannot access those APIs. In widgets, the security model that we are discussing is one where APIs are made available on request only... or till implementers consider them benign enough to allow them in the wild (e.g., XHR). >> A user agent can expose a feature through, for example, an API, in which >> case a user agents that supports the [Widgets-APIs] specification can allow >> authors to check if a feature loaded via the hasFeature() method. > > Wouldn't this have all the same problems that DOM hasFeature() has had > previously Excuse my ignorance, but I don't know what those problems are. Can you please give us a pointer? > and the problems that have been pointed out as reasons not to > have feature detection at-rules in CSS? Namely, that implementations have > the incentive to claim that they have a feature as soon as they have a > partial buggy implementation. Ok, I see; that is bad. Can you recommend what we should do instead? >> A boolean attribute that indicates whether or not this feature must be >> available to the widget at runtime. In other words, the required attribute >> denotes that a feature is absolutely needed by the widget to function >> correctly, and without the availability of this feature the widget serves no >> useful purpose or won't execute properly. > > What's a widget engine expected to do when an unrecognized feature is > declared as required? Ah, good point! I had not completely specified that in the processing part of the spec. It now reads: "If feature-name is not a valid URI, and required-feature is true, then treat this widget as an invalid widget package. If feature-name is not supported by the user agent, and required-feature is true, then treat this widget as an invalid widget package. If feature-name is not supported by the user agent, and required-feature is false, then this element, its attributes, and its children are in error and must be ignored. Stop processing this element and proceed to the next element in the elements list." >> <feature name="http://example.org/api.geolocation" required="false"/> > > > Suppose a WG creates a feature for the Web, the feature is not part of the > Widgets 1.0 Family of specs and the WG doesn't assign a feature string for > the feature because the WG doesn't consider widgets. Next, suppose browser > engines implement the feature making it unconditionally available to Web > content. > > Now, if such a browser engine is also a widget engine, does it make the > feature's availability on the widget side conditional to importing it with > <feature>? If it does, what's the point of not making the feature available > unconditionally? If it doesn't, what's the point of <feature>? Like I said, the WG has not reached consensus on this (though we have been discussing it at length as part of the security model discussions). Some in the working group want a complete opt-in model (every feature must be declared, possibly even XHR!). I tend to lean towards the world view that eventually APIs will become available without request in the manner you describe above (their usefulness and availability trumps the security risk - or society just learns to deal with it, like they have with inline content information leakage, cookies, eval and scripts - i.e., "it's teh Interwebz, deal with it!":O ). I don't know how to proceed here, unless we try to accommodate both world views. In effect, we can't realistically control what APIs are made available by default by the UA. > If there are two such engines, how do they converge on the same feature name > string of the specifiers of the feature itself just meant it to be available > to Web content unconditionally and didn't bother to mint a widget feature > string? Like I said, feature was originally intended to request access to proprietary features designed for widgets (namely BONDI). If the API just becomes available in the browser, then no feature string is needed. But yes, we have a potential problem here until we settle on the security model. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Monday, 1 June 2009 13:45:12 UTC