3 ms·
It is very hard to prevent exfiltration by code that is allowed to write to the DOM in today’s browsers. There is Content Security Policy (csp) which applies t
by jitl 2y ago
It is very hard to prevent exfiltration by code that is allowed to write to the DOM in today’s browsers.
There is Content Security Policy (csp) which applies to the whole page and sometimes governs scripts injected by extensions but not the extensions themselves.
I would love to see browsers add a chain-of-custody to scripts and DOM nodes, so it is easy to tell which nodes were added/touched by a script, and if a script adds a script tag, that newly loaded script would show up as branches in the custody tree. Then we could say, “no nodes or scripts in this tree may trigger requests to unauthorized domains”. It would be sort of like CSP, but with a runtime-tracked implicit capability/taint for extensions.
- jraph 2y agoAdd some sort of signing process and call this Secure DOM.
- ronsor 2y agoNo, then people will mistakenly think it is 100% secure.
- whereismyacc 2y agoSecurer DOM.
- aristus 2y agoBrowser DOM Security Mechanism.
- xelamonster 2y agoI'd like to see a separation between read and write permissions to the DOM for plugins personally. I would feel much better if I didn't have to give any plugin that might need to modify parts of a limited set of pages the ability to silently manipulate anything and everything I see in the browser. Read-only access could be granted by default, then only when a plugin sees something it wants to act on it could pop up and request my approval before doing so. The current approximation of that by disabling the plugin globally and enabling it on specific pages is so clunky and adds so much extra friction that I don't ever bother with it.