Five Revelations from Facebook’s Internal Documents

A group of British MP’s, seemingly upset at Facebook CEO Mark Zuckerberg’s refusal to appear before the U.K. Parliament, have released a cache of seized Facebook documents. Here are five key facts from the documents.

As Breitbart News reported earlier today, the U.K. Parliament’s fake news inquiry has published a number of seized Facebook documents, which include emails between senior members of Facebook staff and other employees. The cache — which is approximately 250 pages long and was marked as “highly confidential” — was obtained from Six4Three, a startup app company that is suing Facebook. Here are five key facts from the cache of internal Facebook documents.

1: Internal Emails Reveal Facebook’s Cutthroat, Anti-Competitive Business Practices

These documents have provided a deep insight into the inner workings of Facebook and how the company deals with competitors. It has also shown that the company is often acutely aware of the consequences of their actions but chooses to go ahead with them anyway in order to turn a profit or gain market dominance.

In an email dated January 24th 2013, Facebook’s Vice President of Global Operations and Media Partnerships, Justin Osofsky, wrote to Facebook CEO Mark Zuckerberg, saying:

Twitter launched Vine today which lets you shoot multiple short video segments to make one single,6-second video.

As part of their NUX, you can find friends via FB. Unless anyone raises objections, we will shut down their friends API access today.

We’ve prepared reactive PR, and I will let Jana know our decision.

The Facebook CEO replied very simply to Osofsky saying:

Yup, go for it.

Zuckerberg’s nonchalant answer gives a unique insight into how the Facebook CEO deals with competition.

2: Executives Predicted Backlash over Android User Data Permissions

The documents show that executives predicted a public backlash to their Facebook Android app update which would see users call and text data transmitted back to Facebook. In an internal email, former Facebook Product Manager, Mike Lebeau, discusses the PR risks of the app update, stating that despite this the “growth team” will “charge ahead and do it.”

The email from Lebeau reads:

Hey guys, as you all know the growth team is planning on shipping a permissions update on Android at the end of this month. They are going to include the “read call log” permission, which will trigger the Android permissions dialog on update, requiring users to accept the update. They will then provide an in-app opt-in NUX for a feature that lets you continuously upload your SMS and call log history to Facebook to be used for improving things like PYMK, coefficient calculation, feed ranking, etc.

This is a pretty high-risk thing to do from a PR perspective but it appears that the growth team will charge ahead and do it.

Separately, Gravity team had been intending to ship the Bluetooth permission on Android at the same time – in fact we’d already delayed to accommodate more permissions from the growth team, but we didn’t realize it was going to be something this risky. We think the risk of PR fallout here is high, and there’s some chance that Bluetooth will get pulled into the PR fallout. Screenshot of the scary Android permissions screen becomes a meme (as it has in the past), propagates around the web, it gets press attention, and enterprising journalists dig into what exactly the new update is requesting, then write stories about “Facebook uses new Android update to pry into your private life in ever more terrifying ways – reading your call logs, tracking you in businesses with beacons, etc”.

Gravity had a great initial reception. This is because we took painstaking steps to ensure that we had a clear story of user value for the hardware and spoke from a position of transparency but not over-emphasis about the potentially scary bits. But we’re still in a precarious position of scaling without freaking people out. If a negative meme were to develop around Facebook Bluetooth beacons, businesses could become reticent to accept them from us, and it could stall the project and its strategy entirely.

So we’re still treading very carefully, and of course the growth team is also managing a PR risk of their own with their launch. >Given this, and the fact we have lots to iterate on with iOS, and we can still do non-beacon place tips on Android any time, we’ve been thinking the safest course of action is to avoid shipping our permission at the same time as “read call log”

Normally we’d have to wait until July for the chance to ship again, since we only ship Android permissions updates a couple times a year as they tank upgrade rates. So our options, aside from the “ship together and pray” option which feels too risky to me, are to wait until July to ship the Bluetooth permission on Android or ask for a special exception to ship our permissions update sooner.

Sipping permissions updates on Android has the downside of tanking upgrade rates, so we try to do it infrequently. But there could be an argument to doing it sooner in this case, as a compromise to allow both teams to continue moving fast, without unnecessarily conflating two PR risks into one.

3: Zuckerberg Discussed Selling User Data to Developers, Advertisers

