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.
I just finished writing a code test which creates and queues for delivery an end-to-end encrypted email-like message in somewhere around 10-15 lines of #Kotlin code.
Think about it. It's starting getting real. SQUEEEE!!!
🚨 Important update from @signalapp 🚨
The latest update (v7 on Desktop):
✅ Keep your phone number hidden
✅ Choose to share a username instead
✅ Take control with new privacy settings - You decide who finds you by phone number.
Today, a district court in Nevada is hearing a case about whether Meta should have to comply with the state AG’s demand for a temporary restraining order to stop Meta from offering end-to-end #encryption (#E2EE) on Facebook’s Messenger for children in Nevada under the age of 18.
"This is a full-on attack on encryption. If Nevada succeeds here, then it’s opening up courts across the country to outlaw #encryption entirely. This is a massive, dangerous attack on security and deserves much more attention."
If you believe the good guys need to have a way to get around encryption, you either haven’t thought about it enough, or you’re not one of the good guys.
Fascinating ... Apple joins Signal to provide the most secure end-to-end encrypted messaging protocols. Note: Apple engineers created their own “Levels” and magically theirs is the highest. ;) But regardless, this is obviously strong encryption.
"Support for PQ3 will start to roll out with the public releases of iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4, and is already in the corresponding developer preview and beta releases.”
iMessage quantum security arrives with iOS 17.4 - @9to5Mac
This would have been the perfect article to remind people that all of this E2EE doesn’t matter if you backup your iMessages in iCloud, where they will be backed up clear-text to Apple/NSA, unless both parties turn on Advanced Data Protection