JavaScript Restrictor | Hacker News Reader

JavaScript Restrictor

polcak.github.io

92 pointsrlv-dan19 comments

From an announcement to the bug-gnuzilla list today <https://lists.gnu.org/archive/html/bug-gnuzilla/2021-10/msg0...>:

> 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>

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.

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.

Weird definition of paranoia.

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.

> 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.

The protection levels and chosen restrictions for the default protection level 2 seem considerate [1]. Welcome back to the Web of 2003.

[1]: https://polcak.github.io/jsrestrictor/levels.html

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.

> 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.

Arguably prior art albeit not for any of the events you mentioned: https://old.reddit.com/r/Twitch/comments/7m8g37/disable_the_...

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.

Don't know why this comment got downvoted b/c it's a valid concern. 8 out of 10 websites do this wrong in my experience. It's an avoidable nuisance.

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.

I've wanted an extension like this for a while. Thanks for sharing!

Found this page hard to read because text does not wrap when zooming in to increase font-size.

works for me except the last paragraph with abilitools Text Zoom to increase font sizes https://chrome.google.com/webstore/detail/text-zoom-to-incre...

Reply on news.ycombinator.com