Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techsparx.com

Post reply on HN
Print view View original

91–100 of 280 posts

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

#91

Post by IsThisYou »

jefftk wrote: post #41

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…

Is it a good idea for Google to allow random advertisers to use privacy sensitive code (like audio access or fingerprinting) in advertiser supplied iframe content?

People may be visiting a trusted site and then are asked to allow audio and video, not realising that it is an iframe asking for the permission.

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

#92

Post by _hyn3 »

jefftk wrote: post #82
ineptech wrote: post #74

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.

Ads are allowed to run arbitrary JS, but that doesn't mean they are allowed to do arbitrary things by policy. That is, the technical restrictions are not able to be as strict as the policy. A bunch of us were working on a project where ads would be fully declarative, and so no longer able to run arbitrary JavaScript, but this received very little interest outside of Google (advertisers didn't want to move to a new fo…

Why is it up to the advertisers and publishers?

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

#93

Post by hetspookjee »

streptomycin wrote: post #60
yjftsjthsd-h wrote: post #58

Earlier quoted context omitted.

Oh no, how will the poor advertisers survive if someone tries to stop them from shipping malware?

The problem isn't that advertisers should be allowed to ship malware, it's that it's hard to distinguish malware from non-malware. Also the adjacent problem of "not quite malware, but shitty code that spams error logs and runs way slower than it should".

Why should ads be so free to run arbitrary code? It seems to me that in the end Google should be held responsible for anything they serve to others. If they'd be fined for this lack of oversight, perhaps they'd block javascript as a whole until they do have proper oversight in place?

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

#94

Post by tehlike »

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 like this all the time.

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

#95

Post by Tsiklon »

_hyn3 wrote: post #92
jefftk wrote: post #82

Earlier quoted context omitted.

Ads are allowed to run arbitrary JS, but that doesn't mean they are allowed to do arbitrary things by policy. That is, the technical restrictions are not able to be as strict as the policy. A bunch of us were working on a project where ads would be fully declarative, and so no longer able to run arbitrary JavaScript, but this received very little interest outside of Google (advertisers didn't want to move to a new fo…

Why is it up to the advertisers and publishers?

I suppose they're the paying customers.

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

#96

Post by voakbasda »

streptomycin wrote: post #60
yjftsjthsd-h wrote: post #58

Earlier quoted context omitted.

Oh no, how will the poor advertisers survive if someone tries to stop them from shipping malware?

The problem isn't that advertisers should be allowed to ship malware, it's that it's hard to distinguish malware from non-malware. Also the adjacent problem of "not quite malware, but shitty code that spams error logs and runs way slower than it should".

Shitty code should be rejected too, if they have any kind of a standard for of quality. If it runs slow during testing, how do you think users will feel when they run it on their systems?

Code that makes your system appear infected with malware is indistinguishable from actual malware.

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

#97

Post by eganist »

tehlike wrote: post #94

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 and a ToS violation by the ad network?

Sounds like Google Syndication may have taken care of this by enabling Permissions Policies(1) across its domains? I can't tell because the article references Feature Policy (a predecessor to Permissions Policies(2)) "in Safari" even though Feature and Permissions Policies, as best as I understand them, are delivered from the origin for implementation by the browser. So I'm kinda confused.

And if they don't implement it, it tells me they're totally fine with this kind of fingerprinting.

(1)https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Po... (2)https://www.w3.org/TR/permissions-policy-1/

---

A prior version of this comment suggested Google should add permissions policies. I since edited it to clarify that I'm quite confused over whether it's something Google already implemented or something Safari overlaid on top of Google syndication origins since I can't verify using the origins themselves. The article seems to suggest it's something Safari specific even though the spec for both FP and PP involves receiving a set of permissions from the origin as a header and implementing them in the browser.

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

#98

Post by dustymcp »

fsflover wrote: post #85
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…

> the more you try and thwart fingerprinting, the more unique you appear. Not if you use Tor Browser.

Then i just get put on another list :)

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

#99

Post by IsThisYou »

vklmn wrote: post #29

I don't think that it's google's fault. Google sometimes trade ads on auctions, meaning they issue and HTTP request to partners asking "Hey, you want to show an ad here", and partner respond with price and HTML code, the highest bidder wins and HTTP code is inserted. HTTP contains JavaScript, and theoretically anything can be executed within the browser (I've seen people mining bitcoins!). Google can't monitor an exe…

Legally it probably isn't Google's fault. But then again, I don't care. I protect myself.

I use a /etc/hosts file[0] that blocks all of Goog's ad empire and thousands more. I never see YT ads or any other ads anymore. It sucks for the creators, but "safety first" as they say.

Maybe one day Goog starts to care about serving ads that are safe and not intrusive, then I may unblock them again.

Also, I just bought my first iPhone.

[0] https://raw.githubusercontent.com/StevenBlack/hosts/master/h...

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

#100

Post by mschuster91 »

hetspookjee wrote: post #84
jefftk wrote: post #71

Earlier quoted context omitted.

I'm not sure it is allowed; that's not a part of the business I know much about. Since ads can run arbitrary JS it's hard to enforce policy programmatically. On the other hand, it's not clear to me that whatever this advertiser is trying to do is having any real effect, aside from causing a console message that it is being blocked. Access to the mic and camera from cross-origin iframes is blocked by default, and you…

Haha, easy way to create plausible deniability if you just allow everything to run :D. Doesn't that also make it easy for anyone running an ad to run hivemind in the ad itself? In addition, why is it hard to enforce a policy that disallows any ad to reach out to the camera and microphone? I don't understand why that is hard to enforce.

Because ads can use Javascript which is notorious for how hard it is to vet code and how easy it is to hide functionality.
Post reply on HN