According to the documents, Facebook CEO Mark Zuckerberg discussed selling access to user data, including information of users, to developers and advertisers on Facebook’s platform. Emails dating back to October 2012, shortly after Facebook’s IPO, show Zuckerberg brainstorming ways to generate revenue, including selling user data access directly to developers.

Zuckerberg wrote in his email:

I’ve been thinking about platform business model a lot this weekend…if we make it so devs can generate revenue for us in different ways, then it makes it more acceptable for us to charge them quite a bit more for using platform. The basic idea is that any other revenue you generate for us earns you a credit towards whatever fees you own us for using platform.

For most developers this would probably cover cost completely. So instead of every paying us directly, they’d just use our payments or ads products. A basic model could be:

Login with Facebook is always free
Pushing content to Facebook is always free
Reading anything, including friends, costs a lot of money. Perhaps on the order of
$0.10/user each year.

For the money that you owe, you can cover it in any of the following ways:
Buys ads from us in neko or another system
Run our ads in your app or website (canvas apps already do this)
Use our payments
Sell your items in our Karma store.
Or if the revenue we get from those doesn’t add up to more that the fees you owe us, then you just pay us the fee directly.’

In another email dated October 27 2012, Zuckerberg discussed linking user data to company revenue with Facebook’s former VP of Product, Sam Lessin. In the email, it appears that Lessin discussed the possibility of a data leak with Zuckerberg who did not seem to believe that a user data leak was a real threat. Zuckerberg wrote:

There’s a big question on where we get the revenue from. Do we make it easy for devs to use our payments/ad network but not require them? Do we require them? Do we just charge a rev share directly and let devs who use them get a credit against what they owe us? It’s not at all clear to me here that we have a model that will actually make us the revenue we want at scale.

I’m getting more on board with locking down some parts of platform, including friends data and potentially email addresses for mobile apps.

I’m generally sceptical that there is as much data leak strategic risk as you think. I agree there is clear risk on the advertiser side, but I haven’t figured out how that connects to the rest of the platform. I think we leak info to developers, but I just can’t think if any instances where that data has leaked from developer to developer and caused a real issue for us. Do you have examples of this?……

Without limiting distribution or access to friends who use this app, I don’t think we have any way to get developers to pay us at all besides offering payments and ad networks

This is another example of how Facebook views its users as its product.

4: Tinder Was a Key Focus for Facebook, Received Special Treatment

Emails from Konstantinos Papamiltidas, Facebook’s firector of platform partnerships, show how the dating app appeared to receive special treatment from Facebook as the company clamped down on who had access to user data and certain API’s. An email thread between Konstantinos Papamiltiadis and Tinder shows a discussion about giving Tinder full access to Facebook friends data in exchange for allowing Facebook to use the term “Moments.”

Konstantinos Papamiltidas – 11 March 2015:

I was not sure there was not a question about compensation, apologies; in my mind we have been working collaboratively with [name redacted] and the team in good faith for the past 16 or so months.

He’s a member of a trusted group of advisers for our platform (Developer Advisory Board) and based on our commitment to provide a great and safe experience for the Tinder users, we have developed two new APIs that effectively allow Tinder to maintain parity of the product in the new API world.’

Tinder – 12 March 2015:

“We have been working with [name redacted] and his team in true partnership spirit all this time, delivering value that we think is far greater than this trademark.”

It appears that while Facebook publicly claims to be doing everything they can to protect user data, if it makes business sense for the company to provide access to user and friends data, they’re more than willing to do so.

5: Mark Zuckerberg Personally Reviewed Competitors to Decide Who to Squash

Further documents reveal that the Facebook CEO also personally reviews lists of competitors and decides how they should be treated:

Strategic competitors: We maintain a small list of strategic competitors that Mark personally reviewed. Apps produced by the companies on this list are subject to a number of restrictions outlined below. Any usage beyond that specified is not permitted without Mark level sign-off.

Ad services: All developers, save strategic competitors (above), may use our ads services. The reciprocity for these services is clear: money in exchange for new or re-engaged users. In terms of oversight/policy enforcement, we follow the standard ads creative review process.

App services: All developers, save strategic competitors (above), may use our app services. The reciprocity for these services is clear: money in exchange for CPU, data storage and network bandwidth. In terms of oversight/policy enforcement, we will reactive handle any strategic competitors that we discover using these services.

Combined with the news that Facebook considered charging developers for access to user data, it seems that Facebook keeps a tighter hold over its platform than was previously believed.

Read the full 250 pages of internal Facebook documents here.