How this de-anonymization attack works is hard to explain but relatively easy to grasp once you get the gist of it. Someone leading the attack needs a few things to get started: a website they control, a list of accounts linked to people they want to identify as having visited that site, and content posted on the platforms. -shapes accounts from its target list that either allows the targeted accounts to see this content or prevents them from seeing it – the attack works both ways.

Then the attacker embeds the aforementioned content on the malicious website. Then they wait to see who clicks. If someone on the targeted list visits the site, attackers will know who they are by analyzing which users can (or cannot) see the embedded content.

The attack takes advantage of a number of factors that most people probably take for granted: Many major services, from YouTube to Dropbox, allow users to host media and embed it on a third-party website. Regular users usually have an account with these ubiquitous services, and most importantly, they often stay logged into these platforms on their phones or computers. Finally, these services allow users to restrict access to content uploaded to them. For example, you can configure your Dropbox account to share a video privately with one or more other users. Or you can publicly upload a video to Facebook, but block certain accounts from viewing it.

These “block” or “allow” relationships are central to how researchers have found they can reveal identities. In the “authorized” version of the attack, for example, hackers can discreetly share a photo on Google Drive with a Gmail address of potential interest. Then they embed the photo on their malicious webpage and lure the target there. When visitors’ browsers attempt to load the photo through Google Drive, attackers can accurately infer whether a visitor is authorized to access the content, i.e. whether they control the email address in question.

Thanks to the existing privacy protections of the major platforms, the attacker cannot directly verify whether the site visitor was able to load the content. But NJIT researchers realized that they could analyze accessible information about the target’s browser and their processor’s behavior as the request occurred to determine whether the content request was permitted or denied.

The technique is known as a “side channel attack” because the researchers found they could make this determination accurately and reliably by training machine learning algorithms to analyze seemingly unrelated data about how which the victim’s browser and device are processing the request. Once the attacker knows that the only user he allowed to see the content did so (or the only user he blocked was blocked), he anonymized the site visitor.

As complicated as that may sound, the researchers warn that it would be simple to pull off once the attackers did the prep work. It would only take seconds to potentially unmask every visitor to the malicious site, and it would be nearly impossible for an unsuspecting user to detect the hack. Researchers have developed a browser extension that can thwart such attacks, and it’s available for Chrome and Firefox. But they note that this may have a performance impact and is not available for all browsers.

Through a major disclosure process to numerous web services, browsers, and web standards bodies, researchers say they’ve begun a broader discussion about how to address the issue comprehensively. At present, Chromium and firefox did not make the responses public. And Curtmola says fundamental and likely unachievable changes in processor design would be needed to fix the problem at the chip level. Still, he says collaborative discussions through the World Wide Web Consortium or other forums could ultimately produce a global solution.

“Vendors are trying to see if it’s worth solving this problem,” he says. “They need to be convinced that this is a serious enough problem to invest in solving it.”