diff --git a/xep-0363.xml b/xep-0363.xml
index f618dc2e..e5acb625 100644
--- a/xep-0363.xml
+++ b/xep-0363.xml
@@ -32,6 +32,17 @@
     <email>daniel@gultsch.de</email>
     <jid>daniel@gultsch.de</jid>
   </author>
+  <revision>
+    <version>0.10.0</version>
+    <date>2020-01-20</date>
+    <initials>dg</initials>
+    <remark>
+      <ul>
+        <li>Remove statement about access control from  Requirements. (Statement about long randomized file names had been moved to Security Considerations earlier.)</li>
+        <li>Add section about IP address leak to Security Considerations.</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>0.9.0</version>
     <date>2018-12-18</date>
@@ -179,8 +190,8 @@
 <section1 topic='Requirements' anchor='reqs'>
   <ul>
     <li>Be as easy to implement as possible. This is grounded on the idea that most programming languages already have HTTP libraries available.</li>
-    <li>Be agnostic toward the distribution of the actual URL. Users can choose to send the URL in the body of a message stanza, utilize &xep0066;, &xep0370;, or even use it as their avatar in &xep0084;</li>
-    <li>Do not provide any kind of access control or security for file retrieval beyond Transport Layer Security in form of HTTPS and long random paths that are impossible to guess. That means everyone who knows the URL SHOULD be able to access it.</li>
+    <li>Be agnostic toward the distribution of the actual URL. Users can choose to send the URL in the body of a message stanza, utilize &xep0066;, &xep0370;, or even use it as their avatar in &xep0084;.</li>
+    <li>Anyone who knows the URL SHOULD be able to access it.</li>
   </ul>
 </section1>
 <section1 topic='Discovering Support' anchor='disco'>
@@ -347,6 +358,7 @@ Content-Security-Policy: default-src 'none'; frame-ancestors 'none';
     <ul>
       <li>Service implementors SHOULD use long randomized parts in their URLs making it impossible to guess the location of arbitrary files.</li>
       <li>Implementors should keep in mind, that without additional end-to-end-encryption, files uploaded to a service described in this document may be stored in plain text. Client implementors are advised to either use this only for semi public files (for example files shared in a public MUC or a PEP Avatar) or implement appropriate end-to-end encryption.</li>
+      <li>Up- and downloading files will leak the client’s IP address to the HTTP service. The HTTP service might not be the same service as the XMPP service the client is currently connected to.</li>
   </ul>
   </section2>
 </section1>