All of this user’s content is licensed under CC BY 4.0
What is the context behind this post?
Out of curiosity, what’s the output of # dmesg | grep iwlwifi
?
If nothing else, I would recommend Firefox over Brave for the sole reason of the latter being yet another Chromium browser. It would be nice if we could eat away some of the browser marketshare from Google.
A bug report has been submitted for that here.
Its not used with e2ee, is it though? At least it’s not the default and I doubt it can even be enabled.
It depends on what the defaults are for the client that you are using. Element, for example, defaults to E2EE.
Another thing is that e.g. spammers might choose to use a misleading preview. Though I suppose that’s a minor point, probably server-side previews can be tricked as well.
In my opinion this isn’t a huge deal, but you do have a point in that it could be an attack vector for phishing.
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.
What is the security/privacy flaw if the server does it? No point thinking a non-encrypted would be very secret in the first place.
What do you mean? Matrix supports E2EE.
I guess the idea is that this works with simpler clients as well. Other nessaging networks with initiator-side previews usually have single-provider clients, as far as I know.
I mean, it’s up to the client to implement URL previews, anyways; if the client is simple, then the client wouldn’t implement them. Unless you mean that the simple client should still provide other people that have non-simple clients URL previews, which would only be accomplished if the server generated them.
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==
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==
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==
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==
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==
I certainly could link my server into play as well just to keep an always online device in the mix
Yep! That should work perfectly fine.
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:
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:
post-content.txt
.private-key.pem
:openssl genrsa -out private-key.pem 2048
public-key.pem
:openssl rsa -in private-key.pem -pubout public-key.pem
post-content.sig
:openssl dgst -sha256 -sign private-key.pem -out post-content.sig post.txt
openssl base64 -in post-content.sig -out post-content.sig.b64
If you would like to verify your signature, you could then do:
openssl dgst -sha256 -verify public-key.pem -signature post-content.sig post.txt
If the signature is correct, then it will return Verified OK
There 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==
Neat idea! Although, it would probably be more practical to use a centralized model since if one peer is offline, then the syncing would not occur. That is, if my assumption is correct that you are thinking of directly syncing between 2 devices.
Have you posted a suggestion on github?
There are existing issues on GitHub:
OmPLoYXUOIPhnGr5krVHtCI4knI0pbb4zO/7u4iEWtsBXQbEFOJQITsUYRtvd+9lQvbuKYgEF8tip5O7mZcvgFRNdE2jUR+IE9ewoi5prn7pNTx4+xKR5vgVpXYaixpLI1qMMA+iXD+XobZJRGz9nHi+vzcTMkyHD0X6UpS2GVYztqgghxyxkMhvneR2PtwnjJo/KUi5KAtD4Le/p6wAxS/SZHSzKJIS4vflTayYU/zfZhlc/ElDPy/hoZAeLmq3fWJDMQN5ZPIyS9/mMp+/CkIfRj/GvkDfI2+OdHW23WACezuMHBnvO4w2LPakLDasUKpeUx7bJrNdC1qBcDIDAg==
Does your network not support UPnP? You shouldn’t normally need to port forward in order to seed a torrent, unless your network prevents NAT traversal.