dap commit: security and privacy

changeset:   121:4bdb9d0885f3
tag:         tip
user:        Robin Berjon <robin@berjon.com>
date:        Fri Jun 22 16:55:58 2012 +0200
files:       contacts/Overview.html
description:
security and privacy


diff -r f5291a2e408d -r 4bdb9d0885f3 contacts/Overview.html
--- a/contacts/Overview.html	Fri Jun 22 16:36:38 2012 +0200
+++ b/contacts/Overview.html	Fri Jun 22 16:55:58 2012 +0200
@@ -127,10 +127,10 @@
       </p>
     </section>
 
-    <section>
+    <section class="informative">
       <h2>Security and Privacy Considerations</h2>
       <p>
-        The API defined in this specification can be used to find contact information from a user's address
+        The Intent defined in this specification can be used to find contact information from a user's address
         books. This discloses information related to a user's contacts such as their phone numbers, email
         addresses and other personally identifying information. The distribution of this information could
         potentially compromise the user's privacy, or the user's contacts' privacy. A conforming implementation
@@ -140,34 +140,21 @@
       <section>
         <h2>Privacy considerations for implementers of the Pick Contacts Intent</h2>
         <p>
-          A <a class="product-ua" href="#ua">user agent</a> should not provide contact information to Web sites without the express
-          permission of the user. A <a>user agent</a> should acquire permission from the user, unless
-          they have prearranged trust relationships with users, as described below. The user interface should
-          include the <a>document base URL</a>. Those permissions that are acquired through the user interface
-          and that are preserved beyond the current browsing session (i.e. beyond the time when the <a>browsing
-          context</a> is navigated to another URL) should be revocable and a <a>user agent</a> should respect permission revocation.
+          A <a>contact service</a> should not provide contact information to Web sites without the express
+          permission of the user. Obtaining the user's express permission to access a set of contacts does 
+          not imply that the user has granted permission for the same Web site to access more contact information.
+          A <a>contact service</a> should take great care to ensure that the user can clearly see which information
+          is about to be shared, and must not share more information than has been requested by the Web application.
         </p>
         <p>
-          Obtaining the user's express permission to access one API method does not imply the user has granted
-          permission for the same Web site to access other methods provided by this API, or to access the same
-          method with a different set of arguments, as part of the same permission context. If a user has
-          expressed permission for an implementation to, e.g. find a set of existing contacts, the implementation
-          should seek the user's express permission if and when any additional <code>find</code> function is called
-          on this API.
-        </p>
-        <p>
-          A <a>user agent</a> may have prearranged trust relationships that do not require such user
-          interfaces. For example, while a Web browser will present a user interface when a Web site performs an
-          address book request, a Widget [[WIDGETS]] runtime may have a prearranged, delegated security
-          relationship with the user and, as such, a suitable alternative security and privacy mechanism with
-          which to authorize the retrieval of contact information.
+          A <a>user agent</a> may have prearranged trust relationships with a specific <a>contact service</a> 
+          that do not require such user interaction.
         </p>
       </section>
-
-      <section class="informative">
+      <section>
         <h2>Privacy considerations for recipients of contact information</h2>
         <p>
-          Web sites operators that retrieve contacts information using this API are denoted as recipients
+          Web sites operators that retrieve contacts information using this Intent are denoted as recipients
           below.
         </p>
         <p>
@@ -177,7 +164,7 @@
         <p>
           Recipients should dispose of contact information once that task is completed, unless expressly
           permitted to retain it by the user. Recipients should also take measures to protect this information
-          against unauthorized access. If contact information is stored, users should be allowed to update and
+          against unauthorised access. If contact information is stored, users should be allowed to update and
           delete this information.
         </p>
         <p>
@@ -187,7 +174,7 @@
         </p>
         <p>
           Recipients should clearly and conspicuously disclose the fact that they are collecting contact data,
-          the purpose for the collection, how long the data is retained, how the data is secured, how the data is
+          the purpose of the collection, how long the data is retained, how the data is secured, how the data is
           shared if it is shared, how users can access, update and delete the data, and any other choices that
           users have with respect to the data. This disclosure should include an explanation of any exceptions to
           the guidelines listed above.
@@ -195,25 +182,25 @@
         <p>
           Note that even if a user gives permission to share their contact information this can have serious
           privacy implications for those parties whose contacts are shared, as they may not wish such sharing to
-          occur. This should be considered by web services when requesting and using such information.
+          occur. This should be considered by Web applications when requesting and using such information.
         </p>
       </section>
-      <section class='informative'>
+      <section>
         <h2>Additional implementation considerations</h2>
         <p>
-          Further to the requirements listed in the previous section, implementers of the Pick Contacts Intent are
+          Further to the requirements listed in the previous section, implementers of a <a>user agents</a> are
           also advised to consider the following aspects that can negatively affect the privacy of their users:
-          in certain cases, users can inadvertently grant permission to the <a>user agent</a> to disclose their contacts
+          in certain cases, users can inadvertently grant permission to disclose their contacts
           to Web sites. In other cases, the content hosted at a certain URL changes in such a way that the
           previously granted contact permissions no longer apply as far as the user is concerned. Or the users
           might simply change their minds.
         </p>
         <p>
           Predicting or preventing these situations is inherently difficult. Mitigation and in-depth defensive
-          measures are an implementation responsibility and not prescribed by this specification. However, in
-          designing these measures, implementers are advised to enable user awareness of contact sharing, and to
-          provide easy access to interfaces that enable revocation of permissions that web applications have to
-          access this API.
+          measures are a <a>user agent</a>'s responsibility and not prescribed by this specification. However, in
+          designing these measures, implementers are advised to enable user awareness of information sharing, and to
+          provide easy access to user interfaces that enable revocation of permissions that Web applications have to
+          access this Intent.
         </p>
       </section>
     </section>

Received on Friday, 22 June 2012 14:56:24 UTC