638
Head of the Signal app threatens to withdraw from Europe (www.bluewin.ch)
submitted 11 months ago by to c/technology@lemmy.world
134 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 301 points 11 months ago (3 children)

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."

This is why we need the ability to sideload apps.

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 109 points 11 months ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 57 points 11 months ago (2 children)

    putting a bullet (double tap) in Chat Control,

    Yes, please.

    once and for all.

    LOL, no. They'll come back again with some other bullshit to Save the Children!™, it's a never-ending whack-a-mole.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 9 points 11 months ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 11 points 11 months ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 7 points 11 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 11 months ago

    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.

    • 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]

    Hope you have a good SMS plan 😉

  • permalink
  • fedilink
  • source
  • parent
  • [–] 91 points 11 months ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 9 points 11 months ago

    There are groups to support:

    And in the UK:

    Some political groups are better than others, but most politicians are clueless.

    The key is to get muggles to understand we are living in Technofeudalism and why being digital serfs is bad. The problem is ineffective competition law and that monopolies are bad. That monopolies and standards are not the same thing. I have no idea how. Most people are just naturally compliant and unquestioning of something seemingly so abstract.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 11 months ago

    In the 80's (I'm that old), many home computers came with the programming manual, and the impetus was to learn to code and run your programs on your own device. Even with Android it's not especially hard (with LLM's even less so than it used to be) to download Android Studio, throw some shit onto the screen, hit build, and run your own helper app or whatever sideloaded installed via usb cable (or wirelessly) on your own device.

    In certain cases (cars, health related hw etc.) I get why it's probably for the best if the user is not supposed to mod their device outside preinstalled sw's preferences/settings. But when it comes to computers (i.e. smartphones, laptops, tablets, tv boxes etc.) I fully agree with Cory here. Such a shame everything must go to shit.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 26 points 11 months ago (2 children)

    Most likely the reason, among others, they're fighting tooth & nail to remove side loading too.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 11 months ago (1 child)

    Are they?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 27 points 11 months ago (1 child)
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [+] -49 points 11 months ago* (last edited 11 months ago) (1 child)

    Google will soon stop you sideloading unverified apps

    unverified

    ie, unsigned, so they are not

    fighting tooth & nail to remove side loading too

    Sideloading is still available: you can sign it yourself or bypass verification with adb as they documented.

    Will Android Debug Bridge (ADB) install work without registration? As a developer, you are free to install apps without verification with ADB.

    If I want to modify or hack some apk and install it on my own device, do I have to verify? Apps installed using ADB won't require verification.

    So, cool misinformation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 67 points 11 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [+] -33 points 11 months ago* (2 children)

    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.

    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.

    Google promised they would allow on-device sideloading

    Promise kept.

    their word means fuck-all and you know that

    No, I don't. Developers are always going to need some way to load their unfinished work.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 30 points 11 months ago (3 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 10 points 11 months ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [+] -14 points 11 months ago* (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 12 points 11 months ago

    This does fuck all for "security". It's targeting, mainly, power users and puts just more hoops for developers. This has nothing with security (they should purge malware from Play store first) and everything to do with consolidating power over users.

    It's a blatant power grab and I'm surprised to see this interpreted as anything else. Arguing about semantics just helps Google fuck everyone over.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 7 points 11 months ago (1 child)

    So let me buy a goddamn phone that I can install what I want in it. Again, I do not give a shit about any phone manufacturers that want to make a walled garden out of their Android installations. I agree, it's perfect for the grandmas of the world. But Google is forcibly doing this to every goddamn phone, phone manufacturer, and Android enthusiast.

    The only silver lining is that whenever Google decides that unregulated social media services like Lemmy are not family-safe I won't have to listen to your malicious horseshit.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 11 months ago

    Seems you don't care about grandmas & gen z.

    forcibly doing this to every goddamn phone, phone manufacturer, and Android enthusiast

    They can manage.

    whenever Google decides that unregulated social media services like Lemmy are not family-safe I won’t have to listen to your malicious horseshit

    So casual users can get wrecked, yet I'm malicious? Maybe think of users other than yourself, weigh the potential losses to them by successful attacks, and consider whether OS designers have a legitimate claim in preventing exposure of known threats to casual users while still allowing power users to bypass those checks.

    You're assuming I use an Android app (trash) to get on here, and not a proper workstation or web browser. You're welcome to this "malicious horseshit" for eternity.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 11 months ago* (last edited 11 months ago) (1 child)

    developer verification can be disabled, bypassed, or worked with

    In reality this is useless given the technical capabilities (or access to the technology necessary) of nearly every android user. What percentage of them do you think has the capacity and capability to use ADB?

    you called it sideloading removal, which it isn’t.

    Strictly it ticks the box, however effectively it is sideloading removal. Arguing otherwise honestly makes me think you work for them. It's such obvious marketing bullshit "Oh, we left this tiny window open to tick the box which people can use, but almost certainly not you and even if you are capable, it's a pain in the arse". There are lots of intelligent people in my house. I'm the only one capable of using ADB without enormous effort, making it a deliberately huge barrier and even I'm not going to do it to install a trusted open source app.

    Let's be clear; the only reason they left that little window open was to have people like you say "no, sideloading is still possible" to cover their arses legally and also for actual developers, not because they care about an open ecosystem.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 11 months ago* (last edited 11 months ago) (1 child)

    What percentage of them do you think has the capacity and capability to use ADB?

    All of them: they can follow procedures, plug a cable, and push buttons if they really want to. Most won't bother: capacity isn't willpower.

    it’s a pain in the arse

    That's the idea: welcome to an effective deterrent.

    even I’m not going to do it to install a trusted open source app

    Good, then it'll deter as designed.

    the only reason

    Nah, the use cases are legitimate:

    • It will actually deter installation of malicious software once it's been identified & flagged that way in their system.
    • It also verifies install packages haven't been tampered (possibly maliciously) from their original releases.

    Malicious software on devices connected to everything including highly sensitive information poses high-cost risks that you & casual users overlook because muh inconvenience 😭. If casual users can't bother with a straightforward procedure as you say, then how prepared are they to handle the real challenges of a successful attack?

    From a security perspective, it makes sense for OS designers to choose to limit exposure to that threat to power users who can be expected to at least have a better idea of what they're getting themselves into.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 11 months ago* (last edited 11 months ago)

    Google employee confirmed. Absolute trash reasoning verging on trolling it's so ridiculous. Wild that you arguing so vehemently in favour of reduced access to use your hardware the way you want.

    All of them

    Laughable. You've obviously never worked in any kind of customer support role.

    Most people are going to melt at the steps necessary to use adb.

    capacity isn't willpower.

    By capacity I meant access to hardware. There are so many people in poorer countries out there that don't have a laptop, permission to start using one for installing adb on it but also have an android phone.

    welcome to an effective deterrent.

    I don't want an effective deterrent that effectively kills fdroid and the like. That's the whole point. I've favoured android because it's more open. The talking points in favour of it pale in comparison to the loss of freedom.

    If casual users can't bother with a straightforward procedure

    Honestly just jog on. Please. It is not a straightforward procedure and my threat model shouldn't need to include the steps you outline. There are already barriers in place that put off casual users.

    The fact that you want people to stop installing open source apps that they trust is honestly deranged. Deranged.

  • permalink
  • fedilink
  • source
  • parent