"While the UK government adopted powers that could allow the private messages of everyone in the UK to be scanned, it did concede that this could not be put into practice without jeopardizing people’s security and privacy.
ORG has called for Ofcom to publish regulations that make clear that there is no available technology that can allow for scanning of user data to co-exist with strong #encryption and #privacy.“
Proton Mail automatically encrypts/decrypts messages between Proton Mail accounts via OpenPGP/PGP.
Proton Mail supports automatically encrypting/decrypting messages between Proton Mail accounts and external email accounts that support OpenPGP/PGP or GnuPG/GPG.
Ich sehe dies nicht so und könnte sogar die #Wirtschaft extrem schaden aber erst dann wird verspätet zugesagt und wir alle haben ein #Privatsphare-Recht.
»#Europol sieht Ende-zu-Ende-Verschlüsselung (#E2EE) kritisch, #EU soll handeln:
Europäische #Polizei'chefs fordern Industrie und Regierungen auf, Maßnahmen gegen die Einführung von Ende-zu-Ende-#Verschlusselung zu ergreifen - demnach gehen den Behörden die Maßnahmen zu weit, mit denen Nutzerdaten geschützt werden.«
🇬🇧 To enable #ChatControl mass surveillance, 32 European police chiefs call for halting end-to-end encryption #E2EE. This is an attack on our security and digital privacy in violation of fundamental rights!
🇩🇪 Um #Chatkontrolle zu ermöglichen fordern 32 Europäische Polizeichefs (wohl auch das #BKA) Ende-zu-Ende-Verschlüsselungsstopp. Das ist ein grundrechtswidriger Angriff auf unsere Sicherheit und das digitale Briefgeheimnis! #E2EE
Politische Überwachungsphantasien, die mit dem Vorwand gerechtfertigt werden, "schlimmste Verbrechen wie den sexuellen Missbrauch von Kindern zu bekämpfen", sind unerträglich.
Wer wirklich etwas für Kinder tun will, engagiert sich im Kampf gegen den Klimawandel, für sichere Schul- und Radwege, für Bildung, gewaltfreie Familien, Chancengleichheit und freie Entfaltungsmöglichkeiten.
🇬🇧 New #leak on #ChatControl: Privacy-friendly and #E2EE encrypted messaging services are to be penalised with chat control bulk scanning orders. They want to turn the safest services into the most monitored ones!
Can anymany tell me how I'm "supposed" to use end-to-end encryption with XMPP?
As far as I can tell there are three totally different ways to do E2EE:
a)OTR : "[https://xmpp.org/extensions/xep-0364.html](Not intended to be a current standard), or technical specification, as better (albeit, newer and less well tested) methods of end-to-end encryption exist for XMPP. "
b)OpenPGP: There are at least two different XEPs about it. XEP-0027 is obsolete, while XEP-0373 is "experimental" but hasn't been updated in almost three years.
c)OMEMO: "Experimental" and hasn't been updated in over two years.
Is there a way to do E2EE in XMPP which is neither deprecated nor experimental? What's the "Current stable" way to do it?
Just a heads-up that #Snikket#Android has been pulled by #Google from the store. We'll work on restoring it once we figure out their (as usual) nonsensical complaints. Apologies to everyone affected. Please look at #FDroid and free yourself.
Today's excuse for delisting yet another #XMPP app?
"Your app is uploading users' Image information without posting a privacy policy link or text within the Play Distributed App."
I personally feel that this is the optimal delivery and update methodology for future software distribution.
I've written about this at length in several articles, and more and more service daemons and client software are taking advantage of this form of direct from the developers method of delivery - not just Android apps.
#FairEmail is one such app that even states in the docs that this is the preferred method, although they do support a total of four methods:
Google PlayStore - crippleware due to google funding source restrictions. In all cases, this is by far the worst distribution point for software, if not with respect for the product that the developers want to deliver, but also with regards for the privacy of the users who are tracked, mined, and themselves repackaged as a quantifiable inventory item.
F-Droid custom Dev's repo - 2nd best option, because this is built with the developer's keys when the developer decides to push the product, and contain all feature sets that the developer chooses to include.
F-Droid repo - 3rd best option, since it is signed with F-Droid's keys and typically lags by some measure of time with respect to release dates, considering that F-Droid staff pushes these out on a best effort basis, according to the time they have available to do so.
Direct from the developers Git repo - This is the best method. They push a release and the next time you open the app you're notified of an update.
This is part of the magic of Slackware's philosophy too - Patrick and team don't church it up like most distro's do (Debian and AlmaLinux quite often, quite heavily wrt customizations, use Apache or Nginx HTTP servers as examples). Slackware tries to package up software as close to how the upstream intends it to be.
In earlier articles I've published on the topic, I've focused at times on a solution to a theme proffered by #Moxie_Marlinspike, who denigrates the open source model somewhat, for being at a great disadvantage when compared to that of proprietary solutions that can update and evolve protocols, APIs, etc., on a whim, because they're centrally managed and controlled by a single dictatorial source. Microsoft is one such classic example. You simply have NO CHOICE as to when you must allow your software to be EOLed, evolve, or update itself.
Using this model, however, where a central repo, or a distributed, CDN type of repo mirroring is deployed at the origin by the development team itself, FOSS has no problem upgrading even things like protocols as they evolve. Of course, it is ultimately up to the operators of the software to allow updates and the prerogative of the developers to establish the level of nags that users of the software will experience until they permit the updates to occur, but that's beyond the scope of the basis of advocating for this type of delivery model.
Okay I think I'm bordering on hijacking this thread, so I'll make a comment about these types of shennigans by Google, and how one one hand it's certainly a huge frustration, if not an impediment to being found and adopted by users, but moreover, a predatory practice by one of the most egregious violators of personal choice in the free market of consumerism and commerce.
It may hurt being pulled like that, but IMO, I don't think there's anything preventing the good folks behind #Snikket from pushing out the kind of crippleware that google wants them to, while at the same time pushing banner splashes in the app that explain just how fricken' useless it is under the terms necessary to distribute it via that medium, and encouraging users to install it instead by following the instructions at the #git_repo for a fully featured, #e2ee secure messaging platform.
IOW, there's always a silver lining - wear this dejection as a badge of honor and as the evidence to support the fact that you're on the right track!
🇩🇪Die Grundrechtsexperten von EDRi nehmen den neuesten Rats-Vorstoß zur #Chatkontrolle auseinander. Ihr Ergebnis: Weder verhältnismäßig, noch wird Verschlüsselung geschützt.
🇬🇧EDRi's fundamental rights experts analyse the latest Council proposal on #ChatControl. Their conclusion: Neither proportionate, nor does it protect #E2EE encryption.
Um Dateien über das #Internet von Gerät zu Gerät sicher zu übermitenl ist #MagicWormhole sicher eine Lösung. Ein cool gestaltetes #WebApp um es zu nutzen gibt es ebenfalls, das #Wormhole. Wenn die #Daten nicht zufälligerweise öffentlich aufliegen sollten, dann ist dies eine Lösung bei der #E2EE funzt ohne zusätzliche Datensammlung.
“While most countries want to introduce new surveillance laws, Germany is taking the opposite approach: The Federal Ministry for Digital and Transport Affairs (BMDV) has published a draft bill that will require email, messenger and other cloud providers to use strong end-to-end encryption.”
Last week we published our response to Ofcom's Online Safety Act (UK) consultation.
We've raised concerns about the threat to free expression in requirements to proactively screen users' social media content and measures that undermine end-to-end encryption.
Yet another reason why your private messages should be stored on a server you control or e2ee (ideally, both): it's likely the pseudonyms and accounts you use can be linked back to your IRL identity... and sold to anyone willing to pay