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

Hi Henri,

>>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.)
There is no problem with the APIs within the Web content.
There is just a difference on the security policy level whether unauthorized Web content (website vs. widget) may access the API.
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf, section B.4.(1|2).

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: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Henri Sivonen
Sent: Monday, June 01, 2009 4:41 PM
To: marcosc@opera.com
Cc: public-webapps
Subject: Re: [widgets] Purpose and utility of <feature> unclear

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.)

Failing that, I now see the point of the security aspect of the
<feature> design. 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.

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.

>>> 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.

>> 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.

>>> 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.

>> 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).

--
Henri Sivonen
hsivonen@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.

Received on Tuesday, 2 June 2009 10:29:58 UTC