Re: [w3c/webcomponents] Generic programs can't reliably use/manipulate documents via the DOM (#640)

May I add a couple legitimate use cases for hard-private, inaccessible DOM: \*

1. Guarding an `<input type="username">`/`<input type="password">` from successful script injection and/or malicious extensions.
2. Hiding sensitive information like exposed financial data or one-time tokens from successful script injection and/or untrusted extensions.

Currently, all it takes is a single successful XSS attack to literally read a user's password as they type it, and a payload doesn't have to be large.\*\* The only way to stop it at this stage is via CSP policy, and some form of MITM mitigation like TLS (assuming the attacker doesn't catch the initial connection).

Of course, browsers could (and still) should offer APIs for password managers, screen readers, etc. to read such inaccessible text, but it should be guarded by a permission instead of just being wide open to all.

-----

\* I'm by no means a security expert. I'm just super security conscious, and I like to be more proactive in my opsec. (No, I don't like writing exploits, and that's part of why I immediately deleted and did not post the payload referenced below.)

\*\* I created within 30 minutes just now an easily modifiable, rudimentary payload for pages with single `<form>`s that's <300 bytes raw, <350 bytes encoded with `encodeURIComponent`, which can send the submitted password to a C&C server on submit without any way to stop it. The fact I'm just a security-conscious web developer who almost never writes exploits for anything outside of tests should tell you how easy it is to do once you're in.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/640#issuecomment-336017981