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 <[email protected]> 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
