[HN Gopher] JavaScript Restrictor
       ___________________________________________________________________
        
       JavaScript Restrictor
        
       Author : rlv-dan
       Score  : 73 points
       Date   : 2021-10-05 16:43 UTC (6 hours ago)
        
 (HTM) web link (polcak.github.io)
 (TXT) w3m dump (polcak.github.io)
        
       | pattyj wrote:
       | I've wanted an extension like this for a while. Thanks for
       | sharing!
        
       | 8bitsrule wrote:
       | Found this page hard to read because text does not wrap when
       | zooming in to increase font-size.
        
       | tannhaeuser wrote:
       | 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
        
       | zokier wrote:
       | 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 wrote:
         | 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.
        
           | zokier wrote:
           | > 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 wrote:
         | Arguably prior art albeit not for any of the events you
         | mentioned:
         | https://old.reddit.com/r/Twitch/comments/7m8g37/disable_the_...
        
       | cxr wrote:
       | 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>
        
       | elwell wrote:
       | 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.
        
         | eurasiantiger wrote:
         | 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.
        
         | woodruffw wrote:
         | > 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.
        
       | kennywinker wrote:
       | 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!
        
       | phist_mcgee wrote:
       | 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.
        
       | ravenstine wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-10-05 23:01 UTC)