6 ms·

Facebook's Canvas Encryption Proposal

43 points by ssclafani 16y ago

GICodeWarrior 16y ago
This sounds like major overkill. If the only problem is the data in the iframe url, couldn't they POST the data into the iframe? Create the iframe with some JS that POSTs a form containing the data to the canvas app. The resulting iframe url is the same but without any query parameters.
- SriniK 16y ago
  Yup. Also it's not solving the problem of app developers sharing the UID's intentionally. After the decryption at app's server side, they can share uid as usual. I am not sure if fb has rules for not pushing uid's with 3rd party services - other than that, I don't see how this solution avoids the problem.
  - biznickman 16y ago
    Exactly ... this encryption is absolutely useless for intentional sharing. Facebook does have rules against sharing ANY data with third parties, however people are clearly violating that. Update ... I just blogged about it here: http://www.allfacebook.com/is-facebooks-proposed-user-id-solution-sufficient-2010-10 http://www.allfacebook.com/is-facebooks-proposed-user-id-sol...
- finiteloop 16y ago
  Navigation happens within Canvas iframes, and POSTs make the browser back button more than a little screwy. We definitely considered this.
efsavage 16y ago
This privacy problem is trivially solvable. Facebook should generate a surrogate key for user/app relationships, and only share that with the apps. Then my ID cannot be tied back to me by anyone but facebook, and I cannot even be tracked across applications by the same developer.
- GICodeWarrior 16y ago
  This is a great ground-up solution, but I would consider it far from trivial in practice for Facebook at this point. The current ids have completely permeated every part of their public APIs and likely every part of their internal systems...
  - efsavage 16y ago
    True, I meant trivial in terms of complexity (as opposed to encryption). Implementation/migration would be tricky, but not impossible. Also, anyone who's worked with their APIs before knows not to underestimate Facebook's commitment to the "move fast, break things" mantra.
- finiteloop 16y ago
  We have talked a lot about solutions like this, but most of them end up more trouble than the encryption proposal. For example, developers need to link back to your profile page and your friends' profile pages in their UI - do we change all those URLs individually for all applications, too (since they contain a user ID)? I think it is a clever idea, but it ends up breaking down in a lot of ways, and it has the bad quality that it is not backwards compatible with existing applications.
  - zbanks 16y ago
    Why not create a new URL handler that takes an app-specific user ID that redirects to the correct profile page only if the logged-in user has permission to view the page? That way, you would normally only be able to see what the world would see; but if you try to view your or your friend's profile, it's fluid?
gdeglin 16y ago
The risk of sending the UID of the user to ad networks is that it's possible an unscrupulous ad network will store and use or sell the data. However, if an ad network wanted to get the UIDs they can still easily get them. Just about all Facebook iframe applications use the Facebook Javascript SDK, which provides methods that can easily be used to collect the user's current ID or other information. Most ad networks require developers to load a remote javascript file on their site, and this javascript file can simply make calls through the SDK to fetch whichever information it wants.
- brianr 16y ago
  That only works if the ad javascript is embedded directly in the page. All you have to do for this not to be an issue is host the ad in an iframe, and fortunately most ad integrations tend to be this way already.
tgriesser 16y ago
It seems that this is just a PR move by Facebook... that will hopefully be equally as misunderstood by the media and general public as the original problem is in itself. I don't see how the sharing of UID's is any different/worse than cookies that are persistent on users computers other than the fact that users may be less aware of them, and i guess they're not associated with a store of personal information. I think that the perception is that if a business gets my Facebook UID, they have access to my information - which is not true, they can't retrieve any more information than you publicly make available. Maybe I'm just misunderstanding what the big issue is all about though.
tptacek 16y ago
Not that it matters given the problem domain, but the Python example code here has a timeable HMAC. Don't use native string compare to check MACs!
msie 16y ago
Maybe it would be better not to waste time on this and instead work on educating the public. How about a comic ("Facebook UIDs and You")? :D Actually the problem is how Facebook is working its way into all parts of the internet with its widgets and Facebook logins.
zbanks 16y ago
This is a sad attempt to reconcile with the community. It's hardly a proposal when they already seem intent on following through with this plan. It's not exactly an RFC. Not to mention the flaws present pointed out by the other commenters...
zecg 16y ago
So, how does this affect https://chrome.google.com/extensions/detail/ejpepffjfmamnambagiibghpglaidiec https://chrome.google.com/extensions/detail/ejpepffjfmamnamb...

