[Standards] Images in chat
peterwaher at hotmail.com
Mon Mar 14 10:24:06 UTC 2016
Thanks for your response. My answers to your comments below:
> > Hello Nick
> > Thanks for your response. Uploading the image to the XMPP server also
> > counts as uploading it to a third party. The image should be
> > considered private, not accessble to anyone apart from the sender and
> > receiver. Best regards,Peter Waher
> XEP 0363 addresses this explicitly:
> > Do not provide any kind of access control or security beyond Transport
> > Layer Security in form of HTTPS and long random pathes that are
> > impossible to guess. That means everyone who knows the URL SHOULD be
> > able to access it.
> It's true one doesn't need to go through HTTP auth (which might as well
> be considered broken at this point) or have an auth cookie on hand,
> and in that sense the images are accessible to third parties, but the
> long random strings in the path are essentially a password, stronger
> than what most people pick for a normal password. This is what Facebook
> and Github do with their private RSS feeds, and what Google Docs and
> Dropbox do with private sharing links.
Facebook, Github & Google Docs are examples of things to avoid in this case: I.e. not sharing your content with a third party. Making the URL difficult to guess still leaves the file on the server.
> Where HTTP Upload falls over is in conjuntion with end to end
> encryption like OTR. You can encrypt the URL to the image so outside
> observers can't ask for it, and XEP 363 specs that you should can
> encrypt the actual data transfer with HTTPS, but the server itself
> still sees the image. Is that what you're concerned about?
> Otherwise, it's as much third party as passing your IMs over the two
> XMPP servers is in the first place, and with the bonus that for
> self-hosted servers it's not third party at all. If you trust your
> server, you can trust HTTP Upload. If you don't trust your server then
> you need to invest in one of the other options floated. I like HTTP
> upload because it works right now, today, across any receipient server
> and even across gateways.
It's not "as much thirdparty" as asynchronous messaging between two users, as the latter can be encrypted using end-to-end encryption without affecting underlying communication patterns. Third parties, including browsers will not be able to eavesdrop on communication this way. And the problem is not solved by self-hosting your servers. There's a difference between the trust of the developer, or service provider, and the trust the client user has. These are different actors. And you also have the problem of federation, in communication. You would have to isolate your solution, which is undesireable. You cannot solve the security or integrity issues by hosting your own servers, since its not you, but your users who do not want to share their content with others, including you. The HTTP upload solves transport, but not security and integrity. The benefit of not storing something on a broker/server, is that end-to-end-encryption can be used on-top. If end-to-end-encryption can be worked into HTTP upload, it might solve the security/integrity case also, or most of the parts of it. The problem by doing so, is that you would have to update the handling of the normal http and https URI schemes to do so.
Best regards,Peter Waher
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards