Gone now? yes. garry understandably didn't like how he could read anyones PM's from the database n shit. He's looking into a new alternative tho for this forum. for now, you can just @ people in one of the unofficial PM threads if you need to get soemones attention
Alright. Thank you Postal!
As a heads up though you can still access the message feature on the old site (until it's taken offline)
you can also download an archive of your messages if you need them
https://files.facepunch.com/forum/upload/1755/1a04cbca-6c6f-4a35-b774-894361c7953f/image.png
I like how the old PM system with an insecure backend has been replaced (temporarily) with the most insecure messaging system imaginable, where all your messages are in a public thread
Just uhh, shamelessly plugging this here:
https://forum.facepunch.com/f/meta/bslsh/The-Grand-Unofficial-Not-So-Private-Private-Message-Substitute-Switchboard/1/
It is a hold over until they figure out an actual solution, I don't think anyone is trying to pretend it is better than the previous option in anyway ya silly.
the difference is that there isn't an expectation of privacy here
Related, what about profile messages?
Personally I do all my illegal computer stuff in full view of a police officer.
Does anyone actually care about garry being able to read PMs? Not having it be strictly secure isn't exactly a dealbreaker for me, because it's not like I would use it to send *actually* sensitive stuff anyway. When people wanna send PMs now, they kinda go around the issue by sending DMs over Discord or other similar services, which surprise, another third party could theoretically read aswell, and I imagine people similary don't care. All that really matters for a PM system is that it's somewhat shielded against public view and is relatively easy and quick to use. If I ever actually need something that's actually private and I dont want garry to see, I probably wont resort to this forum anyway.
I'm a big stickler for privacy, but at the same time if I'm looking for a secure method of communication, Facepunch isn't exactly the first place I'm going to turn to. I post on here with the expectation that my stuff can and will be made public. I don't mind if my PMs get compromised because of that mindset because I'm not going to be foolish enough to use PMs for sensitive information. At most, I'd just tell someone in a PM to add me on this secure messaging service to hit me up if I really needed to send something confidential, which has never happened.
At the same time, though, it might be Garry trying to protect his ass. Piracy happens here, we all know it. Maybe people are sharing illicit things through PMs in some form or another (stuff that we don't know about because we can't see all the PMs, maybe worse than piracy.) If he can shield himself from it he has plausible deniability in court if something happens, thus protecting him. That's a bit of a reach of a theory but it's a somewhat realistic concern.
I never use a website without full expectation that the site op can view absolutely everyfuckingthing I type, let alone actually post.
Could use end-to-end encryption. Each user has a private key which is required to open the message, and only the encrypted message is stored.
I think this would be a great idea. Everyone could chose to upload a PGP public key to their profile and send private messages to anyone else who made use of this feature. Messages would be truly private that way.
yes hi, as resident infosec professional (well i got a degree 2 months just haven't used it just yet)
PGP keys are a terrible idea. well they're a great idea from security, from usability standpoint they're garbage
You can actually get around that with a bit of encrytion.
Using public key crytography you can send a mesage that anyone can see, but only the intended person can read.
True, but where do you store the public key? The only sensible place to store it is FP servers, which negates the whole fix.
I've been thinking about this for a while, and the only ways I can think of to make the system secure always require some sort of user secret, like a password or a sufficiently large number, that the hoster has no realistic way to acquire. Ideally, you'd generate a keypair locally from a password the user knows, store that locally, and not storing the password itself anywhere but the user's head. I guess you could store that secret in the user's browser, but what happens when he changes browsers, or is in a different device?
The problem is when the user loses that secret, his own information (past messages, in this context) is locked to him forever, and no sufficient amount of admin intervention will work. There's no "recover password" if nobody really knows what your password even looks like.
Solving this is hard from a user experience perspective, even though the tech is all there. I wouldn't be surprised if PMs just don't get implemented at all, and are rather replaced by a "user X has asked for your contact details, do you accept?" prompt that just sends your email through to the other guy. Let someone else handle the hassle of secure communications.
No matter what, I don't see a good way for the server to not always know the contents of the message. I think it's best to focus on keeping the information confidential rather than truly secure.
What I would do is establish a single secret key in the server's code to symmetrically encrypt/decrypt the PMs as they come and go from the database.
That way, only the people with access to the FP code can decrypt the messages, but they can't do it by hand and it must be deliberate. No accidental disclosure.
If we establish that the server running the code must have access to the decrypted messages to serve them, I'd say that's about the best solution you'll get.
I'm assuming any FP employee has access to either the code, the database, and the server running the forum backend (to extract keys in env vars, for example). In that situation, any of them could snoop in and read everything, without anyone even being able to tell (unless you check the access logs, that can also be scrubbed!). Isn't that the sole reason garry scrapped the system?
The secret must be out of FP's hands for anything to make sense, IMO.
Then how do you actually decrypt the messages for the client? I can just as easily snoop outgoing messages as they're rendered on the server, assuming I had code access to it. The message must somehow exist on the server before it's sent to the client.
For what you're looking for, you'd need to essentially iframe another site's page in FP's origin and have all communication done through that service. That's really the only true method of isolating it from FP's server.
Can't you just ask the user for the password - locally - then use that to decrypt and encrypt PMs - also locally - that are stored in FP's servers? You don't need to render the message on the server, just send the encrypted message to the client and let it figure out decryption.
Well, from there you get into a pretty tricky situation where you must move one message from one encrypted inbox to another encrypted inbox, without knowing the passwords or keys for either mailbox.
I missed a step I should've probably explained first. When generating the keypair from your password, FP would store the public key internally, giving users access to eachothers' keys.
Whenever you would send PMs to other users, you'd encrypt them locally so using their public key. That way, the only thing FP would have to store for each user would be their public key and a list of messages received by other users, encrypted with the recipient's public key (so we get mostly unreadable gibberish on the database), and the only thing the user would have to hold on to would be their PM password, which directly generates their private key.
I feel like we're spamming up the thread, and that this would be much better discussed through PMs, but you know :P
right but you're asking people who don't know the intricacies of pubkey mechanics to go "don't forget this password" and then someone will inevitably forget it
Let's say for the sake of argument we were generating RSA keys for everyone. (It is, of course, one of the best pubpriv crypto methods we have)
As recommended by NIST, we'd have to generate 2048-bits of high entropy data for the key to be properly secure. A strong password is ~10 bytes long, nowhere near the necessary 256 bytes to generate a full private key.
While it is true that you can generate private keys with passwords to lock them, the private key must still exist or sync between each machine that wants to access the PMs.
And you're right, I'd love to move this to PMs, hence why I'm here coming up with solutions so we can get this feature back ASAP
I'm standing on the C side of the triad, which is what triggered garry to remove PMs after all. You want a truly confidential solution? The user has to be responsible.
There are ways to mitigate this with some clever implementations, like whatsapp does, but it all comes down to a user-known secret in the end that if he loses, he's busted.
Sorry, you need to Log In to post a reply to this thread.