43 points by ssclafani 16y ago

This sounds like major overkill. If the only problem is the data in the iframe url, couldn't they POST the data into the iframe? Create the iframe with some JS that POSTs a form containing the data to the canvas app. The resulting iframe url is the same but without any query parameters.

SriniK 16y ago
Yup. Also it's not solving the problem of app developers sharing the UID's intentionally. After the decryption at app's server side, they can share uid as usual. I am not sure if fb has rules for not pushing uid's with 3rd party services - other than that, I don't see how this solution avoids the problem.
- biznickman 16y ago
  Exactly ... this encryption is absolutely useless for intentional sharing. Facebook does have rules against sharing ANY data with third parties, however people are clearly violating that. Update ... I just blogged about it here: http://www.allfacebook.com/is-facebooks-proposed-user-id-solution-sufficient-2010-10 http://www.allfacebook.com/is-facebooks-proposed-user-id-sol...
finiteloop 16y ago
Navigation happens within Canvas iframes, and POSTs make the browser back button more than a little screwy. We definitely considered this.

efsavage 16y ago

This privacy problem is trivially solvable. Facebook should generate a surrogate key for user/app relationships, and only share that with the apps. Then my ID cannot be tied back to me by anyone but facebook, and I cannot even be tracked across applications by the same developer.

GICodeWarrior 16y ago
This is a great ground-up solution, but I would consider it far from trivial in practice for Facebook at this point. The current ids have completely permeated every part of their public APIs and likely every part of their internal systems...
- efsavage 16y ago
  True, I meant trivial in terms of complexity (as opposed to encryption). Implementation/migration would be tricky, but not impossible. Also, anyone who's worked with their APIs before knows not to underestimate Facebook's commitment to the "move fast, break things" mantra.
finiteloop 16y ago
We have talked a lot about solutions like this, but most of them end up more trouble than the encryption proposal. For example, developers need to link back to your profile page and your friends' profile pages in their UI - do we change all those URLs individually for all applications, too (since they contain a user ID)? I think it is a clever idea, but it ends up breaking down in a lot of ways, and it has the bad quality that it is not backwards compatible with existing applications.
- zbanks 16y ago
  Why not create a new URL handler that takes an app-specific user ID that redirects to the correct profile page only if the logged-in user has permission to view the page? That way, you would normally only be able to see what the world would see; but if you try to view your or your friend's profile, it's fluid?

gdeglin 16y ago

The risk of sending the UID of the user to ad networks is that it's possible an unscrupulous ad network will store and use or sell the data. However, if an ad network wanted to get the UIDs they can still easily get them. Just about all Facebook iframe applications use the Facebook Javascript SDK, which provides methods that can easily be used to collect the user's current ID or other information. Most ad networks require developers to load a remote javascript file on their site, and this javascript file can simply make calls through the SDK to fetch whichever information it wants.

brianr 16y ago
That only works if the ad javascript is embedded directly in the page. All you have to do for this not to be an issue is host the ad in an iframe, and fortunately most ad integrations tend to be this way already.

tgriesser 16y ago

It seems that this is just a PR move by Facebook... that will hopefully be equally as misunderstood by the media and general public as the original problem is in itself. I don't see how the sharing of UID's is any different/worse than cookies that are persistent on users computers other than the fact that users may be less aware of them, and i guess they're not associated with a store of personal information. I think that the perception is that if a business gets my Facebook UID, they have access to my information - which is not true, they can't retrieve any more information than you publicly make available. Maybe I'm just misunderstanding what the big issue is all about though.

tptacek 16y ago

Not that it matters given the problem domain, but the Python example code here has a timeable HMAC. Don't use native string compare to check MACs!

msie 16y ago

Maybe it would be better not to waste time on this and instead work on educating the public. How about a comic ("Facebook UIDs and You")? :D Actually the problem is how Facebook is working its way into all parts of the internet with its widgets and Facebook logins.

zbanks 16y ago

This is a sad attempt to reconcile with the community. It's hardly a proposal when they already seem intent on following through with this plan. It's not exactly an RFC. Not to mention the flaws present pointed out by the other commenters...

zecg 16y ago

So, how does this affect https://chrome.google.com/extensions/detail/ejpepffjfmamnambagiibghpglaidiec https://chrome.google.com/extensions/detail/ejpepffjfmamnamb...