Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should have the ability to run any code we want on hardware we own

hugotunius.se

Post reply on HN
Print view View original

451–460 of 1001 posts

Re: We should have the ability to run any code we want on hardware we own

#451

Post by KoolKat23 »

josephg wrote: post #260
zmmmmm wrote: post #165

> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your o…

My parents are getting old and they aren't tech savvy. The missing piece here is that I want my parents to have a computer they can safely do their banking on, without leaving them vulnerable to scams and viruses and the like. I like that they have iphones. Doing internet banking on their phone is safer than doing it on their desktop computer. Why is that? The reason is that the desktop PC security model is deeply fl…

This is where Linux and Apple's centralized repository method shines.

Social engineering is really where the threat is at these days.

Re: We should have the ability to run any code we want on hardware we own

#452

Post by Turlututu »

wolvesechoes wrote: post #444

In my country two groups most hated by educated, civilized and self-labeled liberal people are miners and farmers. There are good reasons to not like them, especially miners (they have lot of privilege and cost a lot of money, whereas our (coal) mining industry is useless), but I came to the conclusion that the actual reason behind the hate is the fact that those two groups are able to force government to do their wi…

Have you heard about transversality of the fight? Do you have common ground with those farmers and coal miners? Do they have some with you. They are humans, after all. They feel and fear and hope.

I come from a place famous for social unrest. A successful protest is one uniting the student to the truckers, to the miner to the teachers.

Punching up. Not sideways or down. Their is a greater enemy than the farmers.

Re: We should have the ability to run any code we want on hardware we own

#453

Post by aw1621107 »

breakingcups wrote: post #428
lucideer wrote: post #401

Earlier quoted context omitted.

"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything. Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys". Two things have changed with the rebrand: 1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually. 2. A lot of la…

Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407

> trying to pressure KeepassXC to remove exporting passkeys in an open format

I'm not sure that's an entirely accurate representation of the request? At least from a quick skim the claimed issue is being able to export keys in plaintext. For example, from the issue author:

> I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption.

And later:

> > Besides, determined advanced users could just write code to decrypt the kdbx file and extract the passkeys anyway.

> That's fine. Let determined people do that, but don't make it easy for a user to be tricked into handing over all of their credentials in clear text.

> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.

To me that doesn't sound like they're requiring a proprietary format. Something like AES encrypted JSON sounds like it'd work as well, and that sounds pretty "open" to me?

Re: We should have the ability to run any code we want on hardware we own

#454

Post by bsder »

immibis wrote: post #159
bsder wrote: post #36

Earlier quoted context omitted.

The primary problem is that we can't build a phone and run it on a cellular carrier network. This is where legislation is needed. Apple and Google are still a problem, but they are a secondary problem.

I don't think the cellular network is the problem at all - everything except SMS and PSTN calls works on wifi. The problem is the apps. Netflix only runs on a verified bona fide electrified six car Google- or Apple-approved device; so do most financial apps (EU law requires them to) and basically everything else where the app developers are trying to get money off you (which is most apps). Some apps will refuse to pl…

And why can Netflix ignore everybody who doesn't have a bona fide Google or Apple phone?

Because the number of non-Google and non-Apple phones is a rounding error.

And why is that? Because, except for the incumbents, it is almost impossible to certify a phone.

We could have nice sub-$100 phones (remove camera, etc.) if people could get them certified. But they can't; so we don't.

Re: We should have the ability to run any code we want on hardware we own

#455

Post by nobankai »

GeekyBear wrote: post #257
idle_zealot wrote: post #4

This makes the point that the real battle we should be fighting is not for control of Android/iOS, but the ability to run other operating systems on phones. That would be great, but as the author acknowledges, building those alternatives is basically impossible. Even assuming that building a solid alternative is feasible, though, I don't think their point stands. Generally I'm not keen on legislatively forcing a deve…

The real battle is over Google selling the public on the notion that Android would be the "open" platform that allowed people to run anything they liked on their device, and then deciding to use anticompetitive means to take that freedom away. Without that fraudulent marketing, Android never would have crowded out other options so quickly in the marketplace. The solution is to either have Google back down on breaking…

[dead]

Re: We should have the ability to run any code we want on hardware we own

#456

Post by staplers »

wolvesechoes wrote: post #425
zmmmmm wrote: post #165

> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your o…

> However all of these things are not technical You understand it, but even in this thread you have people proposing solutions like switching from traditional banking to bitcoin, stoping using Netflix and starting torrenting again etc. Tech crowd always tries to solve non-technical problems through technical means, and this is why I don't have much hope.

Technical solutions and alternatives can provide enough leverage for the common citizen to force the hand of those in power. It might not fully "solve" the issue, but making it easier to route around will always force those in power to bend somewhat.

Re: We should have the ability to run any code we want on hardware we own

#457

Post by tadfisher »

breakingcups wrote: post #428
lucideer wrote: post #401

Earlier quoted context omitted.

"Passkeys" is a new brand name slapped on an older open, interoperable technology, so it's difficult for me to be "against passkeys" as they haven't fundamentally changed anything. Before the branding they were known as FIDO2 "discoverable credentials" or "resident keys". Two things have changed with the rebrand: 1. A lot of platforms are adopting support for FIDO2 resident keys. This is good actually. 2. A lot of la…

Except the FIDO Alliance is trying to pressure KeepassXC to remove exporting passkeys in an open format: https://github.com/keepassxreboot/keepassxc/issues/10407

That threat has no teeth; anyone requiring attestation these days will cut out Apple users, because Apple will not implement it (for consumer use cases). If they don't block Apple passkeys, then KeePass can send Apple's AAGUID and the game is over.

