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

On 6/1/09 4:40 PM, Henri Sivonen wrote:
> On Jun 1, 2009, at 16:44, Marcos Caceres wrote:
>
>> On Mon, Jun 1, 2009 at 1:25 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
>
>>>> 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).
>
> In general, this policy seems alien to browser technologies.
>
>>>> 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).
>
> I think it would be preferable to design APIs in such a way that
> security/privacy aspects of the API are Web-ready, i.e. the same API
> could be exposed to Web content. (I consider the design of the
> Geolocation API and it's authorization UI in Firefox Web-ready in this
> sense.)

Yes! I completely agree with you, but you are being idealist. BONDI's 
APIs are not Web ready, but people want to use them regardless. 
Unfortunately, the market is not going to wait to do the "right thing" 
here. Remember that the Geo-Privacy crew have been at this problem for 
at least 5 years. Imagine that a new groups need to be set up to deal 
with Camara-privacy, Contacts-privacy, etc., etc.,... this stuff is 
going to take like 10 years to sort out. Also, it is hard to tell if 
Mozilla has done a good job or not with their UIs: Those APIs and the 
corresponding user interfaces have not been in the wild long enough to 
be able to give an objective assessment... I think a massive storm is 
coming WRT this and the DAP-WG, but I don't know if it will pass over or 
not.

> Failing that, I now see the point of the security aspect of the
> <feature> design.

Right. I personally completely agree with you (and have argued that 
having <feature> is [a necessary] evil, even though I invented it:)). It 
is just a stop-gap measure while the BONDI APIs get brought over to the 
W3C and eventually become a standard part of the Web browser. That's my 
personal opinion, and is not shared by the group.

 > However, for that case, I think the default policy for
> upcoming features of the platform (feature unavailable unless part of
> Widgets 1.0 Family) is backwards if the widget platform is viewed as a
> an extension to the browser platform that keeps up with the evolution of
> the browser platform as opposed to being a one-time fork of the browser
> platform.

Correct.

> It seems to me it would be better to allow features with a Web-ready
> security model to be made available by default and require
> widget-oriented feature specs that lack a Web-exposable security model
> opt in to the <feature> security model.

I think that is what I had in mind.

>>>> 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?
>
> Implementations have an incentive to claim to have a feature when they
> have only partial support. OTOH, when implementors try to do the Right
> Thing and resist the temptation, partial implementations will report
> false even though the script in question could have worked with only the
> part of the implementation that exists. Also, actual feature
> implementation status and what hasFeature reports may be out of sync
> just by omission.
>
> javascript:alert(document.implementation.hasFeature("Selectors-API",
> "1.0")), for example, says false to me on Firefox trunk.

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?" and not so much "does the browse support this 
feature?"), but essentially widget.hasFeature would be plagued by the 
same problems.

So, ISSUE: is widget.hasFeature() really needed?

>>> 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?
>
> Scripts should try to use a given API and whine to the user or perform
> workarounds if the API is missing.

Yes, this is how I see it working too. For example,

if (window.foobarfoo){
    ...
}

I.e., the specification for the feature would need to declare which 
object it will be bound to (e.g, it might explicitly request that a 
feature be made available on the window or on the window.widget 
object... window.widget.barbarbar).


>>>> 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."
>
> Thanks. That makes it clearer what <feature> is about.

Ok, cool.

>
>>> 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.
>
>
> It seems to me this issue is solved by making only widget-oriented
> (BONDI) features participate in the <feature> model and making
> Web-oriented features (like Geolocation) not participate (i.e. work like
> they work in a browser).
>

I, personally, completely agree with you. Other WG members might not. 
This position is marginalized in the working group. The working group is 
polarized between those that want to fix the Web stack and are 
(rightfully?) paranoid about the consequences of just making APIs 
available, and those that just think we leave it to browser vendors (my 
position); it's hard to have a discussion about this, but will be a hot 
topic at our next F2F next week.

For the purpose of the disposition of comments, and as far as the 
current text in the specification goes, can I record that your comments 
have been addressed? If you want to continue discussion of the security 
model, then we should start a new thread.

Kind regards,
Marcos

Received on Monday, 1 June 2009 15:27:42 UTC