-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SUGGESTION] Disabling developer tools #6732
Comments
Just wanted to say that there are also other avenues to do DOM manipulation. Like design mode in some (Chromium?) browsers.
These should be addressed as well. Maybe for starters just a general banner for any type of client side DOM, CSSOM, AOM manipulation? |
This would splinter the Web ecosystem, as power users would flock to browser builds that don't lock them out in this way. |
This is not something the HTML Standard covers, as developer tools are individual to browsers. |
(Domenic closed this while I was writing, but I think it's worth posting anyway for pedagogical reasons) There are two seperate issues here, but I don't think the proposal addresses either of them effectively. One issue is end users being phished with scams that require them to run some code in devtools. That's a real problem, but it's not clear why having a per-site opt-in is an efficient way to address it. If it becomes a large problem I'd expect browsers to respond by making devtools harder to access for users who don't understand them (e.g. requiring a pref to be set or an extension to be installed or something). That works across the whole web without requiring any changes on sites themselves (and to a certain extent is already happening). The other issue is "developer tools allow other things that compromises the security". This is fundamentally a misunderstanding of the security model of the web. From the point of view of the server, the client is always untrusted. Even with such a tag, a malicious user can e.g. run the page through a proxy which removes the tag, or use a user agent which is configured to ignore the tag. Such user agents would be easy to come by because the need to inspect third party sites is common (e.g. browser "web compatibility" teams which investigate sites that are broken in specific browsers). So, as an author, your security model simply can't depend on "malicious users can't access devtools" (or indeed, on "all clients play by the rules" in general). |
Thanks for the responses! I agree that after all this shouldn't be in the HTML spec just because all the possibilities to bypass it. Good points made there @jgraham ! And of course because it's something that is so browser specific. Instead the browsers should provide some safeguard for their users to get protection from internet scams. The intention of this suggestion hopefully was good. |
HTML specification should introduce a new tag to tell browser that developer tools are not allowed in the page. The suggestion is based on the fact that for example DOM modification is used in many internet scams (blog post about the topic: https://drodil.medium.com/internet-scams-browsers-should-warn-user-about-modified-dom-c75bbfc2bf9e). Additionally developer tools allow other things that compromises the security. First idea could be the to add new attribute to the tag:
The text was updated successfully, but these errors were encountered: