--- a/paq/prov-aq.html	Tue Feb 26 18:12:07 2013 +0000
+++ b/paq/prov-aq.html	Tue Feb 26 18:24:04 2013 +0000
@@ -1130,7 +1130,7 @@
         Secure HTTP (https) SHOULD be used across unsecured networks when accessing provenance that may be used as a basis for trust decisions, or to obtain a provenance URI for same.
       </p>
       <p>
-        When retrieving a provenance URI from a document, steps SHOULD be taken to ensure the document itself is an accurate copy of the original whose author is being trusted (e.g. signature checking, or use of a trusted secure web service).
+        When retrieving a provenance URI from a document, steps SHOULD be taken to ensure the document itself is an accurate copy of the original whose author is being trusted (e.g. signature checking, or use of a trusted secure web service).  (See also <a class="sectionRef" href="#interpreting-provenance-records"></a>.)
       </p>
       <p>
         Provenance may present a route for leakage of privacy-related information, combining as it does a diversity of information types with possible personally-identifying information; e.g. editing timestamps may provide clues to the working patterns of document editors, or derivation traces might indicate access to sensitive materials.  In particular, note that the fact that a resource is openly accessible does not mean that its provenance should also be.  When publishing provenance, its sensitivity SHOULD be considered and appropriate access controls applied where necessary.  When a provenance-aware publishing service accepts some resource for publication, the contributors SHOULD have some opportunity to review and correct or conceal any provenance that they don't wish to be exposed.  Provenance management systems SHOULD embody mechanisms for enforcement and auditing of privacy policies as they apply to provenance.
@@ -1140,6 +1140,14 @@
       <p>
         The pingback service described in <a href="#forward-provenance" class="sectionRef"></a> might be abused for "link spamming" (similar to the way that weblog ping-backs have been used to direct viewers to spam sites).  As with many such services, an application needs to find a balance between maintaining ease of submission for useful information and blocking unwanted information.  We have no easy solutions for this problem, and the caveats noted above about establishing integrity of provenance records apply similarly to information provided by ping-back calls.
       </p>
+      <p>
+        When clients and servers are retrieving submitted URIs such as provenance descriptions and following or registering links; reasonable care should be taken to prevent malicious use such as distributed denial of service attacks (DDoS), cross-site request forgery (CSRF), spamming and hosting of inappropriate materials. Reasonable preventions might include same-origin policy, HTTP authorization, SSL, rate-limiting, spam filters, moderation queues, user acknowledgements and validation. It is out of scope for this document to specify how such mechanisms work and should be applied.
+      </p>
+      <p class="TODO">
+        Is CSRF a real threat here?  How?
+      </p>
+      <p>Accessing provenance services might reveal to the service and third-parties information which is considered private, including which resources a client has taken interest in. For instance, a browser extension which collects all provenance data for a resource which is being saved to the local disk, could be revealing user interest in a sensitive resource to a third-party site listed by <code>prov:hasProvenance</code> or <code>prov:hasQueryService</code> relation. A detailed query submitted to a third-party provenance query service might be revealing personal information such as social security numbers.  Accordingly, user agents in particular SHOULD NOT follow provenance and provenance service links without first obtaining the user's explicit permission to do so.
+      </p>
     </section>
  
 <!-- ===================================================================================== -->