An iframe from googlesyndication.com tries to access the camera and microphone • Hacker News Board

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#211

Post by wavefunction » Sun, Dec 19, 2021, 9:23 PM UTC

adtehcmadness1 wrote: post #174

tomudding wrote: post #31

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…

As someone working on exactly this type of stuff, your'e absolutely right. *.safeframe.googlesyndication.com is Google's implementation of the IAB's safeframe standard[0], which is basically a cross origin iframe with an API that's exposed to the embedded 3rd party code (the ad). This is how its HTML looks like (some attributes removed for readability): As you can see, it has both sandbox[1] and allow[2] attributes.…

>allow-popups-to-escape-sandbox

That setting is exactly the sort of reason I'm locked in a war to block ads from Google and others. What good is an escapable sandbox, other than for Google?

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#212

Post by colordrops » Sun, Dec 19, 2021, 9:26 PM UTC

SahAssar wrote: post #147

colordrops wrote: post #32

Earlier quoted context omitted.

Would it have to be audio? It could do TTS on the phone then send the text back.

I said "run speech-to-text on your device". Also TTS would be the other way around as it means text to speech.

Sorry I meant STT

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#213

Post by ghusbands » Sun, Dec 19, 2021, 9:47 PM UTC

shukantpal wrote: post #171

judge2020 wrote: post #156

Earlier quoted context omitted.

Search 'hr platform' and you only get ads for HR platforms. At no point will you see totally unrelated ads for stuff you didn't search for, since those will do much worse than contextual ones in the search context.

Yeah but if you search for something generic, Google will infer what you are searching for based on your profile.

But the context/question is whether or not the adverts are different, not whether the search results are different.

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#214

Post by kevin_thibedeau » Sun, Dec 19, 2021, 9:50 PM UTC

_fat_santa wrote: post #113

ravenstine wrote: post #69

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…

I attack if from a different direction. All these companies want to fingerprint your device and track you for really one reason at the very end: showing you a targeted ad. Now what happens if they can't deliver that ad (because you have an adblocker installed), well all that tracking and fingerprinting they just did is moot, because there's nothing actionable they can do with it. That's my rather naive opinion, idk a…

The problem is all activity gets sold to data brokers who build up a profile on you for future targeting.

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#215

Post by kevin_thibedeau » Sun, Dec 19, 2021, 9:55 PM UTC

dc3k wrote: post #173

tomudding wrote: post #31

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…

> https://fingerprintjs.com/blog/audio-fingerprinting/ > It is particularly useful to identify malicious visitors attempting to circumvent tracking Ah yes, the visitor trying to not be tracked is the malicious one. Barf.

The nerve of some people protecting themselves against browser exploits.

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#216

Post by adtechmadness2 » Sun, Dec 19, 2021, 9:55 PM UTC

wavefunction wrote: post #211

adtehcmadness1 wrote: post #174

Earlier quoted context omitted.

As someone working on exactly this type of stuff, your'e absolutely right. *.safeframe.googlesyndication.com is Google's implementation of the IAB's safeframe standard[0], which is basically a cross origin iframe with an API that's exposed to the embedded 3rd party code (the ad). This is how its HTML looks like (some attributes removed for readability): As you can see, it has both sandbox[1] and allow[2] attributes.…

>allow-popups-to-escape-sandbox That setting is exactly the sort of reason I'm locked in a war to block ads from Google and others. What good is an escapable sandbox, other than for Google?

