All of this user’s content is licensed under CC BY-SA 4.0

  • 3 Posts
  • 23 Comments
Joined 1Y ago
cake
Cake day: Aug 03, 2023

help-circle
rss
What should be used for anonymous usernames?
More often than not, the best way to hide is to simply blend in with the crowds -- this also encompasses one's choice for a username. It is relatively simple to make a single throwaway account -- just come up with a username, and off you go -- however, if one makes throwaway accounts often, the task of thinking of a unique, and non-identifiable username can become a challenge. I would argue that poeple would often resort to using a pattern employing small changes for all subsequent usernames. Such patterns can be identified to a specific user if all users have their own unique patterns. How can one reliably generate many unique-but-normal, and non-pattern-identifiable usernames?
fedilink

Why does this community, which is privacy oriented, use Discord rather than Matrix?
On the side bar it lists the following: > - [Matrix/Element]Dead > - Discord "Discord" is an active link, but the Matrix link is completely inactive. Not only is it inactive (which could have be excused as a broken link), but it is also manually labeled as "Dead", as if there is no intention of making it work. How can a community that is focused on privacy willingly favor a service that is privacy non-respecting when a perfectly functional privacy-respecting alternative exists?
fedilink

I caution mentioning both Matrix, and Element as if they are synonymous – they are not (I’m quite certain that that wasn’t your intent, but the usage of the forward slash could be interpreted as such). It may lead to confusion for newcomers. It would essentially be the same as saying “I recommend ActivityPub/Thunder” to someone who you want to introduce to Lemmy. Matrix is the protocol, and Element is simply a client that interacts with the Matrix protocol.

I personally think that it’s sufficient to recommend Matrix if one is mentioning chat-app alternatives. Of course, nothing is stopping one from also recommending a client, but I don’t believe that it’s entirely necessary.


In that case, the email provider that you use makes little difference at all. Because of the way that email works, it will always be visible in plain text (unless manually encrypted through PGP) by a third party other than the recipient at some point. There is of course the exception of, for example, direct communication happening between two Proton Mail accounts, but this is really hardly worth mentioning in any practical sense.

The long and short of it is that email should never be used for secure communications.


Are you going to audit all the code you use ? You need to trust some organizations to make the audit. You NEED to trust some entities

While lacking in practicalicy, this is not a new idea. While It is certainly not impossible to have an entity that one can completely trust, I would just argue that such certainty is improbable.

What I’m trying to get at is that one shouldn’t approach this question from an appeal to authority – i.e. Proton is trustworthy, therefore all of their services must be privacy friendly, and secure. The russian proverb “trust but verify” comes to mind.


at the very least, this is unimplementable for an email provider.

If one ignores the collection of metadata, then this is the very purpose of PGP.

I am trusting someone for my data

The point that I am trying to make is that one should never have to trust someone with their data – if all data is encrypted, for example, from a privacy perspective, it really doesn’t matter where it is stored. Of course, metadata can still be gathered, but that is, in my opinion, a lesser issue, and the user has some, if not complete control over it.

I should also say that it depends on what you mean by “trust”. My response, and original comment are under the assumption that “trust” is referring only to privacy.


The issue with email, unless you are comumnicating between two Proton Mail accounts, is that your message will likely be stored on another server which is extremely likely to be unencrypted. The bottom line is that you can never trust the rest of the infrastructure, and you have no control over it. You can end-to-end encrypt using PGP, but this is extremely impractical.


Or, better yet, one should simply not use email for secure communications.


Such a point is rather moot – one should not be using email for any form of secure communications, as it is inherently insecure.


it is also owned by the people who run it

The ownership of a service, ideally, should make no difference to that service’s trustworthiness.


Ill get straight to the question: what should i use?

Are you referring to email?


Do you trust Proton?

For starters, such a question is coming at it from the wrong perspective. One should have trust in the software – if such sowtware is, indeed, trustworthy – and not in the entity that created it. If one seeks privacy, then they should be of the mindset that every entity is malevolent.


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.


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.


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:

  1. Put the raw post content into a file, post-content.txt.
  2. Generate an RSA-2048 private key, and output it to a file, private-key.pem:
openssl genrsa -out private-key.pem 2048
  1. Generate the public key, and put it in a file, public-key.pem:
openssl rsa -in private-key.pem -pubout public-key.pem
  1. 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
  1. 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.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==

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==

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==

PSA: Do not enable URL thumbnail generation in 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: > 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== ```
fedilink