The state of Arizona was sending at least 140 illegal subpoenas to money transfer companies to compel them to turn over private financial data of 145 million individuals, amassing it in a huge database and giving virtually unfettered access to thousands of officers from hundreds of law enforcement agencies across the country.

All the activists i know irl use facebook to coordinate sometimes illegal activity

I cant. How'd you do it?

Checks reportedly happening anywhere randomly, including at streets and entrances to shopping malls

cross-posted from: https://midwest.social/post/296777 > A guy I know contributed to this article so I'm sharing it here.

I asked a fellow techie who has worked in cybersecurity close to 20 years what his opinion of Signal is and this is his response: Signal is secure for three reasons that this objection cannot address. Firstly, it is open source, mostly. The only code that has not been seen is the deployment playbooks for the server itself; they don't release these to prevent people from deploying servers. Secondly, the way that Signal performs encryption is mathematically solid, and no one that understands cryptography argues otherwise. Finally, and most importantly, Signal encrypts, decrypts and stores messages on your device. All the server does is route messages, and that is literally all. I helped advise on a pamphlet that is coming out in the next week or so, which gets into this in extreme detail. The question that emerges in this scenario is whether or not the third party can be trusted, and in this case that question is irrelevant. The operators of Signal only have access to the date a number registered and traffic logs. The server essentially sits there and routes messages. When a message is sent into the server the headers of the message route the message to the proper recipients, with the proper public keys used for encrypting the message for each user. That data is verifiably not stored anywhere, and would only be accessible to a person sitting on the server logging that activity live. In that situation the question of the third party doesn't matter because the third party cannot influence the communication, except to shut down the service. A similar model applies to KeyBase, which uses a different, but equally valid encryption scheme. The big differences, and the reasons I do not recommend KeyBase are two fold. Firstly, KeyBase has been audited, but large parts of the code are not open source, and so it cannot be audited independently, only by contractors paid and under NDA. All outward signs are that it is doing what it says it is, and the companies that have tested the framework, and validated it, are reputable, but still I prefer the ability to have neutral third parties audit code. Secondly, KeyBase stores a lot of data about a user, if you provide it, and encourages users to have filled in profiles. These often include names of groups one is a part of on the platform, social media accounts, and a number of other pieces of information about the user. There are other frameworks, like Briar or Cwtch, which are really awesome, but are more technical and have smaller user bases, making the adoption much more difficult. These frameworks provide additional security advantages over Signal (such as routing through Tor), but for the vast vast majority of security contexts these advantages are not very meaningful. So, sort of like Tor Browser, Signal ends up being used due to longevity, scale of use, and usability, combined with solid security and cross-platform support. The reason some projects have been moving to Element, over just using Signal, is the ability to have threaded discussion rooms, as opposed to being in like 9000 Signal groups, like a lot of us are. The reason that they discourage deploying Signal servers (you still can if you really want to and can figure out how, the code is there) is due to the core functionality of the Signal framework itself. If one were to run their own server no one using the main Signal server could communicate with someone using this other server. That means that for this second server to be usable one would need a massive user base. Then the problem becomes scale; one needs to scale the infrastructure to address this number of users. But, then one runs into the problem of needing to secure that infrastructure, and there is the core issue. Signal is relied upon by dissidents in situations far more precarious than ours, and its security guarantees are not only based in encryption, but also in their ability to secure assets within Signal's infrastructure. If that infrastructure were to be compromised, then it is feasible that messages could be distorted or blocked and additional logging could be done by the attacker. So, in order to not encourage a practice that could get incredibly vulnerable people attacked by the state if we are not incredibly careful. Personally, I would love for there to be a way to utilize the Signal protocol more easily, in order to write services that can be used safely by a small userbase for dedicated uses. This is possible, and the Signal protocol can be used outside of Signal, as a framework and infrastructure (WhatsApp and Facebook Messenger do this). The big issue there is development time. There are people working on things like this, but being that these things are questions of life and death, none of these experiments have been able to be resilient enough for full release.

Half an hour of crazy man rambling

Hello and thank you for subscribing. For privacy-related posts in Norwegian, we recommend https://nrsk.no/c/privacy. You can [access and subscribe to it through lemmy.ca](https://lemmy.ca/c/personvern@nrsk.no). Users of other instances can search for "https://nrsk.no/c/personvern" and subscribe through their own instance.