As I noted within my post, #9955859@lemm.ee (alternate link), URL thumbnail generation in Element is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.
Post Edit History
2023-10-02T00:54Z
1c1,2
< As I noted within my post #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server.
---
> As I noted within my post #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
> > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.
2023-10-02T01:28Z
1,2c1,2
< As I noted within my post #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
< > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.
---
> As I noted within my post, #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
> > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.
2023-10-02T03:44Z
1c1
< As I noted within my post, #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
---
> As I noted within my post, #9955859@lemm.ee ([alternate link](https://lemm.ee/post/9955859)), URL thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
Post Signature
ul7mHTfs8xA/WWwNTVQ9HzKfj/b+xw+q9csWf60OJrT58jMJpmsX8/BicwFodR8W
Llo93EMtboSUEtYZ+wQhaL/HmrEr6arup7gJzZgslOBWPFj5azADHSpjX9RYuvpt
Fk2muTUgJP2e+SW3BGDPmlcluw6mQOYcap84Fdc1eU47LOZprBXob97qInMK5LrL
tzNqARRtXGdogZtQYlNCqCd9eQgqTwPfxKVadmM6G3xQMh6mWQxQz56sCXqj+mlG
OqJyZIgB1UXEuVZeAO3pl9wN+cSM4eqHLHQwEd+aVeSPf75r2d7mZs+VNwr1WfMu
0sWcPh3aZLXKqdls6UJMEA==
Yeah it literally tells you in the UI before enabling it
Indeed, it does. It can be overlooked, however. I added that info to my post, though. Thank you for the note.
AcN4ig5AQaP5RPDXd4zDkAmFvg+Xp65zI6i5ossToWdpV7Ad2r7s0UAn6TRKG5NbiBOvr+ZWk8fVS8abFcXGEmEp9axEG/BOxJVSMteDTjhf74fVmRbIxik8EpYR2FA5DXTK/r6nrxxiuTTak5kNUrSi2Bb4ebdFEEhrdikuDm68jjHiXsqOS2O4JYxUhhd0qrjnzaCAtiCr1KnqyR+9eEtUDv8nx8IvAnk/9EmzSnPxn5BinJYFjM3qEh3KYyqfY//d0brUQFkbKJmqn1KGdhmzZG7SUtZPsAozJSrVFHynavEwx6SIhxAbJYojQ10RjkYYXVQ10RNmB+NiPs1Zgg==With my friend we have a bot who does this for us. Check out on maubot - at least it is mot client side work
Using a bot to generate a URL preview is an interesting workaround.
Content Signature: cLObDckmLviCA8xG832rJ8PFk9UTYN/PrdRb5/lCZkl+GsjtkMp90r6PWD+Ffxby0izyxVeDocLbJh8xrP7L3a1dUX2whEABb8mAhl+cHJqbxq07Z3SWBcroLyolMjmIfUQIgRRRB6lUhbsiwCfKcoVrf0HQchXZS+83YcyMtr+dgiIhVQar3/WMkIk+4nJ/sS+O2vz7c/RfxAzYYzFSPErFVe8Y1NWXWqPOajV/BdLS0U8239ElxUb7Q2Zq8SCgzqoOBtFbgWXTsa6lHFj4gqkRiaDzH6jlJhuO4rRZdA6E2dP+G0Ru7MexI1P6ev65I6VMWxYye0nqtdXC8Alp3A==
What is this post signature, and how does one use it and create one for their own post? Also, what is the purpose?
What is this post signature […] Also, what is the purpose?
I’m testing out some ideas that I’ve had for my posts – the signature and the edit history. They are a result of the current status of the following two issues on GitHub:
- Add the ability to view an edit history for posts
- Sign a user’s posts and comments with a private key that only the user possesses, so that server admins are unable to secretly modify a user’s content
Recently (as of 2023-10-02T03:28Z), one of the maintainers/developers for Lemmy closed those two issues with either little, or no rationale. I personally think that they are good features. Since it appears that those features are not going to be seamlessly added to Lemmy, I’m trying to see if it is practical to manually add them to posts.
Regarding the edit history: The purpose of an edit history is to solve the issue of people not knowing what changed in a post when it was edited. The main issue with a user-created, and maintained edit history, however, is its inherent the lack of trust. Its existence increases transparency, but you still have to trust that the user hasn’t lied about what is in the diff. The implementation would be to have the server generate it, but, unfortunately, the dev has removed that possibility for the time being.
Regarding the signature: The purpose of the signature was a means to ensure censorship resilience from the admins of an instance. As it currently stands, any admin can freely edit the content of a user’s posts, or comments with no one being the wiser. A signature would provide a sort of check against this. If a user signs a post with their own private key, then, by verifying the post’s signature with the user’s public key, one can be certain that that user was the one that wrote it, and not a server admin, or any other external entity. But, again, this feature has been blocked on GitHub.
The long, and short of it is this is me trying to protest what I think are silly decisions made by the devs of Lemmy.
how does one use it and create one for their own post?
The way that I am currently doing it is I take the raw content of the post, or comment (the body, and it’s formatting, including the edits, if they exist, and excluding the signature code block), generate a SHA-256 hash of it, and sign the hash using RSA-2048. For example to sign one’s post’s content, the following could be done:
- Put the raw post content into a file,
post-content.txt. - Generate an RSA-2048 private key, and output it to a file,
private-key.pem:
openssl genrsa -out private-key.pem 2048- Generate the public key, and put it in a file,
public-key.pem:
openssl rsa -in private-key.pem -pubout public-key.pem- Hash, and sign the content of the post, then output the signature to a file,
post-content.sig:
openssl dgst -sha256 -sign private-key.pem -out post-content.sig post.txt- To then be able to paste the signature as text, it must be base64-encoded:
openssl base64 -in post-content.sig -out post-content.sig.b64If you would like to verify your signature, you could then do:
openssl dgst -sha256 -verify public-key.pem -signature post-content.sig post.txtIf the signature is correct, then it will return
Verified OKThere likely exists other, simpler methods of going about this, but this method is functional.
content-signature:CEsuKEwcmfYh/3/04OTscm9G/+JNkIoAELQBxqJYe67O6qCbZZ7IuzFjes4yVVW+ntE6807wy0lmt7TU8obFLHGbVrrb+J8M+Qo/qviftMNKAux+7ASWz/z87UOGieOPRlV6PbWzpMBHdF2A5LFLdpS68adQrLNOjb5JalWRYa2vN4L6BO88doirJmHtQ8TQ4mvaNKYe0BD7BdXQkc9pzivKWVmSdZA7avb8QJLDdukgJCRHgjQXKaLnEZHfmSxfG4mUDcK0bw35GmqYLsVlN0nwj1Xdd1A0bl3sgTgCbpkpb9kdQv4L2HINJ1vCy472qG+cnor4Lt6NpdKIhUR35Q==Can’t the admins just edit it and sign with a new key? Either way there won’t be a way to know for sure who edited the comment, you could know if the original poster did it, but well they can just tell you that.
Can’t the admins just edit it and sign with a new key?
Of course, but if the signature were to change, it would no longer match the public key.
Either way there won’t be a way to know for sure who edited the comment
The goal is only to know if the OP edited it or not. It doesn’t really matter who edited it if it wasn’t the OP. The only important information would be that it wasn’t the OP.
but well they can just tell you that.
Verifying with the user’s public key accomplishes the same, and is independent of a direct audit from the user.
content-signature:qbUJz7ND/3+S+W0ptyja6zAeT0q7OyzFvJpAOr3iqbbN37+GcdAashDP8QNahRyAwA1X3tm9mh0PePV3VFDaiWzOeSNOQBwrVgnlepu+euG+07WJQT0Env8/vg+Q6qO7tcVN0vp8WGYftF5cjHCkjox2Mcu3dJ1g7ONMh+nJLIhrDTAki4nVLNJuJzznLBZJzohkW3/LBqDMjkPUDq0E3Mdulm6kUpWG8r3ECgxuOjdiHSvUS9yEjOZFpGiBibjQihAlDNqe2Rcx2kCP2H8nhJwclm667KnoinfV52z8v0zNrKlz8PIb6q+whwn6mNkisC02mQwQkStUi4SocZxaAA==How can I find your public key without going through a channel that could also have been manipulated by the admins, though? That seems problematic to me
This is indeed an obstacle in practicality. You are absolutely right in that any channel under control by the admin could be used as a means to orchestrate a MITM attack and replace my public key with theirs. The only way for this to work is for me to personally provide my public key in a separate, and secure channel like Matrix.
I would like to emphasize that this is all just an experiment for my own interest. I would certainly not recommend what I am doing to anyone else.
content-signature:nHszcVqN6q4R+QXnem7w42nxw58kNPNV3UGVK/rxBP5QBWNjoHX5WstdcuLWiiuuky0ZwXVR6zif2/+oWwRcmDtbv+FNlBOKSIVfcW1lSOQNQeBddbmBNIfP7hBjtTSVbszIZPXNzJQykEFdxh9hJVaC3eEqxYnN4oIOdxWjj+MejQ2zpG3l/BdnTLqWX3rf4HK4VPD8OMYyxTbqhtTMMje+tfCrf/EtRfgY3gd0Clm6oWw6WeD6QgQdJHgbRlDrZwIVE8F5zdtnooFcIptlo4ovJl9VX7FdBCExRW9MQJUU+3AZv5gVCZ4pZ9zZaXihGmhdNRDbAX9XQVUSSRc+1w==Makes sense, thanks for clarifying!
The goal is only to know if the OP edited it or not. It doesn’t really matter who edited it if it wasn’t the OP. The only important information would be that it wasn’t the OP.
OP can edit comment, sign with a different key and claim his comment was edited by the admins.
So we can’t know who really edited the comment unless in the default boring situation: it was OP and he signed it with the correct key which is the same as him just telling “yeah, it was me” or not saying anything at all since it’s the default.
OP can edit comment, sign with a different key and claim his comment was edited by the admins.
Dang, that is a scenario that I hadn’t considered. I’m not sure that there’s anything that can be done about it.
content-signature:h0Iy5AaMSi9fo+LeWpR1hFpbRygi066LKPL7+5aDJ4Y0mf33R8/E+wn9At+N0dvNr8HH1eAghGkpfCbfcoe5NzzcsRMgfl+qSYjrpb4DmN124DLLoFd7q55R/aqXdqqZP+4DaVTLVN5G2MKg5SPL0SMhHxTl6f4BUxhQCWy6PapqwvsG3D59hVQtNlgm4/ab7oo5ORIR+ENV59+rrssNxaNBsKud4rths93SFMCf/si3Uewo0VNCorTb/KUMoZaHv21zmneq5UxZRkqXD3ZR4/H7vDILWArp350OSpZxm69kTJAeBH3VuvYkKunMlouzsxEJqdLDaaApYWwSyyUYLQ==Why not just host your own lemmy instance on a cheap vps and be satisfied you’re the only admin heh
Aha, yeah that is also an option. If signatures are possible, it would be less maintenace compared to hosting an instance. Also, I think other instances can still overwrite your data should they choose. It’s just stored data after all – if it’s not inherently tied to the user, then anybody can modify it; having federated servers only increases this attack surface.
That doesn’t make any sense… If the URLs are server side that means there is no e2ee at any time because the server has to know when to shown the preview…
If that’s true disabling preview generation doesn’t really matter because the vulnerability would be elsewhere
I never used matrix, but do clients own the keys or are they stored on the server?
If you look at this documentation it outlines various methods of generating URL thumbnails. Essentially, a separate request from the client for only the URL is made to the server which then returns a thumbnail. It’s an absolutely moronic design choice, if you ask me.
EDIT (2023-10-02T01:35Z): Do note that the link that I provided is for Synapse v1.37 – Synapse is currently on v1.97. Curiously, the documentation for the new versions of Synapse have removed the sections talking about URL previews. I’m not sure what’s up with that.
RT373YSQwMB+y28d7xm/Xybihcmx9jgkd4RskvPuoFQ3hapIv4exdmtMe+QxsVqos5odxTVuKAftj53zXFFQyD7MK0985zDvfKYjIj+b+8rNSAG0fArG2SXVBW0mLXqRnXiZXiknoPekyu7MKr1aD8k9DMQzCap60oNWmOLoCQXdmEetiEnhGL8zW2KR9P4MxtzxMzLzPWJyLmpLbXVJdxTmHFN32IvMHiyY29iJqZegmIuav0+IP2c3leGrJs75eGW2uWoj8J8VWWzflWfRRO3FwzJFRIvrptPN0osD0wMrgLJ4FYwXZQetIEJ99TxWvxqTYak90q6HxvVygOyHPw==I agree. That’s a terrible choice to me.
Why would they not just offload this as a feature for the client to handle? At least then the security and privacy ultimately would be up to the user’s decision.
Post a link to a channel of 1k users and 1k users send a request to the website, instead of only the server once?
/edit: From a privacy standpoint I’d really trust my chat server provider over random websites. So I definitely don’t see how it’s a terrible choice for these two reasons.
That being said, if you’re concerned, disabling previews is the answer.
Post a link to a channel of 1k users and 1k users send a request to the website, instead of only the server once?
That would only happen if the URL is generated on the recipients side. What Signal does, for example, is it generates the preview on senders side, and sends the preview with the URL, so the preview is only generated once.
/edit: From a privacy standpoint I’d really trust my chat server provider over random websites. So I definitely don’t see how it’s a terrible choice for these two reasons.
What do you mean? How would “random websites” come into play?
That being said, if you’re concerned, disabling previews is the answer.
Thankfully, they are disabled by default.
content-signature:qGFf4UPQ4M6XKPDbSyjOuKK5erMVrib4GPgJTPSifQT6qiijr1MRJxucdCk8rBol/AB+Blsv+aVn1zxs6D8cHttXu7E0uZuGYuS1UyYq/sVyjW6XSgvwpMqmozHaLh61+je8LDeFXVyR8t+okNYEzugMcmZsbes4gPchoxkkk9Mpo9AzIkmh40JEiz3WTrLMOT6Kwc5B0SIu3QENq2ucqSPUJ9HfOM4yMhYV57wQgk6VyssUWRlntq9RD3gauVa2CKi7g21LppoUiVRoxuxlalXM6azmza4M1z3cAK/F2x8ZEaeQbHjec3Q8LD4/w50dWN5hhuRyGdQTRqY+U0ACLA==Fair points. I’d say it depends on what we’re focusing on.
Maybe a good compromise would be to have the account that sent the message generate the preview. At least that way you’d maintain E2EE and save the webserver some unnecessary demand.
I can also see how this could be less reliable (because we’re now relying on a client with all sorts of variables) and less safe (malicious sender could mask malicious links with benign previews) than the server method but it all depends on which you prefer more.
After thinking about it in this situation, previews are just a nightmare to deal with privately and I’d probably just want to turn them off.
Have you posted a suggestion on github? I feel like this was a proof on concept during development and maybe it was forgotten about further along the life cycle.
Have you posted a suggestion on github?
There are existing issues on GitHub:
- Option to generate URL previews at the receiving client, not the server
- Consider making the sender generate url previews, as with e2e thumbnails
OmPLoYXUOIPhnGr5krVHtCI4knI0pbb4zO/7u4iEWtsBXQbEFOJQITsUYRtvd+9lQvbuKYgEF8tip5O7mZcvgFRNdE2jUR+IE9ewoi5prn7pNTx4+xKR5vgVpXYaixpLI1qMMA+iXD+XobZJRGz9nHi+vzcTMkyHD0X6UpS2GVYztqgghxyxkMhvneR2PtwnjJo/KUi5KAtD4Le/p6wAxS/SZHSzKJIS4vflTayYU/zfZhlc/ElDPy/hoZAeLmq3fWJDMQN5ZPIyS9/mMp+/CkIfRj/GvkDfI2+OdHW23WACezuMHBnvO4w2LPakLDasUKpeUx7bJrNdC1qBcDIDAg==
Is there a way to disable client image loading in general?
Syphon does this by default, but I can’t find an equivalent setting anywhere in Element
