Facebook's Canvas Encryption Proposal | Hacker News Reader

Facebook's Canvas Encryption Proposal

developers.facebook.com

43 pointsssclafani16 comments

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.

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.

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

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.

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.

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?

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.

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.

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

Navigation happens within Canvas iframes, and POSTs make the browser back button more than a little screwy. We definitely considered this.

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.

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.

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!

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.

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

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

Reply on news.ycombinator.com