I’d love to see this kind of functionality built in to firefox. I’ve tried running without js entirely but too much of the web is broken. But a paired down js, that might work!
Is there any concern that limiting JavaScript's functionality could cause unexpected behavior? E.g., your credit card is charged upon checkout but next part of payment flow isn't triggered and your order isn't actually placed. Or, some DDOS protector thinks you are the same agent as everyone else using a similarly restricted config.
> Is there any concern that limiting JavaScript's functionality could cause unexpected behavior? E.g., your credit card is charged upon checkout but next part of payment flow isn't triggered and your order isn't actually placed.
I thing this was a common concern with the first few generations of content blockers, one that's mostly proved to be a non-issue. It's not my space, but if I had to take two guesses:
1. Most analytics code is sufficiently flaky and unreliable to keep it far away from the critical concrete value path of someone actually paying with a card.
2. Most developers are probably running content blockers.
Better yet, having this extension installed is just another data point more and will count against your future social score because paranoia is not healthy.
It's only paranoia if you are not being watched. Watching you is the main business of many companies. Therefore, installing this extension is evidence of having basic understanding of modern advertising, rather than evidence of paranoia, in my opinion.
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
This 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.
Would be nice if it spoofed the fonts API. It's a stupidly easy way to fingerprint a browser but it seems like no one has yet been interested in thwarting that.
I know this is a small (and probably petty complaint), but this website seems to have a fixed width larger than my screen, which means I have to horizontal scroll to read.
When I see this particular behaviour on sites, it usually lowers my opinion of the content I am reading and in this case a site about JS, I feel like there isn't an excuse for it.
Neat idea, though it's not really a sandbox or anything. It's doing a lot of clever renaming and wrapping. Which is all you could do as a browser extension. Still helpful, but the descriptions on the page make it sound like it's a deeper set of protections.
> The extension is[...] currently under the name of JavaScript Restrictor but it will be renamed to JShelter soon.
FSF funding announcement: <https://www.fsf.org/news/fsf-announces-jshelter-browser-add-...>
Discussed two days ago: <https://news.ycombinator.com/item?id=28736113>