Posts and replies

@lauren no, because @signalapp is subject to #CloudAct (= incompatible with #GDPR & #BDSG if you ever care!) and collects #PII in the firirm of #PhoneNumbers, which are at best pseudonymous but trivial to track and at most means that people inviting others without their consent comitted an illegal disclosure if PII!

• Use real #E2EE with #SelfCustody of all the keys that isn't a [www.youtube.com] #proprietary #SingleVendor & #SingleProvider solution that peddles [www.youtube.com] a #shitcoin #scam!

Give #XMPP+#OMEMO a shot: @monocles / #monocles & @gajim / #gajim.

1 [docs.monocles.eu] 2 [docs.monocles.eu] 3 [docs.monocles.eu] 4 [monocles.eu] 5 [monocles.chat]

@kkarhan @lauren @signalapp @monocles @gajim This is pretty much all false, & bad security/privacy advice.

@dalias I sincerely disagree because none of my claims got debunked and no evidence against #XMPP+#OMEMO have come up to me as of today.

• @signalapp being a #centralized, #SingleVendor & #SingleProvider solution subject to #CloudAct by virtue of being located in the #USA WILL NOT JUST BLOW UP IN PEOPLES FACES, BUT GET PEOPLE KILLED under #Trumpism!

I hope to be proven wrong, but up until now I've always been at the position of saying [www.youtube.com] #ToldYaSo!

• Whereas with @monocles you have way stricter #DataProtection (cuz there are no #DataProtevtionLaws in the #US that actually get enforced, otherwise #Musk's minions.would've been jailed of not killed for trespassing and hacking critical systems!) AND unlike #Signal, monocles [monovles.eu] doesn't demand any #PII whatsoever! https://infosec.space/@kkarhan/113999675511028742

@lauren

@kkarhan @signalapp @monocles @lauren Very few systems promoted as Signal alternatives match the cryptographic privacy properties (see: ratcheting, etc.) of Signal.

The claims about "located in the USA" and "Cloud Act" are all nonsense because the only threat to Signal users from this is availability (seizure and shutdown of the server infrastructure), not undetected breakage of privacy properties.

There are presently no systems with superior privacy properties to Signal *and* level of functionality on par with what general public expects. There are a lot (like the XMPP stuff, *sigh*, and Matrix) that are worse in both regards. If you're happy with reduced functionality, Cwtch (and possibly some other similar Tor-based systems) or VeilidChat are stronger, but it's gonna be a while before you convince normies to use them, and in the mean time they're still going to be on insecure shit like WhatsApp, FB Messenger, Telegram, etc...

@dalias @kkarhan @signalapp @monocles @lauren

Some people like to make bold statements without verifying first.

The server *can* do malicious things (even targeted, so it maybe already is happening without anyone known) that result in exactly an "undetected breakage of privacy properties". Here's an issue about this, closed with the comment that privacy features are only best-effort with no guarantee: https://github.com/signalapp/Signal-Android/issues/13842

@pixelschubsi @kkarhan @signalapp @monocles @lauren That's that sealed-sender is best effort, which is roughly equivalent to saying "trying to approximate what you'd get with a Tor-based or Velid-based approach on top of open internet is best-effort". It's still way better than all the posers who say "Signal is insecure because it's centralized, try my hand-rolled crypto instead!"

@dalias @kkarhan @signalapp @monocles @lauren

People always go with "Signal has the best crypto" to argue why Signal and only Signal. However, crypto alone is not the only thing in the world.

Good crypto might be necessary for good privacy and security, but it doesn't alone solve the problem. If Signal would send a clear test backup of all messages to their servers, all this great crypto would be worth nothing.

@pixelschubsi @kkarhan @signalapp @monocles @lauren Signal can't do that because they do not have arbitrary code execution privileges on the client. The client is FOSS and anyone can read the source, verify that it matches what's shipped, and audit what it does. Users who lack the skills or time to do that can refrain from updating right away until updates have received scrutiny.

@dalias @kkarhan @signalapp @monocles @lauren

Users, to a large degree, download the Signal app from the Google Play Store and Apple App Store. The apps shipped through this can hardly be verified by endusers. A modified version of the app could be delivered to selected users.

The official Signal app for Android is not fully open source and in its non-free parts does have a mechanism built-in that allows the code to be changed at runtime without allowing external auditors to review it.

@pixelschubsi @kkarhan @signalapp @monocles @lauren Citation needed.

@dalias @kkarhan @signalapp @monocles

Here's the link to the Signal source code dependency file importing a proprietary, obfuscated library that is known to dynamically load and execute arbitrary code from a server in the context of the calling process, thereby granting it access to everything that happens inside the app: https://github.com/signalapp/Signal-Android/blob/main/gradle/libs.versions.toml#L123

@pixelschubsi @kkarhan @signalapp @monocles @lauren Gradle is a Java build system not a runtime dynamic code injection system...

@dalias @kkarhan @signalapp @monocles

Mastodon removes the line number from the shared link in the nice preview.

In the shared file, line 123 is the reference to a proprietary and obfuscated library that is included as part of the build process. This library was never audited, but it is known to, when used, dynamically load and execute code without any additional sandboxing (thus inheriting all the permissions and access to the private files of the app calling into the library).

@pixelschubsi @kkarhan @signalapp @monocles @lauren You could have cited it by name then. I can't find any details on it right off much less whether it has RCE vectors. If you believe it does, can you please either file an issue on the tracker or provide sufficient information on where to find the evidence so that someone else can?

@dalias @kkarhan @signalapp @monocles

Honestly, "RCE" is the whole purpose of the library embedded here. That's not an issue, it's a feature, Google sells this as dynamically updating your dependency. This is why Signal cannot be made available in the F-Droid store.

@pixelschubsi @kkarhan @signalapp @monocles @lauren Again, citation needed.

@dalias@hachyderm.io @pixelschubsi@troet.cafe @kkarhan@infosec.space @signalapp@mastodon.world @monocles@monocles.social @lauren@mastodon.laurenweinstein.org I see the line number and I get the following

google-play-services-maps = "com.google.android.gms:play-services-maps:19.0.0"

@puppygirlhornypost2 @signalapp @dalias @monocles @kkarhan

For legal reasons, I can't speak about a bunch of internals of Play Services. This page https://developers.google.com/android/guides/overview?hl=en clearly shows that Google has the power to issue automatic updates to the part that is not inside the embedded library. I leave it up to your imagination that for technical reasons, some play services features (including Google Maps) had to replace IPC with dynamic loading.

@pixelschubsi @puppygirlhornypost2 @signalapp @monocles @kkarhan That's marketing copy that doesn't explain anything technical about what's going on or how an application might or might not be affected in the way you claim.

If it's only affected when the host OS has Play Services (i.e. if dynamic code delivery has to happen thru the system service), this is really a non issue, because you're already running a backdoored host OS that could interfere with any application regardless of what libraries it links. And of course de-Googled Android users would not be affected.

(See caveats about "compromised device" in my other toot.)

@dalias @puppygirlhornypost2 @signalapp @monocles @kkarhan
This has nothing to do with the "host OS". If you use e.g. GrapheneOS and run its sandboxed play services, you're affected just as well.

Also, what you call "compromised" is one of the suggested setups according to Signal and probably also the most popular setup among its users. Thus, when suggesting anyone to use Signal without any further instructions, you're practically suggesting to use something you consider compromised.