Live data from Hacker News

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

techsparx.com

81–90 of 280 posts

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

#81
post #73

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…

Those anti-fingerprinting tools should make you appear as the most common iPhone as much as possible.

the basicest of basic

live laugh love as the user-agent

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

#82
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…

> 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 format, publishers didn't care) and we moved on.

(Still speaking only for myself)

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

#83

Quite ironic that the website posting the article actually has googlesyndication.com.

> These messages appeared in the JavaScript console on Safari while browsing multiple pages on techsparx.com. At first I saw it on one page, then checked other pages and got the same messages. This site is using Ezoic's advertising system, which in turn uses Google Ad Manager for some advertising.

Yeah he noticed it... on his own website.

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

#84
post #71
post #63

Earlier quoted context omitted.

Curiously no explanation why this sort of malicious behavior is accepted by "Google Ad Manager" in the first place. If you haven't already installed: https://addons.mozilla.org/en-US/firefox/addon/ublock-origin... https://chrome.google.com/webstore/detail/ublock-origin/cjpa...

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.

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

#85

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…

> the more you try and thwart fingerprinting, the more unique you appear.

Not if you use Tor Browser.

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

#86
post #27
post #13

Earlier quoted context omitted.

That doesn't protect your microphone from being exposed though.

this is why we need hardware switches for microphones

https://puri.sm/products/librem-14 - this device has the kill switch.

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

#88
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…

[deleted]

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

#89
post #67

Earlier quoted context omitted.

This is a catch-22 though. If something dangerous to privacy is being widely used in the world, then putting it behind a prompt creates an avalanche of prompts, and results in user apathy. But not prompting requires you to choose a default, which either default to block and breaks things (if it was actually required) or defaults to allow.

I would happily set all browsers to always deny all ads and untrusted domains the ability to use microphone and camera at all times. So there's no need for an avalanche of alerts, it just shouldn't be permissible for a resource from an untrusted source. It may be widely used, but for a highly concentrated set of sites. I can't think of an occasion I've used it beyond Google, Microsoft, and Zoom properties. Perhaps Sl…

> deny… untrusted domains the ability to use microphone and camera at all times

I believe this is the default for most browsers now, right? (Or have I been spoiled by Firefox?) This is the best way, where the camera is always inaccessible, unless you enable it for a domain which needs it. Since I rarely ever see the camera/mic request option, I don’t think we’ve been conditioned to allow this type of request. (Compared to cookies, which show up on nearly every site.)

If you want to disable permissions dialogues altogether, then what’s a trusted domain? Just zoom and a handful of others? If you write yourself a nice app which uses the mic, do you have to email Google to get yourself added to the list of trusted domains? That would be pretty bad for the open web, so permissions dialogues are the alternative

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

#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.
Post reply on HN