It’s amazing what a difference a little bit of time can make: Two years after kicking off what looked to be a long-shot campaign to push back on the practice of shutting down server-dependent videogames once they’re no longer profitable, Stop Killing Games founder Ross Scott and organizer Moritz Katzner appeared in front of the European Parliament to present their case—and it seemed to go very well.

Official Stream: https://multimedia.europarl.europa.eu/en/webstreaming/committee-on-internal-market-and-consumer-protection-ordinary-meeting-committee-on-legal-affairs-com_20260416-1100-COMMITTEE-IMCO-JURI-PETI

Digital Fairness Act: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14622-Digital-Fairness-Act/F33096034_en

  • qqq@lemmy.world
    link
    fedilink
    English
    arrow-up
    91
    ·
    edit-2
    14 hours ago

    Security is constantly used as a guise for removing consumer rights and as someone who has been in the security industry for about 9 years I’m so sick of it.

    First and foremost, everyone please understand: the user should be allowed to opt into your concept of insecurity: you do not know their threat model and you do not know their risk tolerance.

    Using exploits in low level drivers in the wild is approaching APT level, and even if there were a simple one to use it’d likely be useless without some sort or local access to the device (bar some horror show bug in a Bluetooth or WiFi firmware). The risk is incredibly low for the average person. I’d put it pretty close to 0.

    Wire transfers aren’t instant and for large sums (your inheritance) the banks will likely require more than just a request from your app. If the bank cares about that then they can also use the attestation APIs which would be more than sufficient, as much as I hate them.

    This boogey man of the APT going after my technologically illiterate <family member> with nation state level exploits needs to die. Long ago we entered a new era of security where it just isn’t worth it to waste exploits. Especially when you can just text people and ask for their money and that works plenty well.

    Security is not a valid reason to soft brick consumer devices at some arbitrary end of life date.

    • porcoesphino@mander.xyz
      link
      fedilink
      English
      arrow-up
      5
      ·
      13 hours ago

      Agreed, but I think a framing or two is missing here, and it only applies to a subset, is that the people of the world shouldn’t have to deal with more/larger bot nets because these things haven’t been considered.

      Another is just that the average great aunt isn’t opting into a concept of insecurity they’re simply ignorant to what threats there are. If it’s possible to distinguish between the two sets of people, or to maybe even bucket devices by potential threat, it might go a long away. I probably a lot wrong here, I just woke up.

      But yeah, agreed security is an argument that’s hidden behind

      • qqq@lemmy.world
        link
        fedilink
        English
        arrow-up
        8
        ·
        edit-2
        13 hours ago

        Yes I’m not going to take some “survival of the fittest” nonsense approach to security: consumers need securely built devices and software. This is the first line of defense always: we need to make things secure and then have secure defaults according to whatever we decide “secure” means in the context of our widget or software. Then we need to provide “advanced” (or even just “ignorant but risk tolerant”) users with the ability to change the device or software to match their definition of “secure”.

        The easiest example is secure boot. Your laptop likely has a key provided by your OEM and likely Microsoft’s key preinstalled. This is a valid “secure boot” path for the average user, provided your OEM and Microsoft don’t get compromised, which is APT territory. However you are provided with the ability to use a different key if you know how to do that. You have thus opted in to protecting your own private key but now you have more control over your device. This design is notably absent in phones, which is absolutely bananas and actually less secure in some threat models

        You could extend examples like this if you wanted. One could easily imagine a device that does soft brick itself after the EOL date to simply protect people that are ignorant of the potential risks, but also provides an advanced user with the ability to revive it in a “less secure” state. The less advanced user will then have to either learn something new or buy a new device.