Re: Verizon Public Policy on Netflix
At 11:17 AM 7/13/2014, Todd Lyons wrote:
Because that Netflix box is not an on-demand cache, it gets a bunch of shows pushed to it that may or may not be watched by any of Brett's customers. Then the bandwidth he must use to preload that box is large, much larger than the sum of the streams his customers do watch.
Yes. Especially since Netflix insists upon sending multiple copies of each video -- not only in different formats but in different resolutions -- to the server.
I did agree with the comment later in the email that making content freely cached is a non-starter because that content could be copied too easily.
The content could be copied just as easily from a Netflix server if it were stolen from the ISP's office. However, by far the most likely place for illicit copies to be made is at the client end, because it can be done in a private location and attract no attention at all. However, if there is any concern about either a Netflix server OR an ISP's cache being used to obtain illicit copies of the video, the solution is simple. This is a trivial problem to solve. Send and store the streams in encrypted form, passing a decryption key to the user via a separate, secured channel such as an HTTPS session. Then, it is not possible to obtain usable copies of the content by stealing either a Netflix server OR an ISP-owned cache. Problem solved. --Brett Glass
On 7/13/2014 12:54 PM, nanog@brettglass.com wrote:
However, if there is any concern about either a Netflix server OR an ISP's cache being used to obtain illicit copies of the video, the solution is simple. This is a trivial problem to solve. Send and store the streams in encrypted form, passing a decryption key to the user via a separate, secured channel such as an HTTPS session. Then, it is not possible to obtain usable copies of the content by stealing either a Netflix server OR an ISP-owned cache. Problem solved.
Unless of course you've promised the content owner that you would be encrypting each delivery with a different key (because they'd been burned before by things like DVDs, which do not). Then not "problem solved" at all. You're also assuming that every customer is viewing the same bitrate/resolution/aspect ratio. With multi-bitrate streaming, there's often low overlap between the segments adjacent customers wish to load... even if the content is not encrypted, or is encrypted with the same DRM key for everyone. Of course, the facts of the situation don't appear to matter really... Matthew Kaufman
However, if there is any concern about either a Netflix server OR an ISP's cache being used to obtain illicit copies of the video, the solution is simple. This is a trivial problem to solve. Send and store the streams in encrypted form, passing a decryption key to the user via a separate, secured channel such as an HTTPS session. Then, it is not possible to obtain usable copies of the content by stealing either a Netflix server OR an ISP-owned cache. Problem solved.
That works for individual sessions, but not for the cache scenario. Either everyone gets the same key (which is equivalent to no key at all) or the cache has to be able to participate in the encryption. Beyond that small fly in the ointment, I believe Netflix current model operates pretty much as you suggest. However, their cache boxes have to participate actively in the encryption in order to avoid providing the same decryption key to everyone for any given show. I suspect (though I don't know) that encrypted content is loaded onto the cache in a form encrypted with a key known to the software on the cache. That each streaming request causes said content to be decrypted and immediately re-encrypted with a user-specific key and/or session-specific key and then sent to the user. Hence the requirement that the cache be on a box run by Netflix, and probably part of the reason for the greater power requirements. Owen
participants (3)
-
Matthew Kaufman -
nanogļ¼ brettglass.com -
Owen DeLong