Re: Permission Systems across APIs

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
[Bugzilla] 
http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG

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