Conversation

Matthew Garrett

Running an app in a browser rather than natively means you place most of your trust in the browser vendor's security rather than the OS vendor's security. Do you think this is a reasonable tradeoff? In comments, for which OSes?

Good tradeoff, any OS
29.7%
Good tradeoff, some OSes
38.2%
Bad tradeoff, any OS
22.2%
Bad tradeoff, some OSes
9.9%

910 votesFinal results

40

5

27

Replying to

i have a lot of confidence in app sandboxing on Android, and am probably more concerned about cross-site attacks in the browser

1

1

Replying to

and

i would love if there were a way to put different websites into their own app sandboxes

1

4

Deirdre •° A Nameless Ghoulette °• Connolly¹

@durumcrustulum

Replying to

and

Worse comes to worse, you run one website at a time in a single browser. This is not why I have multiple browsers installed on my devices, but it helps :P

1

Replying to

@durumcrustulum

and

Can force enable strict site isolation on mobile Chromium via chrome://flags. It will already largely use site isolation on high memory devices, similar to desktop Chromium. Other browsers don't have a complete implementation so sites aren't really isolated at the sandbox layer.

1

1

Replying to

@durumcrustulum

In other browsers, a renderer compromise generally gives all site data, etc. Traditional browser sandbox protects the OS, not other sites and browser data. Browser sandbox security largely comes down to OS security. Much stricter seccomp-bpf filter than the app sandbox though.

1

1

Replying to

@durumcrustulum

Sites should set these headers to enforce cross-origin isolation for documents: Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp Content-Security-Policy frame-ancestors directive should also be set to 'none' or 'self'. Most sites don't do it.

2

2

Replying to

@durumcrustulum

Beyond proper isolation in the browser sandbox you can disallow cross-origin requests via Cross-Origin-Resource-Policy: same-origin and avoiding setting Access-Control-Allow-Origin. Still get incoming requests from other sites. SameSite=Strict is nice. Sec-Fetch-* headers too.

1

1

Replying to

@durumcrustulum

SameSite=Strict is trivial if you use static documents/resources and handle everything dynamic via JavaScript communicating with JSON APIs. It doesn't work if you use dynamic HTML like most traditional sites. You won't get the session cookie on navigation from another site.

1

1

Replying to

@durumcrustulum

github.com/GrapheneOS/Att is what we use for attestation.app and is a good reference for headers. Session cookie is also SameSite=Strict. Only thing we don't do is enforcing rules via Sec-Fetch-* headers for the dynamic APIs. Could add it but SameSite=Strict is enough.

attestation.app

Device integrity monitoring

Hardware-based remote attestation service for monitoring the security of Android devices using the Auditor app.

1

1

Replying to

@durumcrustulum

Anyway, my point is that while you can do it, few sites bother enabling decent isolation from others. Can use securityheaders.com to look at it across different sites but ignore the grade because A+ is given out even from hardly doing anything beyond setting no-op values.

12:13 AM · Apr 7, 2021Twitter Web App

Replying to

@durumcrustulum

The web hardly has a same-origin policy unless you go far out of the way to make it into a much different environment than what most sites use. I do think that if you do all of this, you get a really good sandbox from Chromium. Reality is that ~0% of top 100000 sites do this.

1

1

Replying to

@durumcrustulum

And by ~0%, I mean pretty close to actually zero. Google started setting up most of what I mentioned above for some of their core services. However, they have the complexity of tons of intentional cross-origin stuff for login, etc. so it's a huge mess and hard for them to do...