- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 06 Jan 2011 23:35:45 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv16562
Modified Files:
Overview.html
Log Message:
Update introduction to emove explicit references to framework and
charter, add reference to privacy requirements. Move policy
requirements with appropriate use cases, reframe without assuming
framework. Update 2.1.2 to remove "glances at privacy policy" since we
know this has issues, and added note about possible lack of "informed
consent" in this privacy model.
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -d -r1.52 -r1.53
--- Overview.html 6 Jan 2011 21:16:14 -0000 1.52
+++ Overview.html 6 Jan 2011 23:35:43 -0000 1.53
@@ -63,9 +63,14 @@
Various groups have been defining APIs designed to enable
Web sites and applications access to device resources, including geolocation [[GEOLOCATION-API]], personal information such as calendar and contacts [[CONTACTS-API]],
system information [[SYSINFOAPI]] such as network information, etc. Much of this information is sensitive and can be misused.</p>
- <p>As part of its charter, the Device API and Policy Working Group is developing a set of technologies to control access to this information, including through the use of a policy framework.</p>
- <p>This document explores use cases for such a framework through user stories, and derives requirements both for APIs and the framework based on these use cases.</p>
+ <p>This document outlines "user story" use cases
+ for security and access
+ control for device APIs and derives requirements from these
+ cases. Although security and access control is related to
+ privacy, this document does not discuss privacy specifically as
+ there is another document specific to privacy [[DAP-PRIVACY-REQS]].
+ </p>
<section id="defs">
<h2>Definition</h2>
@@ -92,12 +97,22 @@
<h4>User Story: Unknown restaurant Web site</h4>
<div class="story">
<p>Alice uses her browser to get more information on a restaurant her friends have told her about. The Web site of the restaurant offers to give her indications on how to come from where she stands to their location, as well as to send automatically a SMS to reserve a table for lunch.</p>
- <p>Alice follows a link to the direction page, and her browser asks her unintrusively to confirm she wants to share her current location with the map service provider embedded in the Web restaurant site. She glances at the privacy policy and decides she can safely share her current location. She consents to sharing her location through the browser, and gets detailed directions to the restaurant.</p>
+ <p>Alice follows a link to the direction page, and her browser
+ asks her unintrusively to confirm she wants to share her current
+ location with the map service provider embedded in the Web
+ restaurant site. After considering issues related to sharing this
+ information, she decides to share her current location. Upon consenting to sharing her location through the browser, she gets detailed directions to the restaurant.</p>
<p>Her browser then displays a non-modal prompt asking if she wants to send an SMS to make a reservation at the restaurant. She is not interested and simply ignores the prompt.</p>
</div>
<h4>Analysis</h4>
- <p>Access to non-safe APIs from web pages or applications with which the user has no pre-established relationship must only be granted after explicit user consent, and that consent needs to be granted for each non-safe API separately.</p>
+ <p>Access to non-safe APIs from web pages or applications with
+ which the user has no pre-established relationship must only be
+ granted after explicit user consent, and that consent needs to be
+ granted for each non-safe API separately. Note that it isn't
+ obvious whether this consent is truly informed, or that the user
+ understands all the issues involved. This is discussed further
+ elsewhere [[DAP-PRIVACY-REQS]].</p>
<p>The user may need to gather more information before making a decision on granting access to a given API: e.g. reading the site privacy policy or getting more information on what the collected data will be used for. To make it possible for the user to make an informed decision, the user consent interactions need to be non-blocking.</p>
@@ -231,8 +246,15 @@
<p>To that end, it should be possible to describe
platform-independent and declarative policies that determine which
APIs can be used from what Web site or application.</p>
+ <section id=delgated-authority-story1-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>The access control policy language MUST be device-independent.</li>
+ <li>The access control policy language MUST be declarative.</li>
+ </ul>
</section>
- <section id='delegated-authority-story2'>
+ </section>
+ <section id='delegated-authority-story2'>
<h4>User Story: Third-party protection against malware</h4>
<div class="story">
<p>Alice keeps a lot of her private and sensitive data on her phone. Having heard that her friend Charlie has had troubles with a phishing attempt recently, she would like to use a service to increase her safety.</p>
@@ -253,26 +275,50 @@
</p>
<p>This policy needs to be integrity-protected during various points in its life-cycle.</p>
+ <section id=delgated-authority-story2-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>Integrity protection and source authentication of the access
+ control policy MUST be
+ supported, not only in transit but also storage.</li>
+ </ul>
+ </section>
</section>
<section id="delegated-authority-story2a">
- <h4>User Story: User-defined cross-devices policies</h4>
+ <h4>User Story: Transfering remembered choices to another device</h4>
<div class="story">
- <p>Dave has been using advanced features on the Web from his phone for quite some time, and has thus accepted and rejected permissions from a large number of Web sites on his device.</p>
- <p>But Dave is now looking to the brand new phone released by ACMEdev, and would like to migrate his settings to that new phone, which also uses a different browser.</p>
- <p>Dave’s operator offers him to transfer seamlessly these settings from one phone to other, and informs him that they can also be used on his other connected devices.</p>
+ <p>Dave has been using advanced features on the Web from his
+ phone for quite some time, and has thus accepted and rejected
+ permissions from a large number of Web sites on his
+ device.</p>
+ <p>But Dave is now looking to the brand new phone released by
+ ACMEdev, and would like to migrate his settings to that new phone,
+ which also uses a different browser.</p>
+ <p>Dave’s operator offers him to transfer seamlessly these
+ settings from one phone to other, and informs him that they can
+ also be used on his other connected devices.</p>
</div>
<h4>Analysis</h4>
- <p>If user decisions
- are themselves expressible in the policy language, then they can be
- preserved by encoding them in a local policy. Similarly, user
- configuration settings should be possible in the policy
- language. This means that the policy document is not just a
- way of creating
- an initial policy configuration, but can be the sole and complete
- representation of the access control configuration at any time.
+ <p>
+Remembering earlier decisions and
+maintaining these choices when changing devices either across vendors or
+device versions has value to the user. This may also be the case when
+wishing to have the same choices on multple devices. It should be
+possible to transfer or share a
+representation of user choices across devices at any time.
</p>
+ <section id=delgated-authority-story3-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>Access control policy MUST be able to record user decisions
+ regarding policy configuration at an appropriate level of
+ granularity.</li>
+ <li>Access control policy MUST be portable across devices and
+ not bound to specific devices.</li>
+ </ul>
+ </section>
</section>
<section id='delegated-authority-story3'>
@@ -283,11 +329,11 @@
<p>Dave checks the widget, sees that the only special permission it requires is access to messaging features, and feels confident that he can now install it.</p>
</div>
<h4>Analysis</h4>
- <p>An initial security policy configuration may be
+ <p>An initial access control configuration may be
provided by an external
authority, together with any other associated device
configuration (such as
- root certificates). The configured policy may
+ root certificates). The configured policy may
determine access control policy
without reference to the user, or may refer certain
decisions to the user.</p>
@@ -307,26 +353,13 @@
<section id='delegated-authority-case-rqmts'>
<h4>Requirements</h4>
- <p class="note">The management of security policies and revocation mechanisms are out of scope of the Device APIs and Policy Working Group charter.</p>
<ul>
- <li>The security framework MUST express policies in a device-independent manner.</li>
- <li>The security framework MUST express access control policies in a declarative manner; this declarative language SHOULD be in an XML syntax.</li>
- <li>The security framework SHOULD make it possible to record
- security configuration choices and interactive policy
- decisions using the policy language.</li>
- <li>The security framework SHOULD make it possible to update portions of policy independently.</li>
- <li>The security framework MUST provide integrity protection and source authentication for policy.</li>
- <li>The security framework MUST NOT preclude different authorities defining the security policy.</li>
- <li>The Security Framework MUST be applicable to Javascript and define a Javascript binding</li>
- <li>The security framework MUST be compatible with the
- same origin policy.</li>
- <li>The security framework MUST support sufficient granularity
- for sensible access control decisions.</li>
- <li>The security framework SHOULD allow users to have control
- over general configuration of security
- decisions</li>
+ <li>It SHOULD be possible to update portions of policy independently.</li>
+ <li>Access control policies MAY be associated with
+ different authorities, including the user.</li>
</ul>
- </section>
+ <p class="note">The management of security policies and revocation mechanisms are out of scope of the Device APIs and Policy Working Group charter.</p>
+ </section>
</section>
</section>
<section id="threats" class='appendix'>
@@ -339,23 +372,24 @@
The landscape that is being created
is the enablement of
cross-platform, cross-device, easy to develop, highly functional
- applications based on browser technology that has been proven
- repeatedly to be untrustworthy - a perfect recipe for evil. Will
- this meet all the criteria for really successful malware on
- mobile devices for example?
+ applications based on browser technology. Experience with
+ security attacks suggests that the increase of scope and
+ power of the Device APIs raises the potential for attacks of
+ increasing significance. This section outlines some known threats.
</p>
<p>
Up until now the measures taken by the mobile industry have
proven highly successful in ensuring no major malware incident
has affected the industry. There have been attempts: the
- MMS-spreading Commwarrior is probably the most infamous, along
+ MMS-spreading Commwarrior virus is probably the most infamous, along
with the Spyware tool, Flexispy. An additional factor in
ensuring the success of mobile security has been the fact that
mobile platforms have been too fragmented and complex, therefore
not representing an attractive target so far. Existing modus
operandi from technology-related attacks can provide indicators
as to the types of attack and abuse that can be expected on
- widgets and web applications as device APIs are opened up.
+ widgets and web applications as device APIs are opened up
+ and the size of the mobile market increases.
</p>
<section id="premium-rate-abuse">
<h2>Abuse Case AC1: Premium Rate Abuse</h2>
Received on Thursday, 6 January 2011 23:35:46 UTC