search

theajack / disable-devtool

Disable web developer tools from the f12 button, right-click and browser menu
https://theajack.github.io/disable-devtool/
MIT License
1.99k stars 191 forks source link

Entire Premise is Flawed #86

Open samrahimi opened 8 months ago

samrahimi commented 8 months ago

This product should not exist in its current form. There is nothing wrong with preventing the debugging or reverse engineering of content that YOU hold copyright to

But there is something VERY wrong with interfering with use of the developer tools on a page that belongs to ME, is in active development, and is costing me money every day that bugs don't get fixed. This is not a hypothetical situation: there exists a company which distributes streaming video channels via a player intended for embedding via iframe in somebody else's website... This company, Company A, has chosen to use disable-devtool to protect their assets.

Then there is another company, Company B, who has added features such as multi-lingual subtitles to the content provided by the first company. They have accomplished this by embedding Company A's player into an HTML document, loading the subtitles from an API, and then displaying them on top of the video...

Then there is Company C, which belongs to me. I am a customer of Company B - and I embed Company B's player into the UI for my own app... Specifically, I embed it into a page which contains: metadata and artwork about the item of content being played in the player, 20 recommended or related content items that the user may wish to view next, a buggy and ill conceived attempt at a fancy responsive nav that need to be refactored, AND AN AI CHATBOT THAT COMMUNICATES WITH THESE OTHER PIECES VIA POSTMESSAGE.

Because Company A has chosen to use the disable-devtool package, Company B is forced to include it in their offering to the customer, Company C, who then embeds it in an extremely complex JS app, only to find that the player works perfectly - but that it takes 3 times longer than normal to fix bugs in their front end code... Company C first works around the problem by substituting the offending player with a placeholder (most of the features on the parent page do not directly interact with the actual video stream) - but it proves to be a giant pain in the ass switching back and forth, and finally one of Company C's competitors, who also uses the player from Company B, takes pity on C's founder and points him to a plugin that DISABLES THE DISABLE-DEVTOOL.

Why don't you do the dev world a favor and stop maintaining this package, because it is literally malware - yes, i think anything that makes it impossible for me to use my browser devtool to debug code I wrote myself definitely qualifies as malware (and it doesn't just break the debugger - I can't even inspect the DOM because opening the devtool causes the location.href to navigate away to a different page!)

theajack commented 5 months ago

@samrahimi I think the problem you raised may not exist, disable-devtool provides a rich API to choose whether to enable or disable developer tools in different scenarios

vlad-solomon commented 4 months ago

@samrahimi Exactly the problem I was facing a few months ago, gave up quick, after having a word with Company A. @theajack facilitates these abhorrent developers, giving them the toolkit to absolutely destroy DX.

farhansolodev commented 3 weeks ago

@samrahimi while i agree this is arguably malware, your frustrations are best directed at Company A since if this didnt exist then Company A would have probably built something similiar to this from scratch for in-house use anyway. You should also just blame Google and the creators of Javascript for making it so cumbersome to obfuscate shipped code

samrahimi commented 2 weeks ago

@farhansolodev but i would argue that the difficulty in obfuscating client side javascript is overall a good thing when it comes to reducing malware. personally i would strongly urge google and other browser vendors to fix the vulnerabilities in devtools that make it possible to break debugging IN THE PARENT DOCUMENT due to code running IN AN IFRAME OF UNTRUSTED ORIGIN

I've heard that certain configurations of disable-devtool let you break console.log as well, by basically trampling the prototype of "console" - i'm not sure if this affects the parent page too, but if it does, that is extremely dangerous... because that same vulnerability could be exploited by somebody who is actually seriously malicious - and they could, for example, cause text that you want to log to the console to be silently uploaded to the attacker's server...

I don't know about you, but when I'm developing, I'll often use console.log to help debug stuff, and that means I might log something - in the version running locally - that's totally inappropriate to log in production, like passwords, credit card numbers entered into a text field, etc... because I assume the console.log command to be a safe, local-only built in function placed there for developer convenience... You know what I mean?

farhansolodev commented 1 week ago

@samrahimi

fix the vulnerabilities in devtools that make it possible to break debugging IN THE PARENT DOCUMENT due to code running IN AN IFRAME OF UNTRUSTED ORIGIN

yeah i agree, that is reasonable