- From: Robin Berjon via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 06 Apr 2011 13:08:45 +0000
- To: public-dap-commits@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 UTC