; Date: Tue Dec 14 2021
In case you're not aware, there is extreme alarm about the possibility that the web-camera or microphone built-in to laptops, smart phones, and the like, could be surreptitiously turned on. What if Big Brother were to turn on the camera, without turning on the indicator light, and take pictures, or record audio from the built-in microphone? There's a long list of possible nefarious results, and this has to be seen as a serious privacy intrusion.
Trying to search for information on googlesyndication connecting to camera or microphone turns up results indicating that many believe
safeframe.googlesyndication.com is some kind of malware or virus distribution server. That's a strange assumption to make, considering the purpose for the
Namely, that domain is affiliated with the Google Ads and Google Adsense advertising networks. The purpose is delivering tailored marketing (advertisements) to people. Whether you think this is malware, I suppose, depends on how you consider Google Ads or Google Adsense.
GoogleSyndication.com domain is part of Google's legitimate ad serving service. Given Google's policies around that service it is extremely unlikely for malware to be distributed through that particular service.
But... if that's the case, how can you explain these messages?
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.
The messages are somewhat clear -- that an
<iframe> loading stuff from
safeframe.googlesyndication.com triggered a Feature Policy check. Fortunately the policy checks for Camera and Microphone failed. The same script,
talon-1.0.37.js, also tried to enumerate (list) the available devices, which failed.
Fortunately the feature policy settings in Safari disallowed this. I shudder what to think of what an advertiser would do after turning on the Camera or Microphone on my laptop.
Browser settings to limit Camera or Microphone access
In Google Chrome we can allow or disallow websites to access the Camera or Microphone. To take a look at this, take your mouse to the upper-right-corner of the browser where there are three vertical dots. This is the Chrome browser menu, and one of the choices is Settings. In the Settings area, navigate to Privacy and Security, then to Site Settings. There you'll find areas dedicated to Camera and Microphone, and in both areas you can set a default policy, and set which websites are allowed to access these devices.
In Firefox, open the Preferences dialog, then navigate to Privacy & Security. You'll find Camera and Microphone areas in which you can select websites that are allowed to access these devices.
In Safari, open the Preferences dialog, and navigate to Websites. You'll find tabs for Camera and Microphone, each of which list domains that are allowed (or not) to access these devices.
Notice that I have set one domain to Deny. That's because the scripts in question came from that domain -
What's blocking access is a Feature Policy
It is incumbent for website publishers to provide a safe browsing experience to our visitors. Modern web standards have at least two HTTP headers which affect security policies in the web browser.
- The Content-Security-Policy header lets the website inform the web browser from which domains it should allow content to be loaded.
- The Feature-Policy header lets the website inform the possible browser features that will be needed. This includes not just the Camera and Microphone but things like Accelerometers, Gyroscope, displaying in Fullscreen, and so forth.
What blocked the Camera and Microphone access in this case was Feature Policy settings in Safari.
Apparently the Feature-Policy header is being renamed to Permissions-Policy by the standards committee. For now, use Feature-Policy.
Both policy headers are set in the HTTP response headers sent by your web server. If you are not able to set HTTP headers, you can use a header like this:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
This header is to be put in the
<head></head> section. The
<meta http-equiv> tag is to be interpreted as if the corresponding HTTP header was set.
Mozilla Developer Network has examples of using Feature-Policy in both HTTP headers and on
<iframe> elements. For iframes, the
allow=... attribute sets the policy for it.
Unfortunately, the normal way Google Adsense and Google Ads advertising gets into a web page does not allow website publishers to control attributes on the