W3C home > Mailing lists > Public > public-dap-commits@w3.org > April 2011

2009/dap/contacts Overview.html,1.119,1.120

From: Robin Berjon via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 06 Apr 2011 13:08:45 +0000
To: public-dap-commits@w3.org
Message-Id: <E1Q7STV-000287-1o@lionel-hutz.w3.org>
Update of /sources/public/2009/dap/contacts
In directory hutz:/tmp/cvs-serv8136/contacts

Modified Files:
	Overview.html 
Log Message:
editorials, section 3

Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/contacts/Overview.html,v
retrieving revision 1.119
retrieving revision 1.120
diff -u -d -r1.119 -r1.120
--- Overview.html	6 Apr 2011 12:56:29 -0000	1.119
+++ Overview.html	6 Apr 2011 13:08:42 -0000	1.120
@@ -204,110 +204,91 @@
 
     <section>
       <h2>Security and Privacy Considerations</h2>
-
-      <p class='note'>The overall architecture for addressing privacy in DAP is still under construction. As it
-      is finalized, there may be changes made to this API to reflect requirements or support for
-      privacy-related functionality.
-      </p>
-
       <p>
-      The API defined in this specification can be used to find contact information from a user's address
-      book(s). This discloses information related to a user's contacts such as their phone number(s), email
-      address(es) 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
-      of this specification MUST provide a mechanism that protects the user's privacy and this mechanism should
-      ensure that no contact information is retrievable without the user's express permission.
+        The API 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
+        of this specification MUST provide a mechanism that protects the user's privacy and this mechanism should
+        ensure that no contact information is retrievable without the user's express permission.
       </p>
-
       <section>
         <h2>Privacy considerations for implementors of the Contacts API</h2>
-
         <p>
-        A <a>user agent</a> MUST not retrieve contact information to Web sites without the express
-        permission of the user. A <a>user agent</a> MUST acquire permission through a user interface, unless
-        they have prearranged trust relationships with users, as described below. The user interface MUST
-        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) MUST be revocable and a <a>user agent</a> MUST respect revoked
-        permissions.
+          A <a>user agent</a> MUST NOT provide contact information to Web sites without the express
+          permission of the user. A <a>user agent</a> MUST acquire permission through a user interface, unless
+          they have prearranged trust relationships with users, as described below. The user interface MUST
+          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) MUST be revocable and a <a>user agent</a> MUST respect revoked
+          permissions.
         </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
-        MUST seek the user's express permission if and when any additional <code>find</code> function is called
-        on this API.
+          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
+          MUST 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 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 authorise the retrieval of contact information.
         </p>
       </section>
 
       <section class="informative">
         <h2>Privacy considerations for recipients of contact information</h2>
-
         <p>
-        Web sites owners that retrieve contacts information using this API are denoted as recipients
-        below.
+          Web sites operators that retrieve contacts information using this API are denoted as recipients
+          below.
         </p>
-
         <p>
-        Recipients should only request contact information when necessary, and only use the contact
-        information for the task for which it was provided to them.
+          Recipients should only request contact information when necessary, and only use the contact
+          information for the task for which it was provided to them.
         </p>
-
         <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
-        delete this information.
+          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 unauthorised access. If contact information is stored, users should be allowed to update and
+          delete this information.
         </p>
-
         <p>
-        The recipient of contact information should not retransmit the contact information without the
-        user's express permission. Care should be taken when retransmitting and use of encryption is
-        encouraged.
+          The recipient of contact information should not retransmit the contact information without the
+          user's express permission. Care should be taken when retransmitting and use of encryption is
+          encouraged.
         </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
-        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.
+          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
+          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.
         </p>
-
         <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.
+          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.
         </p>
       </section>
-
       <section class='informative'>
         <h2>Additional implementation considerations</h2>
-
         <p>
-        Further to the requirements listed in the previous section, implementors of the Contacts API 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 User Agent 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.
+          Further to the requirements listed in the previous section, implementors of the Contacts API 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
+          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.
+          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.
         </p>
       </section>
     </section>
Received on Wednesday, 6 April 2011 13:08:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 April 2011 13:10:23 GMT