Re: Firefox OS Permissions

<keeping my manifest spec editor hat on> 

On Monday, February 24, 2014 at 1:34 AM, Paul Theriault wrote:

> - For all other permissions, access is granted as a result of marketplace security review, and not shown to the user.

I think this works ok for closed/proprietary ecosystems - as the security decisions are mediated through a trusted third party who is willing to do the due diligence on the app's security on behalf of the user (in this case, Mozilla's marketplace). However, this security model doesn't scale on the Web as we know it today (where any/all URLs can be considered a web application) -  as it effectively creates a  walled garden.  

This is my understanding of what Mozilla does:

1. Dev creates an application that requires access to "WebAPIs". In their manifest they explicitly declare why they need access to certain things. An example from Moz's documentation:

"permissions": {
  "contacts": {
    "description": "Required for autocompletion in the share screen",
    "access": "readcreate"
    },
  "alarms": {
    "description": "Required to schedule notifications"
  }
}


2. The Marketplace security expert reviews the access request above. They can then make a security assessment about the truth of what is in the "description" and "access" by looking at the app's code. If they find the application to be honest in its usage, they give it a digital certificate (which serves as the key that actually grants the access). However, this cannot be done with Web Applications, as their code can change at any moment - so can only be done with "packaged applications" (which come with their own set of problems/limitations). 

3. The application is listed in the store. 

There are, of course, a number of issues with the above (the following list is not exhaustive, just the most obvious stuff - it also applies to all marketplaces, not pointing the finger at Mozilla): 

1. The user is left out of the picture. Even if they were included, they would not be able to make an informed decision. For example, user speaks Portuguese - they see "Required to schedule notifications". Allow? 
2. Centralized trust can be abused, misguided, or corrupted. For example, company X may strike an economic relationship with a marketplace. Only special interest get access to particular APIs - and the user might not get a say on the matter or have any means to revoke access.   
3. The developer may not be able to write in the language spoken by the reviewers, hence they are excluded. 
4. Digital signatures are time-bombed. An application might suddenly stop working if the certificate expires. 
5. Requires a marketplace - marketplaces may come and go. Or the marketplace doesn't allow applications that make political statements.
 
Obviously, the Web platform doesn't have a marketplace in the sense above. The best we have right now is search engines, and social connections that recommend us things. I think we generally believe that, on the Web, we don't want to have walled gardens. 

But we are seeing a rise of close and proprietary marketplaces from browser vendors that mirror those of native platforms: for example, Mozilla's Marketplace and Google's Web Store. I'm personally worried that the heavy investment into proprietary walled gardens and ecosystems will eventually serve as a disincentive to address permissioning on the Web. This might be ok. It might turn out that we can't fix permissioning and walled gardens are the way to go... I at least hope not - but we have been trying to work out the permission thing for the Web for about 10 years now and we've not made a lot of progress :(

Received on Monday, 24 February 2014 12:04:35 UTC