Hey! Chief Architect at Storj here.<p>Data on Storj is by default end-to-end encrypted with keys only the data owner controls (with optional support for sharing features). Only the data owner can decide who to share the keys with and who can see the data. Put another way, Storj can’t access data without the data owner sharing keys and access!<p>However, if the owner shares the encryption keys and provides access to others, it can be further distributed by others. Storj does not allow illegal content per our terms of use and conditions. If someone has stored potentially illegal content and shared it with others, law enforcement may seek to obtain information by way of a subpoena, warrant, or other legal process. As you probably know since you're reading this thread, often such inquiries are confidential and the recipients may be prohibited from disclosing their existence.<p>If you're interested in our encryption and security design decisions, there are a lot more details over at <a href="https://www.storj.io/disclosures" rel="nofollow">https://www.storj.io/disclosures</a>. Glad you're all paying such detailed attention!
According to web archive, it happened somewhere between October and mid-November:
The last time it was up: <a href="https://web.archive.org/web/20221021050048/https://www.storj.io/canary.txt" rel="nofollow">https://web.archive.org/web/20221021050048/https://www.storj...</a>
The first time it's gone: <a href="https://web.archive.org/web/20221114070255/https://www.storj.io/canary.txt" rel="nofollow">https://web.archive.org/web/20221114070255/https://www.storj...</a>
It could also just be a glitch as it appears it is a script that generates the .txt (and fetching external text / news as content).<p>In NSLs, you are not allowed to reveal the existence of the request.
Removing the warrant canary reveals the existence of the NSL.<p>Sometimes courts also prohibit you from revealing that you gave away user account information to the police.<p>In theory, using the (incorrect) logic of the canary warrant, you could publish a list of all user IDs and say "The police never requested the user information for these IDs below:", but this seems very gimmicky in front of a judge.<p>At the end of the day, a company that is actually subjected to NSL wishes has very little reasons to remove a canary warrant.<p>1) They cannot be sued for lying in their canary warrant as this was a properly formed court request.<p>2) It is good marketing for them.<p>3) They risk significant criminal charges for no benefits.<p>They really have no incentive to do so.
The first warrant canary will, in a day or so, be 17 years old:<p><a href="https://www.rsync.net/resources/notices/canary.txt" rel="nofollow">https://www.rsync.net/resources/notices/canary.txt</a><p>We discussed it a bit more at length a few years ago:<p><a href="https://twitter.com/rsyncnet/status/1387090538273206274" rel="nofollow">https://twitter.com/rsyncnet/status/1387090538273206274</a><p>"What hasn't gone away are the nondisclosure provisions of National Security Letters that were amended by the USA FREEDOM ACT of 2015 and the 9th Circuit Court of Appeals' ruling that "the nondisclosure requirement does not run afoul of the First Amendment."<p>...<p>"... and so we will continue. We will also continue to mirror internationally to CH and HK. A false, or coerced, publication will require cooperation across multiple continents, languages and legal regimes - all in seven days or less since we publish every Monday morning ..."
Has the use of warrant canary’s ever been tested in the US courts, especially with an NSL (or whatever they are called these days)? I don’t ever remember a case, but maybe I missed it.
It would be interesting to see a company implement this on the individual account level, rather than for the service as a whole. As it stands, while certainly interesting from a legal standpoint, I'm not sure this achieves much other than confirming that secret warrants are in use, and perhaps giving some vague indication of their frequency.
I dislike the phrasing here. The proper design of a warrant canary is to actively publish new messages on some time period. No one should have actively pulled the canary, they just didn't publish a new message.<p>This distinction, from my understanding, is important for legal reasons.
Storj has 2 ways to upload and download data:<p>1. The native Storj "uplink" command. Using this interface, a Go utility called uplink is run on the local client machine. It contacts a Satellite Node (the non-decentralized aspect of Storj) to retrieve a list of Storage Nodes that will accept the upload, then the file is split up and encrypted by the local uplink client code and sent to Storage Nodes recommended by the Satellite Node. In this case, the Satellite Node knows about the various pieces making up a file, the Storage Nodes have encrypted pieces of the file (but do not know how they relate to each other), and neither the Satellite Node nor the Storage Nodes could reconstruct the original file, even if working together, because the encryption key is stored on the local client machine only.<p>2. There is an S3 Gateway that gives Storj an S3-compatible interface. To use this, a Storj user would register a user account on the S3 Gateway, giving them an access key (login name) and secret key (password). When files are uploaded using the S3 Gateway, the access key and secret key are used to validate that the user has access to the specified bucket <i>but there is no encryption happening</i>. When data is received on the S3 Gateway, the Gateway uses the uplink technology to send split and encrypt the file and send the pieces to Storage Nodes. When a file is retrieved using the S3 Gateway, the Gateway does the reverse and sends the original, unencrypted file back to the S3 client.<p>Storj customers using the Storj network with the native Storj uplink client should have nothing to worry about as long as their local Storj key isn't disclosed.<p>For Storj customers using the S3 Gateway, it seems to me that by using data stored on the S3 Gateway, authorities could reconstruct files that were uploaded.<p>For HashBackup (I'm the author), both interfaces are supported, though the S3 interface is recommended. Since HashBackup encrypts everything locally before doing any uploads, backups stored on Storj using either interface cannot be reconstructed without a copy of the HB backup key, which is only stored on the local client machine, is not part of the backup data, and is never uploaded anywhere.
Is there a particular reason to think any of this involved national security? The "standard" warrant canary is extremely broad, and would appear to cover any kind of warrant at all.
There was <a href="https://www.canarywatch.org" rel="nofollow">https://www.canarywatch.org</a> being pushed by the EFF that now appears to be out of service.
Do you think they would be in trouble if, sat 3 months in the future, they started saying they had not received any NEW warrants in the past 3,4,5,X months?
I understand it's an open source project with p2p encryption. So for government to snoop, they must modify the code and let users download it and run the now insecure application. So in this case the GitHub code itself is a warrant canary.
Can we please repeal the Patriot Act or Freedom Act or whatever it is called now? It’s been a one-way ticket down the toilet since this travesty was foisted on the stupid scared populace of 2001. I really frame my life in America in two sections, before and after the planes hit the Twin Towers. Not because of the tragedy which it was, but because that is when the America that I know changed and started becoming twisted. Optimism gone, privacy gone, thinking gone, replaced by fear and ignorance and lowest common denominator politics and TV.