this post was submitted on 22 Apr 2026
1326 points (99.6% liked)
Technology
84041 readers
4962 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Not only games. Goes for all electronics as well.
Sick of supporting your 'old phones'? You're required by law to disclose all binary blobs as source code to let somebody else pick it up the slack.
Feeling like bricking old Kindles? Fine, but users must be able to install alternative OS on your old device.
Not providing software updates for your TV anymore after you removed features? That's your right, but so is the right of the effing device owner to install something else on it.
And it's not just consumer electronics. (caugh John Deere caugh).
And the private encryption keys they use for DRM and bootloader locking too. I doubt that would go over well, but it needs to fucking happen. It is the only way to truly have right to repair and digital device ownership.
Not to be pro-corporate/anti-repair...but I feel I have to play devils-advocate here...
That sounds like a legal and security nightmare.
If you just give binary blobs and no sources, there's no way to maintain the code/device long term. As exploits continue to be found in upstream dependencies, the hardware continues to become increasingly insecure.
But if the source needs to be released...I imagine that there are heaps of proprietary code that is still in use on "active" devices even after another model goes EoL...so if that code is released, there's instantly thousands of nefarious eyes on it.
On top of the regular zero-days that are found out when a popular product reaches EoL.
I think that's potentially a lot to ask of users. Will your technically-challenged great-Aunt switch to post-support build when her phone hits EoL, or will hackers be able to remote control her banking app and take away your inheritance before the community can even patch it (assuming there's enough community support out there for an 8-year-old Galaxy A-series...)
Then there could also be licensed code that would need to be released as well...hence the legal nightmare.
Not saying it's impossible...in fact, I greatly agree with your stance and stated position. Just saying that there are some blockers on this epic.
I can't believe this is so heavily downvoted for pointing out flaws in the expressed/written stance while still expressing they agree with the general position
I think the worst risk with this would be data leaks from that government database.
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 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.
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
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.
That's seems pretty reasonable, it just sounded in you post like you were so emotionally invested in how often security is used as an out that you were ignoring that the post you were responding to brought up some valid points about security for some segments of the population that aren't as knowledgeable as you seem to be
Security by obscurity is a myth
it's a mythos.
Technically, I'd say its a stalling tactic, but yeah, by no means is it a sound, comprehensive strategy.
No. It's a valid tactic but needs to be part of a much broader strategy.
Absolute security is unachievable, but it is much harder to probe a black box to understand how it works than reading its entire manual.
This is not true.
And what part, exactly, is not true?
People like to think in black and white, but you're definitely right. Having your SSH server on port 36271 will likely stop a ton of drive by attacks because they simply won't check it. Having it only listen on IP6 would stop almost all of them because you can't trawl the IP6 space efficiently. These are "obscurity", but they have real benefits. The idea that "obscurity" doesn't help is just a meme that people love to quote because it's a great single sentence with some nice rhyming "security by obscurity". I assume the reason it became a meme is because tons of products fully relied on obscurity; I still see it all the time. As you said, it's all layers.
Yep! I don't know a single engineer who would say that security by obscurity is never useful. Everyone knows, as you said, to put SSH on a random port. It's the first step you do to secure a server.
I mean really the whole thing. Security by obscurity is no security at all. Device search engines like shodan exist and seeking out specifically insecure devices becomes easier by the day.
Absolute security is achievable, but comes with costs. If I'm willing to airgap everything and never go online, only using my own code, my device will be safe.
Black box testing is MUCH harder than white box testing, especially as, and I hate to say it, AI based security scanners become better and better at identifying flaws in source code. Having more information about your target is always the first step in penetration testing, and more information is ALWAYS better.
The difficulty of black box over white box is the reason obscurity has benefits...
You're going to write your kernel and bootloader as well? Drivers for the hardware? And a compiler for those? And an assembler to build that bootstrap compiler? Build the CPU? The second any of these are "out of your control" you lose "absolute security". The reason people say there is no "absolute security" is that it is not a useful concept to even consider. Since you have to approach it theoretically, you can easily end up stuck at the fact that every computation changes the state of the world and thus every computation can in some way be measured. It's a useless endeavor even if it were theoretically possible because it leads you to absurd solutions against absurdly powerful attackers. You want security in a well defined threat model not some "absolute".
Air gapping isn't sufficient to prevent communication either. For example there are functional TCP stacks working over audio. Silence on the Wire is quite old at this point, but also explores esoteric exfiltration methods.
This comment... Confuses me.
This is exactly why security by obscurity is a valid tactic. It hides information and makes a system harder to attack.
No, it's not. Every system has flaws. Using your own code is especially a bad idea, as it is much more likely to be flawed than a 20 yo open source project. Your airgapped device may be secure from remote attacks, since it is not connected to any network, but if it is stolen, that means nothing.
Absolute security is impossible.
That implies any and all FOSS project should be getting exploited constantly, especially those being run by a community of hobbiests, and that is simply not the case.
There's been a notable uptick in supply chain attacks coming from the odd FOSS dependency.
Fortunately the FOSS environment as a whole, ironically, reflects the best aspects of a "free market" in the capitalist sense. If a package is no longer maintained, or poorly maintained, or the maintainer is a douche/Russian asset, it forks and many users jump ship to the newer package.
Users have full transparency into how the sausage is made. Everybody does.
So if exploitable code is discovered, it can just as well be discovered first by a defensive researcher (non-inclusive term: white-hat) or offensive researcher (black-hat).
And if an offensive researcher discovers it first, they have a choice:
Submitting bad code to a project in itself though. Some new user with no reputation is going to be heavily scrutinized putting a PR on a large/popular project. And even with a good reputation, you're still putting the exploit code out there in the open and hoping none of the reviewers or maintainers catch it.
Uh, sorry to comment besides the subject, but could someone explain why white-hat is non-inclusive? I'm not trying to argue it is not, but I had not heard that and I can't find any answers by searching about it
There's been a push in IT (and I assume other industries as well) towards inclusive-language.
Part of that is moving away from phrasing that has non-technical historical connotations...like using "leader/follower" or "primary/secondary" instead of "master/slave".
But another part is also getting away from catagorizing things as good/bad on a white/black spectrum. We no longer blacklist things, we denylist or blocklist them. Likewise we no longer whitelist things...they get allowlisted or permitlisted. We don't have white-hat/black-hat hackers...we have defensive/offensive, or blue-team/red-team.
Afaik it's still okay to refer to plugs and prongs as female and male, as that is referring to biological sex moreso than gender. But yet, people gasp when I refer to plugs that have a sheath over them as "uncircumcised".
Aahhh, yes of course, the classic white-good evil-black problem. Thanks for the answer!
They are exploited constantly. And fixed constantly.
That is not a corporations problem who's given away the rights to his product. That is my problem as an informed user, deciding that I know well enough about what I'm doing.
Security can't be the constant reason for EoLs. Especially when there's no real reason beyond the company needing the next cash cow.
This isn't for the average user. My grandma isn't gonna learn how to flash a custom firmware on her old phone. But an informed user can.
Right now, if your device has no more support, you can use it until something else changes and it becomes incompatible. Then you have a dead box that doesn't do anything anymore, and simply because the company decided to no longer support it.
It's about having the OPTION to use it in the future so the community can at least try to fix it.