Hacker News Reader

Comment by i2shar | Hacker News Reader

It is indeed disturbing. Why should a web page be able to detect if dev tools has been opened? Isn't this a browser security issue?

View on HN

It's pretty insane how much your browser knows about you:

http://webkay.robinlinus.com/

There's another one I can't find, but it writes out things like "user moved mouse to x,y. User has been idle for 10 seconds, page lost focus, page gained focus" .. kinda creepy how much is available to the Javascript engine.

This is pretty normal for a UI programming framework. The creepy thing for me is when that stuff is reported back to the origin over a websocket.

You must be talking about clickclickclick.click

And thanks for the new novelty website bookmark :D

https://clickclickclick.click

Clickable link

Reminds me of “Achievement Unlocked”:

http://armorgames.com/play/2893/achievement-unlocked

Elephant Games are incredible and their creator is also imcredible. I highly recommend checking out his other games if you haven't already. http://www.jmtb02.com/

http://imgur.com/6ep0YnW

Operating system, browser, CPU, local IP, connection speed. That's all I was shown, probably thanks to uMatrix blocking 3rd party scripts.

>Browser Plugins

>No plugins detected.

Interesting. I have 6 installed on Firefox.

Firefox no longer reports installed plugins to websites. It causes some interesting behavior on websites that check to see if you have flash before letting you play games (sorry, you need to have flash installed). I had a user script for a while that 'fixed' the navigator.$whatever to show having flash installed so I could play some game; now I just use Shumway and it seems to work.

If you think this stuff is creepy well...okay?

I mean, it's not like every desktop application you've ever used in your life couldn't do the same or more?

The difference is that you run only trusted native applications with the ability to check their source code, while you are visiting untrusted sites which often have obfuscated javascript.

I think that it would be a better comparison between a pdf file and the web: pdfs files can't do the same or more.

PDFs can run JavaScript too. Open this PDF in Chrome: https://raw.githubusercontent.com/osnr/horrifying-pdf-experi...

And I would argue it is harder for the average user to view the JavaScript inside PDFs: on the web just right click and choose Inspect Element right in the browser; for a PDF you'll have to use specialized tools to decode the myriad encoding schemes inside a PDF. The average JavaScript developer doesn't know how to extract JavaScript from a PDF.

While it works on Chromium it does not seem to work in xpdf, pdf.js nor any other pdf viewer that I tried. It seems that JS, flash, etc inside pdfs are proprietary, useless, and potentially dangerous adobe-only extensions that nobody else implements and nobody uses. It's just that Chromium happened to have a JS engine so they decided to let JS inside pdfs to be executed with a very constrained API (which can't do anything malicious probably - unless a bug is found in its JS engine).

My point still stands: I do not expect a pdf document to be able to do anything like the djsumdog's link and neither do most people. If a pdf document was able to do anything like that I would consider that viewer as broken.

> The average JavaScript developer doesn't know how to extract JavaScript from a PDF.

They could learn with a few google searches.

> you run only trusted native applications with the ability to check their source code

Is the "you" in this scenario Richard Stallman?

I would suspect it's sniffing for the window-size suddenly changing in certain ways, perhaps along with watching for the normal dev-tools keyboard shortcuts via keydown listeners. I can't actually remember off the top of my head if Chrome suppresses the event in that case, but it wouldn't be surprising if it didn't.

The easy check for this would be to see whether opening the devtools in detached mode via the menus makes it notice.

Note that this would actually be quite a pain to hide from the page, just because it's something the page needs to know to display some stuff and make rendering calculations. If it was hidden from the page, we'd suddenly be complaining about debugging floating footers which are hiding under the devtools.

This is what happens when I trigged DevTools while logging key events:

document.addEventListener('keydown', ({ keyCode }) => console.log(keyCode))

You can see each key.

But there's different ways of opening dev tools. You can use the mouse to right click as well. In fact, when using keyboard shortcuts in the better these days, I have a habit of hitting alt+D first to get to the address bar first (Outlook likes to hijack browser shortcuts like Ctrl+n), in which case the website shouldn't know I'm pressing anything at all.

I think OP's point is you can listen for a bunch of signals: If you see the right keydown events, or if you see a contextmenu followed by a rapid change to innerWidth, they probably opened dev tools, and you should delete your evil cookies.

The person who figured this out probably opened them via menu and had dev tools in another window, so the evil folks couldn't detect the resize.

Reply on news.ycombinator.com