Not that I think this has actually been applied by anyone in the wild, but it'd be fun to make a site that take advantage of this

You can detect developer tools being open in Chrome pretty reliably, so detect dev tools have been open then "clean up your act" before there's a chance to view anything of note

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.

Not trying to defend anyone here, but I wonder if there's a non-nefarious reason for this.

Specifically, there have been a lot of changes to cookies lately because malicious actors (malware/adware) figured out how to access the cookie store and infer/determine cookie information from other sites.

I suspect that maybe this cookie store is kept in a more secure part of the application and only the cookies relevant to the site you visit get pulled out of it. It may even be a risk to have the information for all domains even loaded into memory for the application.

With all that said, there should be some way to manage/introspect that cookie store from outside of the browser imho.

Let's remain serious. It is entirely within the capability of modern computers to admit a dialogue which would let the user view their cookies without magically exposing them to websites. There is no non-nefarious reason for this.

Thank you. The pretence (naivety) of "there must be a good reason" has to stop

There’s usually a “good reason” — however that “good reason” is subjective to the people maintaining the application and might not align with the preferences of its users.

Reasons don’t really matter to users though. It’s pointless arguing if we should assume innocence or guilt because irrespective of the developers motives, if a particular feature is a show stopper for you then you switch to a platform that supports said feature. Anything else added to colour the discussion is irrelevant.

I agree with what you pointed out about subjectivity. I think it’s still worth discussing though to serve as a warning to others who act with their own best intentions only to have them get bitten. Without calling this out it just always leans on the malicious side which doesn’t trend with reality in my experience.

In terms of end users driving decisions ultimately, I agree. That said, this is a discussion forum so I figured it was open for discussion and assumed that folks would be deciding on their own how to react to the change.

I guess this all depends on what we think we’re having a discussion about!

The problem is any such discussion is going to be entirely speculative. Sure, you can discuss what you presume the developers motives might have been but it reveals more about the opinions and personalities of the people holding the discussion than it does about the developers since all you’re doing is projecting your own story to fill in some pretty sizeable blanks.

But what many others in this thread have done is just as speculative, assuming malice, and to be clear, I think it could very much be the case, but I’m sharing another perspective based on a lot of experiences I’ve had where external parties assumed malice when internally it was far from it. Take it or leave it. This is the internet and I’m typing into a box.

I agree, but I suspect this was also what was believed when they originally did it and adversaries found very clever ways to find that cookie store - that part at least is true, which is why I bother mentioning it, given the complexity of browsers it is likely very daunting to redesign this kind of thing around the existing features. Anyways, I'm glad I'm not working on browsers, it seems like an ever-losing cat and mouse.

Those two things are unrelated if there is such interaction and the fix was removing the dialog I would be scared to use that browser.

So whether your theory is true or not, no one should use Chrome.

I agree.

Chrome already has functionality to put different sites in different processes and sandbox the processes, so that if there's a renderer bug, the attack is stuck in the sandbox of a single site and can only access that site's data. This also helps with CPU speculative execution bugs.

https://www.chromium.org/Home/chromium-security/site-isolati...

> Not trying to defend anyone here, but I wonder if there's a non-nefarious reason for this.

The tools are designed for developers who often want to manually edit cookies on pages they are debugging.

I recently had to develop a feature that would have been much easier to develop and debug had I been able to view the contents of Local Storage and Session Storage before loading the site.

A particular feature of a web application (shopping cart) had different behaviour depending if the page was loaded as "an initial pageview on revisit", e.g. the user coming from [search engine|other link|bookmark|url bar] or from normal site browsing. By storing data in both Local Storage and Session Storage, and comparing the two on page load, I could determine if the user, who had been to the site in the past, had just come back. This all had to be developed in the dark as the major browsers have no method of viewing Local Storage and Session Storage for websites not loaded.

I know that. It seems like a given for this forum and topic specifically that I am not ignorant of that.

If the browser is designed properly (this does not apply to Safari), the UI can and should have totally different permissions from the site executor/renderer.

>If the browser is designed properly (this does not apply to Safari),

Slow clap. Well done.