In the rush to deliver a great game to market, security can often times take a back-seat to game play, but it is a vital part of the overall experience that requires some consideration before a successful title launch. After all, my addiction to protecting castles from zombie ninja fruit while standing in line at Starbucks should not expose me to concerns about my personal or financial data being intercepted. So while thought should be given to a whole list of security concerns, secure entry and delivery of any type of asset in any online social setting should be a priority when planning distribution.
Facebook came to this realization back in 2011, and as of October 1st of that year SSL connections were required for all of their application developers. Earlier this year, Facebook also began using HTTPS by default for all users, and virtually all traffic to www.facebook.com and 80 percent of the traffic to m.facebook.com uses SSL. For developers and publishers this means that considering SSL connectivity for your application is a requirement for effective distribution, and even if you aren’t planning on publishing through Facebook, it is a standard that should be adopted whenever possible.
Before we get into deciding which options to undertake for the SSL delivery, it is always a good idea to first plan on doing a little bit of future-proofing your application for working with multiple networks. Your game may require that every asset be delivered through the same SSL connection and domain, but it may also only require the launcher to be delivered securely while art assets come in over standard HTTP. Regardless of which route you go, planning for flexibility when it comes to delivering your application and assets is much easier to achieve before you launch. To help with that future-proofing and to provide flexibility, it’s always a good idea to have as many options as possible to determine (all the way down to a per asset basis) what the domain, or base URL, for requests will look like, and make it configurable.
Ideally, every link and embedded request URL can be changed simply on your end, or by your application making a decision based on the referrer or requesting domain. That information can then be used to determine the base URL (or even possibly the entire asset path) and to alter the location it is delivered from. For example, you may have your launcher configured so that when launched from www.facebook.com it delivers using https://secure.mydomain.com/game.launcher, but when it downloads an art asset for Level 5 as the player progresses it changes to a non-secure connection and pulls from http://content.mydomain.com/assets/level5.art. In that same scenario a request from a different publishing partner may make you want to deliver the launcher from their platform directly in which case the player would be getting files from https://mydomain.publisher.com/game.launcher. Having the flexibility built in to handle all of these scenarios will make publishing and distribution much easier as you navigate all of the different delivery paths available to you.
Now that you have the code in place to easily adapt to using different domains for delivery within your game or application, you can decide what flavors of SSL delivery make sense for you. There are four basic options:
- Your own certificate hosted on your web servers.
- A wildcard certificate utilizing a distribution provider’s domain.
- A shared domain on a provider’s certificate.
- A copy of your certificate hosted by your distribution provider.
Picking which one of these options (or which combination of options) usually depends primarily on how strict your distribution channel is in its requirements, and whether or not you have e-commerce or other sensitive user information that requires the highest security to avoid browser warnings or blocking.
For games and applications launching from Facebook, wildcard certificates from your distribution network (such as Highwinds Game Delivery Network™) will cover your needs. We provide a Highwinds certificate and an SSL connection for each request that is delivered on a Highwinds domain. This domain is not editable, and it will display as coming from our network, but the costs for this service are generally the lowest of the options, and you will not have to worry about maintaining your own certificates, purchasing, or keeping the trust levels for your domain high.
If maintaining your own domain and certificates is important to your application or business, then most distribution networks (Highwinds included) can also provide the actual hosting of a certificate you have purchased and delivery of your assets through that domain. This can be especially important if there are any financial transactions or any other regulated data passing through your application since most browsers will require that all domains on those secure pages match in order to allow the user to proceed. In that scenario you can purchase a certificate for your domain, such as https://secure.mygame.com, and all content delivered will be sent from that domain with a matching certificate. In most cases purchasing your own certificate will also mean you have it available for your web servers as well, and combinations of these four basic options can also be used.
We realize that every customer has a different story and we would be happy to speak with you to answer any additional questions that you might have about SSL or developing with SSL in mind.
At the end of the day, security is your top concern and making sure you get the right SSL solution is our only concern.
To learn more about Highwinds SSL and download a free SSL data sheet, click here.
By Barry Whitley, Director of Solutions Architecture