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

Official browser API? #28

Open
auchenberg opened this issue Dec 21, 2016 · 13 comments
Open

Official browser API? #28

auchenberg opened this issue Dec 21, 2016 · 13 comments

Comments

@auchenberg
Copy link

auchenberg commented Dec 21, 2016

I'm the PM on Edge DevTools, and I was wondering if we could help this extension, by setting a property on the global object when the DevTools are opened?

The current approach seems rather hacky, and I imagine it would be easy to get implemented in most engines

interface DevTools {
    attribute Boolean isOpen;
    attribute String dockState; 
}

window.devTools.isOpen
window.devTools.dockState // 'left, right, top, bottom, inline'
@sindresorhus
Copy link
Owner

sindresorhus commented Jan 10, 2017

👍 That would be very useful!

@mgol
Copy link

mgol commented Feb 9, 2017

It seems to me it should go the other way round. Adding such an API makes it possible for web sites to block developer tools access to the site.

@fatso83
Copy link

fatso83 commented Jun 23, 2017

@mgol how could they block it?

@mgol
Copy link

mgol commented Jun 23, 2017

@fatso83 Once you open DevTools, remove everything on the site; simple.

@fatso83
Copy link

fatso83 commented Jun 23, 2017

@mgol Thanks for explaining. But this is also presently doable, using this lib in all supported browsers, so presently only Edge and IE is not vulnerable to sites that don't want you to poke around. Or do I misunderstand?

I don't think the practice of blocking access like that would be widespread, as it is such a nuisance, and easily defeatable through numerous low-tech techniques (download & remove blocker script, modifying proxies, etc), and having native support such as above would in practice just make a few additional browser engines vulnerable to non-snooping-around-supporting sites.

BTW I am not sure what you mean by "the other way around": could you elaborate?

@mgol
Copy link

mgol commented Jun 23, 2017

@fatso83 It's not 100% doable as indicated in README.

easily defeatable through numerous low-tech techniques (download & remove blocker script,

That won't work for Single Page Apps.

BTW I am not sure what you mean by "the other way around": could you elaborate?

I mean that browsers should work hard to make DevTools detection impossible. For me all the code in this repository is basically a list of bugs in various browsers which should be fixed, making this library report false even if DevTools are open.

@auchenberg
Copy link
Author

@mgol @fatso83 Wrote a little demo page: https://github.com/auchenberg/devtools-self-destruct

@sindresorhus
Copy link
Owner

I mean that browsers should work hard to make DevTools detection impossible.

That's a losing battle.

@maxnordlund
Copy link

I suggest putting any sort of detection API behind a permission, one that cannot be requested by a page but only from inside the devtools themselves.

Which means that you can allow your site to display some nicer info/start logging to the console etc. But at the same time preventing any random website from denying access to their DOM/sources/etc. While the document.body.innerHTML = "" clears the current DOM, a location.href = "page reminding you of breach of ToS, or worse".

@fatso83
Copy link

fatso83 commented Jan 7, 2018

@maxnordlund that's adding a lot of logic for a futile approach to doing something that's impossible: blocking access on an open web. Like I said to @mgol, it's easily defeatable by, for example, saving the web page locally, modifying the source to remove the logic that does the check and firing it up behind a local proxy that delegates the API calls to the original site. Or you could build some proxy that does all this in transit. This should work fine for SPAs, as well, as you need to download JavaScript in any case.

It's like those JavaScript techniques employed in the early 2000s that prevented you from right-clicking on images and saving the image. No-one is doing that anymore as the HTML would always be available for inspection, revealing the URLs.

What's the use of a permission that prevents access to a feature that's always available and can be circumvented? Sites could display the warning in any case.

@maxnordlund
Copy link

maxnordlund commented Jan 7, 2018

I mean the detection API suggest by @auchenberg. If, and only if, such an API should be made available it needs to be behind a permission that can only be manually enabled in the devtools.

As for counter measures, yes that will lead to an war of attrition. But I do oppose making it easier to detect the devtools rather then make it easier. This is because of behaviour you mentioned by highjacking right click.

Which coincidentally is done by Facebook to display clean links, but force you to copy the analytics redirect link. Same for normal opening of the link, rewrite before opening.)

@TristanWiley
Copy link

So the problem I see with adding an property in Chrome would make it possible for sites to self destruct. However, currently this is not always possible. For example, if you open the Devtools in a new window "Undock into a separate window" the current approach will not work.

If that makes sense, my two cents.

@resynth1943
Copy link

The proposal above would be nice, but how would that be used to actively track the opening of the Developer Tools? It's just a boolean, not an event.

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

No branches or pull requests

7 participants