0807

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

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

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

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

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.