Should Facebook fix this security bug if it means losing a little functionality and a lot of influence?

Yesterday, we wrote about a security bug on Facebook and Twitter that exposes users to phishing attacks when they click a link and it opens in a new tab or window. That newly-opened page has some access to the source page that the user clicked from. The access is limited, but it’s enough to force the original page to load an entirely different website.

After we published that story, Facebook got back to us and laid out its options for fixing the bug, demonstrating that the fix is not quite as simple as it may appear. Facebook has a conundrum: Should it fix this simple bug even if it has a negative effect on user experience and Facebook’s influence as a traffic-driver?

As we wrote yesterday, the vulnerability exists on Facebook and Twitter because both websites insert the target="_blank" attribute into their hyperlink code, which is the common method for making links open in new pages. The full hyperlink HTML looks like this:

<a href="//qz.com" target="_blank">Quartz</a>

A fix for this, as developer Ben Halpern pointed out on his website earlier this month, is to insert the rel="noopener" attribute into a hyperlink that uses target="_blank", so it would look something like this:

<a href="//qz.com" target="_blank" rel="noopener">Quartz</a>

Facebook says that although Halpern’s fix (and an older one, which is to add the rel="noreferrer" attribute) would indeed block possible phishing attacks, it would also block websites from seeing that their visitors came from Facebook.

Facebook’s status as a top traffic referrer is a major source of its influence, as well its revenue. Many websites count on knowing where their visitors came from, particularly if they’re paying Facebook to get them.

“It’s critically important to everyone who publishes content on the Internet to know who is driving their traffic, so this option doesn’t work,” said a Facebook spokesperson in an email. Facebook could also use the window.open() JavaScript method, the spokesperson added, but that “slows down link opening substantially.”

Halpern, the developer who called out the issue earlier this month, agrees that the tradeoff between referral data and safety presents a difficult choice. “Basically you either don’t pass relevant information or you put your users in a vulnerable position,” Halpern said in an email. “It’s sort of a lose-lose.”

Rather than give up link-loading speed or its referral influence, Facebook has opted for a more macro approach. The site limits the number requests a given IP address can make to it each second, which keeps hackers from phishing users en masse, the spokesperson said. Facebook constantly monitors for suspicious activity as well. That won’t stop websites from exploiting the vulnerability on a small scale, however, or keep hackers from targeting individuals.

The makers of web browsers also have a role in this, Facebook’s spokesperson pointed out, and could simply change the behavior of target="_blank" to fix the bug going forward. But this would not fix the issue for users of older browsers, Halpern said, “which I would suspect would be the people most vulnerable in the first place, as the more technically savvy people will not use older browsers.”

There is, of course, another option. Facebook could simply load the links people click in the same tab or window. But that would mean leaving Facebook. That would obviously be bad for Facebook, but many of the website’s 1.7 billion users probably wouldn’t like losing that functionality either. People like to keep their place on social feeds, and not everyone knows how to right-click to open a link in a new tab.

home our picks popular latest obsessions search