4 ms·
One thing that I've been thinking is that in addition to restricting what APIs JS can access, browser could restrict when JS can run; in practice I guess that'd
by zokier 5y ago
One thing that I've been thinking is that in addition to restricting what APIs JS can access, browser could restrict when JS can run; in practice I guess that'd mean what events are allowed to trigger JS. Most importantly I'd block the stuff that runs automatically in the background, such as scroll/hover/timer events, and allow stuff that represents more explicit user actions such as form submit events.
Not sure if such thing would be really feasible without breaking half of the web, but I envision that it could bring nice perf improvements and block many sorts of nasty user behavior tracking
- cookiengineer 5y agoThis is literally what Safari does on iOS. Lots of APIs, like playing an audio file or a video stream, need a user event (read as: touch event) fired beforehand in the same callstack, otherwise it won't work. Lots of webdevs abuse this, however, to start an interval with "privileged" rights that will do all things just in a centralized loop after the user did the first interaction with the website. So I'd kinda argue that this security concept is a little flawed. Something like OPs approach to override the APIs with monkey patched checks seems promising. I hope there won't be bypasses or quirks with different web worker or iframe contexts.
- zokier 5y ago> So I'd kinda argue that this security concept is a little flawed I'd agree that its not a model that works in an adversarial setting. But it does hopefully nudge some devs to "right" direction.
- mst 5y agoArguably prior art albeit not for any of the events you mentioned: https://old.reddit.com/r/Twitch/comments/7m8g37/disable_the_page_visibility_api_to_prevent_ads/ https://old.reddit.com/r/Twitch/comments/7m8g37/disable_the_...