Geo Filtering Architecture: The upLynk Approach
flags CC-BY-ND-NC Kexino
Keeping with the upLynk mantra of making everything simpler to integrate, we made the decision to use a token exchange system to enforce Digital Rights Management (DRM) business rules our customers design to protect access to their content. Here's an example user experience flow.
User visits content access site.
User passes business rules.
User presented accessible content complete with access tokenized URLs.
User selects content to play back.
Token checked by upLynk CMS to ensure it hasn't expired or been tampered with.
If the token is validated, the m3u8 is returned.
Pretty simple right?
We provide customers sample code for generating the tokens. It's nothing your OAuth gals haven't seen before.
And that's it.
Does this mean it's up to you to develop the actual geo filtering system? Yes! But you want to be in control. Here's why.
Every user experience is different. There are several different ip database providers. There are options on those databases such as including filtering of anonymous proxies, etc. Everyone wants a different set of rules applied to their content.
However, the most important reason is to ensure your users are not frustrated by your experience.
Let's walk through an example.
Perhaps today, you rely on your video platform to do the geo filtering for your content. Here's a typical frustrating experience.
User visits content provider's site.
User browses enormous catalog.
User attempts playback of content.
Error pops that content is not currently available in their area, or worse, user watches an ad followed by the error.
That is of course, if there's any error at all!
There are business and marketing reasons to "tease" users with available content. If legal rights will prevent the user from content playback, don't risk frustrating the user by presenting that content. Here's an alternative experience.
Ensure you have enough content. Only you will know how much is enough.
Geo filter the user early in the process. The ip db query is not that expensive. Most web stacks support custom middleware which could perform the query and set a cookie with the location code, or other custom identifier. This will help scalability as the user includes the cookies with all their requests.
In your application, check for the cookies (or whatever session based mechanism you choose for minding the location code) and present the user content they can successfully playback.
Keep in mind, this does not exclude content that may require user registration or even a subscription. The point is to present the user content that, given their location, they can potentially playback.
Slightly more evil is presenting the content you have rights to, but may not be available in the user's location, but is clearly marked that it's currently not available. Say it's "coming soon", if you want. It's ultimately your decision if you'd like to risk the trust of your user.
You can't afford to lose that trust.