Another AI slop..

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.

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 :)

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).

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

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.

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.

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 :)

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.