This has absolutely been used "in the wild". One particularly nasty strain of ad-block-evasion scripts would detect the developer tools being opened, and would reload the page and disable most of its features to prevent them from being analyzed.

Way back when, we thought about this for Firebug. One thing that came out of it was browsers started adding the console object (also because devs forgot to remove the calls on it).

Even so, we added CSS and stuff to highlight elements and that was easily found.

What do people look for today?

The two big ones are:

1. Watching window.innerHeight/innerWidth for sudden, large decreases, indicating that the user just opened the inspector.

2. Logging objects to the console with toString methods and checking if that method gets called.

1. That could also be triggered by browser sidebar windows opening though. All of my browsers open dev-tools in a separate window so this is far from foolproof.

2. Ahhh, clever!

1. should be trivial to avoid, by opening dev tools in a new window

but 2. I have no idea, except the browser vendors would add a "stealth dev mode"

2. JSON.stringify(object)

But isn't the point that you want to detect what the foreign code does?

So your solution would require inject your code into the code that wants to hide from you ... ?

I think the idea is you patch the console to display the objects without calling their toString methods.

I don't think that works

I might be off here, but I imagine console.log early exits if there's no console open, so it doesn't call toString

If that's the case you can just write to the console in a loop and immediately know if one is open

> I might be off here, but I imagine console.log early exits if there's no console open, so it doesn't call toString

The point is to avoid calling toString when the console is open, by using some other way of displaying logged values.

I'm saying you can't avoid calling toString.

Their code will call console.log(object) every X ticks.

As soon as you open the console, console.log fires instead of early exiting => object.toString is called => they know the console is open

Well… you can on a lot of things. We never did .toString() on a whole lot. However, I was big on .displayName (as an override on .name which is found on functions)

My memory is fuzzy, but I also had a different function I would call if frameworks added it so instead of “Object {}” it was “Backbone.Model {id=1}”.

I put these in and used them in firebug extensions I wrote for frameworks.

Later I asked chrome to add something, which is why there is a “enable custom formatters” option for the console. Really needs to work in the debugger though.

Do you not understand that it's not your code and that their code wants toString to be called?

Someone else is writing code that they want to have react to the console opening.

So they will intentionally force the call as soon as the console is open, as a result toString is called regardless of if you yourself have made a call to it.

> console.log fires instead of early exiting => object.toString

The point is that you patch the console to not do that.

How does "JSON.stringify(object)" patch the console not to do that without first opening the console?

For 2 my first thought is the opposite. Fire the detected method even if devtools isn't opened.

The ad-block thing is where I first saw it, that and DRM for less-than-legal sites to prevent downloading (stops streaming if the dev console is open)

I mean more specifically taking advantage of the awkward UI to cover up your tracks on local storage, it's something that's just devious enough that if you get caught (which is not difficult) it'll be hard to explain what you were doing, and you'll be trying to explain it to technical people

Discord does this. Try to find the login cookie.

When discord loads, it copies it out of localstorage into a js var and deletes the localstorage. So if you examine localstorage it will be empty. On page unload it copies it back into localstorage. So if you want to see the value, you have to make sure no discord tabs are open in your browser.

I believe one reason for this is to prevent self-xss. It's hard for a malicious person to write a snippet of js to steal the login cookie now that it's no longer in localstorage. Another reason might be to prevent bots. It's hard for someone to automate a discord account if there's no way to get the account's login cookie.

Wouldn't this cause problems with multiple tabs/windows?

Like, if I have one Discord tab open (so localstorage is cleared) and I open a second one in parallel, will I be logged out in the second one?

I didn't look into it too deeply. Maybe if there are multiple windows they can communicate with each other in some way.

"in some way" --> probably postMessage to send the variable to the new tab.

Service workers would be the solution to that problem, wouldn't they?

Could you see the original cookie by inspecting the headers of the network request? This would presumably be the value before the page loads and gives access to document.cookie or a change triggered by a server-side header.

Consider using something like https://mitmproxy.org/ to deal with a site so devious as to detect browser-level tools being used to inspect headers/cookies/etc.