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.
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.
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
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.
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?