4 ms·

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 de

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!
- hendzen 9y ago
  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.
  - tzahola 9y ago
    Bits can’t be colored... http://ansuz.sooke.bc.ca/entry/23 http://ansuz.sooke.bc.ca/entry/23
- dmannorreys 9y ago
  What tool did you use to make that schema?
  - tzahola 9y ago
    http://asciiflow.com http://asciiflow.com
    - aylmao 9y ago
      yup, that's the one.
- adrianmonk 9y ago
  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.
prostoalex 9y ago
> 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.

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!

hendzen 9y ago
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.
- tzahola 9y ago
  Bits can’t be colored... http://ansuz.sooke.bc.ca/entry/23 http://ansuz.sooke.bc.ca/entry/23
dmannorreys 9y ago
What tool did you use to make that schema?
- tzahola 9y ago
  http://asciiflow.com http://asciiflow.com
  - aylmao 9y ago
    yup, that's the one.
adrianmonk 9y ago
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.

prostoalex 9y ago

> 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.