I've complained about this GH exchange in the past and have come to understand that Apple is also part of the alliance, and the entire concept of blocking software-only password managers is just dead outside of enterprise situations where they mandate the hardware/software anyway. Mr. Cappalli might disagree, but he and his employer do not have the power to change this without breaking the standard and throwing away over a decade of work.

Re: We should have the ability to run any code we want on hardware we own

#458

Post by GeekyBear »

Aachen wrote: post #405
GeekyBear wrote: post #257

Earlier quoted context omitted.

The real battle is over Google selling the public on the notion that Android would be the "open" platform that allowed people to run anything they liked on their device, and then deciding to use anticompetitive means to take that freedom away. Without that fraudulent marketing, Android never would have crowded out other options so quickly in the marketplace. The solution is to either have Google back down on breaking…

What worries me is that Google has a fairly legit argument to say "then Apple should as well". But we've accepted Apple's status for so long now, a lot of consumers are stockholmed into thinking giving away control is the only way to have a good phone (evidence: see any thread discussing that maybe Apple should allow other vendors to also use their smartwatch hardware to offer services in non-smartwatch-hardware mark…

> What worries me is that Google has a fairly legit argument to say "then Apple should as well".

Not a legal argument, since Apple never claimed the iPhone was anything else but a walled garden, and walled gardens are legal as long as you are clear that users will be buying into a walled garden from the start.

(For example: Nintendo, PlayStation and Xbox)

Legally, the only thing you could do is change the law to make walled gardens illegal, as they did in the EU.

The changes Google has proposed for sideloading are illegal under existing law, since Android was sold to consumers with the promise that it was the "open" platform that allowed users to run anything they like.

Re: We should have the ability to run any code we want on hardware we own

#459

Post by Earw0rm »

josephg wrote: post #359
matheusmoreira wrote: post #299

Earlier quoted context omitted.

> think of the elderly This stuff is not just for the elderly and computer illiterate. It's for you as well. You think they're going to stop? You're giving up freedom for safety. You will have neither.

> It's for you as well. You think they're going to stop? No! Which is why I don't want every npm package I install to have unfettered access to my internet connection and to access all my files. If this is being exploited now, I might not even know! How sloppy is that! > You're giving up freedom for safety. At the limit, sure, maybe there are tradeoffs between freedom and security. But there's lots of technical solut…

IMO what's needed is less per-app sandboxing, and more per-context.

Think user accounts but for task classes.

If I'm doing development work, I want to be able to chain together a Frankenstein of apps, toolchain, API services and so on, with full access to everything else in that specific context.

But that doesn't need visibility of my email, my banking and accounting software should have visibility to/from neither, and random shareware apps, games and movies should run, like you say, with a browser tab level of permission.

Making this work in practice while keeping performance maximised is harder than it sounds, preventing leaks via buffers or timing attacks of one sort or another (if apps can take screenshots, game over).. for now I use user accounts, but this is becoming less convenient as the major desktop OS and browser vendors try to force tying user accounts to a specific online identity.

Re: We should have the ability to run any code we want on hardware we own

#460

Post by mike_hearn »

josephg wrote: post #260
zmmmmm wrote: post #165

> In this context this would mean having the ability and documentation to build or install alternative operating systems on this hardware It doesn't work. Everything from banks to Netflix and others are slowly edging out anything where they can't fully verify the chain of control to an entity they can have a legal or contractual relationship with. To be clear, this is fundamental, not incidental. You can't run your o…

My parents are getting old and they aren't tech savvy. The missing piece here is that I want my parents to have a computer they can safely do their banking on, without leaving them vulnerable to scams and viruses and the like. I like that they have iphones. Doing internet banking on their phone is safer than doing it on their desktop computer. Why is that? The reason is that the desktop PC security model is deeply fl…

> Any program I run is allowed to silently edit, delete or steal anything I own ... there's currently no desktop environment that provides that ability

Putting aside the philosophical issues, that statement isn't true for a few years now. It's not well known, even in very technical circles like HN, but macOS actually sandboxes every app:

• All apps from outside the app store are always sandboxed to a lesser degree, even if they are old and don't opt-in.

• All apps from outside the app store may opt in to stricter sandboxing for security hardening purposes.

• All apps from the app store are forced to opt-in, must declare their permissions in a fine grained way, and Apple reviews them to make sure they make sense.

To see this is true try downloading a terminal emulator you haven't used before, and then use it to navigate into your Downloads, Photos, Documents etc folders and run "ls". You'll get a permission prompt from the OS telling you the app is requesting access to that folder. If you click deny, ls will return a permission error.

Now try using vim to edit the Info.plist file of something in /Applications. ls will tell you that you have UNIX write permissions, but you'll find you can't actually edit the file. The kernel blocks apps from tampering with each other's files.

Finally, go into the settings and privacy/security area. You can now enable full disk access for the terminal emulator, or a finer grained permission like managing apps. Restart the terminal and permissions work like you'd expect for UNIX again.

Note that you won't see any permission popup in a GUI app if you open the file via the file picker dialog box. That's because the dialog box is a "powerbox" controlled by the OS, so the act of picking the file grants the app permission implicitly. Same for drag and drop, opening via the finder, etc. The permission prompt only appears when an app directly uses syscalls to open a file without some OS-controlled GUI interaction taking place.

So, if you want a desktop OS with a strong sandbox that you actually control, and which has good usability, and a high level of security too, then you should be using macOS. It's the only OS that has managed this transition to all-sandboxed-all-the-time.

Post reply on HN