well, while I definitely block ads as well (when I don't reverse engineer them), this directive does have a good reason. It means:

"Allows a sandboxed document to open new windows without forcing the sandboxing flags upon them".

If it was absent, when user clicks the ad and it opens a new tab of the advertiser website, it would inherit the sandbox directives from the safeframe, which might break it. To be clear "sandbox" in this context refers to the iframe sandbox[0], not to be confused with the renderer process sandbox[1].

[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#217

Post by userbinator » Sun, Dec 19, 2021, 10:00 PM UTC

archsurface wrote: post #90

They recently changed their meet application for some reason. I use it without video, voice only; recently it has started trying to force me to use both - I have to refuse both, then once in the meet go and enable voice only. I loathe all things google but am forced to use meet for work.

I doubt you actually work there given your last sentence, but have you tried proposing an alternative (along with some reasons why it would be better) the next time someone asks you to use it?

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#218

Post by NavinF » Sun, Dec 19, 2021, 10:01 PM UTC

wavefunction wrote: post #211

adtehcmadness1 wrote: post #174

Earlier quoted context omitted.

As someone working on exactly this type of stuff, your'e absolutely right. *.safeframe.googlesyndication.com is Google's implementation of the IAB's safeframe standard[0], which is basically a cross origin iframe with an API that's exposed to the embedded 3rd party code (the ad). This is how its HTML looks like (some attributes removed for readability): As you can see, it has both sandbox[1] and allow[2] attributes.…

>allow-popups-to-escape-sandbox That setting is exactly the sort of reason I'm locked in a war to block ads from Google and others. What good is an escapable sandbox, other than for Google?

The iframe sandbox is not for you or google. It’s for sites that want to protect themselves from ads they embed on the page. You’ll also see this used on proxy websites that scrape your requested URL and embed the contents of that page in an iframe.

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#219

Post by jessaustin » Sun, Dec 19, 2021, 10:02 PM UTC

guptaneil wrote: post #24

jessaustin wrote: post #2

We have a chance to notice this when it's mediated by a browser. Native apps don't barf all over the console and thus escape such scrutiny. I first considered this when a friend told me about a brand of lawnmower of which I had never heard let alone searched (mowing lawns is the least interesting activity I can imagine), and one minute later a podcast app had a big banner at the top by which I could purchase a lawnmo…

This is a common belief that phones must be listening to us because ads are so targeted, but the scary truth is they aren’t[0] because they don’t need to. They have far more effective ways of targeting ads. For example, the reason you probably saw the lawnmower ad is because your friend searched for lawnmowers, and google knows they are friends with you, so they showed you targeted ads too because you might recommend…

In this case, the conservative explanation seemed unlikely for several reasons. This friend would be more precisely described as the elderly friend of my elderly parents. Neither of us are on social media, she doesn't know what podcasts are, and neither of us had even used a web browser in the preceding several hours. Neither of us was in the market for a new riding mower nor had been in the preceding decade. I was on her (remote, inconsistent-cell-reception) farm to help with some cattle. I had never heard of this brand before, and now over a year later I can't think of it.

Is it so unlikely that an ad network sketchy enough to pay its way onto random Android apps would also be sketchy enough to monitor conversations for keywords that can get it paid? I don't think that's unlikely at all.

Re: An iframe from googlesyndication.com tries to access the camera and microphone

#220

Post by 1vuio0pswjnm7 » Sun, Dec 19, 2021, 10:04 PM UTC

ravenstine wrote: post #69

tomudding wrote: post #31

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…

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

In the interest of fair balance, I have had the opposite experience.

"I've given up..."

That's probably what "tech" companies are hoping you will do. I see this response repeatedly on HN when the fingerprinting topic comes up. I am wondering if the persons submitting these replies want others to "give up".

Is there a difference between users wanting to appear "the same" and a desire by users to stop supplying maximum amounts of free data/information to "tech" companies and exacerbating the problem of online advertising and associated surveillance.

If a user sends no fingerprinting data/information, then she might be "unique" because most users are sending excessive amounts of fingerprinting data/information. However, IMO, that is hardly a sound argument for continuing to send excessive amounts of fingerprinting data/information. I subscribe to the general principle of sending the least amount of information possible to successfully retrieve a page. This might be "unique" user behaviour, but I am confident it is the correct approach. The big picture IMHO is that "tech" companies, generally, are trying to collect data/information about users to inform online advertising. Uniquely identifying users is only a part of what they are trying to do.

It is a bit like telling a user to use/not use an ad blocker based on what other users are doing, so as to avoid being "unique". This might help with avoiding "uniqueness" but clearly there are gains to be had from using an ad blocker that are greater than the value of trying to appear "the same" as every other user.

Imagine users are all trying to appear exactly the same, so they embark upon coordinating with each other to make the exact same choices. It stands to reason that the number of choices each user has to make is going to be a factor in whether this is successful.

If every user is choosing to send large amounts of data/information (e.g., using browser defaults), then every user has to coordinate their choices on every single data point or bit of information. The higher the number of "correct" choices each user has to make, the less likely that all users succeed in being uniform. There are more chances for error. Whereas if we reduce the number of data points and bits of information so that every user is only sending one or two headers, with no Javascript, CSS, etc.,^1 then that is far easier for users to coordinate.

1. This has been tested heavily by yours truly for decades. One does not need a graphics layer or graphical browser features to make successful HTTP requests. I am not interested in being "invisible", I am interested in reducing the amount of free data/information I give to "tech" companies. Perhaps there is a difference between wanting to "blend in" and wanting to stop "feeding the beast".

"We do not know anything about User A. It looks like she is using TOPS-20 to browse the internet."

Is User A less or more likely to be unique. Probably more. Is User A a more or less viable target for online advertising. To me, it is the second question that matters the most.