Re: [widgets] Purpose and utility of <feature> unclear

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