Facebook Offers Canvas Encryption Proposal to Fix the User ID Issue

Facebook has responded to the issue of applications inadvertently sharing user IDs through HTTP referrer headers by proposing a new system for encrypting the parameters passed to applications. This Canvas Encryption Proposal stipulates that UIDs would require the receiving application’s secret key to decrypt, preventing anyone else from reading information about the user. The company is now soliciting feedback from developers on the proposal. It hopes to implement parameter encryption for iframe-based canvas applications within the next few weeks, add support for all of Facebook’s SDKs, and help applications transition to the system. Facebook Platform engineer Mike Vernal explains in the post to the Facebook Developer Blog that, “while initial press reports greatly exaggerated the implications of sharing a UID, we take this issue seriously.” Facebook prohibits the sharing of user information with ad networks, data brokers, or anyone else not explicitly authorized by the user. The data being shared in this case is already public, but Facebook wants to assure users they are protected against even benign data leaks. See our previous coverage for more details. Facebook says some of the iframe-based canvas applications which were sharing data have since devised their own systems including “redirects or 'double framing' to remove UIDs from the URL." However, the site is looking to set up a Platform-wide solution. The proposal explains that by using signed request parameters,“developers will now decrypt data instead of just checking the signature.” Developers can see psuedocode, sample code, examples, and explanations of how base64_url encode and decode works on the proposal page. Here is how the parameter is generated and decrypted: Instead of reading the current fb_sig_* parameters, your application will read only a single parameter, named request. This parameter is generated as follows: Encode the data in JSON format. Encode that JSON with base64url to make the package websafe. Encrypt the base64url using AES-256-CBC algorithm. Then, take the encrypted blob and add it to the envelope with key payload. The envelope is just another JSON array that describes the encryption, containing keys algorithm, iv, andissued_at. Encode the envelope in JSON then base64url. Take the entire blob, sign it with HMAC-SHA256. Prepend the signature, then a period ".", then the blob, and you're done. To decrypt it, you do the reverse: Split the string on period, and get the signature and the blob. Check that the HMAC SHA256 of the blob matches the signature provided. Then, base64url decode the blob, and check the issued_at isn't more than an hour old. Decrypt the payload using AES256, the iv parameter, and your application secret. Finally, you can use the data inside the payload. Applications that aren’t iframe-based such as FMBL-based canvas applications, as well as Facebook integrated Open Graph web sites, mobile interfaces, and social plugins won’t be affected by the change. Facebook says it is “very open to discussions about using this scheme in OAuth2” but a protocol hasn’t been set yet. The proposal doesn’t address applications that were purposefully sharing or selling user data which may be of significantly greater danger to users than the UID issue. We’ll continue our coverage as the Canvas Encryption Proposal evolves and Facebook begins the transition.

Social Pro Daily

Facebook Offers Canvas Encryption Proposal to Fix the User ID Issue

Josh Constine

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Josh Constine