4 ms·

To really fix this, Facebook will have to stop allowing 3rd party developers direct access to user data. Basically, FB should introduce an App-Engine like plat

To really fix this, Facebook will have to stop allowing 3rd party developers direct access to user data. Basically, FB should introduce an App-Engine like platform where the backend of any 3rd-party application that uses FB data has to run on FB-owned servers. Developers of these applications would then ship their code to FB (similar to Heroku) and run in a sandboxed environment where they are not allowed to take data out at all. That way FB can audit how the data is being used at anytime and kick out people who are out of compliance with their terms. If a user deletes their FB account, now all their data could be deleted from any 3rd party applications automatically. This is basically similar to the way the government handles classified data.

prostoalex 9y ago
> the backend of any 3rd-party application that uses FB data has to run on FB-owned servers Would that work for mobile apps?
- hendzen 9y ago
  The backend of the mobile app would run on FB servers.
  - prostoalex 9y ago
    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.
    - hendzen 9y ago
      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.
      - prostoalex 9y ago
        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.
aylmao 9y ago
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?
- hendzen 9y ago
  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).
  - aylmao 9y ago
    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!

prostoalex 9y ago

> the backend of any 3rd-party application that uses FB data has to run on FB-owned servers Would that work for mobile apps?

hendzen 9y ago
The backend of the mobile app would run on FB servers.
- prostoalex 9y ago
  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.
  - hendzen 9y ago
    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.
    - prostoalex 9y ago
      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.

aylmao 9y ago

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?

hendzen 9y ago
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).
- aylmao 9y ago
  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!