W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Permission Systems across APIs

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 10 Aug 2011 09:41:13 -0400
Message-ID: <4E428A79.5080006@nokia.com>
To: ext Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
CC: public-webapps <public-webapps@w3.org>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, Robin Berjon <robin.berjon@gmail.com>, Matt Womer <mdw@w3.org>
Hi Philippe,

Thanks for notifying us of ENISA's work.

I generally agree W3C specs should be as consistent as possible and 
practical. If there is a need for WebApps WG to coordinate with some 
other group, please be more specific about the issue.

FYI, the Geolocation API is specified by the Geolocation WG [GeoWG]. The 
System Information API is specified by the DAPI WG and they are also 
doing the only explicit permissions-related work at the W3C that I know 
about [DAPIWG]. As such, if you have not already contacted those WGs, 
you may want to do so.

WebApps' specs are enumerated in [PubStatus]. If you have identified any 
specific spec issues, please submit them to the 
<mailto:public-webapps@w3.org> mail list (or file a bug via [Bugzilla]). 
If ENISA's work resulted in test cases for any of WebApps' specs, please 
send the details to <mailto:public-webapps-testuite@w3.org>.

-Regards, Art Barstow

[GeoWG] http://www.w3.org/2008/geolocation/
[DAPIWG] http://www.w3.org/2009/dap/#roadmap
[PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus

On 8/3/11 1:48 PM, ext Philippe De Ryck wrote:
> 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/
Received on Wednesday, 10 August 2011 13:41:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC