Note by Damian Collins MP, Chair of the DCMS Committee Summary of key issues from the Six4Three files 1. White Lists Facebook have clearly entered into whitelisting agreements with certain companies, which meant that after the platform changes in 2014/15 they maintained full access to friends data. It is not clear that there was any user consent for this, nor how Facebook decided which companies should be whitelisted or not. 2. Value of friends data It is clear that increasing revenues from major app developers was one of the key drivers behind the Platform 3.0 changes at Facebook. The idea of linking access to friends data to the financial value of the developers relationship with Facebook is a recurring feature of the documents. 3. Reciprocity Data reciprocity between Facebook and app developers was a central feature in the discussions about the launch of Platform 3.0. 4. Android Facebook knew that the changes to its policies on the Android mobile phone system, which enabled the Facebook app to collect a record of calls and texts sent by the user would be controversial. To mitigate any bad PR, Facebook planned to make it as hard of possible for users to know that this was one of the underlying features of the upgrade of their app. 5. Onavo Facebook used Onavo to conduct global surveys of the usage of mobile apps by customers, and apparently without their knowledge. They used this data to assess not just how many people had downloaded apps, but how often they used them. This knowledge helped them to decide which companies to acquire, and which to treat as a threat. 6. Targeting competitor Apps The files show evidence of Facebook taking aggressive positions against apps, with the consequence that denying them access to data led to the failure of that business 1. White Lists In the Six4Three documents, exhibits 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 94 and 95 include discussions on whitelisting businesses. The following are of note: Exhibit 84 – whitelisting of Badoo [dating app] Email from Badoo to Konstantinos Papamiltidas, Director of Platform Partnerships at Facebook, 16 September 2014: ‘We have been compelled to write to you to explain the hugely detrimental effect that removing friend permissions will cause to our hugely popular (and profitable) applications Badoo and Hot or Not. ‘The friends data we receive from users is integral to our product (and indeed a key reason for building Facebook verification into our apps).’ Email from Konstantinos Papamiltidas to Badoo, 23 January 2015 ‘We have now approval from our internal stakeholders to move ahead with a new API – working name Hashed Anon All Friends API. The new API as well as the relevant docs will be ready next week. ‘How would this API work…For each of the FB logged in users, the API will return: FBIDs: App friends that logged in before your migration to V2: App Scoped IDs: App friends that logged in after your migration to V2: Annonymous one-way hashed IDs: Non-app friends The API will hopefully let you understand some of the structure of the graph in order to determine which non-app friends to recommend to a given user.’ Email 5 February 2015 Konstantinos Papamiltidas – ‘We have whitelisted Badoo App, HotorNot and Bumble for the Hashed Friends API that was shipped late last night.’ Email – 6 February 2015 Konstantinos Papamiltidas to Badoo ‘Badoo APP ID has definitely been whitelisted…According to out logs you have already made 100 calls against this API.’ Exhibit 87 – whitelisting of Lyft [taxi app] Email from Konstantinos Papamiltidas to Lyft, 30 March 2015 ‘As far as I can tell, the App ID below has been whitelisted for All Mutual Friends access.’ Exhibit 91 – whitelisting of AirBnB Email Konstantinos Papamiltidas to AirBnB, 18 March 2015 ‘As promised, please find attached the docs for Hashed Friends API that can be used for social ranking. Let us know if this would be of interest to you, as we will need to sign an agreement that would allow you access to this API.’ Exhibit 92 – whitelisting of Netflix Email 17 February 2015 between Netflix and Chris Barbour and Konstantinos Papamiltidas at Facebook Netflix wrote on 13 February ‘We will be whitelisted for getting all friends, not just connected friends’ Exhibit 80 – discussion about the whitelisting process Email from Simon Cross [FB – Product Partnerships] to Konstantinos Papamiltidas [FB], Ime Archibong [FB] and Jackie Chang [FB] 5 September 2013 12.33pm ‘I’d say for now just list out the capabilities/Gks/Sitevars we want to audit…We need to build collective experience on how to review the access that’s been granted, and how to make decisions about keep/kill/contract. ‘This review cycle should include whats currently in Capabilities, as well as whitelists administered via Gks and Sitevars. I don’t want to have to go through this exercise ever again. For example, we should appraise what Netflix (for example) has across all these three whitelisting mechanisms in one go.’ 2. Value of friends data Exhibit 83 – discussion of Royal Bank of Canada neko spend alongside whether they should be whitelisted Email from Sachin Monga at Facebook to Jackie Chang at Facebook, 10.38am on 20 August 2013 regarding the impact of the platform changes on Royal Bank of Canada ‘Without the ability to access non-app friends, the Messages API becomes drastically less useful. It will also be impossible to build P2P payments within the RBC app, which would have dire consequences for our partnership with them.’ Response email from Jackie Chang to Sachin Monga, 10.46am 20 August 2013, regarding Royal Bank of Canada ‘What would be really helpful for us is if you can provide the below details first: 2/ did they sign an extended api agreement when you whitelisted them for this api? 3/ who internally gave you approval to extend them whitelist access? Can you send me email or permalink from the Platform Whitelist Approval Group. 4/ Is there budget tied specifically to this integration? How much? We need the above info foremost and we understand the context below.’ Email from Sachin Monga to Jackie Chang, 10.58am, 20 August 2013 ‘Thanks for the quick response. Answers below: 2/ They did not sign an extended API agreement. Should they have? I didn’t know about this… 3/ Doug gave the approval… 4/ There is budget tied specifically to this app update (all mobile app install ads to existing RBC customers, via custom audiences). I believe it will be one of the biggest neko campaigns ever run in Canada…’ Email from Jackie Chang to Sachin Monga, 22 August 2013, regarding Royal Bank of Canada ‘Let’s pause any action for now until we have internal discussions about this tomorrow…we’ll do the right thing to take care of this. Thanks!’ Email Simon Cross to Jackie Chang, Sachin Monga, Bryan Hurren (Facebook), 25 October 2013 ‘+ bryan who recently whitelisted Netflix for the messages API – he will have a better idea of what agreements we need to give them to access to this API.’ Email from Bryan Hurren to Sachin Monga, Jackie Chang and Simon Cross, 25 October 2013 ‘From a PR perspective, the story is about the app, not the API, so the fact that is uses Titan isn’t a big deal. From a legal perspective, they need an “Extended API agreement” (we used with Netflix) which governs use going forward and should provide us with the freedom to make the changes that Simon mentions below (without being too explicit).’ Email from Jackie Chang to FB group, 28 October 2013 ‘Bryan – can you take the lead on getting this agreement written up?’ Exhibit 79 – linking data access spending on advertising at Facebook Email from Konstantinos Papamiltidas [FB] to Ime Archibong [FB] 18 September 2013 – 10.06am From email about slides prepared for talk to DevOps at 11am on 19 September 2013 ‘Key points: 1/ Find out what other apps like Refresh are out that we don’t want to share data with and figure out if they spend on NEKO. Communicate in one-go to all apps that don’t spend that those permission will be revoked. Communicate to the rest that they need to spend on NEKO $250k a year to maintain access to the data.’ Exhibit 80 - linking data access spending on advertising at Facebook Email from Konstantinos Papamiltidas [FB] to Simon Cross [FB], Ime Archibong [FB] and Jackie Chang [FB] Discussion about presentation Simon Cross is to give re P3.0 Rollout Planning 4 September 2013 4.28am ‘Slide 5 – I am not sure about the revenue saved. Is this really a cost cutting exercise? Removing access to all friends lists seems more like an indirect way to drive NEKO adoption.’ Exhibit 97 – discussion about giving Tinder full friends data access in return for use of the term ‘Moments’ by Facebook Emails discussion between Konstantinos Papamiltiadis [FB] and Tinder regarding allowing Facebook to use ‘Moments’, a term that had already been protected by Tinder Email from Konstantinos Papamiltidas to Tinder 11 March 2015 5.34pm ‘I was not sure there was not a question about compensation, apologies; in my mind we have been working collaboratively with xx 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.’ Email from Konstantinos Papamiltidas to Tinder 12 March 2015 1.10pm ‘We have been working with xx and his team in true partnership spirit all this time, delivering value that we think is far greater than this trademark.’ Exhibit 170 – Mark Zuckerberg discussing linking data to revenue Mark Zuckerberg email – dated 7 October 2012 ‘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 plaform. 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.’ Exhibit 38 – Mark Zuckerberg discussing linking data to revenue MZ email 27 October 2012 to Sam Lessin at Facebook ‘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.’ Exhibit 78 – selected slides showing how Neko spend and relationship to Mark Zuckerberg and Sheryl Sandberg influenced outreach to developers ahead of Platform 3.0 launch Login v4 Platform changes) Update: 1/27f2014 HIGHLY Affected Apps Total 1,000 MAU 10.000 MAU API callers [last 30d] 1.4M 17K 3,206 Affected apps 27,019 7,744 2,532 Affected games 3.111 1,475 521 Affected Credits 338 315 253 apps Affected Ad 89 82 60 Spenders Affected Salesforce 1,639 1,262 812 apps Affected Salesforce 458 375 253 games Affected Salesforce 1,181 887 559 non?games requesting 0f apps read_stream Mark?s friends 31 76% Sheryl?s friends 66 62% Generating TPV 332 51% Neko spenders 831 59% Noisy 23 82% TO T1 partners 160 77% All on a list for pre-launch outreach COIJI- 3521.22 3. Reciprocity Exhibit 45 – discussion on making reciprocity a key feature of Platform 3.0 Email from Mike Vernal FB, 30 October 2012 Mike Vernal ‘On Data Reciprocity – in practice I think this will be one of those rights that we reserve.. We’ll publish a spec for an API that you have to implement to integrate with us, we’ll have POPS review, but we’ll pay closest attention to strategic partners where we want to make sure the value exchange is reciprocal.’ Greg Schechter ‘Seems like Data Reciprocity is going to require a new level of subjective evaluation of apps that our platform ops folks will need to step up to – evaluating whether the reciprocity UI/action importers are sufficiently reciprocal.’ Mike Vernal ‘As many of you know, we’ve been having a series of conversations w/Mark for months about the Platform Business Model… ‘We are going to require that all platform partners agree to data reciprocity. If you access a certain type of data (e.g. music listens), you must allow the user to publish back that same kind of data. Users must be able to easily turn this on both within your own app as well as from Facebook (via action importers) Exhibit 48 – Mark Zuckerberg email on reciprocity and data value MZ email 19 November 2012 ‘After thinking about platform business for a long time, I wanted to send out a note explaining where I’m leaning on this. This isn’t final and we’ll have a chance to discuss this in person before we decide this for sure, but since this is complex, I wanted to write out my thoughts. This is long, but hopefully helpful. ‘The quick summary is that I think we should go with full reciprocity and access to app friends for no charge. Full reciprocity means that apps are required to give any user who connects to FB a prominent option to share all of their social content within that service back (ie all content that is visible to more than a few people, but excluding 1:1 or small group messages) back to Facebook. In addition to this, in the future, I also think we should develop a premium service for things like instant personalization and coefficient, but that can be separate from this next release of platform… ‘We’re trying to enable people to share everything they want, and to do it on Facebook. Sometimes the best way to enable people to share something is to have a developer build a special purpose app or network for that type of content and to make that app social by having Facebook plug into it. However, that may be good for the world but it’s not good for us unless people also share back to Facebook and that content increases the value of our network. So ultimately, I think the purpose of platform – even the read side – is to increase sharing back into Facebook.’ …’It seems like we need some way to fast app switch to the FB app to show a dialog on our side that lets you select which of your friends you want to invite to an app. We need to make sure this experience actually is possible to build and make as good as we want, especially on iOS where we’re more constrained. We also need to figure out how we’re going to charge for it. I want to make sure this is explicitly tied to pulling non-app friends out of friends.get.’ (friends information) …’What I’m assuming we’ll do here is have a few basic thresholds of API usage and once you pass a threshold you either need to pay us some fixed amount to get to the next threshold or you get rate limited at the lower threshold.’ Response to this email from Sheryl Sandberg Email from SS – 19 November 2012 SS ‘I like full reciprocity and this is the heart of why.’ Exhibit 43 - memo setting out the policies for Platform 3.0 This document also stresses the importance of reciprocity to Platform 3.0 ‘The fundamental principle that governs Platform usage is a simple concept: reciprocity. Reciprocity involves an equable value exchange between a 3rd party developer and Facebook. This value exchange involves one of the following from developers: high quality experiences that FB users can use to tell great stories to their friends and family on FB and/or monetary value in the form of revenue sharing or direct payment. In return, Facebook offers a developers access to our Platform. ‘When considering the implications of reciprocity it is important to note that a second order principle quickly emerges: competitive access. There are a small number of developers whom no amount of sharing to FB or monetary value can justify giving them access to Platform. These developers do not want to participate in the ecosystem we have created, but rather build their own ecosystem at the expense of our users, other developers and, or course, us. That is something that we will not allow.’ 4. Android Exhibit 172 – discussion of changing ‘read call log’ permissions on Android From email dated 4 February 2015 Michael LeBeau – ‘He guys, as you know all 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 highrisk thing to do from a PR perspective but it appears that the growth team will charge ahead and do it.’ Yul Kwon – ‘The Growth team is now exploring a path where we only request Read Call Log permission, and hold off on requesting any other permissions for now. ‘Based on their initial testing, it seems this would allow us to upgrade users without subjecting them to an Android permissions dialog at all. ‘It would still be a breaking change, so users would have to click to upgrade, but no permissions dialog screen.’ Exhibit 180 – further discussion of read call log and SMS on Android Email from Matt Scutari, Manager Privacy and Public Policy, Facebook 15 November 2013 ‘Matt has been working with the privacy PM, PMM and Legal to understand privacy risks associated with several Android permissions that will go out in the next release, including permissions associated with reading call logs and SMS’ ‘Matt is providing policy feedback on a Mark Z request that Product explore the possibility of making the Only Me audience setting unsticky. The goal of this change would be to help users avoid inadvertently posting to the Only Me audience. We are encouraging Product to explore other alternatives, such as more aggressive user education or removing stickiness for all audience settings.’ Exhibit 158 Facebook email discussing rapid growth of revenues from Neko advertising 5. Onavo Exhibit 69 – slides from presentation showing market analysis driven by Onavo data Facebook ‘Industry update’ presentation based on Onavo data, 26 April 2013 US emerging mobile apps 3 store Vine- #1 overall social networking In US ITLlne v: . m- Mu . store Path- #9 overall social networking In US ITunes z? source: APPAnnie CONFT US mobile messenger apps (iPhone) US iPhone App Reach, Aug 2012 Mar 2013 (source: Onava} FBMessenger Kik erer Maryann .k Skype Tango Wm March Reach . Skype 17.1% FB Messenger 13.7% WhatsApp 8.6% Viber 5.3% Kik 4.7% Voxer 3.8% Tango 3.5% GroupMe 2.4% Line 1.4% KakaoTalk 1.2% MessageMe 0.5% source: Onavo: *Nielsen CONFIDENTIAL Fi?-0136781 5 WhatsApp message sends Mamie messages per day by service 3 comes :(Mum) i? iffy?II) H31, HIGHLY CONFI DENTIAL Message sendsiday WhatsApp 8.2 billion Facebook 3.5 billion (mobile) Facebook 11.5 billion (mobile web) Exhibit 70 - Facebook ?Industrv update? presentation based on Onavo data, 15 March 2013 US mobile apps (iPhone only) US iPhone App Reach, Aug 2012 - Feb 2013 (source: Onavo) Facebook . . Facebook Messenger . . . . lnstagram Snapcnal Twitter .. I I I so WM mw? MmWei-manCUNF: DENTIRL Februa Reach Facebook 72.0% ms} lnstagram 32.3% DIS) Twitter 27.1% plS) FB Messenger 13.5% ms} Snapchat 11.6% (+02 pts} Pinterest 10.6% (+0.1pt5) WhaisApp 8.3% (+0.0pts) foursquare 4.8% Google+ 3.1% (WA) Vine 6. Targeting competitor Apps Exhibit 44 – Shutting down Vine’s friends data access Facebook email 24 January 2013 Justin Osofsky – ‘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. MZ – ‘Yup, go for it.’ Selected documents ordered from Six4Three EXHIBIT 38 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL From: Sam Lessin Sent: Saturday, October 27, 2012 6:50 PM To: Mark Zuckerberg Subject: Re: notes on platform Back at you On 10/27/12 1:57 PM, "Mark Zuckerberg" wrote: >More thoughts >From: Sam Lessin >Sent: Saturday, October 27, 2012 9:14 AM >To: Mark Zuckerberg >Subject: Re: notes on platform >Thanks for reading it through and the response. I agree with your framing of the three questions embedded in my >proposal. >Regarding your notes on #1 I do agree that 10% to 20% of a small number of businesses doesn't get >us thereS just as a platform with thousands of developers who pay us >nothing doesn't get us there. That is why I basically land on a model >where some APIs are widely available at scale (and we get thousands of >developers at scale) but there are a set of APIs that really are just for >partners. Also known as, I think we need to have it both ways. Yeah, I think having two programs is pretty reasonable. The question me is just what's in each program and what we get from it. My of your proposal is that we get the vast majority of the from the companies we partner with, but I have a hard time we actually have these kinds of deep partnerships with of companies, so there's a disconnect for me there. I also your proposal as if we won't make very much money at all from companies, and I think there needs to be and likely is a opportunity for us there. my model, we?ll define rev shares for as many industries as we can of. There will always be some companies that don't fit whatever we have or we want to give them deeper access in exchange for 1 CONFIDENTIAL value share, and that's what the deals are for. But I'd love to to a state where most of the value we derive is from the open part the platform with clearly articulated rules rather than custom I think we will get a ton of value from the companies using the 'free' APIs it is just that the value will funnel all directly through our ads/distribution which is not a bad outcome at all it is seeing platform as all aboutjust making the distribution business more efficient and scale better against a model where there is natural pricing a market. At the same time, I do think that we will also get a lot of value out of the partners which I really see as a set of companies producing a set of products which we would probably consider building ourselves if we The problem have with a rev-share directly, or forcing a developer to >use our payments ad network is that we are not connecting the value and >the cost closely enough. If the thing that is valuable is our payments, >they should pay for our payments if they use our payments? if the thing >that is valuable to them is the ad networkS. The rev-share could be an >interesting deal term at the high end, but is just too hard for developers >to evaluate know the value we are driving for them and whether it is >therefore worth it to be on the 'platform'. I agree this is a big problem with my proposal. It's much easier for a to be able to take pieces a la carte and know what they're for them. Another issue that's implicit in my proposal is that not yet clear how a dev would disconnect the revenue share, it's quite clear how you'd disconnect payments or ad network That said, I think there is probably a reasonable solution to problems that would still let us get a revenue share. just we need to work through this a bit more. The root of my belief is helping people sign up faster, ramp up faster and remain more is fundamentally valuable. So even though it is more difficult disconnected to value, rational actors should be able to value it. I think having a market of participants will help devs value For example, there's no reason why 2% is a reasonable rev share for credit card processing company to take, but since everyone else it, it now seems more "reasonable" and more folks do it. If we with the head and then open this program up more broadly, I bet can figure out a set of reasonable revenue shares here for each Yes, the 'how does a company disconnect' bit is a really big one to call out in this context. RE: the concept that helping people sing up faster, ramp up faster, and remain more engaged as 'fundamentally 2 CONFIDENTIAL FB-01389022 valuable' -- my believe is that these things are valuable, but not at all infinitely valuable (actually, to the contrary, they are quite measurably valuable). We aren't the only ones that can help people signup/ramp up faster/ remain more engaged, we exist in an ever more competitive marketplace for these services. Also, the reality is that the value of a marginal customer a customer that would 'bounce' without us is measurable and usually relatively low for all companies except for networks which are looking for initial Which begs exactly the question of long-term lockin. Think of this from our perspective. If we had had some magic 'engagement' product we could have bought early on as a company it would have been worth a ton to us in the short term we would have paid a lot for it for the first few million users (just as we are willing to pay a lot to get early users in new markets via search ads, etc.) -- once the is going, it is worth something to but honestly not very much, both because we would inevitably develop our own cheaper routes with time and money if the cost was anything but completely nominal OR because we would get to the point that the marginal user isn't economically worth that much to us (the situation we currently face) >Regarding your notes on #2 Reading your responses, I do think you are right, I am being stark. >worry about mobile messaging apps, etc. and I probably need to temper >that in my own thinking? the irony is I would be more comfortable with >competition if I thought we knew better how to leverage our scale asset >(and if scale weren't' becoming cheaper and cheaper to achieve every day). What I think is that we should effectively not be helping our >competitors more much more than how they could get help from elsewhere >in the market. They can acquire users in ways other than us? so >obviously we shouldn't be failing to take their money when they will just >give it to someone else and get the same outcome. I do, however, again >think that we want as much control here as we can get. I agree we shouldn't help our competitors whenever possible. I think right solution here is to just be a lot stricter about enforcing policies and identifying companies as competitors. AMEN >Regarding your notes on #3 CONFIDENTIAL FB-01389023 On whether the things developers contribute to the system are valuable >to us or not?. In my mind they are really only valuable if users want them either because they value the self expression or drive engagement. If >they do neither, then I do not believe that applications writing to >Facebook is currently worth much -- AND I believe that if they do neither >there are other ways for us to work with developers more efficiently to >get the value from the data they collect from users. I think it's quite possible that developers writing to the graph today no incremental engagement or information targeting value for us. do think users appreciate the ability to share things and that helps us somewhat, but I think users also like having the to take their info out of Facebook and we're considering for that. By charging for distribution, we'd essentially be a way for users to access those features, but developers have pay us for them. I think we need to provide DLYD obviously, and you are right that some power-users do appreciate the ability to take data out in general push it to other I think this is something we can manage around. I do think it is basically zero cost to us to allow applications to write content on behalf of users, but we should just think of it as that -- which is allowing apps to fulfill a user re: the distribution, I don't think we should under-weight distribution from apps, just don't think we should over-weight it -- and I think that if the real value translation is apps publish data to Facebook because users want to publish data to Facebook, then we should do the right thing by users around creating good experiences vs. worrying about pushing 'traffic' back to apps (aka, go with snow-box type solutions for third party photos and pinterest pins rather than pushing the user out to the site. Really what this boils down to is that I think developers are rational >business actors. They will not give us structured data which is actually >valuable to us unless users demand it. Agreed. AMEN Again, I think we just need to get away from thinking about a developer >'using' platform or not/ or that we can 'tax' platform as a whole. We >have a series of APIs, just like amazon web services, etc? the decision >to rely upon use or not use any service we provide is really an >independent business decision. I think that saying that in order to 4 CONFIDENTIAL >'pub ish' to Facebook, or in order your users you >must implement our payments or ad-network, or pay us a percentage of >revenue is just too abstract for rational decision making? I'm not sure I agree with the overall point here. I agree it would be if we could make everything a la carte efficiently, but it seem like we can do that and that realization is leading us a path of minimizing development and access to an important piece platform that I think devs do value (the read side). I do agree it's for a dev to think about whether the value exchange is fair but if we can get a few folks on board then I think we start to establish a market norm and more folks will do this. In some ways, I actually think an overall tax is the most efficient to do this. If the most valuable aspect is distribution and if a la carte for that, then I do think that would encourage to be sparing and economically efficient about when they data to Facebook. However, if we have an overall tax and then is free within that, then their incentive is to get as much out of the integration that they're paying for as possible. I don't agree -- but I do understand your perspective. I really just can't see any developer making the revenue trade with us for a bundle of services some of which they value, others of which they may not, and overall where it is really hard for them to know what is what (especially over the long term) Today we have (or think we have) more efficient engagement and >re-engagement tools than anyone else, and we pretty much have a functional >way of pricing it and having developers rationally evaluate paying for it. That is great?. We should be leveraging that all the way Today we also have some functions on a platform which our users want, >we are at least neutral on, and therefore developers implement (ideally). is unclear exactly how much our users want the functions, but the >things that are strict user benefit and no cost to us we should produce, >though we should think of the eng tradeoff just as another feature of >Facebook. Tomorrow we should have things like a payments solution and ad-network, >which should be better than everyone else's should be able to compete in >the marketplace on their own; however, only marginally so -- and as a >result probably not in a way that we can rationally demand a huge premium >(though lam sure we can demand some premium) It's not clear to me that our solutions here will be automatically than alternatives for a while. And even if they are better, then we have is a payments or ad network platform and we still don't an information platform. This is part of what I don't get here. If 5 CONFIDENTIAL FB-01389025 value is in the information platform (read/write) then trying to money from payments/ads seems pretty disconnected and inefficient. I hear basically tho, my view is that we should only develop payments APIs if we have a reasonable belief that we are going to be able to provide better payments APls than competitors (more cost competitive, Same with an valid things for us, but they have nothing/little to do structurally with being an information platform directly when presumably if all we want is the 'data' that comes off of having an ad-network, or the 'data' that comes off of having a payment platform we can get that information other ways. Finally, if we are going to have another return on scale business other >than attention, we need for that business to stand on its own be a >rational trade in and of itself for us and for developers. Unfortunately, >the dynamics around data are just complicated enough that I think we end >up in a world with maybe 100 or 200 partners for the next few years, not >everyone -- and we have templatized, but not formalized terms. I generally agree with this point, but I wonder if we can't both get scale in terms of getting people to write to us and also get them to us for it. As an analogy, it's good for us that devs build games FB. We could have made the argument that it was good for us so shouldn't tax them, but in reality by taxing them I just think we to a state where we both got the games and made more money. We lost some games, but I think we generally maximized profit. Overall, I'm just pretty optimistic about this idea of being an service and establishing that as a layer of the app stack so the norm is that developers pay for it. Maybe comes with the ability to push content to a person's friends, maybe itjust comes with the ability to ramp up a new user more and connect them to friends and interests. But this does seem it should be a real thing to me that should stand on its own and be a loss leader to push lower margin payments and ad networks I believe we should always charge what the market will bear to others companies in the but not more than what the ecosystem will bear. For payments, or an ad-network, we have competitors. Either we can produce better products in these spaces which in a head to head competition can beat other solutions on value, or we can't. IF we can, we can make money, if we can't then we will not. Same goes for our distribution business. In the canvas case, developers basically had no other option when platform 6 CONFIDENTIAL FB-01389026 was succeeding for games. Now we compete with the mobile platforms, and while we still have a decent enough position for games to generally get away with taking real-estate on web 45% of revenue, I also think the best developers the best games have left, and what we really have is a set of games made by people who see a financial opportunity to hack our system for free I am not proud of the fact that we are currently extolling 'game? companies that make online slot machines as positive examples of those willing to pay our fees (I am fine with it, just not proud of it) I am totally bought into our identity business in the sense that giving apps the ability to uniquely get identifiers on all their users is a huge huge deal the question is only what do you do with that how do you match it up with an economic and I think we need to couple the identity value services, where our services are better because of identity (be they engagement/ re-engagement, an ad-network, or payments with better built in fraud The only thing we should be careful of is making sure that we are selling things in ways developers can rationally evaluate and want. Obviously happy to (1) continue this conversation (2) not continue it if the marginal value is now too One thing I intend to do next is basically wireframe out very roughly what our developer landing page sales page, could look like under a more 'holistic' fee scenario and under a more a-la-carte model. I think that putting some practical screens up on how things could look in mid 2013/2014 might be Sam >On 10/27/12 6:06 AM, "Mark Zuckerberg" - wrote: think I understand your proposal. >>It seems like it really comes down to three main questions: What is a revenue model that scales to build the kind of business we 7 CONFIDENTIAL >>want? What is a read model that reduces the strategic risk to our business >>(and doesn't undercut that revenue growth)? What is a model that developers will participate in rather than >>abandoning? >>Now going through each of >>For(1k I agree with your argument that we need to get some value proportional >>to the value we create as opposed to a fee on our costs for this to work. generally sold on that. I also agree with your argument the other day that whatever we do needs >>to be very widely adopted. Having 10-20 partnerships where we own 10-20% >>of the companies isn't where we want to be either. The underscores the >>importance of question (3) and developing a model that many developers >>will go for. I am not sure how this foots with doing a lot of of specific >>deals though. In theory we could do an infinite number of deals, but in >>practice a strategy of making deal seems explicitly like a strategy to >>work with a smaller number of companies, which may by itself prevent us >>from reaching the long term revenue goals we have. There's a big open 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. >>For(2k 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 skeptical 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 platform. I think we >>leak info to developers, but I just can't think of any instances where >>that data has leaked from developer to developer and caused a real issue >>for us. Do you have examples of this? I also think your argument about not selling down our advantage is too >>rigid. Businesses pay for new customer acquisition and then for >>reengagement. Eventually you run out of new customers and need to focus >>more on reengagement. We shouldn't prevent ourselves from helping >>business get new customers just because one day they might run out of new >>customers to acquire. It doesn't scale infinitely, but it does scale >>pretty far. CONFIDENTIAL FB-01389028 I also think your argument about how we help competitors is too black >>and white. In reality, we do this with distribution too. We let most >>competitors buy ads. And even if we didn't, we'd let other media >>companies buy ads, and then our competitors could buy ads from those >>companies. At some level I think helping your competitors is a fact of >>life. We need to make sure we're not doing this to an extent that it >>destroys us, but we also shouldn't be so rigid as to rule out any model >>where competitors get benefit from us. >>For (3): I think what developers will be willing to bear is the biggest open >>question here. No one knows this for certain and a huge amount obviously >>hinges on this. I do agree that if we give away distribution and login for free, then >>basic info alone isn't enough value to command a meaningful revenue >>share. That said, this makes me wonder if we need to question our assumptions >>on what we want to be free. If what developers mostly value is >>distribution (which we're currently not charging for), then I think we >>really need to ask the question of whether we're actually getting value >>from this. In theory we want information, but are the posts developers >>are giving us actually valuable? They don't seem to be for targeting and doubt they drive meaningful increases in engagement either. That >>suggests that from an information perspective perhaps these aren't so >>valuable for us. They aren't negatively valuable, but if there's a big >>disparity between what developers get and what we get then perhaps >>charging for this isn't so crazy. I'm not yet convinced this is the right >>thing to do, but it seems at least worth thinking about to me. If we were >>strategically okay with not giving this away for free, then I think many >>more developers actually would accept a rev share to enable their users >>to connect with F3 and share back to us. If we did this, we'd see some >>dropoff in developers, but I'm not sure how much. The distribution is >>very valuable for developers and as long as the rev share isn't onerously >>high then I bet most would stick around. And counterintuitively, once >>devs were paying for this, they'd probably be more invested in getting >>the most out of the integrations so they'd likely invest more and >>actually push even more info into FB. 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 which can stand by themselves and >>compete with other companies' services. But at that point we still don't >>really have a sustainable platform; we just have a good payments service >>and ad network. So that might make us more money, but over time we'll >>shift our energies towards building those services and we still won't >>develop a great platform. CONFIDENTIAL FB-01389029 >>From: Sam Lessin >>Sent: Friday, October 26, 2012 10:51 PM Mark Zuckerberg >>Subject: notes on platform >>Zuck, have been going through iteration after iteration on the platform story >>trying to suss out a perspective that feels strategically right in the >>long term as a set of guiding principles AND which is implementable and >>functional in the short term. Obviously I know you have been thinking >>about this a lot as well (along with a lot of other smart people) and >>am happy to get behind and drive whatever you want to land on; however, I >>do want to try to share my full thinking with you the perspective on >>which I have landed. This is long? sorry. >>Uncharacteristically, I would like to start with what I think we should >>practically do, and back out to the 'why' rather than visa versa. >>Practically, I strongly believe that we should operate platform in the >>following way: Applications can write to the graph freely. - (A) They can write information on behalf of a user to the user's >>timeline (so long as they have collected the necessary 'write' >>permission) - (B) They can write information on their own behalf (in the voice >>of a 'page', as an 'advertisement', adding information to their CRM >>against a UID, email, etc.) - (C) We can choose to show the content they write to the graph on >>their own behalf or that of users in newsfeed as we see fit to maximize >>the consumption experience? and if applications want they can 'boost'/ >>trump the auction Applications can use 'Facebook login' freely have many avenues to >>getting user's IDs - (A) Any app can choose to have their users login with Facebook, >>and if they do we will give them the user's UID (not a hashed - (B) We will can also open up other avenues for giving >>applications Identifiers that allow them to better leverage our >>system (via email matching, invisible pixels, cookies perhaps, mobile >>tracking, etc.) - (C) We need to have terms that make it clear that sharing UIDs >>across applications is not OK, and stringently enforce - (D) We should develop things like a payments API that sits on top >>of these IDs and has its own fee structure at a flat rate - (E) We should develop things like an ad-network that sits on top >>of these IDs and has its own structure for paying developers at a >>market-defined rate 10 CONFIDENTIAL FB-01389030 -- Reading 'Basic Information' freely - (A) Applications can ask permission of users to read 'basic >>information' which a user would otherwise provide when registering for >>their service freely - (B) Applications can ask for the Ule of a user's friends who is >>also using their applicaiton freely - (C) Users should be actively encouraged to engage with the >>information they are giving applications -- Reading/Using Non-'basic' Information functions - (A) We should develop a whole set of non-basic information >>datasets and APIs which encompass: -- (1) User Data which doesn't reasonably fit into something >>which an application could ask for themselves as part of registration >>which other services cannot provide -- (2) Facebook insights data (coefficient, trust, etc.) -- (3) An Oracle for things like 'twinning' making >>specific decisions about a user based on a application provided signal -- (4) Eventually, a brokering business where applications >>other than Facebook can provide insights to other applications (and we >>can run a marketplace in-between) - (B) These data-sets become leverage able openly via our >>ads-trageting distribution channels - (C) We can provide some sort of very low testing limit on most of >>these APIs for free, but to use them at any scale is a conversation with >>our BD folk?. - (D) These APIs are best thought of as white-list internal APIs >>which if you are owned by us, or a close ally, we will open them up for >>you. -- Competitive exclusions stuff to deprecate change that now >>exists - (A) We should dramatically increase our enforcement of competitive >>exclusions, and actively suggest to application developers that even if >>they are small they should check with us first if they are worried about >>our definitions - (B) We should turn off all APIs that don't fit the 'registration' >> itmus test of while maintaining them on a 'white list' basis for >>bucket #4 if we want (things like the full friends.get, the messaging >>APls, etc.) >>Upshot: where this nets out for me is that we end up with (1) an open, stable, and free platform for writing data to Facebook, >>getting the information you need to wire up a set of users you have >>engaged, and all the IDs hooks you need to actively participate in our >>attention market (buy ads) as well as leverage any other services like >>payments or an ad-netowrk we may want to offer in the future (2) an ever increasingly valuable set of proprietary APIs for richer 11 CONFIDENTIAL FB-01389031 >>information, etc. which are not openly available beyond perhaps a 'free >>sample', but which allow us to 'project' into the ecosystem the value of *hopefully* ever deeper data-sets?. giving us the ability *hopefully* >>to participate in a variety of deeply socially enabled businesses which >>ideally we would build ourselves if we could, but in a heterogeneous >>enough set of industries with different margins and properties that it >>would be impossible for us to price effectively. (3) we have some 'starter' APIs which are free, and then we try to >>directly associate the cost of a given API for a developer with the APl's >>value to that developer, rather than trying to subsidize one API with >>another, or put developers in a hard to measure opaque position where >>they don't exactly know if using platform holistically is worth it to >>them? so where there is an easy way to do that (advertising on FB, ad >>network on app partner, payments API) we can have very transparent >>pricing, and where it is not easy to do that we have to have a >>conversation negotiate. (4) the messaging to the ecosystem becomes that we are deprecating a >>few things for privacy reasons to simplify our model for users, we are >>enforcing non-competitive terms we have always had, and we are opening up series of new white-list APIs for the best companies that want to build >>the best social services and want to work with us deeply. >>The above stated, let me try to justify it? starting by walking through >>the incentives perspectives of each of the parties to our system. >>Users (in brief) >>The user incentives around platform are pretty straight forward in the >>abstract long-term, though there are some quirks to pay down >>shorter-term. Over time, users just want to have amazing experiences in >>the physical and virtual world enabled by social. First, they want great >>apps where they can find and interact with great content and experiences >>with their friends. They certainly don't want to have to 'sign in' to >>anything with different passwords, etc. Over time I think they will want >>applications to help them express themselves so that they can have more >>custom experiences better experiences of the world, and I think they >>will eventually appreciate things like ever better targeted 'ads' as a >>real benefit? I also think they fundamentally want control. >>Developers/Businesses (in brief) >>Developers are rational actors that fundamentally want to make as much >>money as possible. Plain and simple. The days of application developers >>without a business model building projects for fun are rapidly >>disappearing. There will always be people hacking playing, and every >>once in a while we will have a chat roulette, but the reality is that the >>app ecosystem has professionalized and anyone building anything of scale import are going to act like rational consumers of services APIs. To >>run businesses, what developers need from us is the following (1) 12 CONFIDENTIAL FB-01389032 >>Stabi ity. They need to be able to project/ model forward for years at time in order to get cheap capital to build, and know how to >>efficiently and effectively scale their businesses (2) Measurability. >>They need to be able to know what their costs are going to be, and how to >>maximize their profits efficiently? which means that the easier we can >>make it for them to tie together costs revenues and profits the >>better (3) Services which make them more efficient than their competitors >>at acquiring, re-engaging, merchandizing creating great user >>experiences, and monetizing their users. (4) Strategic flexibility/ >>option value that translates into valuation. There may be some minor >>value for developers in having fewer partners vs. using a wider range of >>services by different providers, but ultimately in a world of well formed they will swap in-and-out providers at will to get the most >>effective systems cheapest rates etc. >>Facebook (in a tad more depth and with a detour through our business >>model) >>Our mission is to make the world more open and connected? and the only >>way we can do that is with the best people and the best infrastructure -- >>which requires that we make a lot of money be very profitable. My >>assertion is that for us to be very profitable over a long time, we have >>to be in businesses have a business model where we get more profitable >>the bigger we are (a return on scale business)?. Conversely, we cannot >>be in a commodity business or 'sell off' our assets in a way that >>transfers wealth from ourselves to others. >>There have been three paths to sustainable robust margins historically. regulation having a powerful monopoly like a state dictate that you >>are the only way to do something (2) proprietary expertise knowing >>something or having the structural ability to produce goods and services >>that no one else can (the coke formula) (3) being in a business with >>natural return on scale dynamics (where you are more profitable because >>you are bigger)?. Neither regulation nor expertise are actually good >>ways to be a non-commodity business for us. Regulation is obviously an >>unappealing course not at all interesting, and is something I list only >>for completeness/looking at history. Expertise doesn't work when >>infrastructure is commoditizing rapidly given the talent dynamics of >>the technology industry. Return on scale must be our bet as a company?. we need to focus on businesses where we are better/ more profitable >>than everyone else because we are bigger than everyone else. >>Currently, the thing which we provide which is not commodity where >>there is real return on 'scale' is DISTRIBUTION at 'scale'? the reason >>that distribution has return on scale dynamics is largely because a >>certain set of 'brand' advertisers crave it deeply, and they have very >>few options for buying it (Facebook vs. TV). Brand Advertisers crave >>?scale' for three reasons (1) they are in businesses themselves where >>they are profitable enough that it is worth them talking to a huge number >>of people imprecisely in order to reach just a few new customers (2) They >>have developed expertise in generating an image content where an >>initial paid marketing buy gets supplemented with word of mouth free >>social diffusion of their message over time and space (3) They have 13 CONFIDENTIAL FB-01389033 >>deve oped the ability to measure feel like they can measure the >>effectiveness of how they spend. >>However, the problem is that most businesses (local, etc.) don't fit into >>the bucket where they can advertise on a 'brand' basis. (1) they aren't >>profitable enough to speak to many people imprecisely to just reach a few >>new customers (2) they don't have the expertise to generate the creative >>they need to get 'free distribution' multiplier (3) They can't measure >>well enough to know what to spend?. upshot, not everyone can be a brand >>advertiser, actually most people can't?. There are also several problems >>with 'brand' advertisers being our 'non-commodity' business (1) there >>are new ad networks platforms tools which chip away at the >>defensibility/ non-commodityness of 'scale', (2) we are running out of >>humans (and have run-out of valuable humans from an advertiser >>perspective) (3) brand advertisers will get better, but they aren't that >>good at measuring their spend, so they have finite budgets. -- The >>upshot of which is that while being 'big' does provide us a return on >>scale currently, it isn't something which we are going to be able to more >>than 2X-4X in my mind anytime soon, and in some ways I think we will face >>increasing pressure on the value we derive from our distribution scale. >>The second thing which we provide which is non commodity where there >>*may be* return on scale is 'information' about people? this is far less >>tried and true than the return on scale of distribution, which is well >>understood and practiced?. but as far as I can tell, it is the bet we >>need to make as a company if our ambitions are long-term and grand, and >>to me at least it feels right. For instance, if you look historically, >>it was in many ways information which actually got us 'scale' rather than >>visa versa. One of the things that puts us currently in a very >>defensible place is the relationship we have created between people using >>Facebook all the time, and us having the information we need to make >>Facebook a better product. This is the fundamental insight in something >>like coefficient. We know more about what people want to see because >>people look at more stuff on our platform? In this respect, while there >>are other ways to get close, it feels viscerally correct that there is an dynamic at play? the more people that use the system, the more >>information we have on how to make more people use the system?. >>The challenge comes in not when we use the scale of our own information >>to drive our own business platform, but when we try to leverage the >>information with other parties to the system businesses which we >>want to do on the premise that we practically cannot build everything >>that can benefit from 'social' the information we have for a hole host >>of reasons. The first part of the challenge is that packaging >>information alone is not valuable, rather, the value of information at >>scale must be expressed indirectly through other vehicles. The second >>part of the challenge is that because information is infinitely copyable, >>it is hard to 'sell' without giving others 'scale', and since the value >>of scale is always relative not absolute? so the risk becomes that by >>monetizing your value you also destroy your value (because generally >>people only need by information once, and two entities with the same >>information will race to the bottom on the price of re-selling that 14 CONFIDENTIAL >>information since there is no cost of goods sold). >>With these challenges in mind, there are two clear channels via which to >>monetize information (1) Advertising engagement re-engagement >>(lnformation makes distribution more efficient effectively ads a >>multiplier to our first return on scale business) (2) Merchandizing/ >>customization (Information allows companies people to do better things >>for their customers, on top of which they can scale revenue and >>profitability NB: things like risk assessment fit in here). >>Mixing information with distribution to create value you can measure is >>relatively straight forward. You simply allow ways of targeting messages >>extremely narrowly/ leveraging everything known about any person. This >>effectively makes advertising more efficient contextual. The >>efficiency gains in the system create more margin for us to take. The >>best part about this is that the market should 'price' the information >>efficiently over time. You do still risk 'leaking' information via >>clicks on ads, etc; however, this is a very slow leak, and can be mostly >>dealt with via policies limiting the use of data to the party that ran >>the ad. >>Converting information into better 'merchandizing' means giving a third >>party the data to use as they see fit. There should be a bunch of value >>here, but there are also a lot of issues?. specifically, unlike the >>distribution market where there is a real natural scarcity and everyone >>competes in one finite marketplace (ultimately bracketed by the 24 hours >>in the day), the value to a developer of being able to provide better >>?services' is extremely conditional on who the business is what they It varies widely from industry to industry and company to company >>and can changes dramatically based on exactly what information exists/ >>is exposed to them via the system. >>Upshot? the number one threat to Facebook is not another scaled social >>network, it is the fracturing of information death by a thousand small >>vertical apps which are loosely integrated together. This will either >>happen because there is fundamentally no 'return' on the centralization >>of information the graph OR it will happen because we sell off the >>graph piecemeal for less than it is worth and in the process destroy >>efficiency and value. >>When User/Developer/FB incentives meet/ come into tension? >>Where I come out is that there are (1) parts of platform where we benefit >>from everyone interfacing with us, like apps publishing for users and >>apps having Facebook IDs for their users. We don't want to tax those >>actions directly we just want them broadly and widely adopted because >>they drive value for our users and for us in the form of services you >>enable on top of them. That said, we also don't want to orthogonally >>subsidize them. If users don't want apps to publish for them we can't >>create a compelling enough experience, then we should fix that rather >>than subsidizing incentivizing with orthogonal value to developers? There are other parts of the platform that we currently provide which 15 CONFIDENTIAL FB-01389035 >>have some value, but the value is not very deep or meaningful (basic >>info)? we hypothetically could charge for those parts of the platform, >>but it wouldn't be enough money to matter at this point -- it is too easy >>for applications to get it elsewhere (3) Finally, there is what I hope >>can become will be the deep value of Facebook (something like >>coefficient)? the problem is that where the deep value is we don't want >>to under-price the value, or over price what an app is willing to pay -- >>and that forces us to basically just give a taste and then be ready to >>negotiate deals?. going line by line -- >>Applications *should be allowed* write to the graph freely?. Currently rational applications the free market of apps currently >>write to Facebook primarily because we give them 'free' distribution >>(engagement and re-engagement), and they do so in a way which maximizes >>the free resource we give them over user value demand right up to the >>line where a user would 'un-install' the app not give them the right to >>publish on their behalf. While that makes logical sense as a game plan >>for them, what we want to be the case (and is the case for some of our >>favorite apps like Instagram) is that they write to the Facebook graph in >>order to provide user value because users demand it to express >>themselves. We are still pretty far away from being in a place where the >>app writes to the data for the publishing user, and where we show that >>content on the publishing user's timeline, and to people in feed as a >>user value, but the only way that a free and open publishing channel >>works is when it is moderated by invested users and both sides of the >>equation are factoring for their benefit. -- uncontroversial; >>we don't want to limit the ability for apps to write on behalf of users >>openly and freely, but we need to keep investing to make sure that users >>are moderating it want the apps to do it? apps also should obviously be >>able to write on their own behalf (as a page, CRM data, etc) at will? and >>if the data they are writing on behalf of users and or their own behalf >>helps them target ads better acquire or re-engage users more >>efficiently, that is good healthy for the whole system. >>Applications *should be allowed* to use 'Facebook login' freely have >>many avenues to getting user's IDs Applications currently use Facebook connect by-in-large in order to (1) >>get the 'friend' graph that enables their service to be compelling, (2) >>get the publication rights that resolve to free distribution for them (3) >>sometimes for the minor benefit of speeding signup* (though in reality FB >>converts worse than non-FB signup in many cases now) (4) sometimes for >>the minor benefit of providing easier login for users, (5) in a very few >>cases for specific access to a specific type of Facebook data (photos, what they don't do in general is implement Facebook login in >>order to get user's Ule and thereby better engage/re-engage them, >>advertise more effectively, and/or in order to use things like a connect >>payments solution or get higher on a future tense advertising >>network. The trade we should be pushing on trying to establish with >>companies is not that Facebook login is in-and-of-itself good, but that >>by doing it we end up providing you as a company easy to understand, and >>easy to value benefits either on the cost side or the revenue side of 16 CONFIDENTIAL FB-01389036 >>your business. UPSHOT: Right now I believe that if you asked an >>application to implement Facebook connect but didn't give them the friend >>graph, publication rights in the same dialog, etc. people would have no >>reason for implementing it at all. There is no direct value for >>implementing FB connect. I think that as we add if we add good >>services on top of FB connect having users logged in like payments/ad >>network (which monetize on their own obviously) and better paid >>acquisition channels (which are easy to create a marketplace around and >>are easy for apps to measure evaluate, then we have businesses in those >>areas, and we will want FB connect distributed as widely as possible we >>will not want to charge for it. >>Applications *should be allowed* to read basic information freely Applications currently get a bunch of 'basic information' and users are >>not confronted with exactly what they are giving to apps. We give out a >>lot of things under 'basic information', some of which really weaken our >>competitive position like 'email addresses' by opening up a non-facebook >>channel for applications to reach out to users. This has troubled me >>greatly; however, I have come to terms with the fact that for friends >>already using the app, we simply can't remove what we have already >>promised and enabling the function provides a ton of user value value >>for the world while still making the app go back through our platform for >>real new-user acquisition. For things like email, name, profile photo, >>etc? making these signup elements easier for an app certainly >>erases some cost/ makes the app more valuable, but we really aren't in >>competitive landscape where these things have meaningful value where we >>could charge a lot for them. First, a user will just give them to the >>app if the app is good. Second, tons of other people like apple can now >>give out the same information. UPSHOT, we should give this >>information away because it has become worthless to us and allowing users >>to give away their own basic info provides value to them. >>Applications *should be allowed* to read/use non-'basic' Information >>functions with some key caveats A scant few applications currently really use any of the APIs we offer >>beyond the basic information APIs. Most of the companies that use these (message send, photos export, feed.get, etc.) exist in a competitive >>grey zone? generally speaking though, there isn't currently all that much >>more you can do with our platform (though we have contemplated a lot of >>things that would add a lot of value to other partners). This is the >>category where I would put all my eggs in terms of building a dataset >>which has real return-on-scale dynamics our actual information >>monetization scheme? As we build up value in this type of data we should >>certainly will certainly feed it into the market-mediated ads system. >>That should easily create more value for all if enabled widely? the >>question is who do we give the actual data out to and on what terms. >>Here we face an issue?. which is that the same data is just worth >>massively different amounts to different players. If we price it too >>high apps will not consume it, if we price it too low we are giving away >>one of our only scaleable profit centers. If we give it to competitors >>we are sewing the seeds of our own destruction? and if we give it out on >>any general model we are going to lose the ability to effectively 17 CONFIDENTIAL FB-01389037 >>negotiate with people where we really want a piece of the action a >>tight business. -- UPSHOT, we should sell this, but I just don't see >>any way we can sell it on standard terms. >>Some select objections and responses?. few things that I don't like about this proposal but I have come to >>terms with?. >>We should monetize more of the 'read' side of Facebook? like basic info, >>or connect, etc. >>The problem is that the basic platform just isn't worth that much outside >>of perhaps 'friends also using this app' which with the apple deal is >>rapidly on its way to commoditization as well? AND every calculation we >>have seen shows either that we can't make enough money from the current >>version of platform for it to matter to us even with generous >>assumptions over a fairly long time OR it seems prohibitively expensive >>not worth it to our developers (with the exception of people that make so >>much money they wouldn't notice). deals any structure that relies on them crushes innovation?. >>This is generally true, BD sucks? entrepreneurs don't want to talk to >>people or wait days to get something they need. That said, this proposal >>is basically that the core of the APIs where there is rational value >>exchange, etc. is open and free? and I would argue that the people that >>wil want to use our higher end APIs are going to be more sophisticated >>people anyway at least for a long time. We should invest to make this >>as painless as possible, have a 1 hour turnaround time, etc?. but I just >>keep coming back to the fact that I actually really want to think we >>need to talk to every person who wants to leverage our higher-end data. >>Not having transparent pricing will make people wary to invest in the >>platform? >>True? again though, it is a specific part of platform which I am saying >>we require BD for, not the whole thing. >>We suck at picking winners/ BD will force us in that direction and as a >>result we will miss big opportunities >>Probably true, but again, better than the alternative. and the APIs that >>are 'free' under this model really should be enough for all but the most >>sophisticated businesses to get up and running. 18 CONFIDENTIAL FB-01389038 EXHIBIT 43 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL Platform 3.0 Plan The following outlines the changes that we are planning to announce with the roll out of Platform 3.6. We will announce all of these changes out at the same time in a single blog post that starts the clock ticking on a 90-day migration. This 90-day migration window is the standard that we adhere to in Platform and helps developers handle large changes in features (this is especially important for native mobile developers which have a much longer lead time). We will make all API/permissions changes available in the migration so developers can test against these changes. We will make the review tool and new APIs available before the migration takes effect. We will make all tooling/policy changes available on the day the migration is turned on by default. Timing We have the following rails that will inform the timing of our announcement and roll-out. Our next migration window opens on June 26. If we decided to snap to this date that would put these changes live on Oct. 2nd. In terms of implementation, looking at the schedule for app review and SWAG for the APIs, it appears that the needed functionality should come online in August. Based on the above, a reasonable schedule is the following: 1. June 26: Announce Platform 3.0 on the developer blog, making the API/permission changes available under a migration. 3. Aug Bring the App Review tool and new APIs online start testing with a limited set of developers. 4. Oct. 62: Default the migration to on and review all new apps. 5. Oct. 14: Begin to review apps for policy violations. [Note: Need to talk to Sean about the impact of these changes on games developers to see if this schedule works. We may need to accelerate the API development. Ideally we could be in position to have the new APIs in beta when we announce the migration.] Changes to Permissions and APIs Facebook Replacement APIs: We are removing the ability to request permission and read data from the user's stream, notifications, and inbox (message/thread). These features are used primarily for apps that attempt to recreate the Facebook experience on other devices. We will still make these APIs available to a limited number of select partners were it makes sense (phone OEMs, etc). Friends Data: We will reduce the scope of the friends? data that a developer can request and access from users. Specifically, we will change the /friends Graph API connection to only return the user's friends that are already connected to the app. In addition, we will no longer support friends_* permissions or data access. CONFIDENTIAL FB-01220345 New APIs: In order to help developers address scenarios for which they utilize the above APIs, we are going to make two new APIs available: Suggested Friends and Recommendations. Suggested Friends will help developers pick the right app friends and non-app friends to invite to the app. Recommendations will help developers recommend various 06 objects based on their friends likes and 06 activity. App Review Reciprocity Since the launch of Open Graph in Jan. 2612, we have moved toward an app review model were we review and approve an apps integration with Facebook social channels (News Feed, Timeline, etc.). We extended this model to the App Center. With this announcement taking the next step in this evolution. In 90 days, we will begin to review and approve all apps that integrate with Platform. This will ensure that we are maintaining a high-level of app quality and that our user and developer interests are aligned. Developers may continue to develop and test on Facebook Platform as they always have, but before they can take their app "live" to non-developers/testers, their app must be approved and reviewed by Facebook. As part of this review process, we will examine the quality of the app, but also if the app is in compliance with our policies. In particularly, we will determine if the app is following our reciprocity and duplicative functionality policy. All apps may use Platform for Login and Social Plugins, but if the app accesses extended user information such as the friend graph, photos, etc. the app must also make it possible for the user to bring their data from the app back to Facebook. In order to help developers with this requirement, we are releasing tools collective known as Action Importers. Further, for the small faction of developers who's app may duplicate existing FB functionality, we can make this determination at review time, before the app launches, to ensure that can work together to see if we can come to an equitable resolution. Canvas Redirect Policy We have had a long-standing policy prohibiting canvas apps from redirecting outside of F8. As the ecosystem has developed, we have seen more and more web sites create canvas app with the sole goal of gaining access to bookmarks and requests for there web apps outside of F3. In 90 days, will begin to enforce this policy in earnest. Canvas apps that exist that chiefly exist to redirect to external web sites will be disabled. For developers that were relying on this mechanism to gain access to requests, we recommend that they utilize the Send dialog to implement their request/invitation functionality. Page Apps (optional/for discussion with Mike/Dan) CONFIDENTIAL FB-01220346 There are a number of apps that are utilized to manage pages. Previously, an app could ask for the manage_page permission and access the page feed, post to the feed, etc. Moving forwarding, securing access to this permission and the Page API is limited to specific apps that offer compelling Functionality above and beyond what is available on Facebook. For developers building page management apps, they can use this permission for developer/tester owned pages during development, but need to be explicitly approved via our App Review before they can ask any user for this permission or manage pages on their behalf. Canvas as Game Platform (optional/for discussion with Mike/Dan) As we have watched the development of the 3rd party ecosystem on Facebook.com, a clear pattern of usage has emerged. Canvas has become the default home for social games and Page tabs have become the default home for brand, contest, etc. apps. Moving forward, we are going to codify this within our product itself. Only new game apps will be able to leverage canvas (existing non-game apps are not effected). Non-games will continue to have access to page tabs. Platform 3.6 Rules of the Road As we work towards implementing the decisions that we made last year, which are now known as Platform 3.6, we need a common framework by which we can make decisions about what types of app to give access to Platform. This framework must address three key questions: what are the broad principles of our platform, how do these manifest in our products/policies and how do we communicate this to developers? This document answers these questions, constituting the Platform ?rules of the road". Principles The fundamental principle that governs Platform usage is a simple concept: reciprocity. Reciprocity involves an equable value exchange between a 3rd party developer and Facebook. This value exchange involves one of the following from developers: high-quality experiences that FB users can use to tell great stories to their friends and family on F8 and/or monetary value in the form of revenue sharing or direct payment. In return, Facebook offers a developers access to our Platform. When considering the implications of reciprocity it is important to note that a second order principle quickly emerges: competitive access. There are a small number of developers whom no amount of sharing to FB or monetary value can justify giving them access to Platform. These developers do not want to participate in the ecosystem we have created, but rather build their own ecosystem at the expense of our users, other developers and, of course, us. That is something that we will not allow. CONFIDENTIAL FB-01220347 Platform Services In order to outline how the above principles manifest in our products/policies, we need to identify the various parts of Platform. This is required because we have a disjoint set of product and policy constrains that apply to each of these different areas: App services: these are paid generic services (storage, compute, etc.) that apps may use to build the core foundation of their app. At present, we do not have an offering in this space, but we are close to closing an acquisition that adds these services. As such, in order to be complete and future-proof we will outline the rules associated with these types of services. Ads services: these are paid promotional services that enable developers to drive awareness and installations of their apps using News Feed and other paid channels. We have always had an advertising business the developers could leverage, but this is increasingly an area of focus for us with the transition to mobile. Identity services: these are the traditional identity/social services that we have provided to developers since 2067. These services enable developers to build personalized app experiences for people and enable these people to share aspects of those experiences back to Facebook. [todoz payments is here] Application The following outlines the application of the above principles to the various kinds of platform services. 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. CONFIDENTIAL FB-01220348 Identity services: this set of services is the subject of much of the rules of the road. This is due to the fact that we have a variety of mechanisms for value exchange. All developers, including strategic competitors (above), may use the Login and Social Plugin features available within identity services. We permit this because we wish to see our core login service and basic sharing services used by users in any app, creating an equitable relationship with the all, including competitive, developers. To this end, we make these features available to developers with out app review. The use of identity services, beyond Login and Social Plugins, is subject to app review. We review the apps usage of our APIs to determine if they are adhering to our principles. In particular, we look at the quality of the app's user experience and if there existing some equitable value exchange. During app review, we determine the quality of the app by using the app and comparing the experience to our quality guidelines [link]. Apps that do not meet our quality bar are rejected. During app review, we examine the APIs that the app uses in order to determine what the appropriate level of reciprocity. The guideline for this review is ?take data, give data". The review tool is built to help with this assessment in that for every read API used by the app, we flag if the app has also implemented Action importers. Using this tool, as well as an examination of the user experience itself; we can determine if the app is reciprocating. If they are not, the app is a "data leach" and will be rejected. Open Issues There are a number of different fields like birthday, hometown, etc. that apps can request and there is no way for them to write back anything. We can do a couple of things: create an API to set this info (maybe not a bad idea for identity growth?), limit these data fields to just canvas apps (the value exchange is time on site and maybe payments), pull these fields, something else? How do we think about the baseline level of value exchange of canvas apps due to time on site? Is that enough to forgo the "take data, give data" mandate for non-payment games/apps? If you are offering real/world goods for sale on your web site or mobile app, in order to use identity services, you must use Facebook Wallet (Payments Registration Plugin Need to talk to the field about not selling FB platform as part of an CONFIDENTIAL FB-01220349 ads deal (this is where we are seeing non-games canvas use) Group Management Event Todo/Notes Read Login (uid, name, profile pic, small of core fields) - anyone can get this. No a priori review. User Data - requires user_* permissions. Ability to ask for those user_* permissions requires unified review. Friend List - Requires unifed review. If you access the friend list, you must conform with Social Reciprocity, as defined above. Friend Data - we're removing this (removing friend_* permissions) Core Facebook Features (News Feed API, Inbox API, Full Search API, etc.) - requires unified review. Generally only available with a business deal, generally limited to Facebook replacement apps. Write Share Dialog - anyone can use Open Graph (defining actions, using the API) - requires unified review Other Write/Management APIs (events, groups, etc.) - requires unified review. Generally requires a business deal, only available to Facebook replacement apps. Distribution Bookmarks - limited to canvas apps mobile games. Requires unified review. Requests - limited to canvas apps mobile games. Requires unified rev1ew. Notifications - limited to canvas apps mobile games. Requires unified review. App Center Search - limited to apps that have gone through unified review. Messaging (Invitations) - will require unified review. Available to anyone who abides by our rules (does not spam the channel). Reciprocity language: "Facebook Platform provides an extensive set of APIs that allow users to bring their data with them to your application. If you use any APIs beyond the basic login APIs, then you must also allow users to bring their data from your app back to Facebook by implementing the Action Importer spec." CONFIDENTIAL FB-0122035O EXHIBIT 44 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL From: Dan Rose Sent: Thursday, January 24, 2013 12:21 PM To: Mike Vernal; Justin Osofsky, Mark Zuckerberg; Kevin Douglas Purdy; Dan Rose Subject: Message summary [id.406l39916141381] Justin Osofsky: >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. Mark Zuckerberg: >Yup, go for it. CONFIDENTIAL FB-OO934373 EXHIBIT 45 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 48 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 69 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 70 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 78 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 79 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 80 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 83 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 84 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 85 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 86 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 87 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 88 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 89 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 90 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 91 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 92 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 94 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 95 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 97 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 158 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 170 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 172 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL EXHIBIT 180 UNREDACTED VERSION OF DOCUMENT SOUGHT TO BE LODGED UNDER SEAL