Fwd: Permission Systems across APIs

The security analysis noted below may be relevant to DAP WG as well. The specifications reviewed (as noted in the PDF referenced below) included:

1. HTML 5 specification 

2. Cross-origin messaging specification

a. XML Http Request levels 1 and 2
b. Uniform Messaging Policy
c. Cross-Origin Resource Sharing
d. HTML5 Web Messaging

3. Device API specifications 

a. MediaCaptureAPI
b. System Information API
c. Permissions for Device API Access 
d. Device API Privacy Requirements
e. WebStorage
f. Geo-location API Specification 

 4. Widget specifications

a. WidgetAccessRequestPolicy
b. DigitalSignaturesforWidgets

The report executive report expresses concern about security by design (and implicitly privacy by design) across the suite of W3C specifications, noting "Many of these standards are reaching a point of no return, beyond which opportunities for security- by-design will be lost. "

We should probably review this document and see what if any related steps we should take in DAP.

regards, Frederick

Frederick Hirsch
Nokia



Begin forwarded message:

> Resent-From: <public-webapps@w3.org>
> From: ext Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
> Date: August 3, 2011 1:48:33 PM EDT
> To: <public-webapps@w3.org>
> Subject: Permission Systems across APIs
> 
> The following comment contains information about a general observation,
> identified during a recent security analysis of 13 W3C standards,
> organized by ENISA (European Network and Information Security Agency),
> and performed by the DistriNet Research Group (K.U. Leuven, Belgium).
> 
> The complete report is available at http://www.enisa.europa.eu/html5
> (*), and contains information about the process, the discovered
> vulnerabilities and recommendations towards improving overall security
> in the studied specifications.
> 
> 
> 
> The security analysis of multiple specs shows that permission systems
> are very inconsistent or incomplete across the specifications. The
> specifications suffer from a number of problems, which will be addressed
> below.
> 
> * Permission System Design
> 
> Several specifications include a permission system, without any
> consistency between these systems. This is troublesome, since some
> systems are fairly weak compared to other systems. One good example is
> the Geo-location API versus the System Information API, where the latter
> is much more extended (e.g. it requires permission for a pair of origins
> for a framed document and distinguishes between one-host vs. monitoring
> permissions).
> 
> Our recommendation is to co-ordinate these permission systems across
> specifications. This would enable a strong permissions system for all
> involved APIs and makes it less complicated for browser vendors.
> Optionally, a separate permission specification, which describes how
> permission systems should work across all the specifications, can be
> created. The specification should describe the necessary types of
> permissions (e.g. persistent vs one-time, one-shot permission vs a
> watching process, ...) and what they are based on. The specifications
> describing the APIs can then reference the permission specification with
> a certain type of permission, and require the implementation of that
> permission system. This brings consistency across all permission systems
> and decouples improvements to permission systems from functionality
> developments. Recent work on Feature Permissions
> [http://dev.w3.org/2009/dap/perms/FeaturePermissions.html] already
> points in this direction, but does not yet cover all aspects raised in
> this analysis.
> 
> Additionally, it might be useful to investigate potential conflicts of
> the permission systems with underlying security controls (e.g. on a
> smartphone device). Integration of API permissions systems and
> underlying security controls not only avoids potential conflicts between
> systems, but can also be useful in delivering an integrated and
> consistent experience to the end user. 
> 
> * User Interfaces
> 
> The specifications do not include much detail about the user interfaces
> for giving permissions and managing permissions. Typically, they require
> that the origin of the document is displayed. One major missing item is
> the nature of the permission (one-shot vs watching process) as well as
> the actual document requesting it (e.g. is it sandboxed or framed? is it
> visible?). For managing permissions, the specifications typically state
> that it should be clear and easily usable. This is very vague and is not
> even a strong requirement (should instead of must). Evidence of this are
> the current permission management interfaces, which are not always
> intuitive or clear.
> 
> Our recommendation is to extend the specifications to include more UI
> requirements. At least all the aspects of the requested permission
> should be present. For managing the permissions, the specifications
> should describe how it should happen (not what it should look like). For
> example, they could state that "A user must be able to get an overview
> of all assigned permissions, grouped per origin".
> 
> Optionally, these UI requirements can be included into the
> abovementioned separate permission specification, which is then
> referenced from all other specifications requiring a permission system.
> This ensures consistency and facilitates improvements or extensions of
> the permission system. 
> 
> 
> (*) HTML version of the report is available as well:
> https://distrinet.cs.kuleuven.be/projects/HTML5-security/
> -- 
> Philippe De Ryck
> K.U.Leuven, Dept. of Computer Science
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>

Received on Wednesday, 3 August 2011 19:31:45 UTC