Alexei
Alexei
Chameleon's injected page script detects the navigator accesses (as per the following developer-mode page console output), but it looks like Chameleon proper never receives that info. ``` Navigator.plugins prop access:...
While this scenario might be an acceptable edge case, it is true that Chameleon does not trap [Plugin](https://developer.mozilla.org/en-US/docs/Web/API/Plugin) properties, only Navigator properties (such as PluginArray).
Oh, sorry, those aren't errors! It's just Chameleon [figuring out the originating script using Chrome stack traces](https://github.com/ghostwords/chameleon/blob/3db3bf2db3fc26333c8c9e2adb1d051d0ce88a28/src/js/injected.js#L187-L217) and me not bothering to edit the traces before dumping them to the...
On that [second demo page](https://securehomes.esat.kuleuven.be/~gacar/dev/test/navfp/access_nav_plugins.html) Chameleon currently picks up a single hit for navigator.plugins and a single hit for navigator.mimeTypes. While that's correct, I agree it would be great to...
Now that I turned off raw counting of property accesses (96f3468), this ticket should help (re-)light Chameleon on [Panopticlick](https://panopticlick.eff.org/).
Yep, adding it soon: #6
Just added site whitelisting: 68919fa. At least now there should be a better workaround. Let me know what you think.
My reasons for starting with Chrome are that Chameleon has ways to go before it becomes something I can push to non-technical, non-researcher users, and that I'm much more familiar...
This happens because Chameleon currently fixes various JavaScript screen width/height metrics to match Tor Browser defaults, which throws off YouTube's calculations. This is the same basic issue as #8.