Why is Stack Overflow trying to start audio?

Question

I often have my browser's devtools open since I'm often debugging a snippet. I noticed this message often recently:

Why is Stack Overflow trying to start audio?

Update.

I see it's from an ad(?).

https://static.adsafeprotected.com/sca.17.4.95.js

Update 2

It happens when this ad appears, from Microsoft via Google.

Update 3

2019-08-15: Official company response after investigation and inquiry. It has been decided that such user fingerprinting ads will be permitted, as they do not violate any laws or regulations.

Answer 1

The ad is attempting to use the Audio API as one of literally hundreds of pieces of data it is collecting about your browser in an attempt to "fingerprint" it, to uniquely identify you across sites despite your privacy settings.

This isn't general speculation; I've spent the last half hour going through the source code you linked above, and it goes to considerable lengths to deanonymize viewers. Your browser may be blocking this particular API, but it's not blocking most of the data.

I've included several examples below. To be absolutely clear, this logic is not being used for legitimate feature detection. The results of these checks are not used to enable/disable parts of the ad; they're only used in aggregate to generate a user fingerprint, which the ad includes along with the advertising ID when recording analytics for the publisher.

It detects your system's resolution and accessibility settings.

function "==typeof matchMedia&&a239.a341.a77 ("
all and(min--moz - device - pixel - ratio: 0) and(min - resolution: .001 dpcm)
")},function(){return"
function "==typeof matchMedia&&a239.a341.a77 ("
all and(-moz - images - in -menus: 0) and(min - resolution: .001 dpcm)
")},function(){return"
function "==typeof matchMedia&&a239.a341.a77 ("
screen and(-ms - high - contrast: active) and(-webkit - min - device - pixel - ratio: 0), (-ms - high - contrast: none) and(-webkit - min - device - pixel - ratio: 0)
")},function(){return"
function "==typeof matchMedia&&a239.a341.a77 ("
screen and(-webkit - min - device - pixel - ratio: 0)
")},function(){return"

It looks for the presence of vendor-specific cryptography APIs,

return "function" == typeof MSCredentials && a239.a341.a66(MSCredentials)
    }, function() {
        return "function" == typeof MSFIDOSignature && a239.a341.a66(MSFIDOSignature)
    }, function() {
        return "function" == typeof MSManipulationEvent && a239.a341.a66(MSManipulationEvent)
    }, function() {

It looks at the list of fonts you have installed.

    return "object" == typeof document && a239.a341.a68("fonts", document.fonts)

It detects which Audio API capabilities your browser supports.

    return "undefined" != typeof window && "undefined" !== window.StereoPatternNode && a239.a341.a66(window.StereoPannerNode)

It detects which mobile-browser-specific APIs you support.

    return "function" == typeof AppBannerPromptResult && a239.a341.a66(AppBannerPromptResult)

It checks for platform-specific DRM support.

}, function() {
    return !!a239.a341.a72() && a239.a341.a66(a239.a341.a72().webkitGenerateKeyRequest) && a239.a341.a66(a239.a341.a72().webkitCancelKeyRequest) && a239.a341.a66(a239.a341.a72().webkitSetMediaKeys) && a239.a341.a66(a239.a341.a72().webkitAddKey)
}, function() {

It detects a hundred other things but this post is long enough.

Use an ad blocker!

Answer 2

Update: 2019-06-27

We’ve been working on a lot behind the scenes and wanted to give an update here. On Stack Overflow specifically the ads are delivered directly through us or relayed through specific 3rd party providers. The latter is where the fingerprint issue lies.

We are trying to address this on a few fronts:

• We have contacted Google for assistance in what features they provide to address this. (We use them as our ad server, that’s why we’re in contact with them).
• We are testing deployment of Safe Frame to all ads. It’s on most ads now, but we’re putting control on our rendering side to enforce this safety mechanism.
• We are trying to deploy the Feature-Policy header to block access to most browser features from all components in the page.

While Feature-Policy is the browser feature most meant to address this, we’re hitting issues in practice. I’ve reached out to several experts and the Google Chrome security team and we’ve filed a bug in the Chrome tracker. A minimal test version of the header is deployed on Stack Overflow now to help the browser teams investigate what we’re hitting.

We know the audio/fingerprinting issue is not isolated to Stack Overflow, but external sites as well. Our goal is to fix it at the third party layer if possible and add any protections we can to directly our network/pages.

We are not turning off these ad campaigns as a knee-jerk reaction because we need a repro to confidently fix the issues. We would much rather put in protections for long-term guards than playing whack-a-mole with issues as they arise. We are working on those stronger long-term protections now.

We are open to help fixing this. If you have more information, suggestions, can help with the Chrome bug above, or anything else: we welcome it. We are trying to do the right thing and get this fixed and fixed well ASAP.

I’ll update this post as we have more info.

---

Original Response: 2019-06-26

Thanks for letting us know about this.

We are aware of it. We are not okay with it.

We're trying to track down what is doing it and get that mess out of here. We've also reached out to Google to enlist their support. I'll be honest: it's late in the day and we're unlikely to get this resolved today. But we've reached out and hope to get it fixed ASAP.

Note: this is not related to ads being tested on the network - it's a distinctly separate issue. Programmatic ads are not being tested on Stack Overflow at all.

I'm also sorry it took a bit to respond. We had a completely unrelated SQL issue earlier causing production issues that stole a lot of our attention.

Answer 3

There's not much to be done about it, sadly

If you use a mobile phone you've probably noticed this a lot more because Adsense hijacking is a very real and serious problem and, for some reason, Google seems to take a "this filtering is good enough" approach

Many social media posts lamented that even top-tier publishers like The New York Times and The Atlantic were willing to run such intrusive ads on their sites. But experts say the problem isn’t with lack of discernment on the part of site publishers but with an extremely complex online advertising system that makes it hard for publishers involved to detect, let alone weed out, misleading and malware-laden ads.

Malvertising, as it’s sometimes called, isn’t new. The first recorded sighting of a malware-loaded ad, in late 2007 or early 2008, stemmed from a vulnerability in Adobe Flash, and affected a number of platforms including MySpace, Excite, and Rhapsody. In 2012, the Online Trust Alliance, an industry group, estimated nearly 10 billion ad impressions were compromised by malicious ads. But those in the digital ad industry say the problem has been rapidly growing worse.

I notice it a lot because I have a site I frequently (not SO) that runs Adsense, and they used to have a massive problem with their ads hijacking the page (on mobile you can't just easily close the affected tab). I know Nick Craver is going to get farther than most, but I don't think this is a problem he can solve. Yes, you can identify the bad actor and then block and report them, but they're a dime a dozen. Unless SO moves to an entirely in-house ad solution (which means they have to write a system to handle adding, showing and tracking ads, as well as a viable way to sell those ads), or Google comes up with a solution they've not come with in the last 7 years or so, this is going to be a persistent problem.

The only winning move here is not to play