If it were some computation, aggregation or analysis this work, but a lot (I'd guess, most) applications might not fall into this category. How are you gonna present the data in a UI to users, if no data is supposed to leave the server?

The UI could be a web page, mobile app, etc just like FB.com. But to see any user data you would actually have to be authorized as that specific user. I.E. a developer could test their app by logging in with their own FB account and using their own data but would have no capability to look at the raw DB entries of other users.

Or perhaps their could be a limited capability for developers to log in to their app as another user of it, but those accesses would be logged and periodically audited (just like the as-another-user-logins of regular FB engineers are).

Hm, the catch here is something like this could happen:

  +--------------+        +----------+        +--------------+
  |              |        |          |        |              |
  | other server |        |  Server  |        | other server |
  |              |        |          |        |              |
  +-------+------+        +----+-----+        +-------+------+
          ^                    |                      ^
          |                    |                      |
          |               http request                |
          |               containing user             | 
          |               data for UI                 |
    http request made          |               rouge http request
    with a legit purpose       |               sending the user data
    say fetching assets        v               to some other server
          |            +-------+-------+              |
          |            |               |              |
          +------------+  mobile app   +--------------+
                       |               |
                       +---------------+

And there is really no way of knowing which requests are for legit app purposes and which would be leaking data. Now, you could require that the mobile app make no requests to any service but Facebook, which brings two questions:

1. can facebook do this? Apple could; they approve apps and get the binary/manifest before the app is released. But how could Facebook enforce this?

2. would developers be ok with this? Relying 100% on facebook?

It is an option, I'm not saying it's infeasible. An interesting idea for sure, thanks for sharing!

I guess you could let the mobile app access third-party servers but require all traffic to go through a proxy where Facebook can examine it. (Either by letting Facebook handle all the encryption or giving Facebook a copy of the key.)

All of this tends to trade one problem for another, though: the user no longer has to worry that the third-party app has access to their Facebook data. But now the user has to worry that Facebook has access to their third-party app data.

What tool did you use to make that schema?

yup, that's the one.

1) agreed - for mobile apps to maintain some semblance of data sandboxing, this would require FB to work with Apple. I'm imagining some kind of new iOS "Secure API" where the return values from certain API calls are marked "tainted" and then Apple uses static binary analysis to reject apps that write the tainted data to non-whitelisted socket calls.

2) Developers simply wouldn't have a a choice in the matter - FB is so big that they can force the market in a certain direction if they want to.

Bits can’t be colored... http://ansuz.sooke.bc.ca/entry/23

> But to see any user data you would actually have to be authorized as that specific user. I.E. a developer could test their app by logging in with their own FB account and using their own data but would have no capability to look at the raw DB entries of other users.

This is the status quo as of the 2014 platform policy changes.

The entire debacle is around the data retrieved (and saved) prior to that, which is what Cambridge Analytics has done.

> Or perhaps their could be a limited capability for developers to log in to their app as another user of it

FB Developer app has support for test users, who are marked as such.

> the backend of any 3rd-party application that uses FB data has to run on FB-owned servers

Would that work for mobile apps?

The backend of the mobile app would run on FB servers.

Most apps that do "Login with Facebook" also support "Login with Google" and sometimes "Login with LinkedIn". The backend ownership issue becomes a bit more complicated.

This is even before we get into trust issues most developers would have with Facebook having access to their user data.

The portion of the app that deals with FB data would be hosted at FB, the portion of the app that deals with Google would be hosted at Google, etc. And this is only a problem for applications that pull user data from FB itself, if it was merely using FB for authorization but wasn't actually using any FB profile data, photos, friend lists, etc, than it could all be hosted on a 3rd party server.

So most developers would say "But my FB backend is just a simple proxy / transformation layer that parses the data and sends that to the front end".

Most would be correct - some flows like inviting friends to an app, or showing friends who also happen to use this app (for games, etc.) are so common that they're integrated into the Facebook SDK.

For performance reasons (both on Facebook's end and for the sake of user's experience, just in case his phone moved into a zone with inferior coverage) a fat network request was preferred to multitude of thin small ones - you couldn't really predict when the user would fancy inviting their friends, saving their score, looking at their achievements, or checking out friends who are in same town as them - so a 24-hour cache policy was instituted.