I run 0807, a file host I host myself.
You drop a file, you get a short link, and you choose when it disappears.
I am posting it here because the whole thing is built around privacy, and because I would rather lay out the real threat model than call it “secure” and let you find the gaps later.
The privacy side:
- No account, no sign up. An upload is not tied to any identity.
- No ads, no third party trackers, no analytics. Nothing is loaded from outside domains, so no fonts or scripts phoning home.
- The server does not log IP addresses or requests. The rate limiter holds an IP in memory for a few minutes to count requests, then forgets it. Nothing is written to disk.
- Reachable over Tor through an onion service.
- Auto delete by time (one hour to thirty days, or never) or after a chosen number of downloads.
- Optional password on files and on text notes.
- Files up to 20 GB.
- Executable types like exe, bat and scripts are blocked so it cannot be used as a malware drop.
The honest part, which this community will and should ask about:
it is not end to end encrypted. The server can read what is stored, on purpose.
I want to be able to remove illegal uploads when they get reported, child sexual abuse material above all. A server that cannot see its own contents cannot act on those reports, and I am not willing to run one that cannot.
So I gave up that form of secrecy in exchange for being able to take that content down.
What that means for you in practice the password is casual access control, not protection from me as the operator or from anyone who breaks into the server.
If you need real confidentiality, encrypt the file on your own machine before uploading and share the key separately.
Treat 0807 as a way to move files around with self destructing links and no account, not as a vault for secrets you cannot afford to expose.
It is open source, and I host the code on my own server instead of GitHub, so there is no third party in that loop either.
You can read every line check the no logging claim yourself suggest a change, or open an issue all without an account:
OC by developer @0807@lemmy.world
I agree with not providing the encryption, and having the user provide it themselves. If the server provides the encryption, then it could be backdoored. If you as the user can’t be bothered to encrypt the files yourself, then you definitely aren’t inspecting the client-side code yourself either.
Just be safe and encrypt the files yourself
Dear OP, ideally, if you are being honest about supplying the source code than you’d also be serious about supplying the git commit history and dev environment. The
download linkshould offer up a.gitrepo, not a.zip. Apatchwould likely cover multiple files, not be limited to one.I’m a Python dev, not a node.js dev. So you are welcome to ignore this advice; wouldn’t benefit me or you.
Yeah what’s with the homegrown repo viewer. Why not just embed a sourcehut page with some custom styling.
I am posting it here because the whole thing is built around privacy
it is not end to end encrypted.
The server can read what is stored, on purpose.So, data is not encrypted at rest or in transit.
privacy
Also, to be clear, anonymity is not privacy.
It is most definitely encrypted in transit
To have it not encrypted in transit would means it is not using https… is that the case?
it is not end to end encrypted. The server can read what is stored, on purpose.
I want to be able to remove illegal uploads when they get reported, child sexual abuse material above all. A server that cannot see its own contents cannot act on those reports, and I am not willing to run one that cannot.
How would end-to-end encryption prevent you from taking down content that gets reported? Uploads must have an associated ID, in addition to the key needed to decrypt the data, that people could report and that you could then use to identify what data to remove. Because otherwise, how could the server determine what data to deliver to a user who wants to download files that have previously been uploaded to your service.
Surely your strategy for dealing with this kind of thing doesn’t involve manually reviewing every file that has been uploaded to your server, or even just the subset of files that get reported. If it does, then people uploading manually encrypted files, as you suggest they do, would be as big an impediment to you taking down illegal content as automatic end-to-end encryption
Nothing would stop downloads from getting removed. Mega used to take down stuff all the time, because the URLs people would share would contain both the ID and the decryption key. It’s super easy to decrypt stuff and verify if it’s in violation of copyright for example.
Exactly. That’s why I don’t understand the reasons OP is giving for not having E2EE
Without the key, the server operator:
-
can’t know if the content being reported actually exists
-
can’t know if the content should actually be removed or not
An ID is needed to determine if the content exists and a key is needed to decrypt it.
Somebody making a report that there is illegal content in OP’s server, but provides neither an ID nor a key, quickly ceases to be actionable. At a minimum you need the reporter to provide upload IDs.
But even if the reporter supplies the IDs, the report may not be actionable by your standard: The uploader can easily encrypt the uploaded data, as OP themself recommends.
So OP needs a policy on what to do when they cannot inspect the content of a reported upload, regardless of wherever or not their service provides E2EE
Even if it was inspectable content, there are other ways to hide content such as steganography.
-
They want to be able to scan content for illegal contents, without users needing to report it and provide the decryption key first
That’s not what OP said they wanted:
I want to be able to remove illegal uploads when they get reported
Besides, OP’s own advice to upload manually encrypted files runs directly counter to this
You should check out my comment here. Bring-your-own-encryption is a good thing that OP is encouraging here
I’m not saying that doing your own encryption is a bad thing, but them recommending it runs directly counter to OP’s other stated goals
I’m sure OP’s goal isn’t actually to moderate content. It’s common for tools clearly designed for piracy to say “we don’t condone piracy”. OP is using a plausible excuse to not provide encryption, without directly encouraging people to use encryption themselves. Or maybe OP doesn’t realize that people can encrypt their files themselves and bypass all moderation, who knows ¯\_(ツ)_/¯
Tor
😮💨
what’s wrong with Tor?
Cool video but it’s old and barely relevant. Traffic analysis attacks are extremely difficult to pull off, especially on hidden services (since relay nodes are more distributed than exit nodes). Mixnets are cool but still immature. Tor is the best option here, and will fit the use case of 99% of users. For those who want to defend against traffic analysis, there are ways to do so that take way more time and effort, like breaking up a file into tons of tiny pieces. Up to you if you want to put in the effort.
As usual, Whonix has a great page about this: https://www.whonix.org/wiki/Speculative_Tor_Attacks
in research settings, Tor processes and anonymity protection might be seriously degraded under specific conditions. Therefore, users who are likely to be targeted by advanced adversaries should bear this in mind when undertaking anonymous activities – for a small subset, defaulting to offline activities (whenever possible) might be the only safe course of action in their circumstances.
Now, why isn’t TOR using post quantum encryption, and if you don’t care for it, why not i2p instead?
@0807@lemmy.world is the
contributecode open-source? I really like the idea and would like to have it as an option for my own projects. ThanksI don’t want to upload personal files to somebody that can look at them, and I’m not sure you want to have files that are uploaded by somebody who’s malicious. Why not do E2E?
E2E doesn’t prevent malicious uploads
