4 ms·

Am i the only one to think that the 'id' trick is a plain Chrome devtool bug ? Either the ids should be queried without side effect or not queried at all witho

Am i the only one to think that the 'id' trick is a plain Chrome devtool bug ? Either the ids should be queried without side effect or not queried at all without a user action. The second idea, using 'toString()' is well know and also works in other OO languages, Java, C#, etc.

iaml 5y ago
You could fix it by doing Object.getOwnPropertyDescriptor(div, 'id') to check if there's a getter instead of plain value, not sure about performance impact though.
- graderjs 5y ago
  But a work around might be being able to craft a Proxy target that looks like a HTMLDivElement but has a handler that captures the get('id') operation, and does the same thing as the example. In that case it may not be so easily inspectable...
  - hoten 5y ago
    No need to do any of this when you control V8. Chrome DevTools can decide to run code iff there are no side effects (by executing it and bailing on any writes/native functions like alert marked as having side effects). Presumably it costs some overhead to do that and that is why logging elements to the console does not enable the "no side effects" flag.
    - graderjs 5y ago
      But I think the point is more about how does a regular web app in web land detect devtools? Not, how does an app with DevTools privileges (via a Chrome extension, or connecting to the remote debugging port) that controls V8 via debugging APIs detect/prevent if DevTools pane has been opened (there are even APIs/events for this in chrome remote debugging protocol), so no need to rely on the side effects bailout you mention if your goal is to detect DevTools panels and you have "control" over V8. But maybe you're point was more about how would Chrome prevent this DevTools detection? I honestly don't think they would do this, but not because of "overhead"--simply because the console and debugging is useful, and it requires displaying elements, and inspecting those. So there will be no way around having actually printed out elements when DevTools is open. Except if you always printed them out whether it was open or not, but this would be too much overhead, as Chrome only lazily executes console commands (and optimizes things away if DevTools is not open). This is hilarious I'm saying this to you because you work at Lighthouse---so I'm about to learn something I guess! :p ;) xx haha
missblit 5y ago
Naturally this sort of issue has been reported in the past: https://bugs.chromium.org/p/chromium/issues/detail?id=672625 https://bugs.chromium.org/p/chromium/issues/detail?id=672625 From the comments on that bug there's other ways to detect devtools (including timing attacks), and it wouldn't be worthwhile to track down every possible case. As someone who uses devtools debugging a lot I think that answer is reasonable, these kinds of shenanigans mostly only slow down and amuse expert debuggers.
- josephcsible 5y ago
  > it wouldn't be worthwhile to track down every possible case. I disagree with this conclusion. I think websites being able to detect or interfere with devtools should be considered a security bug. Do we give up on stopping XSS and memory corruption because it's too hard to detect every possible case of them too?

iaml 5y ago

You could fix it by doing Object.getOwnPropertyDescriptor(div, 'id') to check if there's a getter instead of plain value, not sure about performance impact though.

graderjs 5y ago
But a work around might be being able to craft a Proxy target that looks like a HTMLDivElement but has a handler that captures the get('id') operation, and does the same thing as the example. In that case it may not be so easily inspectable...
- hoten 5y ago
  No need to do any of this when you control V8. Chrome DevTools can decide to run code iff there are no side effects (by executing it and bailing on any writes/native functions like alert marked as having side effects). Presumably it costs some overhead to do that and that is why logging elements to the console does not enable the "no side effects" flag.
  - graderjs 5y ago
    But I think the point is more about how does a regular web app in web land detect devtools? Not, how does an app with DevTools privileges (via a Chrome extension, or connecting to the remote debugging port) that controls V8 via debugging APIs detect/prevent if DevTools pane has been opened (there are even APIs/events for this in chrome remote debugging protocol), so no need to rely on the side effects bailout you mention if your goal is to detect DevTools panels and you have "control" over V8. But maybe you're point was more about how would Chrome prevent this DevTools detection? I honestly don't think they would do this, but not because of "overhead"--simply because the console and debugging is useful, and it requires displaying elements, and inspecting those. So there will be no way around having actually printed out elements when DevTools is open. Except if you always printed them out whether it was open or not, but this would be too much overhead, as Chrome only lazily executes console commands (and optimizes things away if DevTools is not open). This is hilarious I'm saying this to you because you work at Lighthouse---so I'm about to learn something I guess! :p ;) xx haha

missblit 5y ago

Naturally this sort of issue has been reported in the past: https://bugs.chromium.org/p/chromium/issues/detail?id=672625 https://bugs.chromium.org/p/chromium/issues/detail?id=672625 From the comments on that bug there's other ways to detect devtools (including timing attacks), and it wouldn't be worthwhile to track down every possible case. As someone who uses devtools debugging a lot I think that answer is reasonable, these kinds of shenanigans mostly only slow down and amuse expert debuggers.

josephcsible 5y ago
> it wouldn't be worthwhile to track down every possible case. I disagree with this conclusion. I think websites being able to detect or interfere with devtools should be considered a security bug. Do we give up on stopping XSS and memory corruption because it's too hard to detect every possible case of them too?