As we
continue to evolve our developer platform and to create an environment that
most effectively empowers the developer community while at the same time
protects the privacy of our users, Myspace is enacting a number of new
initiatives related to data security within our application platform. We also wanted to discuss briefly some of the
actions we've taken over the past month to enforce our Developer Terms of Use,
which -- as we've said publicly -- prohibit the passing of any user
information, including user IDs, to third parties without the consent of our
users.
We
determined that a handful of developers had intentionally disclosed user IDs to
a single data broker in violation of our Terms.
We promptly suspended the applications who were engaged in this
activity. We also demanded that the data broker who received user IDs
delete all such information, and it agreed to do so.
We
have been working to come up with both better methods to enforce our Terms, and
also mechanisms to allow developers to provide great apps without the need to
share Myspace user IDs with third parties.
Initially,
we are introducing the following initiatives with the goal of providing the
best possible environment for developers while ensuring we protect the privacy
of our users.
- Encrypt
Myspace User IDs. In order to ensure
that user IDs will not be included in URLs that could be inadvertently passed
to third parties by offsite apps (something that our technology already
prevents for apps hosted on the Myspace platform), we are encrypting the
parameters (including the user ID) exchanged between Myspace and developers for
all offsite apps. Developers will have the ability to decrypt the data
but the user ID will not be readable by other parties.
- Use anonymous
identifiers. We will require all
developers to use anonymous identifiers by January 21, 2011. These anonymous
identifiers should be used as a proxy for the Myspace user ID in cases where
developers need to share a unique identifier with permitted third parties, such
as content partners and advertisers.
- No data brokers. We have no tolerance for data brokers. Accordingly, going forward, any developer
found transferring Myspace user data, including user IDs, to a data broker will
be punished with immediate suspension and a minimum 6-month moratorium on their
apps.
Below are technical changes that
developers will need to make in order to ensure they are not inadvertently
passing user IDs to third parties.
Encrypt Myspace User IDs
We are working to eliminate any trace
of the user ID from the URL in cases where it's not strictly necessary.
For apps that are rendered from an external server via an IFrame, we will begin
encrypting the user ID in a way that only the app can recover the user
ID. Specifically, the user ID will be encrypted with AES 256 using the
specific app's private OAuth consumer secret as the encryption key.
Starting on January 21, 2011, apps will need to change over from using the
unencrypted user ID to using the encrypted user ID, at which time we will
completely eliminate sending the bare user ID as a query parameter. The
sample code provided below (in C#) shows developers how to encrypt Myspace user
IDs using their app's consumer secret key.
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Security.Cryptography;
using System.Web;
// 128 bit iv
private static readonly byte[] iv = new byte[] { 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}; // this is the IV we will be using
/// <summary>
/// Decrypts url and
base64 encoded string
/// </summary>
/// <param
name="encodedCyperText">cyphertext</param>
/// <returns>plaintext</returns>
public static string
Decrypt(string encodedCyperText)
{
byte[] csBytes = Convert.FromBase64String(consumerSecret);
//
generate a 256 bit key
SHA256CryptoServiceProvider sha = new SHA256CryptoServiceProvider();
byte[] cryptoKey = sha.ComputeHash(csBytes);
//
setup encryptor params
AesCryptoServiceProvider aes = new AesCryptoServiceProvider();
aes.BlockSize = 128;
aes.KeySize = 256;
aes.IV = iv;
aes.Key = cryptoKey;
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;
//
url decode, base64 decode the cypher text to byte array
byte[] cypherBytes = Convert.FromBase64String(HttpUtility.UrlDecode(encodedCyperText));
//
decrypt
MemoryStream memStream = new MemoryStream();
CryptoStream decryptStream = new CryptoStream(memStream, aes.CreateDecryptor(),
CryptoStreamMode.Write);
decryptStream.Write(cypherBytes, 0, cypherBytes.Length);
decryptStream.FlushFinalBlock();
byte[] decodedBytes = memStream.ToArray();
return
Encoding.UTF8.GetString(decodedBytes);
Use
Anonymous Identifiers
We have developed a two-phased solution to address the
practical need to share anonymous unique identifiers with legitimate third
parties. The first phase will utilize an anonymous and unique 32 bit
integer matching the same specifications as the Myspace user ID. All developers are required to switch over to
this solution prior to January 21, 2011.
Here
is how to access the anonymous ID via Myspace javascript container for on-site
apps:
opensocial.Container.get().params_["thirdPartyId"]
External Iframe apps came pull this value from the
querystring:
third_party_id
In
addition to this interim solution, we are working on a long term solution that
will be based on industry standards. Anonymous unique identifiers
will not be consistent across applications and will consist of a cryptographic
secure token. This will prevent the
creation of a global lookup table. We do
understand the need for consistent anonymous unique IDs across applications for
fraud prevention purposes and we will provide mechanisms for authorized parties
to be able to link these IDs together across the platform.
We
encourage you to review our Developer
Terms of Use and if you have any questions, feedback, or are unsure if your
app complies or not, please contact us at DeveloperRelations@myspace-inc.com.