Re: Firefox OS Permissions

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

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

David.

Sent from my mobile. Apologies for brevity and touch-screen errors!

-------- Original message --------
From: Paul Theriault <ptheriault@mozilla.com> 
Date:24/02/2014  03:48  (GMT+01:00) 
To: Marcos Caceres <w3c@marcosc.com> 
Cc: Natasha Rooney <nrooney@gsma.com>,W3C Webmob Public <public-web-mobile@w3.org> 
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.

Received on Monday, 24 February 2014 08:12:03 UTC