Re: [widgets] Please include a statement of purpose and user interaction expectations for <feature>

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/

Received on Tuesday, 23 June 2009 11:45:14 UTC