koto1sa

I don't think you can build applications without using the dangerous sinks at all yet. Some common scenarios we know are common:

window.open href Setting text on a script element Setting src of a script element form.action innerHTML

Applications do use these sinks quite often, and some of them cannot be just get ridden of (e.g. href or script.src). Even removing eval takes ages. Complex applications parse HTML from the users, load scripts dynamically, and such.

That said - TT allow you to have such enforcement too - just set a "Content-Security-Policy: trusted-types;" header and all dangerous sinks can never be called. We call it Perfect Types, but it's not yet practical to build client side applications in that setting.

Trusted Types aim to prevent the injection, XSS-y CSP directives (script-src etc) act as an XSS exploit mitigation that fires after the injection is already there. So, for example, even if the JS execution is stopped, the attacker may still exfiltrate the data via form tags etc.

CSP was traditionally deployed by security folks only and is a bit disconnected from the regular dev workflow. For example, if your application does not conform to CSP (i.e. you have an XSS), you can know that only when you deploy it, and the violations keep coming.

TT are part of your JS program, and are much closer to how developers prevent other bugs in their programs. For example, since the API uses types, you can even set up your build for the application not to compile if innerHTML is used with a string.

Additionally, TT allow the application to be a bit more precise - e.g. maybe you can't refactor the application not to use eval() ever (this is surprisingly common), but would rather make sure that this one eval() instance is secure, and disallow all others. TT solve that elegantly. Your reviewed eval starts using eval(TrustedScript), and all other evals - should they exist - are blocked.

In our experience rolling out CSP, its nonced version (w/ no script-dynamic, no unsafe-*) works well for server-side injections, whereas TT cover the client-side better.

https://github.com/WICG/trusted-types/wiki/FAQ#do-i-need-tru...

Well, the age of in-browser reflected xss filters is simply over.

This was a flawed idea for multiple reasons, and they are thankfully now gone from Chrome and Edge (https://portswigger.net/daily-swig/xss-protection-disappears...). I guess from modern browsers only Safari still has one. There are modern XSS defenses you can use, XSS filters just did not stand well the test of time.

I would state that it is good if your XSS works in Chrome, just like it works in Firefox. That XSS should be fixed by the website, instead of that website owners neglecting the fix and assuming they're protected because the alert doesn't fire in Chrome. Especially given that if the attacker spends a bit of time tailoring the payload, they may bypass the auditor.

Exactly. That said, because the API itself is typed, it is possible to have the runtime enforcement also verified when statically type-checking your application code (e.g. that innerHTML is passed a TrustedHTML value, and not a string) in Flow, TypeScript or type-aware linters - like this: https://youtu.be/1KQngEZ8qH4?t=1330

Disclaimer: I'm working on the Trusted Types project in Google.

To clarify, Trusted Types are not a replacement for XSS auditor. They are both related to XSS, but are fundamentally different and even target different flavors of XSS.

Trusted Types are an opt-in browser API that helps developers prevent DOM-based (~client-side) XSS by mandating that developer-specified rules are applied to data that reaches risky functions (like eval or innerHTML). We're working on having it available as a proper W3C spec. More info at https://bit.ly/trusted-types or https://youtu.be/1KQngEZ8qH4

XSS auditor was an opt-out Chrome only feature that tried to stop reflected (~server-side) XSS payloads from executing after the injection has already happened. It was an now outdated concept. The idea was nice - prevent XSS without changing a bit of code in your application, but now we know this just doesn't work for xss.

That's a well researched problem, and is common in most JavaScript frameworks. In practice it makes it harder to protect applications using them against XSS.

Check https://www.slideshare.net/mobile/x00mario/jsmvcomfg-to-ster... or script gadgets research https://github.com/google/security-research-pocs/blob/master... for more complete overview of the issue.

Disclaimer: I'm one of the authors.

See https://github.com/google/end-to-end/wiki/Key-Distribution. In short, we don't invest much into WoT.

I'm an developer on E2E team as well and can confirm that there's no 'hardening' going on. E2E is, to the best of our knowledge and we have expressed what that exactly means in our threat model: https://github.com/google/end-to-end/wiki/Threat-model. E2E is under Google VRP (https://www.google.ch/about/appsecurity/reward-program/), so if you're aware of any vulnerabilities, let us know.

E2E extension is not production ready, but I myself am using the compiled version as it is, in my biased opinion, the most secure of existing PGP-in-the-browser extensions.

One of the developers here:

Yes, the Keyring reimplementation is in progress and ends very soon. After the redesign, applications built on top of E2E library will be able to use different sources of both public and private keys (so it's easy to do integrations with GnuPG, hardware keys HKP, or e.g. Facebook).

The API will be similar to what's in https://github.com/google/end-to-end/wiki/Keyring.

As vague as is may sound, once we feel it's ready. The development is active, but there is still a lot of work to make the project release-ready. You might help too - we started accepting external contributions recently and the project is covered by the bug bounty.

Symmetric encryption key (Km in the article) get encrypted separately with Alice, Bob, Sam and Joe public keys and then all those encrypted keys get concatenated with the message.

That's this bug: https://code.google.com/p/end-to-end/issues/detail?id=121 , it will get fixed after weekend.

Disclaimer: I'm a member of E2E team.