Fascinating, but wasn’t... Dropbox supposed to have client-side encryption? If the backend is recompressing JPG images, that means it has full access to the file’s plaintext. That’s a bit uncomfortable.
(I'm a former Dropbox employee who worked on related things, though not specifically the linked paper)
Edit: That's what I get for commenting before reading the paper. They literally mention deduplication in there.
This makes me believe there is no problem for Dropbox to read content in clear.
I think that's still far from being possible in practice. IIRC, the best homomorphic encryption can do now is to run simple queries on very small datasets, on a supercomputer, with performance of a 386?
I'd guess they implement it by having the client upload an encrypted version of both the original image and a thumbnail, and then decrypting the thumbnails on the client at display time. Javascript has reasonably performant crypto primitives now, so it's very doable to download data from a server, decrypt it with a client side key, and display it.
If mega can do this, it's a shame other services don't.
End to end client side encryption is a tough problem from usability. Most people don’t like being told they can’t recover their “cloud backup” if they lose their laptop or phone or forget their password.
I think even iCloud only does end-to-end for specific sensitive data.
There are special providers like SpiderOak who do this, but it is non trivial to use safely.
It would also have been possible that they did the recompession client side though, and send enough metadata to calculate metrics. I had thought that's what they were doing, to save bandwidth/reduce upload times as well as save space on the servers.