The original discussion was about Hollo but now it’s about Mastodon. They’re almost the same things anyways. And if you can have everything encrypted on a VPS it does not mean every instance owner (and even every major instance owner) will do it. Here I think we need an official requirement by Mastodon and probably a code integration so it’s impossible to have everything decrypted without breaking the federation support. The performance will be cut in half at best but at least IP and metadata mining attacks will be harder to perform.
How would encryption even make sense here? Up to the server, everything is protected via TLS. And if you don’t trust the server provider, you can encrypt all you want, but they can just read out the RAM of the VPS or they could have backdoored the bare metal hardware to do the same. As long as the server has to somehow work with the data in question, the decryption keys have to be somewhere in there.
And what do you mean by code integration? We’re talking FOSS here, how could someone prevent me from removing any “is everything encrypted?” checks in Mastodon?
Also, what does the encryption on other federated instances even matter? Without having any in depth knowledge about Mastodon, your user agent will hardly be sent to other instances, and when and what you posted is meant to be visible.
Code integration means that all Mastodon data a server stores is automatically encrypted on arrival. But even in that case it can be intercepted on decryption or in RAM as you mentioned. FDE + trustworthy provider can be a good option still. I don’t think any providers except the most sketchy ones will try to read the RAM. Anyways all of that is impossible to enforce so we’re really waiting for a breach with this one.
They’re not almost the same thing at all, and your whole position is weird given that the context is social media which is fundamentally content people want to publish publicly.
My point is not about the content. My point is about the metadata which I clearly mentioned in one of my replies. Even though Mastodon doesn’t collect much unnecessary metadata afaik there is still some required stuff. At this point I suspect you in causing a fight. Your constant downvotes are a proof of it.
What metadata is collected by third parties is completely tangential to the topic of the submission. However, as I’ve repeatedly tried to explain to you, there is no practical difference between running on bare metal which nobody does nowadays, or running a VPS. At this point it’s quite clear that you’re just trolling, so I’m going to stop here. Bye.
We’re either having drastically different definitions of metadata here or you’re just trying to fight (that is more likely). The metadata I meant is collected by the first party (the server) and includes but is not limited to IP, interaction timestamps (the most important thing), file type, user agent (approximate browser name). Also since the data on the server isn’t required to be encrypted, all account information (that can contain emails and 2FA keys) is unsafe too. At this point my suspicion of you not keeping the discussion civil is too high to continue it so I’m glad you chose to stop it yourself. I hope I could explain my point clearly and prove my innocence in this situation.
The original discussion was about Hollo but now it’s about Mastodon. They’re almost the same things anyways. And if you can have everything encrypted on a VPS it does not mean every instance owner (and even every major instance owner) will do it. Here I think we need an official requirement by Mastodon and probably a code integration so it’s impossible to have everything decrypted without breaking the federation support. The performance will be cut in half at best but at least IP and metadata mining attacks will be harder to perform.
How would encryption even make sense here? Up to the server, everything is protected via TLS. And if you don’t trust the server provider, you can encrypt all you want, but they can just read out the RAM of the VPS or they could have backdoored the bare metal hardware to do the same. As long as the server has to somehow work with the data in question, the decryption keys have to be somewhere in there. And what do you mean by code integration? We’re talking FOSS here, how could someone prevent me from removing any “is everything encrypted?” checks in Mastodon? Also, what does the encryption on other federated instances even matter? Without having any in depth knowledge about Mastodon, your user agent will hardly be sent to other instances, and when and what you posted is meant to be visible.
Code integration means that all Mastodon data a server stores is automatically encrypted on arrival. But even in that case it can be intercepted on decryption or in RAM as you mentioned. FDE + trustworthy provider can be a good option still. I don’t think any providers except the most sketchy ones will try to read the RAM. Anyways all of that is impossible to enforce so we’re really waiting for a breach with this one.
They’re not almost the same thing at all, and your whole position is weird given that the context is social media which is fundamentally content people want to publish publicly.
My point is not about the content. My point is about the metadata which I clearly mentioned in one of my replies. Even though Mastodon doesn’t collect much unnecessary metadata afaik there is still some required stuff. At this point I suspect you in causing a fight. Your constant downvotes are a proof of it.
What metadata is collected by third parties is completely tangential to the topic of the submission. However, as I’ve repeatedly tried to explain to you, there is no practical difference between running on bare metal which nobody does nowadays, or running a VPS. At this point it’s quite clear that you’re just trolling, so I’m going to stop here. Bye.
We’re either having drastically different definitions of metadata here or you’re just trying to fight (that is more likely). The metadata I meant is collected by the first party (the server) and includes but is not limited to IP, interaction timestamps (the most important thing), file type, user agent (approximate browser name). Also since the data on the server isn’t required to be encrypted, all account information (that can contain emails and 2FA keys) is unsafe too. At this point my suspicion of you not keeping the discussion civil is too high to continue it so I’m glad you chose to stop it yourself. I hope I could explain my point clearly and prove my innocence in this situation.