On Jun 23, 2009, at 12:55 , Henri Sivonen wrote:
On Jun 2, 2009, at 16:02, Robin Berjon wrote:
On Jun 2, 2009, at 14:57 , Henri Sivonen wrote:
Please include a corresponding UA requirement to obtain
authorization from the user for the features imported with
<feature>. (It seems that the security aspect requires an
authorization and doesn't make sense if the dangerous feature are
simply imported silently.) As far as I can tell, the spec doesn't
currently explain what the UA is supposed to do with the 'feature
list' once built.
I don't think that that is a good idea. The purpose of <feature> is
to provide a hook through which a widget may communicate with a
security policy. What's in the security policy really isn't up to P
+C to define (though it certainly should be defined somewhere
else). Maybe it could ask the user, as you state, but maybe it
could see that the widget was signed by a trusted party, or know
that the device doesn't have any sensitive data for a given API, or
maybe anything goes on the full moon.
I see. The track record with Java APIs doesn't fill me with
confidence that the Right Thing will be done, but I guess this is
outside the scope of interop-oriented specs. (My current phone asks
me every time Google Maps Mobile wants to use the network and
doesn't allow me to grant the permission permanently and doesn't ask
me when GMM wants to grab my geolocation and send it to Google.)
Precisely: defining behaviour would turn us into a UI specification —
which we dearly want to avoid. Constant prompting makes for a dreadful
UX, that's for sure, but fixing that should be up to UA vendors. At
the end of the day, I do however have some confidence that they can do
UI much better than anything Java related :)
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
