The head of the Signal app has criticized plans in the EU to allow messengers to have backdoors to enable automatic searches for criminal content. Signal is considered one of the most secure messengers.
Signal CEO Whittaker said that in the worst case scenario, they would work with partners and the community to see if they could find ways to circumvent these rules. Signal also did this when the app was blocked in Russia or Iran. “But ultimately, we would leave the market before we had to comply with dangerous laws like these.”
I have become convinced by Cory Doctorow’s (tech writer and inventor of the term “enshittification”) argument that the fact that we’re even discussing this in terms of “sideloading” is a massive win for tech companies. We used to just call that “installing software” but now for some reason because it’s on a phone it’s something completely weird and different that needs a different term. It’s completely absurd to me that we as a society have become so accustomed to not being able to control our own devices, to the point of even debating whether or not we should be allowed to install our own software on our own computers “for safety.” It should be blatantly obvious that this is all just corporate greed and yet the general public can’t or refuses to see it.
TBH I was confused when I came across the term “sideloading” for the first few times because I thought it was something new. Part of the plan I guess. Damn.
That means nothing when the servers stop taking EU traffic. I get your point, but the real solution here is putting a bullet (double tap) in Chat Control, once and for all.
Signal has never done that. Whilst the app might not be available in some regions they’ve been proud to talk about how people can use it to avoid government barriers.
That means nothing when the servers stop taking EU traffic
I don’t use any of these apps, so I’m not quite sure how they work. But couldn’t you just make an app that keeps a local private and public key pair. Then when you send a message (say via regular sms) it includes under the hood your public key. Then the receiver when they reply uses your public key to encrypt the message before sending to you?
Unless the sms infrastructure is going to attempt to detect and reject encrypted content, this seems like it can be achieved without relying on a server backend.
A short message is 140 bytes of gsm7-bit packed characters (I.e. each character is translated to “ascii” format which only take up 7-bit space, which also is packed together forming unharmonic bytes), so we can probably get away with 160 characters per SMS.
According to crypto.stackexchange, a 2048-bit private key generates a base64 encoded public key of 392 characters.
That would mean 3 SMSs per person you send your public key to.
For a 4096-bit private key, this accounts to 5 SMSs.
As key exchange only has to be sent once per contact it sounds totally doable.
After you sent your public key around, you should now be able to receive encrypted short messages from your contacts.
The output length of a ciphertext depends on the key size according to crypto.stackexchange and rfc8017. This means we have 256 bytes of ciphertext for each 2048-bit key encrypted plaintext message, and 512 bytes for 4096-bit keys.
Translated into short messages, it would mean 2 or 4 SMSs for each text message respectively, a 1:2, or 1:4 ratio.
NIST recommends abandoning 2048-bit keys by 2030 and use 3072-bit keys (probably a 1:3 ratio)
average number of text messages sent per day and subscriber seems to be around 5-6 SMS globally, this excludes WhatsApp and Signal messages which seems to be more popular than SMS in many parts of the world [quotation needed, I just quickly googled it]
That is how the signal protocol works, it’s end to end encrypted with the keys only known between the two ends.
The issue is that servers are needed to relay the connections (they only hold public keys) because your phone doesn’t have a static public IP that can reliably be communicated to. The servers are needed to communicate with people as they switch networks constantly throughout the day. And they can block traffic to the relay servers.
That makes the assumption you want to use your phone number at all. And I’m sure the overhead of encryption would break SMS due to the limits on character counts.
Not officially I don’t think. And even if you did, you’d need a customized app to point to said server, and then you wouldn’t be interoperable with the regular signal network
Bruh, you’re trying to sanewash this of all things? Right now I can go to any third-party app store and click install on an app without me nor the developer having to kiss the ring of Google or by extension the regulators (EU with Chat Control) that they are beholden to.
After this I’ll have to fucking install Google’s SDK on my computer, manually download application files, and deploy them to my device over USB with CLI commands. I will never ever ever be able to get friends and family access to third-party applications after this change.
And fuck, man, there’s not even a guarantee this solution will last, either. Google promised they would allow on-device sideloading back when they started adding deeper and deeper settings restrictions on enabling sideloaded app support, their word means fuck-all and you know that.
You misidentified your objection.
It isn’t sideloading removal, which isn’t happening.
It’s developer verification, which affects the sideloading that remains available.
Just because you don’t understand the value of verifying signatures doesn’t mean it lacks value.
I recall the same alarm over secureboot: there, too, we can (load our certificates into secureboot and) sign everything ourselves.
This locks down the system from boot-time attacks.
I will never ever ever be able to get friends and family access to third-party applications after this change.
Then sign it: problem solved.
Developer verification should also give them a hard enough time to install trash that fucks their system and steals their information when that trash is unsigned or signed & suspended.
That’s twice that you’ve missed the point that everyone else is saying. Read it again:
without me nor the developer having to kiss the ring of Google or by extension the regulators (EU with Chat Control) that they are beholden to
Google is irreversibly designating themselves the sole arbiter of what apps can be freely installed in the formerly-open Android ecosystem. It’s the same as if they just one day decided that Chromium-based browsers would require sites have a signature from Google and Google alone. I honestly don’t give a shit if they did it just on Pixel devices, but they’re doing it to the phones of ALL manufacturers by looping it into Play services.
I just don’t understand: why the fuck are you so pussy-whipped by Google that you’re stanning their blatant power grabs?
I don’t understand why you can’t read: (1) developer verification can be disabled, bypassed, or worked with, (2) you called it sideloading removal, which it isn’t.
You just don’t like the extra steps that limit the ease for ignorant users to install software known to be malicious that could have been blocked.
I don’t like handholding my dumbass folks through preventable IT problems they created.
This is why we need the ability to sideload apps.
I have become convinced by Cory Doctorow’s (tech writer and inventor of the term “enshittification”) argument that the fact that we’re even discussing this in terms of “sideloading” is a massive win for tech companies. We used to just call that “installing software” but now for some reason because it’s on a phone it’s something completely weird and different that needs a different term. It’s completely absurd to me that we as a society have become so accustomed to not being able to control our own devices, to the point of even debating whether or not we should be allowed to install our own software on our own computers “for safety.” It should be blatantly obvious that this is all just corporate greed and yet the general public can’t or refuses to see it.
TBH I was confused when I came across the term “sideloading” for the first few times because I thought it was something new. Part of the plan I guess. Damn.
That means nothing when the servers stop taking EU traffic. I get your point, but the real solution here is putting a bullet (double tap) in Chat Control, once and for all.
Yes, please.
LOL, no. They’ll come back again with some other bullshit to Save the Children!™, it’s a never-ending whack-a-mole.
We need to get the right to privacy and control over our own devices enshrined as fundamental rights, like so many other rights the EU protects.
And they only have to win once, we have to fight and win every time they introduce a new variant. Its exhausting.
Signal has never done that. Whilst the app might not be available in some regions they’ve been proud to talk about how people can use it to avoid government barriers.
The CEO is saying they are willing to, that should be taken seriously.
I don’t use any of these apps, so I’m not quite sure how they work. But couldn’t you just make an app that keeps a local private and public key pair. Then when you send a message (say via regular sms) it includes under the hood your public key. Then the receiver when they reply uses your public key to encrypt the message before sending to you?
Unless the sms infrastructure is going to attempt to detect and reject encrypted content, this seems like it can be achieved without relying on a server backend.
It is potentially doable:
A short message is 140 bytes of gsm7-bit packed characters (I.e. each character is translated to “ascii” format which only take up 7-bit space, which also is packed together forming unharmonic bytes), so we can probably get away with 160 characters per SMS.
According to crypto.stackexchange, a 2048-bit private key generates a base64 encoded public key of 392 characters.
That would mean 3 SMSs per person you send your public key to. For a 4096-bit private key, this accounts to 5 SMSs.
As key exchange only has to be sent once per contact it sounds totally doable.
After you sent your public key around, you should now be able to receive encrypted short messages from your contacts.
The output length of a ciphertext depends on the key size according to crypto.stackexchange and rfc8017. This means we have 256 bytes of ciphertext for each 2048-bit key encrypted plaintext message, and 512 bytes for 4096-bit keys. Translated into short messages, it would mean 2 or 4 SMSs for each text message respectively, a 1:2, or 1:4 ratio.
Hope you have a good SMS plan 😉
That’s how signal started way back. Doesn’t work well - sms is terrible.
That is how the signal protocol works, it’s end to end encrypted with the keys only known between the two ends.
The issue is that servers are needed to relay the connections (they only hold public keys) because your phone doesn’t have a static public IP that can reliably be communicated to. The servers are needed to communicate with people as they switch networks constantly throughout the day. And they can block traffic to the relay servers.
I think they’re suggesting doing it on top of SMS/MMS instead of a different transport protocol, like Signal does, which is IP based
Which is what Textsecure was. The precursor to Signal. Signal did it too, but removed it because it confused stupid people.
I think SimpleX removes the need for static relays.
That makes the assumption you want to use your phone number at all. And I’m sure the overhead of encryption would break SMS due to the limits on character counts.
Can’t use Signal without a phone number.
You CAN use it to interact with people without them knowing your number. The only current requirement is specific to registration.
You can run your own server for signal by the look of it
Not officially I don’t think. And even if you did, you’d need a customized app to point to said server, and then you wouldn’t be interoperable with the regular signal network
Most likely the reason, among others, they’re fighting tooth & nail to remove side loading too.
Are they?
Google will soon stop you sideloading unverified apps – here’s what that means for you
ie, unsigned, so they are not
Sideloading is still available: you can sign it yourself or bypass verification with
adbas they documented.So, cool misinformation.
Bruh, you’re trying to sanewash this of all things? Right now I can go to any third-party app store and click install on an app without me nor the developer having to kiss the ring of Google or by extension the regulators (EU with Chat Control) that they are beholden to.
After this I’ll have to fucking install Google’s SDK on my computer, manually download application files, and deploy them to my device over USB with CLI commands. I will never ever ever be able to get friends and family access to third-party applications after this change.
And fuck, man, there’s not even a guarantee this solution will last, either. Google promised they would allow on-device sideloading back when they started adding deeper and deeper settings restrictions on enabling sideloaded app support, their word means fuck-all and you know that.
You misidentified your objection. It isn’t sideloading removal, which isn’t happening. It’s developer verification, which affects the sideloading that remains available.
Just because you don’t understand the value of verifying signatures doesn’t mean it lacks value.
I recall the same alarm over secureboot: there, too, we can (load our certificates into secureboot and) sign everything ourselves. This locks down the system from boot-time attacks.
Then sign it: problem solved.
Developer verification should also give them a hard enough time to install trash that fucks their system and steals their information when that trash is unsigned or signed & suspended.
Even so, it’s mentioned only in regard to devices certified for and that ship with Play Protect, which I’m pretty sure can be disabled.
Promise kept.
No, I don’t. Developers are always going to need some way to load their unfinished work.
That’s twice that you’ve missed the point that everyone else is saying. Read it again:
Google is irreversibly designating themselves the sole arbiter of what apps can be freely installed in the formerly-open Android ecosystem. It’s the same as if they just one day decided that Chromium-based browsers would require sites have a signature from Google and Google alone. I honestly don’t give a shit if they did it just on Pixel devices, but they’re doing it to the phones of ALL manufacturers by looping it into Play services.
I just don’t understand: why the fuck are you so pussy-whipped by Google that you’re stanning their blatant power grabs?
Probably works at google or is a fanboy.
I don’t understand why you can’t read: (1) developer verification can be disabled, bypassed, or worked with, (2) you called it sideloading removal, which it isn’t.
You just don’t like the extra steps that limit the ease for ignorant users to install software known to be malicious that could have been blocked. I don’t like handholding my dumbass folks through preventable IT problems they created.
They’re being precise about their terms, while everyone else is being sloppy. Not stanning
Adb is functionally useless for most people.