Skip to content
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

Closed
drodil opened this issue Jun 2, 2021 · 5 comments
Closed

[SUGGESTION] Disabling developer tools #6732

drodil opened this issue Jun 2, 2021 · 5 comments

Comments

@drodil
Copy link

drodil commented Jun 2, 2021

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:

<html devtools="deny">  // Deny from everywhere
<html devtools="allow">  // Allow from everywhere
<html devtools="192.168.0.*, 127.0.0.1"> // Allow from client IP addresses
@ghost
Copy link

ghost commented Jun 2, 2021

Just wanted to say that there are also other avenues to do DOM manipulation. Like design mode in some (Chromium?) browsers.

document.designMode="on"

These should be addressed as well. Maybe for starters just a general banner for any type of client side DOM, CSSOM, AOM manipulation?

@pshaughn
Copy link
Contributor

pshaughn commented Jun 2, 2021

This would splinter the Web ecosystem, as power users would flock to browser builds that don't lock them out in this way.

@domenic
Copy link
Member

domenic commented Jun 2, 2021

This is not something the HTML Standard covers, as developer tools are individual to browsers.

@domenic domenic closed this as completed Jun 2, 2021
@jgraham
Copy link
Member

jgraham commented Jun 2, 2021

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

@drodil
Copy link
Author

drodil commented Jun 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants