161–170 of 280 posts
The author is concerned that an ad might be able to surreptitiously turn on the camera or microphone, but these are not accessible by default. In this case, it isn't even getting as far as a permissions prompt because the default Feature Policy doesn't allow camera or mic access in cross-origin iframes. (Ex, for Chrome: https://sites.google.com/a/chromium.org/dev/Home/chromium-se... ) Instead, I think the most likely…
Earlier quoted context omitted.
"In a lab environment" -> Certainly happens, but what if the script targets "specific devices" like "samsung galaxy s10" which google won't be able list exhaustively? What if bad actors figured out a way to identify google's emulators and avoid doing bad stuff in that situation? The part i said "google develops browser solutions to prevent issues like this" is exactly what features policy will end up doing. But googl…
I thought they meant more like sandbox environment. Why would the API to access those things exist at all?
I think this sounds more like some sort of fingerprinting attempt. It good to see that random access to these kind of resources fails due to new(er) browser controls. However, this does not mean that the fingerprinting actually failed. There is probably some way to determine if the request was denied automatically by the browser or manually by the user (e.g., time to get "response"), which is definitely something whi…
In my experience, with tools like Cover Your Tracks (apparently this is the new name for Panopticlick), the more you try and thwart fingerprinting, the more unique you appear. Although I still do everything I can to block and filter everything conceivable, I've given up on trying to figure out how identifiable I am on the web because it seems useless. If you don't try then you're identifiable, and if you do then you…
This was fairly secure because even the same employee was unlikely to get the same fingerprint twice - it was only occasionally more convenient than generating a random hash everytime they opened the browser. It became a huge pain for managers to be called constantly on the weekend to remotely reauthorize the devices they'd just authorized a few hours ago, or when chrome suddenly updated itself for half the employees, so eventually we switched to a looser hybrid of fingerprints and local storage.
I think this sounds more like some sort of fingerprinting attempt. It good to see that random access to these kind of resources fails due to new(er) browser controls. However, this does not mean that the fingerprinting actually failed. There is probably some way to determine if the request was denied automatically by the browser or manually by the user (e.g., time to get "response"), which is definitely something whi…
The script at https://cdn.js7k.com/ix/talon-1.0.37.js is an ad verification library developed by Verizon Media (formerly Oath), and it does, among other things,, fingerprinting for bot detection purposes (because they want to prevent ad fraud). It was served together with the actual ad media (so called "creative") into the safeframe.
This a relativity begin case. Iv'e seen much more terrible stuff, from fingerprinting for user taking to straight out malware being served in ads. It's a wild west (or web).
[0]: https://www.iab.com/guidelines/safeframe/
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
Earlier quoted context omitted.
In my experience, with tools like Cover Your Tracks (apparently this is the new name for Panopticlick), the more you try and thwart fingerprinting, the more unique you appear. Although I still do everything I can to block and filter everything conceivable, I've given up on trying to figure out how identifiable I am on the web because it seems useless. If you don't try then you're identifiable, and if you do then you…
One thing you can do is use different computers for different purposes.
Earlier quoted context omitted.
"In a lab environment" -> Certainly happens, but what if the script targets "specific devices" like "samsung galaxy s10" which google won't be able list exhaustively? What if bad actors figured out a way to identify google's emulators and avoid doing bad stuff in that situation? The part i said "google develops browser solutions to prevent issues like this" is exactly what features policy will end up doing. But googl…
I thought they meant more like sandbox environment. Why would the API to access those things exist at all?
Earlier quoted context omitted.
> Since ads can run arbitrary JS it's hard to enforce policy programmatically. Letting ads run arbitrary JS is the policy, right? It's not like that's a requirement to make the internet work, that's just a Google policy that trades money for user experience.
> Letting ads run arbitrary JS is the policy, right? I mean, anything on the Web can run arbitrary JS. The entire point is that it's a sandbox environment where arbitrary JS can't do any harm (excluding cases where vulnerabilities are found). If you're not comfortable with arbitrary JS running on your computer, you'd have to either (a) not use the Web, (b) disable JavaScript, or (c) only visit sites which you have ve…
> I don't know what else you could really expect of them.
Your option C is basically how it must work, and mostly does. To be safe online we go to sites we trust. When Google delivers malicious JS through ads, the site operator probably doesn't know Google has harmed the user on their behalf, so their trustworthiness becomes moot. Is there some "safe ads" codeless option for site operators who want to protect their users while still showing ads? Has Google made site operators aware they occasionally deliver malicious JS to users?
This is not google, but a third party ad network serving ads through google. Google tries to sandbox the creatives in an attempt to prevent issues exactly like this, and develops browser features to prevent issues exactly like this. This is likely a script that somehow avoided google's malware scanning pipelines. This is definitely not google's malintent. Disclaimer: Ex googler, worked in ads, dealed with problems li…
> This is likely a script that somehow avoided google's malware scanning pipelines. I can't think of a good reason for scripts through google ad syndication to be asking for camera and microphone permissions. I'd assume Google runs these scripts in something like a lab environment to see what's ultimately invoked before deploying them to production? If so, would this be indicative of both a deliberate controls bypass…