Re: Firefox OS Permissions

On 24 Feb 2014, at 7:09 pm, David Rogers <david.rogers@copperhorse.co.uk> wrote:

> I still find it incredible after all this time that we're resorting to user prompts in new platforms. 

Honestly there weren’t many viable alternatives proposed at the time (suggestions welcome!) The only alternative I recall was the use of ‘magic button’ style UI where we have a kind of always visible button which has a clear meaning - e.g. a camera button which takes a photo. I noted recently (?) that chrome has implemented an interesting UI for <input type="text" x-webkit-speech>. See [1] for demo gif. We avoided this 'magic button' approach in v1 mainly for simplicity, but maybe we could consider something like this for the future (again, would love to see some design work from the broader community here if anyone is interested).

Also I should note that we also achieve a degree of OS mediated access through the use of web activities. For example, in version one regular website &  web apps  are not permitted to use the camera API. They can however request that the some app supply them a picture, and the user will be prompted to choose from a list of apps that have declared that they can handle this type of web activity (e.g. camera, gallery etc). For version one, the most sensitive permissions were restricted to Gaia apps (mozilla developed and security reviewed) so we can be sure of the UX for these APIs.  A full list is here [2]. 

There is a push however to expose APIs more broadly in the future, which may call for more evolved permission granting mechanisms. As an specific example, webrtc getUserMedia will largely replace the need for a camera web activity in the future, providing a way for any web content to directly a picture/video.

[1] http://blog.teamtreehouse.com/wp-content/uploads/2014/01/x-webkit-speech-demo.gif
[2]https://developer.mozilla.org/en-US/docs/WebAPI/Web_Activities#Firefox_OS_activities

> Paul: is the displayed domain tied to the common name of the cert?

For websites and hosted web apps (which are basically websites with a manifest), the identifier displayed is the origin of the page (i.e protocol+port+domain). For packaged apps, which have a synthetic origin, only the app name is shown. (since the origin isn’t meaningful to the user). 

> 
> David.
> 
> Sent from my mobile. Apologies for brevity and touch-screen errors!
> 
> -------- Original message --------
> From: Paul Theriault 
> Date:24/02/2014 03:48 (GMT+01:00) 
> To: Marcos Caceres 
> Cc: Natasha Rooney ,W3C Webmob Public 
> Subject: Re: Firefox OS Permissions 
> 
> 
> On 24 Feb 2014, at 11:56 am, Marcos Caceres <w3c@marcosc.com> wrote:
> 
>> <manifest spec Editor hat on>
>> 
>> On Sunday, February 23, 2014, Natasha Rooney <nrooney@gsma.com> wrote:
>> Hey guys!
>> 
>> I was lucky enough to go along to the FirefoxOS event at mobile world congress tonight. I checked out some of the new devices and the apps running on them. One of the most interesting things was how the OS manages permissions. Inside of ‘settings’ the user can see a list of every app. When the app is selected the user can see the app author (this satisfies some regional legal requirements) 
>> 
>> Do you know which regions? This seems strange as it's so easy to forge (e.g., I can just put Microsoft as an author if I want). From the research I did, I was not able to find any other runtime that makes use of this info. It's only really used by curated stores. This is the reason why I dumped them from the manifest spec: declaration of authorship is kinda useless. It would be better to get such info from a digital cert. signed by a reputable CA (as browsers already do with banking sites, etc). 
> 
> I can’t answer your question regarding regions - I would try asking on dev-webapps@lists.mozilla.org (info here https://lists.mozilla.org/listinfo/dev-webapps)
> 
> But I can say that at the platform level, the ‘developer’ field (which includes the author) is not mandatory. However, Firefox OS Marketplace requires that all apps submitted have these fields populated, and I believe this is verified through the review process. See https://developer.mozilla.org/en-US/Apps/Developing/Manifest#developer
> 
> 
>>  
>> and a list of each permission the app is using. The user can then select ‘ask’, ‘deny’ or ‘grant’ for each permission. Below are links to tweets with pictures. I liked the solution a lot, and would love to know what you guys think!
>> 
>> https://twitter.com/thisNatasha/status/437618486047965184
>> https://twitter.com/thisNatasha/status/437617298678235136
>> 
>> 
>> It's quite similar to what browsers already do with site prefs. The question still remains if the average user knows what, for example, "geolocation" means in that context.
> 
> We provide localised prompts for the permissions that we think users can make a decision about. The settings app (shown above) is for users to review permissions. We don’t show permission descriptions in the first version, but perhaps we should/could in the future. 
> 
>> Same with DNT... Don't track what? What if servers just ignore that? Do users understand that it gives 0 assurances or protections? For both examples, there is no information on that screen to help them make an informed choice - or what can happen to an app if they change permissions. Also, I don't think that there is a way for users to see when services are using a particular permission. 
> 
> DNT is a setting handled separately from app permissions. It is handled from its own setting screen, which explains briefly what DNT is, and also provides a link to MDN for more information.
> 
>> 
>> I wrote a paper about this stuff (particularly about geolocation and permission dialogs) a few years back if people are interested:
>> http://marcosc.com/wp-content/uploads/2010/06/caceres_marcos_geopriv.pdf
>> 
>> 
>> 
>>  
>> Natasha
>> 
>> Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org 
>> 7th Floor, 5 New Street Square, London EC4A 3BF
>> 
>> This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
>> 
>