There seems to be an implementation ongoing that the satellite will be able to manage the passwords for the user if he chooses so:
If I understand correctly it looks like in the future Storj has access to the user passwords as they have to be stored somehow on the satellite.
The password is only a small part of whatâs needed. You also need an encryption phrase to get an access to the content.
But this is not what that issue is suggesting.
This is for browser-managed local storage to temporary store your encryption phrase in the local browser storage.
However, even in this case (you know, server-side encryption if you use a browser to manage your data), the encryption phrase is never leaving your device.
Sorry, for me passwords = passphrases.
Are you sure? According to this, it is about satellite managed passphrases:
We have users who are interested in using distributed storage, but may not be interested in saving and managing their own encryption passphrases.
oh, I see. Never thought about this. I do not think it will be for everyone.
In my opinion, why do you need to use an encrypted cloud storage if you allow to store your encryption phrase on the third-party server?!
However, if your content is supposed to be a public anyway (web hosting), perhaps itâs not an issueâŚ
I really wonder, if that gets implemented, if Storj could be forced to disclose passwords in the future by e.g. court order.
And I also wonder if it destroys the argument that encryption makes Storj DCS GDPR compliant.
I do not think so. Perhaps only for cases, where the user decided to store their encryption phrase on our servers (who is really need that?!). But I suppose most of these cases will have a public content anyway, so nothing is required.
But as end user without access to the buckets I will never really know.
I mean those cases when I am just a customer of a service which uses Storj as storage backend. Maybe I have chosen that service because Storj DCS is marketed as zero-trust encrypted super secure storage and so I believe my data is super secure even if stored outside the EU.
But when the service has chosen to use the satellite managed passphrase option I have no way to know it.
So if this gets implemented as a end user without access to the buckets to verify, in the future I must assume that Storj has access to the passphrases.
This is easy. Use only API keys: Create Access Grant in CLI - Storj Docs
You will never provide your encryption phrase even to your browser, it will be in CLI, so definitely never leave your device.
No, I mean when I am an end user and use a service that uses Storj DCS as backend.
For example a service like this: Mydatabox | Store your files here
It is just an example but they state:
When creating your account, Mydatabox create a âbucketâ of the size selected on the Storj.io network. A bucket is simply a storage space.
They could create these buckets using the option to have the passphrases stored on the satellite. (Maybe it is even likely they will do so so they will not lose the passphrases of their customers).
As end user I donât know anything about that. But in the future I have to assume that this option has been enabled and Storj is in possession of the passphrase to the bucket(s) where the provider is storing the data.
You.
Choose how.
Your keys are stored.
Did you get it? YOU AND ONLY YOU chooses, how your keys are stored.
Sorry for caps.
You still donât understand what I am trying to say.
I try it again:
You are talking about a Storj customer.
I am talking about a customer of a Storj customer.
Do you see the difference?
Imagine Dropbox would be a Storj customer. They can choose how they store the key. Their customers canât. Do you understand now?
yes. This will depend on a provider for sure.
Yes this is what I mean.
Before that, you could be rest assured that unlike AWS or Microsoft, Storj could not look at the data, even if the wanted to because they did not have the keys.
With such a change you donât know. Maybe the keys are stored on Storj satellites, maybe they are not, depending on what the provider has chosen.
I could imagine such a feature to be a huge âsuccessâ. Imagine any provider losing the passphrases and losing access to customer data. So maybe many of them will enable that feature as a last resort.
However it sounds also like a fundamental change from Storj cannot access user data even if they wanted to to Storj might be able access your data even if you believe they canât.
Are we going to rehash the age-old ânot your keys, not your cryptoâ debate again? 
Users are all for security and ownership⌠until they realize itâs a burden as much as a feature⌠and many of them donât want to be responsible for keys/phrases that could forever lock them out of their own accounts if lost. They want someone else to do it for them, and understand the security implications. So they choose (and pay for) services that perform custody of some things for them.
I think Storj offering the option is a great idea!
You may not know if they have implemented this through their service. But then, you donât really know if they are storing the data on Storj at all. It could be somewhere else. And they are just telling you it is at Storj. The minute you trust a third party with the keys, anything can happen. That hasnât changed.
So are you saying that as a final customer, if you choose a cloud service because it uses Storj, dosenât give you any assurance of that?
Than why to choose Storj in the first place?
Maybe Storj should work on this, and give some sort of waranty or certification for that service, that assures the final customer that his data realy is stored on Storj network and the cloud service dosenât use anything else.
Second, I donât see any benefits for Storj from the fact that Storj Inc offers passphrase management for clients, only complications.
If a service canât manage itâs own keys, than it should not be a Storj client. Failing at the baisics will disqualify it from the start.
Storj is all about privacy and security. It should not compromise that in any way.
The only plausible explanation, besides the abusrd wish to stop beeing a popular and desired storage option for final customers, to me it seems that they are under pressure from US Government to do this, in order for the US agencies to have easy access to those passphrases when they need to.
Day by day I discover more and more things about Storj that contradicts the fundamentals of this project. Privacy, security, decentralisation⌠they start to seem like fairy dust. And I say this with pain in my heart, I donât try to throw mud on this project; I love this project and I always supported it, by joining and by everyday interaction with the team and forum members.
For those who want to use the traditional system of keys, it is there for you to use.
For those who have data that requires less security, they have an option of using the password system.
One doesnât impact the other. This has nothing to do with any Government request or otherwise.
