You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
End-to-end encryption API
Now that end-to-end encryption for teams is available, will there be any API support for this feature?
Hi josuegomes , currently there are no plans to support the API with encrypted files/folders. But I'll share that feedback with our team.
Thank you!
apfund
Dropbox Product Manager
Dropbox Product ManagerI appreciate your perspective. To clarify, when talking about API support for end-to-end encryption, I'm referring to whether we plan to extend our API support to enable developers to integrate end-to-end encryption functionality into their applications or workflows,. However, I understand your concern about potential implications for the security of end-to-end encryption. It's crucial for any extensions or integrations to maintain the same level of security and privacy protection. Thanks for highlighting this aspect.
Are you serious? 🧐 What means "API support" in this topic context? API can compromise end-to-end encryption; API cannot support it!
Such type of encryption can be supported only with library code that developers can choose from (on their own opinion - something any developer can do at any time). If you want, you may share such a code in your SDKs, where developers can select, but wouldn't advised anybody (developer or end user) to rely on API or other support directly provided by Dropbox (or any other service probider). This is illogical - like a rabbit to ask for protection some fox, for instance. 😁 Such type of protection is against service providers! 😉 Its use for something else is meaningless!!!
I'm failing to understand why providing API support is a security threat.
And instead of a (closed?) library, the most secure approach is to use a public, open source encryption algorithm that can be analyzed and scrutinized by third parties. Good encryption relies on strong keys and public algorithms.
josuegomes wrote:...
And instead of a (closed?) library, the most secure approach is to use a public, open source encryption algorithm that can be analyzed and scrutinized by third parties. Good encryption relies on strong keys and public algorithms.
Hi again josuegomes,
Absolutely! I fully agree. 😉
josuegomes wrote:I'm failing to understand why providing API support is a security threat.
...
... and ... what's Dropbox API? 🤔 Is it something public you can rely on? 😀 No!
No - about the e2e protection at least. As I said, such type of protection targets avoiding info leak during transmission from one end to another end; the weakest point in this route is the service provider that would provide protection. Use either third party service (as far as you may rely there is no any relation) or organize it on your own - using library of your choice with keys algorithms selected by you or your users and unknown to Dropbox (or any other service provider).
Dropbox may improve transportation between endpoints and its servers only. That's something encrypted well with TLS 1.2 (may be better). Don't rely, as I said, a fox to protect a rabbit - something equivalent to expect service providers to organize protection targets them. 😉
Hope this sheds some light.
I'm talking about specifically about an API support. Something like a hypothetical: /upload_session/start_encrypted that only accepts locally encrypted payloads.
- apfund
Indeed, I confused "API" and "SDK", apologies and thanks for being so understanding. It's important to emphasize that only ciphertext can be uploaded and downloaded via the HTTP API itself.
To enable End-to-End Encryption (support for third-party developers, integrating the encryption and decryption logic into the SDKs(!) would be necessary. I've already shared this feedback with the team.
About Discuss Dropbox Developer & API
Make connections with other developers
