Conversation

virtual signalist

@ttaskett

Oct 30, 2018

Replying to

@DanielMicay

@Whonix

and

@QubesOS

I think this approach is really less about containment and more about reducing the complexity of data formats exchanged between subsystems. Even the strong isolation of Qubes relies on the idea of simplified formats used at critical points.

Replying to

and

It's fine-grained isolation of different components. Improving that involves having minimal attack surface exposed between the components, simple data formats and a focus on hardening the code most exposed at the boundaries with safe tools, etc.

Replying to

Isolating per-contact in a messaging client, per-site in a browser, etc. is applying the same principle of QubesOS at a fine-grained level using existing privacy/security boundaries. Since they're existing boundaries, it doesn't require the user to do anything or be aware of it.

Replying to

and

OK re per-contact-site isolation.... Now, demote "kernel" to "services" and look to hypervisor+qrexec as the actual kernel.

Replying to

and

There are implementations of fine-grained isolation within applications using different mechanisms than OS sandboxing. Architecture-level virtualization is one possible approach and has pros / cons, as do other approaches like a higher-level virtual machine, etc.

Replying to

The isolation between sites in a browser or contacts in a messaging app are good examples of existing fine-grained trust boundaries to reinforce. There are a lot of other examples and reinforcing those can improve security for a billion users with no more work on their part.

Replying to

and

IDK if that's literally true. The move to https was itself a form of site isolation & industry was tinkering with hiding URLs altogether when they did about-face out of necessity. We might not have Chrome internal isolation today if not for trend reinforcing site identity in UI.

Replying to

Representation of https became weaker (location semantics "scare" users!) in browser UIs before they became stronger. Location bar became explicitly a part of security context, lock icons returned, plus EV certs and domain highlighting.

Replying to

and

Lock icons and EV are on the way out. The default will be HTTPS, anything not HTTPS will have scary warnings and the only identity will be the domain since that's the only identity that ever worked / mattered.

Replying to

and

You sound like me 12 years ago. 🙂 Seriously, https (and EV) are valuable for some threat models. And they can be subverted. My mention of them was not intended to promote them as "only identity that ever worked", etc. Its just an example of isolation in the UI.

Replying to

and

HTTPS is obviously valuable. EV doesn't accomplish the intended purpose because company names aren't unique and positive security indicators are near universally ignored by users. If a user doesn't change their behavior based on it being missing, it accomplishes nothing.

7:35 PM · Oct 30, 2018Twitter Web Client

Replying to

Twitter uses EV which generally shows up as "Twitter, Inc. [US]". It's possible to register another company in a different state with the same identity. It would need to show state to be unique. No significant portion of users will notice EV is missing or act differently anyway.

Replying to

Chrome is removing the positive security indicators and other browsers are likely to follow: blog.chromium.org/2018/05/evolvi. It doesn't actually work properly. EV is already not shown on mobile. iOS recently stopped because what they did was actively harmful: troyhunt.com/extended-valid.

Show replies