Sooo. The latest Storj LinkedIn article mentions partner W3 Cloud.
Which is even localized like
- https://w3.io/de
- https://w3.io/fr
- maybe even more (not tested)
And this links to:
Check it out.
Maybe you want to pass to the team that the browser tab on https://console.w3.cloud/login or https://console.w3.cloud/signup still displays Storj.
As a lot of effort has gone into hiding the Storj name everywhere else, I am assuming it should not show up there as well.
Even more as using the login/signup link in the console page, changes the browser tab title from Storj to W3.io storage:
1 Like
There’s something shady with W3. They have a node program too (that initially pays random “$DUBS” tokens, but apparently will switch to USDC once they make money)… called Knights.
Which made me think maybe it was a complete reskin of a Storj node or something… but… you don’t run the node you pay them to run it for you.
So it’s another rent-a-masternode system: today you’re paying real cash ($40/month) to rent a Knight node… and you get “participation tokens” worth nothing. Cloud mining at it’s finest… 
Their marketing is also all AI-generated… which isn’t bad in itself… but they aren’t catching the most basic typos.
Maybe Storj is going down the Wasabi route… to have their storage+compute resold/rebranded by as many different partners as possible? And not every partner is going to be an angel… 
Great find.
Maybe also this:
So Storj and W3 Cloud have the same customers? Except Vivint. Vivint is as we all know a Select customer. Maybe W3 cloud will be a new brand for the Global network?
Oh, a stablecoin… At least something appropriate.
But hold on. To be able to earn stablecoins you will first have to hand out your fiat. I know there are people willing to provide resources for free, but I’m not sure there is a single soul willing to pay a company to be allowed to provide resources for that company.
The way the rental-masternode systems usually work is they give away their own token for as long as possible (which is free: the masternodes aren’t real: they’re just airdropping tokens to customer wallet addresses). Then when enough of those customers threaten to leave… they start paying back USDC at $1/month. Then $2/month etc… all the time customers are “renting” their node for $40/month
When people see their returns are growing… they’ll stick around… thinking eventually they’ll break-even then make money. But magically even though they keep paying $40/month… they’ll never get payouts of at least $40/month. Then the project posts that market conditions haven’t been ideal, and thank everyone for their participation… and they disappear.
I don’t know if that’s what W3 is doing. But they definately claim to be selling 1000 “Knight” nodes to a special list of initial customers… that would make them $40k/month… and there’s no roadmap to when those customers would ever make a penny in profit 
1 Like
Still many left:
Exactly. Totally not just a-number-in-a-webpage . Magically they’ll never quite run out… there’s always a few left for a new person to rent. But act quickly: space is limited!
(right??? 
)
Once in a lifetime opportunity!
1 Like
Beggars can’t be choosers.
1 Like
The company mentioned on w3.io is the same that is the sender of the mails when you signup to w3.cloud:
Hi Science, Inc.
1532 S. Washington Street
Denver CO 80210
So an US company also. With that you can find a press release:
Also what I noted, there doesn’t seem to be an option for self managed passphrases and no password required to create buckets. So I guess Storj managed encryption is the default here which means according to the docs:
- Encrypts objects using a passphrase stored (encrypted) in the satellite’s database.
- Automatic (Storj-managed encryption): Storj securely manages the encryption and decryption of your project automatically.
@Alexey
So they/Storj have potentially access to all files uploaded there. They are encrypted but they have the passphrases, correct?
The difference between the self-managed encryption and the satellite-managed encryption you can see there:
More details about the automatic encryption:
Thanks.
From the links I understand it that way that the randomly created project passphrase is stored encrypted in the satellites database. And to decrypt it requires a master passphrase which is stored securely on Google but is also in the memory of the satellite during its lifetime.
As I understand it this means with the master passphrase, any satellite stored project passphrase can be decrypted and therefore any file in there.
So the question is who can access the master passphrase. Of course this would be the satellite and obviously access is restricted. But and this might be a key for potential customers looking for more data sovereignity: Can Storj be forced e.g. by judges under the CLOUD ACT to handover the master passphrase to US authorities or forced to decrypt specific customer projects when US authorites demand it? It’s my impression that technicall this would be absolutely doable and when using w3.cloud there is no built-in way around that compared to using Storj natively with its self managed passphrases option.
Actually no. There is no master encryption phrase for the automatically encrypted data. As far as I understand, we cannot access the automatically encrypted data besides the project name, bucket names and prefixes. The data content is still encrypted and there is not an easy way to be decrypted even with a full access to the database. However, if someone get access to the account, then they could get access to the data too (for the note - they are separate services, so you need to hack much more services, than the one distributed database with own security options, even for the emplyee it’s not easy to get access to).
Thus a more secure option is to use the self-managed encrypted phrase. Even if your login creds and 2fa are breached, the malicious actor still cannot access the content, but they could delete your data, unless there is also an object lock in a compliance mode, in that case even we cannot delete it without deleting of the entire account (this option also does not have a self-service).
Ok, maybe I misunderstood.
I took it from your links:
The master key and store - The master key will be used to encrypt and decrypt passphrases.
This is part of the Satellite that will be responsible for fetching the master key at startup, and encrypting and decrypting passphrases at the request of another service that can manage a project. It will keep the master key in memory throughout the lifetime of the Satellite.
So it was my understanding that there is the encrypted passphrases for a project and the master key that is required to decrypt it. As it referst to fetching the master key on startup and keeping it in memorey during the entire lifetime of the satellite, it sounds like there is one master key for all projects to me.
Yes, that is accurate as far as I understand. Unfortunately as a US company, we can probably be required to provide decrypt-able data uploaded via satellite managed encryption to the authorities. From a technical perspective, it would be extremely annoying and inconvenient if we ever had to do this, because we don’t currently have any tooling to support this (to my knowledge), but I don’t think “we don’t have the tooling to support this” is a legally valid excuse to not hand over the requested data 
If you care enough about data sovereignty/privacy and want to ensure that it is not possible for Storj to share your privately uploaded data without your consent, you should be using user managed encryption. Just be aware that user managed encryption is only as secure as your encryption passphrase, and that there are quality of life/user experience things that are only available with satellite managed encryption.
This is also true. With our whitelabeled satellite solutions, we can support a wide variety of configuration options, including any of [user managed encryption only, satellite managed encryption only, satellite and user managed encryption]. If the whitelabeled satellite (or a satellite in general) has only satellite managed encryption enabled, then that data is all theoretically decryptable by Storj, who controls the master key. Ultimately this is a decision that comes down to our discussions and agreements with specific whitelabel customers.
To finish up my comment, I wanted to clarify that this is not an issue with Storj specifically, but rather an issue with US-based cloud companies generally. The same absence of true data sovereignty exists with Storj’s competitors, with the main difference being that Storj does offer the option for the user to fully manage their own encryption keys, and that with user managed encryption, Storj truly cannot decrypt your data.
I also wanted to make sure to point out that satellite managed encryption did have a lot of thought put into it from a security perspective. While it is true that the one who holds the keys can unlock the door, that doesn’t mean that the door is inherently insecure. Please see my comment here on Github for some arguments about why satellite managed encryption can actually be more secure for a lot of users.
3 Likes
AS i herd from Pavel Durov interview, US has a law that every employ can be asked to put backdoor to system for US government to use and do not tell about it to anyone or face legal consequence’s.
It is very good that code is open source, but s3 are not. I mean it is very hard to check that S3 gateway do not copy all keys to somewhere. not main application, but some additional app.
I think what Vadim wants to say is that there’s no guarantee that Storj Inc’s gateway-mt is actually running exactly what is published in the github repository.
1 Like