> This is a console friendly pastebin that allows binary files.
No fancy website, no intermediate pages to click through, and no CAPTCHAs.
The site is cool, but is it not just going to be abused?
The site is cool, but is it not just going to be abused?
The full code for the service is here: https://paste.fulltxt.net/42
The command-line paste tool was this simple script: https://paste.fulltxt.net/txtp
In another distant past, I ran an URL minification service at http://uzy.me/, and there too because of spams, I had to discontinue it.
Spam is really killing the internet… This actually saddens me.
If you play the good citizen and encrypt the files, giving the key to the owners, then you also don't have any means to preemptively detect and delete that stuff, you just keep waiting on some law agency knocking at your door. Also, if you openly say "hey I'll peek into your files to see if they are legal", then they will be the ones encrypting. Disallow that? It's a nightmare to detect and abusers are really, really creative! So much dedication too!
And it's not just CSAM, there will be detailed instructions on practically any illegal thing you couldn't even imagine.
It's bad, really bad, and I've grown to accept that small, closed community services (best with real-world connections) are the only way forward.
Our first technology, community, serves a purpose after all.
I run it on my LAN for my own use, which is what I think it's best for, but I really don't like having something like this on the web.
Luckily, I've never advertised or shown it off so nobody but myself uses it, but I'll probably take down the demo site too, soon.
EDIT: Typo
The project is already open-source on Github, but I don't actively link to it in public forums because I don't want to have to deal with it being used for questionable/illegal content, which is also the reason I haven't added some of the features I'd like to, and severely limited the size and duration for the demo site.
It's been a nice toy project, I added multiple architectures support for the Docker image builds when I was working out how to do that, manifests to deploy it in Kubernetes when I was first learning that and even made it a Nix flake when I first started playing with NixOS; The code itself is written in Go with a goal of using zero external (outside of standard library) dependencies, keeping the code small and clean for non-programmers to be able to understand and uses some Go features that were new/interesting to me at the time they were added.
It'd need to grow a lot and forgo some of those goals for me to add the features I would like to see, but for something nobody will use, and I use quite sparingly myself, there's no need.
This is why (for example) Google Drive and OneDrive have become so popular despite Dropbox being first to market.
There’s plenty of other file transfer solutions out there too but you’ll find the un-siloed ones will be lesser known than the siloed ones simply because of the power of $$$
I would personally suggest that this site probably "wants" accounts. Yes, with CAPTCHAs (on registration.) If you want to be able to ban people who abuse your service, you'll need some thing-that-is-costly-to-get-multiple-of to ban them by. Otherwise they just keep coming back.
To still be a "console-friendly pastebin", the result of doing that costly registration process, could just be a page that gives you a (private) URL, that works like the base URL does now. https://paste.c-net.org/b/{bucket} or something, where {bucket} is a UUIDv4, or anything else with enough entropy to not be able to brute-force enumerate your way into someone else's account URL.
The uploaded files themselves could still have short human-writable top-level paths, for ease of repeating them over the phone.
Though, I notice that when you upload a file, you get a "delete key" as well as a URL. IMHO the "delete key" shouldn't be a weird nonstandard header you send with an HTTP DELETE; it should just be a URL — e.g. https://paste.c-net.org/b/{bucket}/{delete_key} — that you can HTTP DELETE directly.
In other words, make /b/{bucket}/{delete_key} the file's "true name", and /{link} a "read-only view" of the file.
Is there a hash database or something that could be queried to block known bad stuff? (would probably fail in the face of compression or encryption, but catching the low-hanging fruit would at least probably handle any potential legal liability?) Seems like something useful AI would actually work well for, if FBI/publishers/etc., would train a model and release it or host a service with an API.
Actually No. It take 5 minutes to create a script to randomize a password, encrypt and upload.
Abusers have been doing the same for 20+ years and it is very effective.
For example, hosting a password-protected binary with a cleared hash is one thing. The bad actor posting a password (any password) might be another.