undefined | Better HN

0 pointssurajrmal1y ago0 comments

While there is no direct UX exposing this to an end user, it hypothetically be used as the basis of such UI. The parent of a component gets to ultimately decide what capabilities it routes to a child component. It's not like landlock where the process decides to sandbox itself after it's already running. Similar to a user constructing a VM to run a hypothetically malicious program, the same could be done much more lightweight with a fuchsia component.

0 comments

vlovich1231y ago

All I said is that in the general case you’re not going to be able to rely on capabilities to do things like prevent phoning home or otherwise doing things you semantically define as harmful. This isn’t a UX issue - this is a technical issue. Capabilities, outside from very rare circumstances, can’t enforce it no matter how you structure this. The only rare circumstances is if you can restrict access to servers that aren’t owned by the same people as wrote the component. As soon as you give access that allows access, they can implement it in ways that capabilities can’t prevent.

stouset1y ago

Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way.

Sure, a web browser that needs to open arbitrary network connections can be built to phone home. But nearly none of the components it’s built out of can. The image decoding and rendering libraries can’t touch the network, the rendering engine can’t touch the network, and nor can the dozens of other subcomponents it needs to work.

Your installed editor extensions can’t phone home even if the editor itself can. Or perhaps even the editor itself wouldn’t be able to, if extensions are installed out of band.

Your graphics driver vendor can’t phone home, your terminal can’t phone home, and on and on and on.

A solution doesn’t have to be perfect for it to be an improvement, so stop acting like it does.

vlovich1231y ago

But your editor extensions can’t phone home only if your editor sandboxes them into a separate process. Hint: VSCode doesn’t do such sandboxing and neither do most editors that I can think of.

Anyway, you’ve just proven my point with “install extensions out of band” - you’ve ceded that it’s a losing position technically and are arguing for alternative UX solutions. I’m not pretending it has to be perfect. Like I said, capabilities are great for creating a secure OS and writing more secure software more generally. But the threat model it’s protecting against is not software that phones home but against the size of the exploit opened up from a compromise.

Think about it this way, Android apps and iOS apps are largely sandboxed through a primitive capabilities system already, not super fine-grained capabilities but still the same concept. Would you care to claim that privacy and malware isn’t a problem on these systems or that the permissions model has meaningfully curtailed anything but the most egregious of problems?

1 more reply

j / k navigate · click thread line to collapse

0 comments

vlovich1231y ago

stouset1y ago

Your perspective is coming from a very rigid all-or-nothing mentality and I don’t think it’s wise to see things that way.

Your installed editor extensions can’t phone home even if the editor itself can. Or perhaps even the editor itself wouldn’t be able to, if extensions are installed out of band.

Your graphics driver vendor can’t phone home, your terminal can’t phone home, and on and on and on.

A solution doesn’t have to be perfect for it to be an improvement, so stop acting like it does.

vlovich1231y ago

But your editor extensions can’t phone home only if your editor sandboxes them into a separate process. Hint: VSCode doesn’t do such sandboxing and neither do most editors that I can think of.

1 more reply

j / k navigate · click thread line to collapse