And a good one too. I'm currently maintaining https://0bin.net, and because we encrypt everything client side, people feel like they can post anything they want. We get some pretty personnal stuff.
They really should not. It's a can of worms. We can get compromised. Bought. Receive a court order (we comply with dmca). Or they could be on the wrong URL (typo squatting, phishing...).
Don't trust random online services with your data. FOSS or not, the code we serve can only be trusted as far as you and I we can be. And you don't know us. And you will make mistakes.
Now I'm guilty of it too, I share passwords with 0bin sometimes. But at least it's my service, I can assess the level of threat.
People post the full links (including the key) everywhere, so regularly, we google a bit to check what people use us for.
This allowed us to discover we were pretty popular on the crypto community and in specific fan fic subreddits. Which lead us to implement btc tipping and reader mode.
We also got reports, tickets, dmca, etc.
We cannot brute force our thousands of paste encrypted payloads, but for a sample, it's easy to follow the bread crumbs. And if we do it, others do it too.
>The goal of 0bin is not to protect the user and their data (including, obviously, their secrets).
>Instead, it aims to protect the host from being sued for the content users pasted on the pastebin. The idea is that you cannot require somebody to moderate something they cannot read - as such, the host is granted plausible deniability.
The titles aren't encrypted. Perhaps people are putting personal data in the titles of their posts, or hinting at personal data in the encrypted portion? Which is still a problem since the code served by the site has access to the plaintext, even if it's not normally sent back to the server. It would be trivial to change the code to send the plaintext or encryption key to the server, or just weaken the encryption somehow. Even if you trust the site operators they could be ordered to implement a change like that with an NSL, and prohibited from talking about it.
As they say in the FAQ, the encryption is there to provide plausible deniability for the operator of the site, not to protect the users' data.
Titles are rarely used, but I did receive emails of users saying "woops, can you delete this ?" with very personnal content.
Which is why we implemented the delete feature (creating a paste gives you a cookie that allows deletion) recently because we don't want to spend time on customer service for a free site.
Super easy to set up with Vault, it just hooks into the cubbyhole engine. The one-time-token is also the decryption key for the data store. I find it great for myself and the occasional email but also wouldn't really want to have others use it too much.
Up to now we just delete it. We coded an admin for that. It takes time because we have to read the claim and assess the legitimity of it, not for the deletion.
Assessing said legitimity is tricky. Not because people lie, up to now they have been pretty decent, but because you really don't want to be tracked while following potentially child pron links, so it may take time.
Scaling moderation could become a problem if 0bin becomes more mainstream, but with so few reports, it's not a problem right now.
They really should not. It's a can of worms. We can get compromised. Bought. Receive a court order (we comply with dmca). Or they could be on the wrong URL (typo squatting, phishing...).
Don't trust random online services with your data. FOSS or not, the code we serve can only be trusted as far as you and I we can be. And you don't know us. And you will make mistakes.
Now I'm guilty of it too, I share passwords with 0bin sometimes. But at least it's my service, I can assess the level of threat.