Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fortscan
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Thanks Kevin. Using the on-screen keyboard is obviously not easy for the end user.

We have reviewed all SDK related documentation but we still couldn't find a complete explanation, perhaps with a couple examples, that defines how the rendezvous linking works. Could you perhaps point us to some specific part of the documentation, or a basic flowchart of how it operates?

Where can we find the "Content Data and Hosting" document? (developer.roku.com is not working)

Is the token number retrieved from a variable internally stored on the DVP, such as serial/mac, or is it retrieved remotely from a server? If this is generated remotely, and user has to enter the token number he sees at the screen while being logged into the membership site (on his PC), this would confirm that only he is able to know that number. But how does this imply that every request coming from his DVP will be treated as "authenticated" by our servers? In other words, what kind of individualization process is added (perhaps encrypted headers?) to each request coming from a registered DVP to validate it at the CDN/servers level?
0 Kudos
RokuKevin
Visitor

Re: Piracy protection for private channels (SDK DRM?)

fortscan,

There is no "Content Data and Hosting" document in the SDK.... I believe you are looking for the "RokuDvp-DeviceRegistrationAndLinking.pdf" document. That doc will explain the linking process in detail.

There is also a "register" sample app that shows the brightscript implementation of rendezvous linking. Note that there is also a server side implementation that will be specific to your site. Your server will generate the rendezvous number the user will enter on your server. It has nothing to do with the serial number or mac addr of the box. Your server will also generate a "Device Service Token" (DST) that you Roku channel will store in the registry. It is this DST that is used to authenticate the box and associate an account when the user gets customized feeds from your site.

--Kevin
0 Kudos
hoffmcs
Visitor

Re: Piracy protection for private channels (SDK DRM?)

I wrote a rendezvous type linking page that is built on Google App Engine which have very generous free limits. All API keys and authentication tokens are stored locally on the Roku box and all this really does is handle the handshaking between the Roku box and the service.

You can see the source here:
http://bitbucket.org/chrishoffman/appen ... ulink/src/

Chris
0 Kudos
FML2010
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Thanks Kevin for pointing out this Post.

how would we use this in a php environment and connect soley to our Mysql DB? not using google app engine or oauth

Python is as foreign as Brightscript is to me 😞
0 Kudos
fortscan
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Thanks to everyone who is contributing with ideas regarding this post.

We will install and try the linking page built on Google App which seems a great reference from hoffmcs.

We are currently deploying a global VoD service in a region outside the US, where Netflix/Amazon don't operate. Due to the security requirements from each of the studios and content aggregators we work with, we are trying to improve DRM scheme for the devices we will be supporting for streaming (set-top-boxes). Although it seems like we won't be able to use propietary DRM when streaming to Roku DVPs, we still want to incorporate it as a supported device due to its economical price, which could make the whole service more attractive, globalizing its adoption.

Besides SSL mutual authentication and random, expiring links for the content at the CDN, does anyone have any suggestion/idea about additional security features compatible with the Roku SDK for securing the content?

Thank you.
0 Kudos
denizb
Visitor

Re: Piracy protection for private channels (SDK DRM?)

We have a membership service where members have unlimited access to videos (similar to Napster.com for music, or Hulu Plus). Videos are stored on Level 3 CDN, and can be authentication via a token (time expiring unique code generated on our servers based on authentication).

We will be creating a Private Channel, which will allow members of the website to view the same content on Roku.

We need help understanding how the registration and authentication is performed. Once a user links their Roku via rendezvous, they will have access. How do we revoke access once the membership is expired?

The members table stores username/password/membership status (1=active, 0=expired).
So should we also store the Device Service Token in this table to associate the account with a Roku box?

If a member does not have roku box id store in our db, or his status is expired, an XML file with the list of videos would not be generated.

How would I notify the user on the Roku box, that his membership has expired?

I would want the steps to be like this:
1. Go to our private channel
2. If device is linked to service, go to step 4, else, go to step 3
3. Register/link device to account.
4. If member active, proceed to showing content, else display a screen that informs the membership is expired, instructing the user to go to desktop to reactivate account.

What happens if the Roku channel is left open while the membership expires? At this point, since the channel already checked for membership status once, it would still allow access to the channel, but my XML files with content and authentication tokens would return empty. How can I in some way poll for the status, upon status change , the viewer should be presented with the same dialog box in step 4.

Finally, it would be very useful to have a complete example in the SDK that mimincs Hulu Plus or Netflix's channels to see how they perform these authentication steps.
0 Kudos
RokuKevin
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Denizb,

> How do we revoke access once the membership is expired?

You could remove the DST from the "valid DST" column in your members table on your website.

> So should we also store the Device Service Token in this table to associate the account with a Roku box?

Yes. That would be a good place.

> How would I notify the user on the Roku box, that his membership has expired?

You may want to have a section of your channel accessible to "members only". If they don't have a valid account they won't be able to access it. You could message the user to this effect and show a linking screen anytime this section is not accessible. (Try Your Video Library in the Amazon channel as an example).

> What happens if the Roku channel is left open while the membership expires?

You could validate the DST on every request if desired.... Or any timeout period you desire.

> Finally, it would be very useful to have a complete example in the SDK that mimincs Hulu Plus or Netflix's channels to see how they perform these authentication steps.

Please see the "register" example in the SDK. There is also the Device Linking and Registration guide in the SDK.

--Kevin
0 Kudos
joetesta
Roku Guru

Re: Piracy protection for private channels (SDK DRM?)

> You could validate the DST on every request if desired.

How would one do this, is there an equivalent way to put the DST in the header as is done with "x-roku-reserved-dev-id" in the mutual SSL setup?

(This is what i have for that)
    screen.Addheader("x-roku-reserved-dev-id","")
screen.SetCertificatesFile("pkg:/source/cacert.pem")
screen.InitClientCertificates()


and I've tried
screen.Addheader("RegToken","XYZ")

as well as various other things but the RegToken wasn't in the headers even though 'x-roku-reserved-dev-id' is-

OK I figured it out; in the videoPlayer there is a 'appDetailScreen.brs' and 'appVideoScreen.brs' - these settings appear in both and I was only putting it in one (the wrong one). pardon the interruption 🙂
aspiring
0 Kudos