1. 10
  1.  

  2. 6

    Disgusting work. And the security angle is pure BS. Its entire purpose is to deny us our computing freedom. To “protect” the code from us like we’re some adversary.

    This will only be used by scammers and those who now try to block right clicks with an alert()

    1. 6

      I don’t think this is about how to make your website more secure. This is a “hey, here’s shit evil people could do, you need to be aware of it” kind of thing.

      1. 5

        Disgusting work.

        I think this is great, assuming browser vendors are willing to fix it. @freddyb Do you know if firefox is vulnerable to this too?

        1. 3

          I think treating this sort of thing as a vulnerability that can be fixed is a losing battle.

          1. 4

            Why ? Browser vendors are already implementing pretty good js environment segregation for webextensions, I can’t imagine why they wouldn’t be able to do the same for debuggers.

            1. 2

              I think those issues can be treated as fixable, but I don’t think they will all be fixed. Most of the things in part 2 are about calling into site-code (e.g., overridden prototypes), which I consider possible. But some of the things posted here (and in part 1) are hard to resolve. Especially when they cause additional second-level side-effects like source map URLs, the layout shift that comes from enabling DevTools etc.

              I’ll try to get a definite answer from the team though :)

            2. 1

              if that’s the case then it’s an admission of defeat

        2. 2

          Anti debugging is insane, I faced it on a video website a few months ago I think to defeat it I saved the page and had to load it with custom js…