INOM TEKNIKOMRÅDET EXAMENSARBETE
INFORMATIONSTEKNIK OCH HUVUDOMRÅDET
INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK, AVANCERAD NIVÅ, 30 HP
STOCKHOLM SVERIGE 2016,
Embedding premium video in social streams
NICOLÒ SOLANO
KTH
SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK
Embedding premium video in social streams
NICOLÒ SOLANO
Master’s Degree Project
Stockholm, Sweden April 2016
A
BSTRACTD
igital videos are a sequence of bits encoded in a universal recognized format. Bits are easy to copy, duplicate and reproduce. However, certain videos have a very high financial value and therefore the respective owners want to protect them according to the Copyright law, in order to acquire the exclusive rights to publish and to reproduce them. Digital Rights Management (DRM) is the technology used nowadays to protect video distribution and to maintain at the same time a complete control over the usage of the owned resources.Another actual phenomenon is the increasing number of social users, in all the different age ranges. Since social networks are moving towards becoming publishing platforms and many allow third party applications and integration, the project aims to achieve a safe and secure integration of DRM protected videos into social media. In fact, as now this kind of videos are accessible only from proprietary applications, after the payment of a subscription. The major challenges that prevent an easy integration of these technologies are represented by the poor APIs offered by social networks and a market fragmentation created by the existence of several DRM systems and Adaptive Bitrate protocols.
After an extensive analysis of video streaming technologies and social networks, we chose Facebook as social network of reference and we described both the backend architecture and the frontend requirements of a web application aiming to stream DRM protected videos in Facebook.
However, the solution has to face the following impediments: the impossibility to embed DRM technologies in social mobile platforms and to show protected video content directly from the social News Feed. To this extent, we proposed two alternative solutions by looking at the problem from the social network point of view.
Finally, in order to evaluate the quality and the utility of the proposed web application, we conducted a user experience test. The results pointed out a diffuse interest and appreciation.
However, the two drawbacks mentioned above are perceived as a negative factor. The proposed application results instead portable on all the desktop browsers and on the 90 percent of social mobile platforms.
D
EDICATION AND ACKNOWLEDGEMENTSThis thesis work is the conclusion of a Double Degree program between Politecnico di Milano and KTH. The whole project has been conducted in the Accedo offices (Stockholm), from September 2015 to February 2016.
I want to dedicate the project to all the members of my family: my brother, companion of life with his humor and vitality, and my parents, because I could not have done anything without the love and support that they have never failed to give me. I also want to thank my grandparents who are unique role models and point of reference with their strength and strong values, and my aunts, for the immense affection they have always given me in all these years, since I was a child.
All of you contributed to my growth and education, with your example and support, and I am really happy to celebrate this important achievement with you.
A special thank goes to all the people from the Accedo office, in which I spent six beautiful months.
In particular, I want to thank my technical supervisor Niklas Björkén for his helpfulness and support. I would also like to thank all the professor that I encountered during my academic career in Politecnico di Milano and KTH. In particular, my supervisors Marco Brambilla and Peter Sjödin, who have been a reference point for comparisons and suggestions for my final project.
Last but not least, an important thank goes to all my friends, who walked by my side in these years and shared with me wonderful and unique experiences.
T
ABLE OFC
ONTENTSPage
List of Figures ix
1 Introduction 1
1.1 Overview . . . 1
1.2 Motivation . . . 2
1.3 Problem statement . . . 3
1.4 Goals . . . 3
1.5 Proposed solution . . . 4
1.6 Methodology description . . . 5
1.6.1 Background study . . . 5
1.6.2 Design and implementation . . . 5
1.6.3 Analysis . . . 6
1.7 Thesis outline . . . 6
2 Analysis of Digital Right Management in video distribution 7 2.1 Why is DRM important? . . . 7
2.2 Functional architecture . . . 8
2.3 DRM system Architecture . . . 8
2.4 Different DRM vendors . . . 12
3 Background study 15 3.1 Social networks . . . 15
3.1.1 Facebook . . . 15
3.1.2 Twitter . . . 16
3.1.3 Tumblr . . . 17
3.1.4 Google+ . . . 17
3.2 Adaptive Bitrate streaming . . . 18
3.2.1 Background . . . 18
3.2.2 Different solutions . . . 19 3.3 Relevant standards for integrating DRM and Adaptive Bitrate protocols in HTML5 21
TABLE OF CONTENTS
3.3.1 CENC . . . 22
3.3.2 MSE . . . 23
3.3.3 EME . . . 23
3.4 JSON Web Token . . . 24
3.5 Related work . . . 25
4 Proposed solution 27 4.1 Video streaming opportunities in social platforms . . . 27
4.1.1 Desktop . . . 27
4.1.2 Mobile . . . 29
4.2 Limitations . . . 29
4.3 Proposed solution . . . 30
4.3.1 Facebook as social network . . . 30
4.3.2 Video player requirements . . . 31
4.3.3 Maintaining the playback status . . . 33
4.3.4 Application use cases . . . 33
4.3.5 Backend architecture . . . 35
4.4 Alternative solutions . . . 38
4.4.1 Improve the default video player . . . 38
4.4.2 Integration of external DRM-capable video players . . . 40
5 Implementation 41 5.1 Phoenix Framework . . . 41
5.1.1 Phoenix components . . . 42
5.1.2 Plug . . . 42
5.1.3 Ecto . . . 44
5.2 Data Model . . . 44
5.2.1 Database specifications . . . 45
5.3 Authentication: Guardian framework . . . 46
5.3.1 Guardian’s configurations . . . 46
5.3.2 Guardian’s plugs . . . 47
5.4 Fluidity . . . 48
5.5 Page dispatcher . . . 49
5.6 Video player . . . 49
5.6.1 Desktop . . . 49
5.6.2 Mobile . . . 50
6 Analysis 51 6.1 Portability test . . . 51
vi
TABLE OF CONTENTS
6.1.1 Results . . . 52
6.2 User experience evaluation . . . 52
6.2.1 Data collection . . . 52
6.2.2 User test description . . . 53
6.2.3 Data analysis . . . 53
6.2.4 Results . . . 55
6.3 Discussion . . . 62
6.3.1 Portability . . . 62
6.3.2 User experience . . . 62
7 Conclusion 65 7.1 Conclusions . . . 65
7.2 Future work . . . 66
7.3 Business, ethical and societal aspects . . . 67
A Appendix A 69
Bibliography 73
L
IST OFF
IGURESFIGURE Page
2.1 Functional architecture of a DRM system . . . 9
2.2 Overview of a DRM system architecture . . . 11
2.3 DRM systems supported by currently existing devices and platforms . . . 13
3.1 High-level view of an Adaptive Bitrate protocol . . . 19
3.2 Principal characteristics of currently existing Adaptive Bitrate protocols . . . 21
3.3 Browsers supporting MSE and EME standards . . . 22
3.4 Communication flow of JWT authentication . . . 25
4.1 Video streaming possibilities on social networks . . . 28
4.2 Backend architecture of the proposed solution . . . 36
5.1 Entity-Relationship diagram corresponding to the Data Model of the proposed applica- tion . . . 44
5.2 Sequence diagram showing how the session fluidity between two concurrent devices is handled . . . 48
6.1 Summary of the information related to the age, sex and profession of the survey respondents . . . 55
6.2 Graphical representation of the survey’ s answers related to social networks usage of the respondents . . . 56
6.3 Graphical representation of the survey’ s answers related to the video consumption habits of the respondents . . . 57
6.4 Graphical representation of the survey’ s answers related to the utility of the proposed application . . . 58
6.5 Graphical representation of the survey’ s answers related to the quality of the proposed application . . . 59
6.6 Histograms representing the survey’ s answers of the questions used to delineate user profiles, divided by group . . . 61
C
HAPTER1
I
NTRODUCTIONI
n this chapter we introduce the problem faced by our thesis project. First, we give an overview of the problem domain in section 1.1. Then, we state the motivations in section 1.2, the problem statement and the goals of the project in sections 1.3 - 1.4 and we present our solution in section 1.5. Finally we describe our methodology description in section 1.6 and we conclude with the outline of our thesis in section 1.7.1.1 Overview
A digital video is a set of binary information representing video content. Bits are easy to copy, transfer and store. These characteristics make digital video intrinsically unprotected because everyone can theoretically store, reproduce and duplicate them an infinite number of times, without any restrictions [10]. However, the video market is worth billions of dollars nowadays, and it is still growing rapidly [3]. Certain video have indeed a very high financial value which the respective owners obviously want to protect according to the Copyright law, in order to acquire the exclusive rights to publish and to reproduce them [10]. Consequently, the digital content has to be protected before its distribution, guaranteeing that users can watch the content only if correctly charged. The current way to handle video protection is through the use of Digital Rights Management (DRM), which is an access-control technology used by content holders to maintain the complete control over the usage of the owned resources [6].
Nowadays, protected video content is served through the Internet by correctly handling at the same time user authentication and DRM protection: after the payment of a subscription, the users are given authentication credentials to a so called "premium account", which consists in the on demand access to different video accessible exclusively from the service provider website or application.
CHAPTER 1. INTRODUCTION
Modern video providers support another important technology called Bitrate Adaptation, which is a technique that allows to adapt the quality of the transferred video to the network capabilities. However, for both DRM and Adaptive Bitrate protocols, the lack of an initial standard led different companies to develop proprietary protocols. Luckily, three important standards has been recently proposed: DASH, which is an Adaptive Bitrate streaming technique [16], EME, which defines a Javascript API enabling web applications to interact with content protection systems [34] and MSE, another javascript API enabling the streaming of fragmented video sources inside a browser [33]. Therefore, it is now possible to natively integrate DRM capable video players into HTML5 and get rid of external plugins, which otherwise would have to be added to video players in order to correctly handle each different DRM implementation. However, key systems and license management are still vendor free. So, what is happening nowadays is that each browser and platform SDK supports only the specific DRM system owned by the respective producer company [11]. In addition, another problem is that DASH standard is not supported by all platform yet.
The following trends lead to a market fragmentation which makes difficult to provide a video player able to stream protected content independently from the underlying platform and it certainly represents one important reason why this feature is not yet supported by social networks.
1.2 Motivation
Nowadays, there exist many service providers offering protected video content. Hence, especially for new companies that want to enter the market, it is difficult to improve their competitive advantage.
By looking at the following statistical research [30], it is possible to notice how fast the number of social network users is increasing worldwide. Surprisingly, not only young generations but also adults are attracted more and more by social platforms, whose usage is becoming universal: millennials and older generations are spending much time on social feed, most often from smartphones and tablets [5]. Furthermore, social networks are moving towards becoming publishing platforms, and many allow third party applications and integration. So, it’s easy to deduct that video service providers would be able to get more customers if their video content could be consumed inside social feeds as well, and consequently they would increase very much the differential advantage with respect to their direct competitors.
Due to the fact that DRM protected content is still completely dissociated from the social world, the purpose of the project is to understand how it is possible to integrate premium video resources into social streams, without loosing the desired level of protection.
2
1.3. PROBLEM STATEMENT
1.3 Problem statement
The problem faced in the thesis is to describe the requirements of an application that aims to integrate a platform independent video player able to stream DRM protected content inside a social network, given the state of the art technologies. In particular, the requirements of the video player are the following:
• Authentication: a user should be able to authenticate himself from the social network, possibly with the same credentials used in the service provider app or website
• Access control: the video player should support DRM allowing the usage of licenses, which guarantee to maintain access control over the owned resources.
• Encryption: the video player should support a key management system, which allow video decryption
• Portability: the video player should be used in all the different devices supported by the considered social networks
• Fluidity: if a user accesses the same video on two different devices, then the playback session should not be interrupted.
1.4 Goals
The goals of this project are the following:
1. Explore the opportunities offered by the current existing social media, with a focus on video streaming
2. Investigate the state of the art technologies adopted in video streaming and the techniques used to secure video distribution
3. Define the backend architecture of a video provider and the video player characteristics of an application aiming to satisfy the requirements listed in the above section.
4. Find out existing limitations of the actual social networks that could prevent the realization of such an application and propose interesting solutions for them.
5. Implement the aforementioned solution
6. Evaluate the proposed solution, analyzing in particular its portability and the perceived user experience
CHAPTER 1. INTRODUCTION
1.5 Proposed solution
The initial purpose of the project was to analyse social media in terms of video streaming and to define which is the best way to embed the above described video player. In particular, the video player requires:
• Support of adaptive bitrate protocol
• Support of DRM systems
• Rely on native HTML5 and Javascript technologies
The last choice has been made in order to create a modern solution that does not rely on external plugins such as Flash player and Microsoft Silverlight, since these plugins are being deprecated in the last versions of desktop and mobile browsers.
The following limitations came across the social media analysis:
1. It is impossible to embed a DRM-capable video player in any mobile applications of the current existing social networks.
2. The default video players of the current existing social networks do not provide an API in order to handle DRM natively. Therefore, the only way to adopt this technology into a social network is to import an external video player.
3. Only Facebook and Tumblr permit the integration of an external DRM-capable video player on the respective Desktop applications
With that in mind, we selected Facebook as social of reference, due to its higher popularity and its better user experience in terms of video sharing and distribution. Then, we described, implemented and analyzed the requirements of a web application integrated in Facebook that aims to overcome the mentioned impediments. The first key element is the presence of a URI that unequivocally represents each video resource. The second fundamental element is the presence of a Facebook Page, handled by a video provider that wants to publish his protected videos on Facebook. Then, for each video resource, a new post containing the respective URI is published, so that the users visiting the same page can be able to access it.
The behavior of our application and the characteristics of the embedded video player are different, depending on the requesting device:
• On desktop browsers, all the requests are redirected to a personalized Facebook Page Tab, where it is possible to embed external code through an <iFrame> HTML5 tag. The video player adopts DASH as Adaptive Bitrate protocol. Moreover, since desktop browsers implement the aforementioned standards EME and MSE, here it is possible to embed a DRM-capable video player.
4
1.6. METHODOLOGY DESCRIPTION
• On mobile platforms, since Facebook Page Tabs are not available, the video player is opened in an internal web page. However, EME and MSE are not supported yet by the current existing mobile browsers. Hence, the adopted Adaptive Bitrate protocol is HLS with AES-128 as encryption method.
The proposed solution gives also an high-level overview of a scalable backend architecture supporting authentication and distributing DRM licenses together with protected video packages in a geographically distributed environment.
Our application is able to reach the objectives that had been initially set. The only exception is represented by the mobile environment, in which DRM is not available. Therefore, as we detailed in section 4.3.2.2, on social mobile applications it is not possible to embed a DRM protected video, ensuring at the same time the above mentioned property of "Access Control".
1.6 Methodology description
To complete this project, we divided the study in three steps. We first conducted a background study on the relevant fields (4 weeks). After having identified the limitations imposed by the current social media, we designed and implemented an application aiming to solve the problem described in section 1.3 (10 weeks). Finally, we analyzed the user experience and the portability of our proposal (3 weeks).
1.6.1 Background study
We conducted a literature study, which consists in the analysis of the technologies directly related to the thesis topic. So, first we individuated among the existing social networks, which are the the most suitable for streaming protected content, by analyzing their functionality, their limitations and their target. Then, we compared the different DRM solutions and adaptive bit-rate protocols.
Finally, we described the characteristics of three recently proposed standards and we introduced an authentication method based on JSON web token.
1.6.2 Design and implementation
Given the results of the previous research, we identified the limitations affecting the current social networks. Then, we proposed and implemented a solution with the goal of streaming protected content into social networks. Finally, we looked at the problem from a social network point of view and we individuated two other possible solutions that could further improve the user experience.
CHAPTER 1. INTRODUCTION
1.6.3 Analysis
The final step corresponds to the analysis of the proposed solution. First we have tested its portability. Then, we evaluated the user experience by conducting a functionality test of the application collecting the opinion of 30 users through a questionnaire.
1.7 Thesis outline
In Chapter 2, we give a detailed description of DRM technologies. Then, in chapter 3 we in- vestigate the state-of-the-art technologies related to the other topics of the project. In Chapter 4 we present our proposed application and we also look at the problem from a social network point of view. Then, we briefly describe implementation details in Chapter 5, before analyzing its portability and user experience in Chapter 6. Finally, in Chapter 7 we draw conclusions from our work, we investigate potential future research and we discuss ethical, business and societal aspects related to our project.
6
C
HAPTER2
A
NALYSIS OFD
IGITALR
IGHTM
ANAGEMENT IN VIDEO DISTRIBUTIONI
n this chapter we want to describe Digital Right Management systems. Since this technology has a huge number of possible applications and it is used to protect both hardware and software solutions, we decided to consider only DRM applied to secure video distribution.First, we explain why it is needed in this particular scenario in section 2.1; then, we give an high level overview of its functionality and architecture in sections 2.2 and 2.3. Finally, we introduce the current existing solutions in section 2.4.
2.1 Why is DRM important?
As mentioned in section 1.1, it is easy to copy and reproduce digital content. Video market has a huge economical value and important actors are involved in this business: authors creating the video, producers and editors investing on the video distribution.
Thanks to the copyright law, content owners "acquire the monopoly of exclusive control of any form of performance (publicly exhibiting the content) and reproduction (duplicating the content on a physical medium) of their work" [10]. However, copyright infringement is a very diffused practice [26]. There are many criminal organizations acting both by selling fake goods (CD,DVD,Blue-Ray) and by illegally exchanging digital content over the Internet (through Peer to Peer networks or direct download sites).
Digital Rights Management is the means currently used by digital content owners in order to protect themselves from these threats. In particular, DRM technology is adopted to achieve the following goals [9]:
1. Access control to the asset: allow only authorized customers to access a specific content
CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTION
2. Protection of the asset: protect the content from theft, alteration or replacement. The tools used to avoid a misuse of the resources are encryption and digital signature mechanisms [13].
3. Use of forensics to trace the asset: ones an authorized user decrypts the content and renders it in the analog world, then encryption becomes useless. Digital watermark techniques make possible to insert hidden information about the rendering source in a video so that it is possible to recognize the responsible of eventual illegal distribution [7].
4. Scout to limit the illegal use of the asset: fingerprint techniques are used to detect and eventually stop the spreading of illegal content [10].
2.2 Functional architecture
Figure 2.1 shows the DRM’s functional architecture, which summarizes what exactly this tech- nology does from the content’s point of view. As we can see, DRM life cycle is divided into three main areas [35]:
• Content creation: Once a piece of content is created, the system needs to immediately define its usage rights, specifying read and write permissions for each user. Then, once a consumer decides to access a resource, DRM checks the validity of her credentials and decide to grant or not the permissions for the requested action.
• Content management: first of all, a DRM system needs to manage the repository containing all the protected content. Moreover, it has to manage payments to ensure that the owner will be payed for the usage of her resources. Last but not least, the content has to be encoded, encrypted and bound with the respective license so that it becomes ready for distribution.
• Content usage: once the content has been traded, the system must enforce that users are going to respect the granted rights. Moreover, in some applications it could also be useful to monitor the usage of a resource, by tracking users’ accesses.
2.3 DRM system Architecture
Distribution of protected content is a process involving several actors [27]. First of all, the Content Provider sends its content to a Distributor, which has the goal to protect the data and deliver them to the customers, together with the respective licenses. Then, there is a Financial Clearinghouse.
Its role is to take care of users subscriptions, to inform a so called Access Control Manager about the clients’ acquired rights, and to remunerate Distributor and Content Provider. Distributor is
8
2.3. DRM SYSTEM ARCHITECTURE
FIGURE2.1. Functional architecture of a DRM system
in turn in contact with the Access Control Manager, in order to correctly validate clients’ rights before delivering the content.
A DRM system needs also a solid architecture in order to fulfill the functionality reported in the section above. The Distributor can be subdivided into the following components:
• Content packager: it is the module responsible for encoding and encrypting the resources in formats compatible with client applications. Furthermore, the packager delivers the protected media to content servers and the respective keys to the license server.
• Content server: it delivers protected content to client applications. In real systems, instead of a single server, this module is composed by a content distribution network (CDN), which consist in a larger geographically distributed servers deployed in multiple data centers.
• License server: it delivers licenses to the clients, under the control of merchant server.
CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTION
Merchant server is the principal component of the Access Control Manager and it is respon- sible for handling client requests: it redirects subscription payments requests to the financial clearinghouse server, and it enforces the validity of authentication credentials and users’ rights at each subsequent request.
Another important component in the DRM life cycle is the software module that resides on the client machine. This client application handles authentication certificates and communication with the other DRM components. It is also responsible for enforcing the respect of user’s rights on the client. Therefore, it represents a critical point for a security point of view because it must guarantee tampering-resistant characteristics [14]. In fact, if a user was able to modify the client software in a malicious way, then all DRM protection would be completely lost.
Last but not least, there is a certification authority on top of the structure, which generates public-private keys and certificates needed to provide users authentication.
As shown in figure 2.1, the sequence of actions involved to ensure that DRM rights will obey the expected commercial rights are the following [10]:
1. The client authenticates to the service (section) and pays a subscription in order to acquire digital rights over a set of resources. The authentication is based on asymmetric cryptogra- phy: during an initialization phase, the client receives a public-private key and a certificate, which are used to digitally sign each message exchanged with the merchant server 2. The client sends a request to the merchant server for a specific resource.
3. The merchant server checks if the customer has the claimed rights to access that particular content.
4. If the a user’s rights have been verified, the content packager encrypts the content so that no attacker may access it without having the right key.
5. The license server receives the usage rights (together with some other auxiliary data) from the merchant server and the secret key used for encryption from the content packager.
Then, it encapsulate them into a data structure called "License".
6. The license is encrypted and digitally signed, in order to prevent malicious falsifications and tampering of user rights. Then, it is sent to the customer.
7. In the meanwhile, the content server receives a delivery order from the merchant server and sends the encrypted media content to the client.
8. Now, the DRM software running on the client has to guarantee that the usage rights declared in the license will not be bypassed. There are two software modules responsible for that: the "Right Enforcement" module receives the license and pass the usage rights to the "Right management" module, which verifies the validity and takes a decision.
10
2.3. DRM SYSTEM ARCHITECTURE
9. In case of positive decision, the decryption key is passed to the so called "Content protection"
module, which will send the clear data to the video player. Since the key is always hidden from the consumer, then it becomes very hard to decrypt the content a second time without acquiring a new license.
FIGURE2.2. Overview of a DRM system architecture
CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTION
The architecture described above is necessary to make a DRM system work. However, in nowadays solutions DRM vendors handle only license servers. Content packager and servers are usually controlled by other third-party providers or directly by the content owner. For this reason, clients will pay subscriptions to access the web and mobile applications of the content owner.
Then, the content owner has to conclude private economic agreements with distributors and DRM vendors in order to have all the described components securely communicating between each others.
2.4 Different DRM vendors
As in the case of adaptive bitrate protocols, a main issue is the lack of an initial DRM standard.
In the end of last century, the spreading of digital technologies created the need of an higher protection level, especially with regard to valuable media content. So, many publishers developed their own proprietary software to meet individual requirements. In this section we want to introduce which are nowadays the major DRM vendors:
• Google Widevine: It is currently available on more than 2 billion devices. It utilizes Common Encryption (CENC) and DASH standards as encryption and adaptive bitrate protocol.
Therefore, it is easy to integrate it in HTML5 using the MSE and EME standards mentioned in section 3.3.
• Microsoft PlayReady: It is available on Silverlight plugin, Internet Explorer browser and other different platforms, including smart TVs, blu-ray players, set top boxes and game consoles. It also supports DASH and CENC and it is therefore integrable in HTML5 thanks to the new MSE and EME standards.
• Adobe Access: It is the DRM solution adopted only by Adobe media players and it is not embeddable in HTML5 with the current standards. It supports both on the Adobe HTTP dynamic streaming and HLS adaptive bit rate protocols.
• Apple Fairplay: It is the only DRM supported in Apple devices and it is based on HLS adaptive bitrate protocol.
The coexistence of many solutions makes it difficult to build a platform-independent video player supporting DRM. In fact, the same companies offering DRM solutions also develop elec- tronic devices, browsers, video plugins and operative systems. This has generated a market fragmentation where devices and platforms support most of the time the specific DRM im- plemented by the respective owner. Therefore, in order to run on all different platforms, an application has to support all DRM systems together. Furthermore, the adaptive bit rate protocol supported by the different systems are different and not all the DRM are still compatible with the new standard DASH mentioned in the section above.
12
2.4. DIFFERENT DRM VENDORS
Figure 2.3 describes the native DRM support in the current existing platforms.
FIGURE2.3. DRM systems supported by currently existing devices and platforms
C
HAPTER3
B
ACKGROUND STUDYT
his chapter aims to give a deeper background on the technologies used in the project.First, we carry out an analysis of the existing social networks in section 3.1. Then, in sections 3.2 we give a deeper description of Adaptive Bitate protocols, explaining why they are needed and how they work. Then, in section 3.3 we describe three other important standards facilitating the integration of DRM and Adaptive Bitrate protocols in HTML5. In the end, in section 3.4 we look at an authentication method based on JSON Web token and in section 3.5 we analyze other related works from the literature.
3.1 Social networks
The following research lists the top-10 social networks [12], ordered by the respective number of registered users. Since the project wants to examine possible ways to integrate video premium content into social media, we decided to analyze, among those, only the ones providing video streaming and sharing. The analysis focuses on the functionality offered by each social network and their target.
3.1.1 Facebook
Facebook is an online social networking service headquartered in California. The first version dates back to 2004. In 2006 it was extended worldwide, and nowadays it represents the social network with the highest number of users.
After registration, users can create a personalized Profile containing photos, images, video, lists of interests and other personal information. They can add other users as "Friends", creating a sort of virtual network with them. It is also possible to privately exchange text messages
CHAPTER 3. BACKGROUND STUDY
and multimedia files with friends through an integrated chat and to publish "Posts", which are personal status composed by text, links, audio and video content. On mobile platforms, links to external pages are opened in the operative system browser: Facebook presents a internal web page preventing the user to leave the application in order to visualize the content. Moreover, each user has access to the so called "Timeline", which is a web space containing personal posts and profile information and to a "News Feed", where all friends’ posts and updates are showed real time in chronological order.
Facebook Pages are another important element of the social network. They allow public figures, businesses, organizations and other entities to create a space which becomes public on Facebook: its content is accessible to any user and it is not possible to modify privacy settings as on a user Profile. Facebook Pages are provided with a "Like" button, that can be selected by users who like the Page and want to receive updates in their News Feed. Furthermore, it is possible to enrich a Facebook Page by adding "Page Tabs", which are extensions containing third party content from another domain: through the use of an <iframe> tag, external web pages can be added and displayed inside the Facebook Page. However, Page Tabs have a limitation: they are not supported on mobile platforms.
Facebook also allows integration of external content into the social graph, thanks to the OpenGraph protocol [? ]. This protocol defines the semantic of meta information in a web page in order to accurately represent the page’s content when it is linked to from a Facebook post.
Video, audio, contact information, locations and other elements are interpreted and displayed automatically, if correctly described in the linked page. So far, it is not possible to link to an external reproducer, but only to the source content.
3.1.2 Twitter
Twitter is a free social network and microblogging platform, created in 2006 by Obvious Corpora- tion in San Francisco. Right after its creation, the sole functionality provided by Twitter was to send and read short 140-character messages called "tweets". Each user could decide to "follow"
other users, which means to receive notifications about their tweets.
Nowadays, the API has been extended: in addition to text, a Tweet can be enriched with a picture, a video or a link. On mobile versions, links pointing to external content are opened inside the social network, without leaving the application. Another feature recently provided by Twitter is the integration of the so called "Twitter Cards": similarly to the Open Graph protocol described above, by enriching content of a web page with particular HTML meta-tags, users who Tweet links to that specific content will have a "Card" added to the Tweet, which becomes visible to all their followers. A card has three different specializations, depending on the represented content:
• Summary card: it can be used to present blog posts, articles, locations (i.e. restaurants or hotels), and other kinds of web content. It is a preview which presents to the reader a specific content before linking to a specific external website.
16
3.1. SOCIAL NETWORKS
• App card: it is a mobile application representation that allows for a name, an icon, a description and other specific attributes. It is used to advertise the app and drive directly the users to installs in the proper application store.
• Player card: unlike Facebook, it allows to embed a audio or video player provided by an external website into a Tweet. The only condition is that the video player and the respective content have to respect certain policies dictated by Twitter [31], otherwise it will not be approved and consequently not Tweeted.
3.1.3 Tumblr
Tumblr was created in 2007 and acquired by Yahoo in 2013. It is a microblogging platform, offering users the opportunity to create a personal blog. It can be considered also a social network because it allows users to create "connections" between each other, which means to receive notifications about posts or updates of other selected blogs. The provided interface permits to enrich posts with different kind of content: text, citations, links, pictures, audio, video can be added together, reaching stylish results with a minimum effort. As Twitter and Facebook, on mobile versions links pointing to external content are opened inside the social network, without leaving the application. Furthermore, instead of using the integrated presentation framework, it is possible to personalize the style of posts using a HTML editor. Thanks to the <iframe> tag is then possible to embed external HTML code inside a post. However, this functionality is not supported on mobile platforms.
3.1.4 Google+
Google+ is a free social network, launched in 2011 by Google. After creating his own profile, a user can add other contacts, creating a virtual connection with them. These connections can be grouped into "Circles", which are interest based communities (e.g. family, friends, office colleagues, etc...), so that it is possible share updates selectively with the different groups. An update can represent a combination of the following elements: a simple text, a video, a photo, a link to an external website, an event or a poll. Pictures and video can be uploaded directly from the device or respectively from Google Images and Youtube, which are integrated with the social network.
This means that Google+ does not offer the opportunity to embed external content, unless it comes from the above mentioned sources.
Businesses are also allowed to be part of the social network, thanks to the concept of Google+
pages. Public entities such as organizations, companies, and public associations can set up their profile and post news, information or events about their activities. Pages are completely integrated with other Google services; however, unlike Facebook Pages, it is not possible to create a personalized space embedding HTML code from an external source.
CHAPTER 3. BACKGROUND STUDY
3.2 Adaptive Bitrate streaming
Given the increasing popularity of video delivery platforms [32], the reliability and the quality of content provider services has become, in turn, really important. In this section we want to introduce Adaptive Bitrate technology, which has given a large contribution to improve video streaming over the Internet: first we describe the high level principles that all different implementations have in common, then we present an overview of the currently existing solutions.
3.2.1 Background
The unpredictable nature of data transport and latency on the Internet can generate cases of network congestion. This has negative effects for the user experience, especially in a video streaming scenario: if the bandwidth decreases, then the packets reception will be slowed down and consequently the buffers on a video player will starve, resulting in a pause for more data to refresh the buffer.
Adaptive Bitrate streaming consists in the adaptation of the quality of a video source to the user’s available bandwidth. Thanks to this technology, the player is able to periodically analyze the underlying network conditions and switch among different bit rate segments accordingly, avoiding as much as possible annoying video interruptions. The result is a lower video initialization time, minimal buffering and a good experience regardless of the bandwidth speed. Furthermore, stream switching is usually seamless to the viewer.
Figure 4.1 shows how Adaptive Bitrate streaming works:
1. Each video source is encoded at different bit rates, and then each of the different bit rate streams are segmented into small chunks, whose length can vary between 2 and 10 seconds.
These resources are then loaded on the server.
2. A XML-based manifest file is also generated. It contains all the information about the video: the catalog of the different encoded video and audio sources and bit rates, the source URL, subtitles if present, content protection alternatives and other details. However, each adaptive bit rate protocol provides its own format to describe these information.
3. Each client accessing a particular video, receives the manifest and requests the video segments, starting from the lowest bit rate stream. To access the different video chunks, the users periodically send HTTP requests including a "Byte Range" header, which indicates the desired range of bytes.
4. The client’s video player checks if the download speed exceeds the initial bit rate. In that case it will request the next higher bit rate segment from the manifest.
5. This comparison is done periodically so that the video will always play at a bit rate which is as close as possible to the user’s bandwidth.
18
3.2. ADAPTIVE BITRATE STREAMING
FIGURE3.1. High-level view of an Adaptive Bitrate protocol
3.2.2 Different solutions
As reported in the following book [25], streaming technology were mainly developed in the end of the 20th century, although attempts to display media on computers were done in the earliest days of computing. The factors that mostly encouraged their development are: an im- provement of networks bandwidth and devices hardware capabilities, the Internet invention and the standardization of new communication protocols such as TCP/IP.
The importance of adaptive bit rate protocols was clear from the early stages and, in fact, the first attempts date back to 1996, when RTP protocol was standardized in conjunction with RTSP [28] [29]. The former is a transport protocol to carry audio and video packets over IP. The latter is a protocol allowing clients of media servers to control the session and the playback of video on the server by issuing command messages such as play and pause, etc. More recent solutions are
CHAPTER 3. BACKGROUND STUDY
based HTTP protocol instead. The main advantage of adopting HTTP-based technology is that specific streaming servers running an alternative protocol are not required anymore; Therefore, all the logic needed to switch between different bit rates and all the video playback controls resides on the player.
However, the lack of an initial standard led to the creation of different proprietary protocols:
• Adobe HTTP Dynamic Flash Streaming: it is the adaptive bit rate protocol created by Adobe and adopted only by Flash video players after the 10th release. It enables on-demand and live video delivery of fragmented MP4 media.
• Microsoft Smooth Streaming: it is the adaptive bit rate protocol created by Microsoft. It is supported by all the video players adopting Microsoft Silverlight plugin, but it is also natively supported on Windows 10, XBox, Windows Phone, iPhone, iPad and STBs(Set-top Boxes). The media files of Microsoft Smooth Streaming are also based on fragmented MP4 videos.
• Apple HTTP Live Streaming: it is a widely used adaptive HTTP streaming protocol available as IETF Internet Draft. It is mostly supported by mobile devices based on iOS like iPhone, iPad or AppleTV, but also Android decided to adopt it after version 3.0. If supported by the underlying operative system, HLS can be also integrated into HTML5 browsers through the <Video> tag by directly calling the OS APIs. That’s why Safari and the Android browser implement it natively. In addition, HLS specifies a standard AES encryption and secure key distribution based on HTTPS. The accepted video format is MPEG-2 Transport Stream.
• MPEG DASH: it is the only adaptive bit rate protocol based on an open IETF international standard [16], proposed as an attempt to solve the complexities of media delivery to multiple devices. Nowadays the devices supporting MPEG-DASH are: Android, Windows phone, ChromeCast and the newer smart TVs. As HLS, MPEG-DASH isn’t directly supported in HTML5 but there are many JavaScript implementations which allow to use it in web browsers thanks to MSE standard (section 3.3.2). MPEG-DASH segments can contain any media data, however the recommended ones are ISO base media file format (e.g. MP4 file format) or MPEG-2 Transport Stream.
Figure 3.2 summarize the principal characteristics of the different protocols. As we can notice, it doesn’t exist an adaptive bit rate protocol universally supported. The actual trend is to follow the new international standard DASH and move away from Flash or Silverlight-based players, which indeed are being gradually deprecated. However, this process is slow and it will take time until all platforms will decide to switch to the same protocol.
20
3.3. RELEVANT STANDARDS FOR INTEGRATING DRM AND ADAPTIVE BITRATE PROTOCOLS IN HTML5
FIGURE3.2. Principal characteristics of currently existing Adaptive Bitrate protocols
3.3 Relevant standards for integrating DRM and Adaptive Bitrate protocols in HTML5
In this section we want to give a high level description of other three recently proposed standards facilitating the integration of DRM and Adaptive Bitrate protocols in HTML5, which are very important in order to create a platform-independent video player with adaptive bit rate streaming and DRM protection capabilities. The first subsection considers CENC, a standard defining a common encryption scheme. The others are two HTML5 extensions: MSE and EME. Being
’extensions’ means that they are not required for HTML specifications compliance. So, since the browser support is optional, we choose to show in figure 3.3 which browsers currently support them.
CHAPTER 3. BACKGROUND STUDY
FIGURE3.3. Browsers supporting MSE and EME standards
3.3.1 CENC
As mentioned in the above section, there are several DRM systems operating on the market and it’s up to them to decide how to encrypt licensed files. However, if they all decided to adopt different encryption mechanisms, for a video provider it would be necessary to replicate the same content multiple times and apply to each copy a different encryption method to be in line with all the requirements.
Common Encryption (CENC) is a W3C standard defined in order to overcome this problem.
Its scheme specifies a "standard encryption and key mapping methods that can be utilized to enable decryption of the same file using different digital rights management and key management systems" [15]. Moreover, it defines a common format for the related metadata necessary to decrypt
22
3.3. RELEVANT STANDARDS FOR INTEGRATING DRM AND ADAPTIVE BITRATE PROTOCOLS IN HTML5
the protected streams.
Hence, content providers conforming to this standard can encrypt their sources once per container/codec and use it with many Key Systems. On the other end, DRM systems have to provide the right key by using ’cenc’ key identifier (KID). However, even if the encryption method is standardized, it’s still up to the DRM system to decide how to handle other important aspects (key storage, acquisition and location, right mappings, etc).
In order to distinguish between the applicable DRM systems, each ISO Base Media file encrypted according to the CENC standard has to present a so called "Protection System Spe- cific Header box" (pssh), containing DRM information such as licenses or rights acquisition information. Each ’pssh’ instance corresponds to one specific DRM system.
3.3.2 MSE
By simply providing the URL of a video source, it is very easy to load, decode and play media in HTML5, thanks to the HTMLMediaElement.
<video src=’videoName.webm’></video>
However, HTML5 video tag still has some limitations: streaming is not supported and it is difficult to customize the video controls consistently across different browsers. There are applications like adaptive bitrate streaming, ad-insertion or video editing in which a more fine-grained control over the media source is needed. In these kinds of scenario, in fact, the video is not directly provided but it has to be rebuilt for playback from various video segments.
Media Source Extensions (MSE) is a W3C standard editor’s draft with the goal of "extending the HTMLMediaElement to allow JavaScript to generate media streams for playback" [33]. This won’t directly solve the HTML5 deficiencies, but it defines a Javascript API which permits to build a universal browser player technology by pushing audio and video into the media tags, independently on how the media are fetched. Furthermore, MSE defines a buffering model to describe how the Javascript software should act when different media segments are appended at different times.
3.3.3 EME
Another limitation of HTML5 <video> tag is that it does not support DRM and data encryption.
Encrypted Media Extensions (EME) is a W3C standard editor’s draft specification enabling web applications to interact with content protection systems and to allow playback of encrypted audio and video. [34]. EME defines a common Javascript API that simplifies discovery, selection and interaction with such systems, enabling a video player to stream the same protected content in any browser, without the need for third-party media plugins like Adobe Flash or Microsoft Silverlight. The media files have to be encrypted according to the Common Encryption standard, described in the section above.
CHAPTER 3. BACKGROUND STUDY
EME needs to interact with the following components:
• Key System: is a generic term for a decryption mechanism and/or content protection provider, identified by a unique String. Apart from Clear Key (see below), the standard does not specify any particular key system.
• Content Decryption Module (CDM): the client-side software or hardware component which decrypts, decodes and enables playback of encrypted video content. EME provides an interface for javascript applications to interact with available CDMs. Usually CDMs are provided by DRM vendors.
• License server: interacts with a CDM to negotiate DRM licenses
• Content server: provides the media content, encoded and encrypted according to the CENC standard.
The interaction with a CDM is not required for compliance to the standard specifications. The only mandatory requirement for all browsers supporting EME is the so called "Clear Key". This is a very simple system in which a media file can be decrypted by providing the same key used for encryption. The key can be specified inside the manifest file or it can be built into the browser.
Clear key is fully interoperable across all browsers supporting EME but it is not used to protect commercial content, due to its poor protection level.
3.4 JSON Web Token
JSON Web Token (JWT) is an open IETF standard used to pass security information between two parties over the Web, typically a client and a server [18]. It is divided in three sections, all of them are Base64 encoded and separated with dots.
1. Header: contains information on the type (always "JWT") and the hashing algorithm 2. Payload: contains all the information that the two parties need to transmit, expressed as
key-value couples.
3. Signature: contains the hash of header and payload obtained by using a secret key. The signature is important because it guarantees that no one else can tamper the contained value without knowing the secret key.
The information contained in the payload can be decoded by anyone. So, if the two parties want to maintain their communication secret, the token should be also encrypted before being delivered over the Internet.
JWT are mostly used for authentication purposes in single sign-on context, in which a user can authenticate himself to many different services by using the same token, until its expiration time. The communication flow is illustrated in figure 3.4 :
24
3.5. RELATED WORK
FIGURE3.4. Communication flow of JWT authentication
1. The client provides user credentials
2. The authentication server checks the validity of the credentials and creates a valid JWT 3. The server sends the JWT to the client
4. The client verifies the token and stores it
5. At each subsequent request, the client attaches the same persisted token in order to authenticate himself
6. The server verifies the validity of the received token at each subsequent request
7. The server returns "OK" message, or throws an error in case the received token is not valid
3.5 Related work
As mentioned in section 1.2, DRM has always been object of research for big companies willing to protect their valuable contents. Therefore, there are not industry-wide standards for this technology. However, noteworthy researches on topics related to the DRM technology have been published: Lin et al. described new methods for providing security, including the roles of encryption and video watermarking [21], Kundur et al. proposed a novel architecture for joint fingerprinting and decryption [19]. W3C has also maid important works with the standardization of the aforementioned EME, MSE and CENC standards.
On the other hand, DRM is also object of much criticism. The first reason is that users do not perceive it as a positive element and they often tend to prefer free software content. Moreover, breaking software licenses is still a diffuse practice and piracy and illegal distribution of protected content represent nowadays a huge market. Hence, all the economic resources used to adopt DRM protection are virtually lost as soon as the content is broken once, since in that case the access control over a specific resource will be lost forever. For example, Daniel James expresses in
CHAPTER 3. BACKGROUND STUDY
his article the opinion that preventing the copying of bits is futile and ultimately destructive to the goal of any modern digital business [17]. Stepen Lewis also agrees with this line of thinking and proposes other market mechanisms to protect Copyright holders as alternative to strong DRM protection [20].
Michalko et al. instead looked at the problem of protecting video streaming in mobile devices [23]. They designed an architecture to stream protected content to mobile devices, using some of the well-known technologies and standards as well. However, no work assessing the integration of actual DRM systems in social media has been found. Therefore, the solution presented in the following sections contains somehow innovative concepts for this specific field.
26
C
HAPTER4
P
ROPOSED SOLUTIONI
n the following chapter we analyze how the goal of streaming protected video content into social networks could be feasible. In section 4.1 we start with a summary of the possibilities offered by the current social platforms in terms of video streaming. Then, in section 4.2 we point out possible limitations preventing an easy integration of DRM technologies into social media. Finally, we describe in section 4.3 the characteristics of a web application embedded in Facebook and aiming to overcome the encountered problems and in section 4.4 we look at other two valid alternatives from the social network point of view.4.1 Video streaming opportunities in social platforms
Given the theoretical background of the previous chapter, we want to look into the details of what the current social media offer in terms of video streaming. More specifically, we focus the analysis on protected video content. We decide to separate mobile and desktop environments and explain in the details what each social network allows to do on the different platforms.
4.1.1 Desktop
All the analyzed social networks present their default video player. Videos added by users are reproduced within this video player, which is portable over all the existing browsers. However, a common characteristic between the different social media is that their players do not implement MSE and EME standards and therefore they are not capable to correctly handle DRM inside the social feed. However, some of the mentioned social networks present slight differences in terms of video streaming policies and technologies:
CHAPTER 4. PROPOSED SOLUTION
FIGURE4.1. Video streaming possibilities on social networks
• Facebook: In order to add flexibility to its platform, Facebook allows the customization of Page Tabs. As previously mentioned in section 3.1.1, a Tab consists in a web space showing external web content. This means that an external video player supporting DRM protection can be embedded and accessed after authentication inside a Facebook Page, without leaving the social network. The authentication to the external video provider can be through Facebook login button and/or custom authentication methods (by sending username and password).
• Twitter: Twitter has recently introduced the concept of Player Card, which allows the users to embed a media player provided by an external website into a Tweet, thanks to the <iFrame> HTML tag. However, to prevent users from improperly inserting random content instead of a real media player, Twitter applies a validation process: once a player card is posted, the Twitter approval team has to manually approve its content, before make it public on the social network.
Technically, this solution would be perfect to solve our problem, because a user could be able to integrate into the social feed an external video player with the desired characteristics.
However, there are specific policies preventing it: first of all, users "do not have to be required to sign-in to the card experience" [31]. Then, "Cards should have the same quality experience across all platforms where Cards are displayed", which, as we pointed out in the
28
4.2. LIMITATIONS
section below, it is not possible since on mobile browsers it cannot exist a native DRM video player.
• Tumblr: On Tumblr it is possible to personalize the style of posts using an HTML editor.
This means that an <iFrame> could embed an external video player supporting DRM protection inside a Tumblr post, without leaving the social page.
• Google+: on Google+ the only way to reproduce videos is by using the standard video player, since it does not allow the users to embed any external code.
A new trend for social networks is to make private agreements with important video providers and embed their respective video players into the social app. The integration is very simple from the user perspective: by adding a link to an external resource of the video provider, the respective video player is automatically embedded inside an <iFrame> and showed in the social feed as content of the post. Google+ allows Youtube video integration. In addition to Youtube, Tumblr and Facebook allow Vimeo video player to be embedded. Twitter is the more complete in this sense and integrates also the Vime’s video player.
This feature would be useful to our cause if the video players of the external providers were able to handle DRM protected content. However, unfortunately this is not the case.
4.1.2 Mobile
On mobile platforms, there are not substantial variations in the video experience on the different social networks: once the playback of unprotected video starts, the default video player opens a new view page and reproduces the video content full screen. The major difference with the desktop environment is that the applications are native and they are not executed into a browser environment. Therefore, in order to stream DRM protected content on mobile platforms the provided video player should adopt the native technologies offered by the respective operative system, as we previously mentioned in sections 3.2.2 and 2.4. However, as now these solutions have not been implemented by any of the current social media: their default video players are simple and they can only reproduce unprotected videos.
Moreover, with a further analysis we can notice that also the browsers supported by the current mobile platforms are not DRM-capable, because no one of those supports yet the new standards proposed in section 3.3.
4.2 Limitations
After the detailed analysis of the sections above now we want to answer the following question: is it possible to achieve the goal of embedding a video player with the characteristics listed in section 1.3 into any of the current existing social networks?
Given the current technologies, we can state that there are evident limitations:
CHAPTER 4. PROPOSED SOLUTION
1. It is not possible to embed a video player capable to handle DRM systems into any of the existing mobile versions of the currently existing social networks.
2. The current social media are not provided with an API implementing EME and MSE standards in their default video players. This problem prevents a native integration of DRM systems.
3. Only Facebook and Tumblr permit the integration of a DRM-capable video player on the respective Desktop applications, by importing external code through the <iFrame> tag. The other mentioned platforms do not provide this functionality and therefore they are not able to satisfy our requirements.
4.3 Proposed solution
This section presents the details of a web application that aims to solve our problem and to reach the goals stated in section 1.4. Initially we want to explain and justify a set of important choices that we made in the design phase of our proposed solution and that allowed us to partially solve the aforementioned limitations. Then, the discussion continues with a more detailed analysis of the application use cases and the backend architecture needed to support video distribution in such a scenario.
4.3.1 Facebook as social network
We decided to embed the proposed Web Application in Facebook. We chose Facebook as a reference social network because it allows the integration of an external video player. Therefore, this choice avoids the introduction of the aforementioned limitation number 3. According to our analysis, Tumblr could be another available option. However, after an initial approach we decided to utilize Facebook, due to its higher popularity and its better user experience in terms of video sharing and distribution.
As we detailed in section 4.1 the deficiencies of the Facebook standard video player prevent an integration of protected videos directly inside the Timeline. That’s why, in order to provide a proper functioning of the proposed application, the content owner needs to create and handle a personal Facebook Page. The key feature of Facebook Pages is that they allow to edit and add new
"Posts", so that all the users following the same Page will receive a notification in their personal News Feed.
An important prerequisite for our proposed application is to assign a unique URI for each single video content. That said, the content provider should create a corresponding Post for each single piece of video resource. The overall Post serves as an advertisement for the real content and it may present the following information, which can be manually added by the Facebook Page administrator or with the help of "Opengraph" protocol (see section 3.1.1):
30
4.3. PROPOSED SOLUTION
• Short description of the content
• Unique link pointing to the specific resource
• Video trailer or picture
In section 3.1.1 we pointed out the differences of Facebook Pages between mobile and desktop versions: in the desktop version of Facebook it is possible to create custom "Page Tabs" and personalize their content through the <iFrame> tag. In the mobile version, Facebook Pages are much simpler and they do not provide this feature. However, on mobile all the links are opened by default on an internal web view, without leaving the social network. Therefore, our decision is to detect the requesting device at each subsequent request and adapt the response content accordingly:
• if the detected requesting device is a desktop browser, the application backend will redirect the user to the customized Facebook Page Tab.
• if the detected requesting device is a mobile application, the content will be opened directly in the Facebook internal web view.
This solution allow us to import external code into both desktop and mobile Facebook versions.
Hence, in both platforms we can import a different videoplayer, solving the second limitation of section 4.2.
4.3.2 Video player requirements
In this section we just want to analyze the differences between the imported videoplayers from a technical point of view, respectively on desktop and mobile platforms.
4.3.2.1 Desktop platforms
The decisions that we made for the videoplayer embedded in the desktop version are the following:
• DASH as Adaptive Bitrate protocol
• DRM as video protection technology
The main reason for these choices is to achieve DRM protection, extending at the same time the portability of the application to the maximum extent possible.
In section 3.3 we showed that all the current browsers support MSE and EME. Hence, with the help of these recent standards, the combination of DRM and DASH technologies become available on all the existing browser platforms. However, as we described in section 2.4, it is important to notice that our application needs to support all the major DRM providers in order to be compatible with all the existing browsers.
CHAPTER 4. PROPOSED SOLUTION
4.3.2.2 Mobile platforms
Given the optimal aforementioned solution for desktop applications, a logic conclusion could be to adopt exactly the same technologies in mobile platforms. However, in section 3.3 we showed that mobile browsers do not support yet MSE and EME standards. Hence, it is clear that it is impossible to overcome the aforementioned limitation number one, given the actual technology status.
For this reason, on mobile platforms we are forced to relax the full DRM requirement, trying to find the best possible compromise. The proposed solution utilizes HLS as Adaptive Bitrate protocol with AES-128 encryption (see section 3.2.2 for further details). This protocol is supported by both the Android stock browser and Safari for mobile, but it is not compatible with the mobile version of Internet Explorer.
From a security point of view, the differences between HLS with AES encryption are the following:
• In HLS with AES, the decryption key is retrieved by establishing a secure connection. So, only the receiver is able to retrieve the key and no one intercepting the communication can have access to it. However, the decryption is handled by native Javascript code. Hence, an expert and malicious user could eventually retrieve the key by exploring the Javascript code on the client. For a video provider this kind of scenario should be avoided, since the ownership on the video content would be lost. Consequently, the property of "Access Control" mentioned in section 1.3 cannot be reached in such a scenario.
• In chapter 3 we explained how DRM works. Basically the main difference is that the user receives a license containing the decryption key plus other information related to the usage rights. However, no one knows how these information are encoded into the license. That’s why there must be a so called Content Decryption Module (CDM) inside the browser, which is a piece of software with the function of verifying the user rights validity and eventually pass the decrypted video chunks to the video player. In that way, providing that the CDM is secure, no one can be able to decrypt the content a second time without acquiring a new license.
For some video providers full DRM protection is a strict requirement. So, to make the proposed application available on mobile platforms they have to wait until all the mobile browsers will include EME and MSE standard in their API specifications. However, as we mentioned in section 3.5, there are also opposite opinions which criticize the effective DRM security level. Moreover, handling all the license systems is expensive and not all the video providers can afford such an expense. For these reasons, some video providers HLS with AES-128 is considered good enough.
In fact, this solution is currently adopted by some provider in their own platforms.
32
