1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00

XEP-0363: refined requirements and security considerations after LC

This commit is contained in:
Daniel Gultsch 2020-01-20 12:18:10 +01:00
parent 9150d39f4e
commit 35271059af

View File

@ -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 clients 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>