🇩🇪 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.
“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
This was an easy blog post for me to write! There is so much wrong with the State of Nevada’s request for an injunction to prevent Meta from rolling out end-to-end encryption in Facebook Messenger. For starters, WhatsApp has had E2EE since 2016, Apple iMessage since 2011 … and more.
Hopefully the district court in Nevada will agree and NOT allow the injunction! We’ll see.
Last night we joined an effort to stop the State of Nevada from making it easier for children’s personal information to be obtained by child predators, criminal gangs, foreign nations, and others.
Together with the ACLU, @riana , @eff , @CenDemTech , @mozilla , @fight , and @signalapp , and Access Now, we filed an amicus brief asking the court to protect children by ensuring they can use the most secure communication possible!
End-to-end #encryption is essential to secure comms on inherently insecure internet+has been available by default for years from other messaging services. Denying children the opportunity to use #E2EE encrypted messaging does not protect them, but instead exposes them to danger.
To security experts: Do you use #VPN for services that are already end-to-end encrypted? Or, you add their apps in split-tunnelling mode?
Or, to rephrase it: is there any use in keeping end-to-end encrypted apps behind a VPN?
This is under the assumption that all things are equal (no ISP issues; no need to bypass any network set up; end-to-end encryption is enabled by default).
The Going Dark High-Level Group is suggesting that the EU should be more like China/Iran and block access to communications services which do not comply with (also suggested) EU law on lawful interception for all types of communications services ("level playing field"), including of course secure #E2EE OTT services.