TL;DR: the government take some interested in us and now we are under pressure.
Another conspiracy theory?
We have a certain number of requests to close malicious links or remove illegal content posted, and we would like users to know that we have a content policy (if it is publicly available, of course, otherwise we have no idea what is stored there by design).
Actually nothing has changed since the launch,
Maybe I’ve been bit careful after Kim Dotcom incident…
We are not a content site or a social media site, so we are not in the business of presenting/suggesting content or enabling end users to find content.
So I do not think it’s somehow related.
Some customers have requested that we manage their encryption keys for them. In such cases, we have legal and technical safeguards in place to prevent Storj from decrypting data except in cases where the customer specifically requests or there is a lawful order to do so.
That’s exactly what I meant:
If you are customer of a provider that uses Storj to store your data and they have the feature enabled that Storj manages their encryption keys then your data can be and probably will be decrypted if ordered by an US court and Storj might be even prevented to be transparent about that.
The balance between a convenience and the security, as usual. If you concerned about security - you will never use this feature.
For the content providers for example it could be not important though, because it’s public anyway.
For some open projects which collaborate on the same shared project of one of the Storj account it could be not an issue too.
There are multiple cases where it is more convenient to allow Storj to manage their encryption keys, even if it’s a less secure than manually manage them.
I personally wouldn’t use this feature for my private data, but I also use 2FA and strong passwords.
There is no doubt that this feature is convenient and we are told it has been requested by customers. I don’t want to question that.
My major point is that an end user who uses a provider that relies on Storj as a backend, doesn’t have a way of knowing whether the provider has enabled the passphrase management feature, and does not have control over this decision.
In the past, a user could be confident that only his provider had access to the keys to his data. However, with this feature, users are left uncertain whether the provider has chosen to allow Storj to manage the passphrases to their data, potentially exposing them to US jurisdiction.
As a result, end users without direct access to their provider’s buckets to verify, are forced to assume that this feature is always enabled, and that passphrases required to access their data are shared with Storj and US jurisdiction.
These providers then may also store their keys insecure, so we always educate such providers how to allow the user to specify their own encryption phrase. Or allow the user to use their own Storj access grant or S3 credentials or even API key, the satellite URL and the encryption passphrase.
And if these providers already managed the users encryption keys, their users may have had a concerns too, so for me it looks like nothing is changed. If these providers would decide to use this new feature, it become their responsibility to notify their users. I do not think that it’s related to Storj anyhow.
Yes sure, may be, may be not. Maybe the passphrase were stored out of reach of the US.
For me this looks like a significant change. Chances are that Storj now can be forced to disclose customer passphrases, whereas previously they could claim they didn’t have access to them, even when faced with a court order.