Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
I'm talking about hardware though. Even before you get into whether or not software can be trusted you should understand that computer chips have a very large number of undocumented processes that can run on them. Some are actually used only for testing purposes, but there really isn't any way to verify everything that happens on the physical machine itself. You just have to trust the people who manufactured it (ie. total strangers).
Absolutely. Open hardware is also incredibly important, and RISC-V is a big part of that.
But honestly, FOSS and good system design is often good enough to limit the impact of bad hardware. As long as the set of hardware you have is different enough and you have multiple layers of security, the chance that something will sneak through is incredibly low. For example, you can control application access to the system (SELinux, AppArmor, etc), separate applications from each other (e.g. containerization), and configure a firewall on the PC side. At the router level, you can configure zones like a DMZ, packet filtering, and firewalls. You may not be able to trust each individual chip, but you can probably trust the system as a while with enough redundancy.
So I'm less worried about hardware than cloud based software. I can mitigate my vulnerability to hardware-based issues, I can't do anything about cloud-based issues once the data leaves my network.
Right, but when we're talking in the context of regulating broad democratic systems, the potential for deliberate corruption of the systems is vastly greater while employing black cube technology.
And I'm saying we can mitigate the risk by driving a wedge between hardware and software. Require companies to allow competition on their hardware. I think Apple and Android manufacturers should be required to allow custom ROMs on their phones and tablets, and provide sufficient documentation to facilitate that. A big part of that is Right to Repair as well, but the focus should be on documentation so customers can find/develop workarounds, not on forcing standardization (i.e. the fight to standardize on USB-C is nice, but it's less important than forcing Apple to provide tooling to re-pair serialized components).
If customers can control the hardware, that represents a check against the hardware manufacturer. The next fight is "the cloud," and again, if customers can control their hardware, there will be alternatives to those cloud services.
So I think the fight needs to be to enable and develop FOSS alternatives for all consumer hardware because that at least provides an alternative of those companies decide to act against the interests of their customers.