Tested on windows 10 , ubuntu 14.04 and mac OS 10.11.6 using latest chrome canary M57 #57.0.2950.0 and issue is reproduced.

Issue is seen from M30 #30.0.1549.0 and hence it is a non-regression issue.

Marking it as untriaged.

Thanks !

dgozman@ - is this an intentional feature? If not, phulce@ can work on it :)

No, this is not intended.

I'd have to disagree that we should try to plug these. There any many ways of detecting that devtools might be open, legitimate reasons for doing so, and even packages written by the community to do it (see https://github.com/sindresorhus/devtools-detect and https://stackoverflow.com/questions/7798748/find-out-whether-chrome-console-is-open which contains code very similar to @labobolink's fiddle). What is the primary concern for allowing this behavior?

Allows malicious scripts to hide themselves when dev tools window is open for example. There's no legitimate reason for leaking this to sites. It will only be abused which I've already seen ads do, of course.

Your first example https://github.com/sindresorhus/devtools-detect is doing it backwards and will only work for sites that implement such scripts. Very small and insignificant usage group.
"Like pausing canvas, adding style debug info, etc." These are things custom dev tools extensions should do, not sites themselves. Sites can expose the debug information (and debug functions) that custom dev tools extensions can gather and display.

If the community wants to allow sites dev tools detection then they can write an extension to intentionally expose it.

I think it is important to prevent the website from detecting the use of the developer tools. I've also witnessed this being used to hide what is going on.

For example install Adblock Plus and then load http://www.nasdaq.com/ . Some adverts are displayed, but when the Chrome developer tools are opened the page instantly reloads and the adverts are hidden. (The adverts are also hidden on further page loads until cookies for the site are cleared.)

That's fair. I agree sites should always be able to be inspected to discourage this sort of malicious behavior. Rather than make this class of console issues not execute client code though I'd be in favor of turning enhanced/more descriptive console logging into an option instead (this seems to be at the root of this set of vulnerabilities DOM element properties, Function.toString, etc). I think it provides significant user value over the more generic `function ()` logging in FF, but this way the user is in control of whether they accept the tradeoff.

Yea I agree, I definitely find the more descriptive logging useful. It would be a shame to lose it.

The idea of temporarily disabling descriptive logging is cool. That would solve solve my problem.

Another idea I had was perhaps Chromium could stop console.log from using wrapped APIs. For example the browser could keep a reference to Function.prototype.toString and use it instead of executing someFunction.toString() when a function is logged.

Has this issue been solved ? If so, how to activate this option to hide if developer tools is opened ?

#10 no movement here yet, current best proposal would be to add a method of opening devtools that pauses javascript execution immediately such that these attacks no longer work, giving you time to inspect the page. This seems preferable to playing whack-a-mole with all the possible vectors where DevTools causes userland code evaluations.

#11 I like that idea, there are too many ways to guess whether DevTools is opened (performance timing, window size, etc.), solving it hard and clean is the best way to go imo. 

The demo linked in the opening no longer works. 

Here is a new demo that I found on StackOverflow: https://output.jsbin.com/cecuzeb/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d10d4609a721f47a05b7d104812b5bd8c37b21b3

commit d10d4609a721f47a05b7d104812b5bd8c37b21b3
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Thu Dec 13 23:52:22 2018

DevTools: allow pausing page upon devtools open.

Bug:  672625 
Change-Id: I16f1e5ffb64bc5dabbbc1e8096c5199cde6923c7
Reviewed-on: https://chromium-review.googlesource.com/c/1372658
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616504}
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/devtools/devtools_toggle_action.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/devtools/devtools_toggle_action.h
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/devtools/devtools_ui_bindings.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/devtools/devtools_window.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/resources/inspect/inspect.js
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/ui/webui/inspect_ui.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/chrome/browser/ui/webui/inspect_ui.h
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/core/exported/web_dev_tools_agent_impl.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/core/exported/web_dev_tools_agent_impl.h
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/core/inspector/browser_protocol.pdl
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/core/inspector/inspector_page_agent.cc
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/core/inspector/inspector_page_agent.h
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/devtools/front_end/inspector_main/InspectorMain.js
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/devtools/front_end/main/Main.js
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/devtools/front_end/sdk/Connections.js
[modify] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/renderer/devtools/front_end/sdk/TargetManager.js
[add] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/web_tests/http/tests/devtools/startup/pause-on-start-expected.txt
[add] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/web_tests/http/tests/devtools/startup/pause-on-start.js
[add] https://crrev.com/d10d4609a721f47a05b7d104812b5bd8c37b21b3/third_party/blink/web_tests/http/tests/devtools/startup/resources/pause-on-start.html

The patch above concludes what we think should be done here. Note that the console.log detection was fixed previously. There is now a way to pause the page before it has a chance to detect devtools. For that you should:

- open chrome://inspect
- select 'Pages'
- click the 'pause' link next to the page you would like to freeze.