End-to-end encryption API

[josuegomes]

Now that end-to-end encryption for teams is available, will there be any API support for this feature?

[apfund · Accepted solution]

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!

[Здравко]

---

@josuegomes wrote:

Now that end-to-end encryption for teams is available, will there be any API support for this feature?

---

Haha...😁

Hi @josuegomes,

What do you mean "support" for end-to-end encryption? When such support comes up (let's hope this won't be) the end-to-end encryption will stay... like a joke. 😀 Do you understand what you ask for? You ask for remove/ban of this feature actually - it'll become meaningless! If even possible (not needed implemented), then it's already meaningless such an "encryption" (especially in quotes) usage.

The promise that this will be evaluated as an option denotes that... no such feature actual exists at all. It's just a marketing trick. 😉 Let's hope this is just @apfund' confusion (misunderstanding the nature of such feature).

Good luck.

[apfund]

I 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!!!

[josuegomes]

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.

[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.

[josuegomes]

I'm talking about specifically about an API support. Something like a hypothetical: /upload_session/start_encrypted that only accepts locally encrypted payloads.

[Здравко]

---

@josuegomes wrote:

I'm talking about specifically about an API support. Something like a hypothetical: /upload_session/start_encrypted that only accepts locally encrypted payloads.

---

Is something preventing you to do so?! 🤔🙂

You don't need special support. Missing of such a support and not rely on such make your code even more secure! 😉 In such a way Dropbox cannot distinguish (or not directly at least) between encrypted and unencrypted content.