[-] 0807@lemmy.world 1 points 15 minutes ago

Hi, yes, everything is hosted on my own servers. And I'm not a big fan for several reasons, including this one:

Copilot was trained on publicly available code without consent and in violation of open-source licenses https://githubcopilotlitigation.com/

The source code is available here: src.0807.st, viewable without an account or registration. And you can push commits anonymously.

[-] 0807@lemmy.world 1 points 18 minutes ago* (last edited 13 minutes ago)

Hi, first of all, thanks for the kind comment, @irmadlad

Yes, you probably saw my old post (which was incomplete) and which I ended up deleting. I’ve been able to add quite a few useful things to the project, and I’ll continue to maintain it and upload updates to the subdomain (src.0807.st)

And of course, I’ll always advise people to run this locally to minimize risk :)

[-] 0807@lemmy.world 1 points 21 minutes ago

I'd say that's the most accurate comment. In life (and even more so on the Internet), people tend to destroy more than they create.

The Internet is a good thing, given all it offers us, but unfortunately there are downsides (a lot of weirdos, for example)

[-] 0807@lemmy.world 1 points 22 minutes ago

Hi, first of all thanks for the nice comment.

And yes, I'm in touch with some people who run file-hosting services, and they've helped me a lot.

Catbox is a good file-hosting service, but unfortunately it doesn't support files larger than 200MB

[-] 0807@lemmy.world 2 points 14 hours ago* (last edited 14 hours ago)

Criticizing just for the sake of criticizing is all you know how to do constantly shouting honeypot even though the src is available.

And I even recommend that people run it locally if they don't trust me (which is understandable).

[-] 0807@lemmy.world 2 points 14 hours ago

You really need to start waking up, man. The hosting service that would actually be suitable for this type of content is one with end-to-end encryption, which I chose not to implement.

As for the part where I explain to them “how to do it,” it seems pretty logical to me that anyone including me who runs a file-hosting service and responds to reports can see your files. So this “tip” that I “suggested” (in quotes) to encrypt your files is just common sense.

People didn’t wait for me to upload CSAM, and malicious actors didn’t wait for me to figure out how to encrypt their files. I won’t even address the comment about the logo, which is childish and irrelevant to the discussion

[-] 0807@lemmy.world 2 points 15 hours ago

As for TOR, that’s my biggest concern right now especially regarding abuse. So far everything’s going well, and if things get out of hand, I’ll remove the onion.

Thank you. I hope to keep the project going for as long as possible

[-] 0807@lemmy.world 1 points 15 hours ago

Yes, I took the liberty of reposting it (by creating a domain specifically for the source code) and adding some major improvements

[-] 0807@lemmy.world 8 points 15 hours ago

You read it right, BLOCKED_EXT is just an extension list and renaming walks straight past it. But that list was never the malware check, it only stops someone uploading payload.exe

Mime sniffing wouldn't have caught it either, since that value rides along in the request and a renamed upload just lies about it.

The actual defense is ClamAV, same file if you grep clamScan and CLAMAV_SCAN, and it reads what's inside the file instead of the name. I tried the calc.jpg trick for real, an EICAR test renamed to calc.jpg sent as image/jpeg, and the upload came back refused.

[-] 0807@lemmy.world 9 points 16 hours ago* (last edited 16 hours ago)

You're right, and I won't pretend otherwise. Someone determined to host illegal content can encrypt it client-side and I'd never see it.

But that isn't where most of the abuse on an open drop host comes from. The whole point of dumping that content somewhere is that the link is easy to click and the file just opens.

Client-side encryption breaks that the recipient needs the key, nothing previews or streams so the lazy and opportunistic uploads which are the bulk of it stay in plaintext.

Being able to remove what I can actually see is real harm reduction even if it never catches the careful ones. Locks don't stop a determined burglar either, we still fit them.

The deciding factor for me is reports. With plaintext, when someone flags a file I can look and pull it. With E2EE I'm structurally incapable of acting on any report even when I want to.

I'm not willing to run a server where, if you show me there's CSAM sitting on my disk, I cannot take it down. That's the line and it's not a technical one

As for the trust E2EE would buy, anyone who genuinely needs confidentiality already has it they can encrypt before uploading to any host, mine included.

So adding E2EE here would cost me all of that moderation ability in exchange for convenience my privacy-minded users can already get themselves. For a casual share-with-expiry tool, that trade isn't worth it to me. You're not wrong that it's the dilemma of file hosting.

I just landed on the side of being able to answer a report, and I'd rather be honest that the password is casual privacy than sell E2EE I'd then be helpless behind.

[-] 0807@lemmy.world 8 points 17 hours ago* (last edited 16 hours ago)

Hello, yes, the name refers to the webtoon (08/07). It’s an anthology of horror stories. https://www.webtoons.com/en/canvas/0807/list?title_no=848743

As for the stored files whose retention period is set to never they do indeed remain online I monitor their status rather than letting them accumulate unchecked.

There is a configurable storage limit and once it’s reached, the server blocks any new uploads instead of silently deleting or overwriting existing files.

There’s also an (optional cleanup feature) for files that haven’t been used in a long time, which I can enable if I ever run out of space.

With 16 TB, I have plenty of leeway and since I manage the server myself I can add disks or sort through the files manually if necessary. No files without an expiration date are automatically deleted.

And thanks I’m glad you like it :)

57
submitted 18 hours ago by 0807@lemmy.world to c/privacy@lemmy.ml

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:

SRC

Questions and criticism welcome. If you think the encryption tradeoff is the wrong call, I will read the argument

85
submitted 18 hours ago* (last edited 18 hours ago) by 0807@lemmy.world to c/selfhosted@lemmy.world

I run 0807, a small self-hosted file host. Drop a file, get a short link, and choose when it disappears.

What it does:

  • No account, no ads, no trackers
  • Auto-delete by time (1 hour up to 30 days, or never) or after a set number of downloads
  • Optional password protection on files and on text notes
  • Files up to 20 GB, with 16 TB of storage behind it
  • Reachable over Tor through an onion service
  • Text notes with the same self-destruct and password options
  • A few file types are blocked for safety (exe, bat, scripts, and similar)

PS: there is no end-to-end encryption, and that is deliberate. The server can read what is stored.

I want to be able to take illegal uploads down when they get reported, CSAM in particular.

End-to-end encryption would make the server blind to its own contents, which is great for privacy but would also stop me from acting on those reports.

If you need real secrecy, encrypt the file before you upload it. The password option is there for casual privacy (not as protection from me or from whoever might get into the server.)

The code is open, and I host it the same way I host the files, on my own server instead of HERE .

You can read it, propose a change, or open an issue there, no account needed

Happy to answer questions about the setup or take feedback.

[-] 0807@lemmy.world 13 points 4 days ago

Hello, there is currently no end-to-end encryption on the server I’ll explain why below. The reasons why

True end-to-end encryption (where I literally can't read your files) means the server only ever sees encrypted blobs. The problem is, that also means I can't scan anything, and right now every upload is checked against known CSAM and run through malware scanning.

Go fully zero-knowledge and I lose that capability entirely, which on an anonymous host is a real problem it basically turns into a blind dropbox for whatever people want to put there.

So it’s genuinely one or the other either I can see enough of the content to keep it clean, or I can’t see it at all and can’t keep it clean. I chose to keep it scannable, because for an open anonymous service, I think being able to block that kind of content is more important.

That’s the real reason there’s no at-rest encryption not laziness it would compromise security. I’m open to hearing how you’d weigh the pros and cons, though.

view more: next ›

0807

0 post score
0 comment score
joined 4 days ago