Embedding Premium Video in Social Streams

EXAMENSARBETE INOM TEKNIKOMRÅDET 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

ABSTRACT

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 ﬁnancial Dvalue 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.

DEDICATIONANDACKNOWLEDGEMENTS

This 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.

iii

TABLEOF CONTENTS

Page

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 distribution7 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

v TABLEOFCONTENTS

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 speciﬁcations...... 45 5.3 Authentication: Guardian framework...... 46 5.3.1 Guardian’s conﬁgurations...... 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 TABLEOFCONTENTS

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

vii

LISTOF FIGURES

FIGURE 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 ﬂow 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 application...... 44 5.2 Sequence diagram showing how the session ﬂuidity 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 proﬁles, divided by group...... 61

ihu n etitos[ restrictions any without . Overview 1.1 iia ie sasto iayifrainrpeetn ie otn.Bt r ayt copy, to easy are Bits content. video representing information binary of set a is video digital A h ndmn cest ifrn ie cesbeecuieyfo h evc rvdrwebsite provider service the from exclusively accessible in application. video consists or different which account", to "premium access the called demand subscription, so on a a the of to payment credentials the authentication after given protection: are DRM users and authentication user time same the [6]. resources owned the maintain of to usage holders the content over Rights by control Digital used complete of technology use the access-control the if an through only is is content which protection the (DRM), video watch Management handle can to way users current that The guaranteeing charged. distribution, correctly its before [ protected them acquire reproduce be to to to order and in publish law, to Copyright rights the exclusive to according the protect to want obviously owners [ respective rapidly times, growing still of is number it infinite and an them duplicate and reproduce because store, unprotected theoretically intrinsically can video digital everyone make characteristics These store. and transfer we 1.7. and section 1.6 in section thesis in our description of methodology outline our the describe with we conclude Finally 1.5 . section in solution our I oaas rtce ie otn ssre hog h nentb orcl adigat handling correctly by Internet the through served is content video protected Nowadays, adw present we and 1.4 - 1.3 sections in project the of goals the and statement problem the 1.2, hscatrw nrdc h rbe ae yortei rjc.Frt egv an section give in motivations we the First, state project. we Then, thesis 1.1. our section by in domain faced problem problem the of the overview introduce we chapter this n 10 .Hwvr h ie akti ot iloso olr nowadays, dollars of billions worth is market video the However, ]. 3 .Cranvdohv nedavr ihfiaca au hc the which value financial high very a indeed have video Certain ]. 1 10 .Cneunl,tedgtlcnethas content digital the Consequently, ]. I NTRODUCTION

C HAPTER 1 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 deﬁnes 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 speciﬁc 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 difﬁcult 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 difﬁcult 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. Deﬁne 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

3 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 deﬁne 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 ﬁrst 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 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 descriptionTo 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 studyWe 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 implementationGiven 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.5 CHAPTER 1. INTRODUCTION1.6.3 AnalysisThe 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 outlineIn Chapter 2, we give a detailed description of DRM technologies. Then, in chapter 3 we investigate 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 ti ayt oyadrpouedgtlcnet ie akthsa has market Video content. digital reproduce and copy to easy is it 1.1, section in mentioned As C,V,leRy n yilglyecagn iia otn vrteItre truhPeer (through Internet the over content digital exchanging illegally by and (CD,DVD,Blue-Ray) ie,pouesadeiosivsigo h ie distribution. video the on investing editors and producers video, rtc hmevsfo hs het.I atclr R ehooyi dpe oaheethe achieve to adopted is [9]: technology goals DRM particular, following In threats. these from themselves protect sites). download direct or networks Peer to [ the [ work" (duplicating practice their diffused reproduction of and medium) physical content) a the on exhibiting content (publicly performance of form any the creating authors business: this in involved are actors important and value economical huge important? DRM is Why 2.1 introduce high we Finally, 2.4. an 2.3. section give and in we 2.2 solutions then, sections existing 2.1; in current section architecture the in and scenario functionality particular its this of in overview needed level is it why explain we First, I Acs oto oteast lo nyatoie utmr oacs pcfi content specific a access to customers authorized only allow asset: the to control Access 1. iia ihsMngmn stemascretyue ydgtlcnetonr nodrto order in owners content digital by used currently means the is Management Rights Digital of control exclusive of monopoly the "acquire owners content law, copyright the to Thanks otaesltos edcddt osdrol R ple oscr ie distribution. and video hardware secure both to applied protect DRM to only used consider is to it decided and we solutions, applications software possible technology of this number Since systems. huge Management a Right Digital has describe to want we chapter this n A 26 AYI OF NALYSIS .Teeaemn rmnlognztosatn ohb eln aegoods fake selling by both acting organizations criminal many are There ]. D IGITAL 7 10 .Hwvr oyih nrneeti very a is infringement copyright However, ]. R IGHT M NGMN NVIDEO IN ANAGEMENT DISTRIBUTIONC HAPTER 2 CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTION2. 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 architectureFigure 2.1 shows the DRM’s functional architecture, which summarizes what exactly this technology 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 ArchitectureDistribution 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 is8 2.3. DRM SYSTEM ARCHITECTUREFIGURE 2.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.9 CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTIONMerchant server is the principal component of the Access Control Manager and it is responsible 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 server2. 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 ARCHITECTURE9. 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.FIGURE 2.2. Overview of a DRM system architecture11 CHAPTER 2. ANALYSIS OF DIGITAL RIGHT MANAGEMENT IN VIDEO DISTRIBUTIONThe 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 vendorsAs 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 implemented 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 VENDORSFigure 2.3 describes the native DRM support in the current existing platforms.FIGURE 2.3. DRM systems supported by currently existing devices and platforms13T h olwn eerhlsstetp1 oilntok [ networks social top-10 the lists research following The oto ita ewr ihte.I sas osbet rvtl xhnetx messages text exchange privately to possible also is It creating them. "Friends", with as network users other virtual add of can sort They information. a personal other and interests of lists social the represents users. it nowadays of and number worldwide, highest extended the was with it network version 2006 first In The 2004. California. to in back headquartered dates service networking social online an is Facebook Facebook 3.1.1 network social each video by providing offered ones functionality target. the their the on and only focuses those, analysis among The analyze, sharing. to and premium streaming decided video integrate we to media, ways social possible into examine content to wants project the Since users. registered networks Social 3.1 section in and token literature. Web the JSON from on works based related method other authentication analyze important an the we In at other 3.5 HTML5. look three in we describe protocols 3.4 we Bitrate section Adaptive in 3.3 and end, section DRM in of integration Then, the work. facilitating they standards how and needed are they fe eitain sr a raeaproaie rfiecnann hts mgs video, images, photos, containing Profile personalized a create can users registration, After w ieadee ecito fAatv iaepooos xliigwhy explaining in protocols, Then, Bitate Adaptive 3.1 . of section description in deeper networks project. a social the give existing in we the used 3.2 of technologies sections analysis the an on out background carry deeper we a First, give to aims chapter his 15 12 ,odrdb h epcienme of number respective the by ordered ], B CGON STUDY ACKGROUNDC HAPTER 3 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 TwitterTwitter 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 TumblrTumblr 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.17 CHAPTER 3. BACKGROUND STUDY3.2 Adaptive Bitrate streamingGiven 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 BackgroundThe 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 STREAMINGFIGURE 3.1. High-level view of an Adaptive Bitrate protocol3.2.2 Different solutionsAs 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 are19 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 HTML5FIGURE 3.2. Principal characteristics of currently existing Adaptive Bitrate protocols3.3 Relevant standards for integrating DRM and Adaptive Bitrate protocols in HTML5In 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.21 CHAPTER 3. BACKGROUND STUDYFIGURE 3.3. Browsers supporting MSE and EME standards3.3.1 CENCAs 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 decrypt22 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 MSEBy 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. <a href="/tags/Media_Source_Extensions/" rel="tag">Media Source Extensions</a> (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 EMEAnother 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.23 CHAPTER 3. BACKGROUND STUDYEME 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 TokenJSON 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 algorithm2. 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 WORKFIGURE 3.4. Communication flow of JWT authentication1. The client provides user credentials2. The authentication server checks the validity of the credentials and creates a valid JWT3. The server sends the JWT to the client4. The client verifies the token and stores it5. At each subsequent request, the client attaches the same persisted token in order to authenticate himself6. The server verifies the validity of the received token at each subsequent request7. The server returns "OK" message, or throws an error in case the received token is not valid3.5 Related workAs 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 in25 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 . ie temn potnte nsca platforms social in opportunities streaming Video 4.1 l h nlzdsca ewrspeetterdfutvdopae.Vdo de yuesare users by added Videos player. video default their present networks social analyzed the All .. Desktop 4.1.1 ie temn oiisadtechnologies: and policies streaming video oilfe.Hwvr oeo h etoe oilntok rsn lgtdfeecsi em of terms in differences slight the present inside networks DRM social handle mentioned correctly the to of capable some not However, implement are feed. not they social do therefore players and their standards that EME a is and However, media browsers. MSE social existing different the the all between over characteristic portable common is which player, video this within reproduced platforms. different the on do to explain allows and network environments social desktop each and what analysis mobile details the separate the focus to in we decide specifically, We More what content. streaming. of video video details protected of the on terms into in look offer to media want social we current chapter, the previous the of background theoretical the Given view. other of at point look network we social 4.4 the section from in alternatives and in valid problems embedded two encountered application the web overcome a to of aiming social characteristics and into the Facebook 4.3 technologies section DRM in of describe integration we Finally, easy media. an preventing limitations possible out point I we 4.2 section in Then, streaming. video possibilities of the terms of in summary platforms a social with current start into the we content by 4.1 video offered section protected In streaming feasible. of be goal could the networks how social analyze we chapter following the n 27 P OOE SOLUTION ROPOSEDC HAPTER 4 CHAPTER 4. PROPOSED SOLUTIONFIGURE 4.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 the28 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 MobileOn 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 LimitationsAfter 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:29 CHAPTER 4. PROPOSED SOLUTION1. 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 solutionThis 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 networkWe 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 pictureIn 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 requirementsIn 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 platformsThe decisions that we made for the videoplayer embedded in the desktop version are the following:• DASH as Adaptive Bitrate protocol• DRM as video protection technologyThe 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.31 CHAPTER 4. PROPOSED SOLUTION4.3.2.2 Mobile platformsGiven 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 4.3. PROPOSED SOLUTION4.3.3 Maintaining the playback statusOne of the initial requirements mentioned in section 1.3 is to keep the fluidity between the playback on different devices: if a user accesses the same video content on two different devices and in two separate times, then the new playback session should continue from the same time in which the previous playback was stopped. Our application models the concept of playback status in the following way:1. Video ID: unique ID identifying a video resource2. Device: random number generated when the user requests a new page3. Time: the current playback timeWhen an user starts a new playback, the application gets the last updated status of the current video and it will seek to the current "Time". If more than two hours pass between two different playback requests or if the status does exist yet, then the "Time" parameter will be reset to zero. During the playback, the user periodically sends the above parameters in order to update the current status. Then those values are associated with the User ID and stored in the Database to not lose the information. The "Device" parameter instead is useful in order to avoid concurrent playback on different devices. We opted for this solution in order to limit the bandwidth usage for a single user: when a different "Device" is detected, the playback will be paused on other devices eventually accessing the same video.4.3.4 Application use casesA fundamental step in the application description is to define its set of use cases, which are nothing but the possible scenarios faced by a user approaching the proposed solution.4.3.4.1 User loginPre-Conditions: none Action Flow:1. The system requests the user to enter his/her username and password.2. The user enters his/her name and password.3. The system validates the entered name and password and logs the actor into the system.Post-Conditions: If the use case was successful, the user retrieves a valid authentication token and he/she is now logged into the system. If not, the user is prompt to insert credentials again.33 CHAPTER 4. PROPOSED SOLUTION4.3.4.2 Not authenticated User clicks a resource linkPre-Conditions: the user does not possess a valid authentication token Action Flow (Desktop browsers):1. the user clicks on a link identifying a unique video resource from a desktop device2. the user is redirected to the Facebook Page Tab created by the content owner3. the Facebook Page Tab shows the login form to enforce user authenticationAction Flow (Mobile platforms):1. the user clicks on a link identifying a unique video resource from a mobile device2. an internal web view is open inside FacebookPost-Conditions: the internal web view shows the login form to enforce user authentication4.3.4.3 Authenticated User click a resource linkPre-Conditions: the user possesses a valid authentication token Action Flow (Desktop browsers):1. the user clicks on a link identifying a unique video resource from a desktop device2. the user is redirected to the Facebook Page Tab created by the content owner3. the Facebook Page Tab’s content is a videoplayer (with DRM protection) reproducing the requested videoAction Flow (Mobile platforms):1. the user clicks on a link identifying a unique video resource from a mobile device2. an internal web view is open inside FacebookPost-Conditions: the web view shows a video player reproducing the requested video4.3.4.4 Authenticated User reproduces twice the same video in two separate timesPre-Conditions:1. the user possess a valid authentication token2. the user has previously accessed a video within a predetermined time interval (120 minutes in our solution)34 4.3. PROPOSED SOLUTIONAction Flow (Both Desktop and Mobile platforms):1. the user requests the same video previously accessed2. the user is redirected to the Facebook Page Tab or the web view depending on the accessing devicePost-Conditions: the playback is automatically seeked to the execution time in which it was stopped during the first execution4.3.4.5 Authenticated User reproduces the same video simultaneously on different devicesPre-Conditions:1. the user possess a valid authentication token2. the user is currently reproducing a specific video contentAction Flow (Both Desktop and Mobile platforms):1. the user start the playback of the same video resource, from a different device2. the playback on the first accessing device is pausedPost-Conditions: the playback on the last accessing device starts4.3.5 Backend architectureIn section 2.3 we described the necessary components for a single DRM system to work. With that in mind, we propose in figure 4.2 a scalable architecture, able to interact simultaneously with the different DRM systems. The proposed solution is able to distribute DRM and HLS protected videos depending on the requesting device. Moreover, it guarantees user authentication and access control over the owned resources in a geographically distributed environment.4.3.5.1 Components descriptionThe basic components of the proposed architecture are the following:• Authentication server: responsible for handling and distributing valid tokens after user authentication• Web server: responsible for HTML pages and video manifests’ distribution. In the figure it is represented as a single sever to make the picture clearer. However, it could be distributed in a Cloud environment.35 CHAPTER 4. PROPOSED SOLUTIONFIGURE 4.2. Backend architecture of the proposed solution• Proxy license server: it receives all the licenses’ requests and it is responsible for the communication with the compliant DRM providers.• Content packager: responsible for the encoding and the encrypting the original video sources• Protected content server: responsible for storing and distributing all the protected videos offered by the content provider• Content Distribution Network: it is a network of servers distributed in multiple data centers. CDN works as a distributed cache for the content storage, with the goal of serving video content to end-users with high availability and high performance.• Certification authority: provides valid certificates in order to guarantee a secure communication between all the interacting components.4.3.5.2 Authentication and Access Control methodsWe chose a single sing-on authentication method based on JSON Web Tokens (see section 3.4). The authentication server is responsible to create, refresh and distribute new tokens to the clients36 4.3. PROPOSED SOLUTION that provide valid credentials. Valid tokens are then hashed and stored in a distributed database, so that all the other services (Web server, Proxy server, CDN components) are able to enforce their validity at each subsequent request. On the client, session tokens are stored in a cookie inside the browser. This strategy is secure if the communication is through HTTPS and the login credentials are sent over a secure channel. Moreover, to avoid "cross-site scripting attacks" [8] it is possible to set cookies’ flags "HTTP-only" and "Secure", preventing the JavaScript environment from accessing them. In that way, we ensure that they will only be communicated to our authentication server when needed and only over secure channels.4.3.5.3 Content protection and distributionThe protection and distribution of DRM protected video has to pass through the following basic steps:1. The original unprotected content is delivered to the so called "Content Packager" component.2. The "Content Packager" provide for the encoding and the encryption of the video file according to the CENC standard. We decided to adopt CENC standard in order to guarantee common encryption between the different DRM license systems (see section 3.3.1 for further information).3. After encoding and encryption, the protected package is sent to the "Protected Content Server" which is responsible to distribute the content to the relative CDN.4. Meanwhile, the manifest is sent to the web server and the unique decryption key belonging to that specific resource is delivered to all the DRM License servers through independent secure channels.In case of HLS with AES encryption, the process is simpler. Basically, the video is encrypted and the relative key is stored inside the manifest.4.3.5.4 Licenses distributionThe authentication method provided by the DRM license servers is based on asymmetric cryptog- raphy. In order to simplify the communication of our web architecture and improve its scalability, we decided to adopt a proxy based solution. The advantage of the proxy is that it allows to have only a unique secure communication channel between itself and each license server. The proxy is then responsible to make license requests on behalf of the clients, avoiding the distribution of certificates between each client and each single license server.37 CHAPTER 4. PROPOSED SOLUTION4.3.5.5 DRM video request scenarioWith reference to figure 4.2, we want to describe the sequence of requests needed in order to stream a protected video:1. The client sends username and password to the authentication server and a new session is established in case the credentials are valid2. The client requests a new video video resource. After validating the authentication credentials, the web server returns the video manifest, which indicates the link of the server containing the protected resource.3. The client requests the video source and retrieves a protected package.In case the video is encoded in HLS and encrypted with AES-128, the protected video and the relative key are retrieved and then decrypted inside the Javascript page, without the need of a license. In case of DRM protection, the next steps are the following:4. A POST license request is sent to the proxy. The proxy contains the logic to filter which kind of license is needed by the client. Therefore, it redirects the request to the right license server.5. Once the user retrieves the protected package and the relative license, the CDM inside its browser will be responsible to decrypt the content and send the plain video information to the video player.4.4 Alternative solutionsIn this section we propose two possible front-end improvements, by looking at the problem from a social network’s point of view. These solutions are not currently available in any social platform. The aim is just to give an high level description of some features that a social network could add in order to overcome the limitations mentioned in section 4.2 and to further improve the user experience.4.4.1 Improve the default video playerThe first possible solution could be to enrich the internal video player, both on mobile and desktop platforms. In particular, in order to be portable on all the devices and guaranteeing at the same time DRM protection, the video player has to be compliant with the Adaptive Bitrate protocol and DRM technologies adopted by each specific platform. In particular the requirements are the following, as we can see from figures 3.2 and 2.3:38 4.4. ALTERNATIVE SOLUTIONS• On Desktop, DASH as Adaptive bitrate protocol and all the different DRM systems, depending on which browser it is used.• On android, DASH as Adaptive bitrate protocol and Widevine as DRM.• On iOS, HLS as Adaptive bitrate protocol and FairPlay as DRM.• On Windows Phone, DASH as Adaptive bitrate protocol and Playready as DRM.However, a DRM-capable videoplayer would not be enough to achieve a complete integration. Another required feature is the presence of a valid authentication method. So, the user experience should present the following steps:1. A trailer video or an advertising content is presented and it can be visualized by all the users.2. An authentication form is then shown inside an <iFrame> or a web View, depending on the hosting platform.3. In case of positive authentication, the protected video starts. Otherwise, an error will be returned to the authentication formDue to the added complexity, this solution implies the presence of three other additional parameters, which can be entered either manually or as meta information with the help of the "Opengraph" protocol. The parameters are the following:1. The URI of the video manifest file2. The URI of a page providing authentication form3. The URI of the license serverTheoretically this solution would be the best both from the user and the video provider perspective. In fact, the former will be able to access a fully integrated solution, since they can watch their protected content and authenticate to their services directly from the News Feed. The latter will be able instead to embed their services into the social media without basically any effort. However, social networks would have to face two main problems: first they would have to implement the aforementioned video players in all the platforms and provide an API to communicate with external video providers. Furthermore, to achieve a scalable solution, the backend architecture of each video provider should to be compliant with our proposed architecture. In particular, the presence of a proxy handling license requests is required, otherwise the number of necessary parameters would increase and it would become dependent on each single implementation.39 CHAPTER 4. PROPOSED SOLUTION4.4.2 Integration of external DRM-capable video playersAnother possible approach to integrate DRM protected videos in social networks is to let the video providers to embed an external video player into their News Feed, by giving to them the opportunity to customize their posts with code imported from an external web application through an <iFrame> tag. In that way, the video provider would be entirely responsible of creating a personalized user experience, together with its own authentication method. This solution reminds to the concept of "Player card" offered by Twitter (see section 3.1.2). However, Twitter’s policies mentioned in section 4.1.1 do not permit external authentication and therefore they are not good for such a context. From the social network’s point of view this solution is much simpler than the one proposed in the above section. However, we realize that in such a scenario a validation process becomes necessary for each Post. In fact, the social network would have to control that each Post really provides the described video experience, that the external video player works correctly on all the platforms and that the content is in accordance with other eventual policies and rules. Moreover, this solution presents the same drawback mentioned in section 4.1.2, concerning the impossibility for mobile browsers to natively handle DRM protection into the web View. The reason is that EME ad MSE standards are not yet supported in the current versions of Android browser, Safari and Windows IE. Therefore, this way of integrating DRM video players in social networks is hypothetically very interesting, but in order to become realizable we have to wait until the mobile browsers are enriched with the aforementioned standards.40 T swbfaeokw eie oaotPonxFaeok[ Framework Phoenix adopt to decided we framework web As atr n ti atclryaatfrbidn TL ps P aknsaddistributed following: and the backends are API Phoenix apps, by HTML5 offered building advantages for The running systems. adapt for particularly is known it system, and runtime pattern Erlang [ systems proven fault-tolerant the and leverages distributed low-latency, that language a Elixir, in Framework Phoenix 5.1 5.6. section in in dispatcher players video page adopted and the about fluidity talk implemented we Finally, we 5.5. how and 5.4 describe sections we 5.3, section in framework • • • ul ntpo h oeEln utm ytm[4]. system are runtime they Erlang since note applications, the Phoenix of distribute top to on easy built really is it distribution: of Easiness [ parame- benchmarks as reported latency and these throughput ters. from considering performances, notice high really can presents we Phoenix as performance: application High runtime. fast with tooling productive by really offered a conciseness offers and Phoenix simplicity language, the Elixir on advantage taking productivity: developer High forpooe plcto.Te,w iea vriwo h urinauthentication Guardian the of model overview data an the give describe we we Then, 5.2 application. section proposed In our section framework. of In web solution. Phoenix proposed the our introduce about we details 5.1 implementation give to aims chapter his 41 4 .Ponxipeet h evrsd MVC server-side the implements Phoenix ]. 2 .PonxFaeoki written is Framework Phoenix ]. I MPLEMENTATIONC HAPTER 5 1 ], CHAPTER 5. IMPLEMENTATION5.1.1 Phoenix componentsPhoenix is composed by a number of distinct parts, each with its own purpose and role to play in building a web application [2]:• Endpoint: it is the first components that handles web requests. It provides a core set of plugs to apply to all requests (e.g. logging request, parsing incoming JSON, etc). Endpoint will then dispatch all the requests into a designated router.• Router: it parses incoming requests and dispatches them to the correct controller/action, together with the corresponding parameters. The Router component defines also named pipelines through which the requests can pass. A pipeline is a way to group together groups of plugs and assign them to a set of routes.• Controllers: they are modules providing functions, called actions, which have the goal to handle requests. An action prepares data and pass it into views, to invoke rendering via views or to perform redirects to other routes.• Views: they act as a presentation layer and they are used to render templates.• Templates: they are pre-compiled and extremely fast. They typically represent full HTML documents, JSON or possibly XML, depending on the context.• Channels: they represent an innovative concept for a web framework. Channels manage web sockets in a very easy way, allowing bi-directional communication with persistent connections. They are usually used to achieve an easy realtime communication, independently on the underlying platform.The following sections describe two other Elixir components that are integrated in the framework: Plug, and Ecto.5.1.2 PlugIn Phoenix all the request are represented by an Elixir’s Struct marked as %Plug.Conn and defined as "connection". This struct contains all the information that there is to know about an HTTP request. Given the fact that Elixir is a functional programming language, the concept of State does not exist. So, the "connection" is passed from function to function, modified depending on different needs and then returned back. Plug is a specification that defines how this modification of the connection should work and creates an abstraction so multiple frameworks can talk to multiple web servers, as long as they are respecting the same specification. There are two different kinds of Plug:1. Function plug: function that receives a connection with a set of options, and returns a connection after a set of modifications. An example is the following:42 5.1. PHOENIX FRAMEWORK def my_plug(conn, opts) do # modify the conn struct and return it conn = my_function(conn,opts) end2. Module plug: any module that implements two function: init/1 and call/2. The value returned by init/1 is passed to the call/2 function. The advantage is that the former is executed at compile time. Therefore, it is possible to insert pre-defined and heavy code here and let call/2 to execute at runtime. An example is the following: defmodule OurModulePlug do # The Plug.Conn module makes the %Plug.Conn{} struct available import Plug.Conn def init(options) do # add an additional option Map.put(opts , :new_option, "Hello") end def call(conn, _opts) do conn |> put_resp_content_type("text/plain") # set content type − |> send_resp(200, "#{opts[:my_option]} world") #return string end endThe simplicity of Plugs’ definition makes them easily composable. For this reason Plugs are often concatenated in order to form a so called "pipeline". The following is an example defining the default concatenation of plugs applied to an HTTP request coming from a browser: pipeline : browser do plug :accepts, ["html"] plug :fetch_session plug :fetch_flash plug :protect_from_forgery plug :put_secure_browser_headers end43 CHAPTER 5. IMPLEMENTATION5.1.3 EctoEcto is a domain specific language for writing queries and interacting with databases in Elixir. With Ecto, it is possible to model domain data, read and write to different databases, and write complex queries in a safe way, being protected against the most common attacks, e.g. SQL injection [2]. Ecto is composed by three main parts:1. Repo: it represents a single connection to a specific database. Every database operation is done via the repository.2. Model: it is nothing else but an abstract definition of the data represented in the underlying database. The Model define table names and fields, field’s type, together with the relationships between models.3. Query: it links together the repository and the declared models, allowing to retrieve data from the repository in an elegant way and cast it into the models themselves.5.2 Data ModelFigure 5.1 shows the ER diagram representing the data model of the database adopted in our application. The described entities are the following:FIGURE 5.1. Entity-Relationship diagram corresponding to the Data Model of the proposed application44 5.2. DATA MODEL1. User - contains all the users’ data• UserID: primary key, defining unique identifier for the entity • Username: username of the given user • Email: email of the given user • Password: user’s password, salted and hashed. Passwords are not stored in plaintext but they are hashed in order to be protected against database attacks. A salt (random string concatenated to the user’s password) is also added in order make ineffective attacks such "lookup tables", "reverse lookup tables" and "rainbow tables" [22].2. Video - contains all the videos’ data• VideoID: primary key, defining unique identifier for the entity • Name: the title of the video • MpdUrl: the URL to retrieve the manifest file of the DASH-encoded video resource • HlsUrl: the URL to retrieve the manifest file of the HLS-encoded video resource • WidevineUrl and PlayreadyUrl: URL of the licenses servers corresponding to the tested licenses ( see the next chapter for further details). These values have been stored since for our tests we are using free licenses and all of them have a different URL. However, in a real case scenario they are not necessary anymore, because the license servers are the same for all the videos and the communication with them is handled by the proxy, as we explained above in section 4.3.5.4.3. Visualization - n to n relation between videos and users. It contains the values described in section 4.3.3 , related to the user’s visualization of each single video.• UserID: unique identifier of the corresponding user. Together with VideoID, it forms a composite primary key for the entity. • VideoID: unique identifier of the corresponding video. Together with UserID, it forms a composite primary key for the entity. • Time: float value representing the current playback time related to the couple video- user • Device: integer representing a unique identifier for the last user’s device accessing the given video5.2.1 Database specificationsTo implement our data model, we decided to use postgreSQL as relational database system. The main reasons why we adopted PostgreSQL are its open-source nature, the fact that it offers high performances and it is integrable with the aforementioned Ecto language.45 CHAPTER 5. IMPLEMENTATIONIn order to be compliant with the Phoenix Framework’s specifications we followed the following steps:1. configure the Ecto Repo with the information of our database2. define the Ecto Model for each of the aforementioned entities and relationship3. migrate the abstract models in our database and define our queries according to the Ecto languageTo store user’s password in a secure way, we adopted "Comeonin", an Elixir’s library facilitating password hashing.5.3 Authentication: Guardian frameworkAs said in section 4.3.5.2, the authentication method of the proposed solution is based on JSON Web token. To be compliant with this technology, we adopted "Guardian", an Elixir’s authentication framework that integrates in Phoenix with the aforementioned Plug specification.5.3.1 Guardian’s configurationsTo make Guardian working, we set up the following configurations: config :guardian , Guardian, issuer: "Accedo video_app", hooks: GuardianDb, ttl: { 15, :minutes }, secret_key: VideoBackend.secret_key , serializer : VideoBackend.GuardianSerializer config :guardian_db , GuardianDb, repo: VideoBackend.Repo• Guardian DB: As mentioned in section 4.3.5.2, the authentication server has to store the tokens in a distributed database, so that all the other servers can be able to verify their validity at each subsequent user’s request. To that extent, Guardian provides "GuardianDB", a module implementing database integration. From the above code we can see that GuardianDB is associated with a specific Repo, so that all the tokens’ information are handled by Ecto.• Guardian serializer: it is a Elixir’s module providing encoding and decoding of the information contained in the payload of the authentication token.• TTL: it is the validity time of the user’s session (in our application it is set to 15 minutes).46 5.3. AUTHENTICATION: GUARDIAN FRAMEWORK• Secret key: it is the key used to sign authentication tokens. As previously mentioned in section 3.4, this key is necessary in order to prevent the tampering of the token itself.5.3.2 Guardian’s plugsGuardian implements the aforementioned Plug specification, so that its functions can be easily integrated in a Phoenix project. Here we want to present the most important Plugs adopted in our project:• Create token: The following function is applied during the user’s login phase, after having validated user’s credentials. The provided functionality is to create a valid token, store it into the database and include it in the response header.Guardian.Plug.sign_in(conn, user, :token)• Verify token validity: The following functions are added in the Phoenix Router under the browser’s and API’s pipelines to verify token’s validity after each subsequent request. Other than validating the tokens, the plugs insert a string in the "connection" struct of each request asserting their. pipeline : browser_session do plug Guardian.Plug. VerifySession plug Guardian.Plug.LoadResource ... end pipeline : api do plug :accepts, ["json"] plug Guardian.Plug.VerifyHeader plug Guardian.Plug.LoadResource ... endThen, the following code is inserted to ensure that the tokens have been correctly validated and decide the action to be taken in case of failure. plug Guardian.Plug.EnsureAuthenticated , on_failure : { VideoBackend.SessionController , :new }• Refresh token: in our application we decided to take the session time quite short (15 mins) and to accept periodic refresh requests from Javascript from active users. The following47 CHAPTER 5. IMPLEMENTATION function is responsible to update the expiration time of the token for the requesting user in GuardianDB:Guardian. refresh !(Guardian.Plug.current_token(conn))5.4 FluidityWith reference to section 4.3.3, this section describes how we implemented session fluidity between different devices:FIGURE 5.2. Sequence diagram showing how the session fluidity between two concurrent devices is handled1. When the page corresponding to a specific video is opened, a random integer is generated and assigned to the "Device" variable on the client. This number is used as unique identifier for the couple user-video. Moreover, the client gets a JSON containing the "Time" information of the current video. Then, the video player automatically seeks to the specified "Time" value.48 5.5. PAGE DISPATCHER2. Whenever the video playback starts, a Javascript function sending the values of the triple "Device - Time - Video" is called. Then, the request keeps waiting for a callback.3. The server checks if the "Device" value in the "Visualization" table corresponds to the one sent by the user. In positive case, it means that the requesting device is the same. Therefore the tuple on the server will be updated with the new values and returned to the user. In case the "Device" value differs, the actual value is returned to the user, without executing any update.4. On the client callback, if the returned "Device" value corresponds to the one previously sent, then the playback will continue and a new timeout for the same function will be called after a certain amount of time (we decided to set the timeoutTime = 1 second). The process restarts from point number 2. In opposite case, the playback will be paused.Figure 5.2 shows a sequence diagram showing the aforementioned process in case of two concurrent accessing devices.5.5 Page dispatcherAs we explained in section 4.3.1, a key feature of our proposed solution is to detect the device requesting each single resource link, in order to redirect the request to the right page depending whether the accessing device is a desktop browser or a mobile. To accomplish this goal, we used an Elixir’s tool called "UA Inspector". This tool works as User agent parser library: it makes a comparison between the "User Agent" header in the request and a set of resources in a local database. Then, it returns detailed information about device type (desktop, tablet, mobile, etc.), operating systems, brands, models and others.5.6 Video playerIn this section we want to describe the technologies used to implement the video player in both desktop and mobile versions.5.6.1 DesktopOn desktop environment we decided to adopt "dash.js", which is a client-side JavaScript open- source library for building video and audio players encoded in MPEG-DASH. In order to achieve a native integration in HTML5, the library leverage the MSE API. Moreover, dash.js relies also on the EME standard and therefore it supports DRM in all the compatible browsers. We chose this solution in order to be compliant with the technologies described in section 4.3.2.1. There are other open-source Javascript libraries providing DASH streaming protected by DRM:49 CHAPTER 5. IMPLEMENTATION• Shaka-player provided by Google.• Bitdash video player provided by Bitmovin.However, after having tried all these solutions, we found out that dash.js is the only one compatible with the free licenses that we tested. More details about license tests are given in the next chapter.5.6.2 MobileOn mobile we adopted "JwPlayer", which is an open-source embeddable media player. JwPlayer supports HLS streaming. We chose it because of its capability to go cross platform and to offer the same user experience on both Android and iOS platforms. Moreover, it is perfectly integrated with HLS files protected with AES-128 encryption. The only required parameter is the link of the HLS manifest, that has to be accessed through a secure connection. Key distribution is then handled completely by the player.50 h olo h rpsdts st eiyta u rpsdapiainwrso l h existing the all on works application proposed our that verify to is test proposed the of goal The eie,i codnewt h ecito ie nteaoecatr.Tets a endivided been has test The chapters. steps: above following the the in in given description the with accordance in devices, test Portability 6.1 I 2. 1. 6.2. 6.3. section section in in experience results its user the evaluate perceived discuss first the we We evaluate Finally, we application. Then, proposed 6.1. the section of in validity portability the analyze we chapter, this n ,ti tpis step this , 4.3.2.2 section in given description the to According encryption. AES-128 eddi re omk h aevdocnetaalbei oieplatforms. mobile in available content video same the make to order in needed videos: provided the of and Encoding licenses free any them. provide test not not could do we Fairplay therefore Apple and Access Adobe Unfortunately, resources: following testing the for find used only be could could we that research, videos extensive licensed an free After correspondent purposes. find to tried we and 2.4 eeto flcne videos: licensed of Selection Vdo2 ie oreecddi AHadpoetdwt ieielcnesystem. license Widevine with protected and DASH • in encoded source video 2: Video • • ie :vdosuc noe nDS n rtce ihbt ieieand Widevine both with protected and DASH in systems. license encoded Playready source video 3: Video system. license Playready with protected and DASH in encoded source video 1: Video ecniee h R ytm ecie nsection in described systems DRM the considered we eecddtesm ie ore nHSwith HLS in sources video same the encoded we 51A C HAPTER NALYSIS 6 CHAPTER 6. ANALYSIS3. Testing on different devices: we tested the mentioned video sources on different desktop and mobile devices in order to verify the correct working of the proposed application.6.1.1 ResultsOn desktop, the tested videos work only on browsers that support the respective license system (the DRM compatibility table is showed in figure 2.3). Therefore, as expected, our results are the following:• Video 1 is compatible only on Internet Explorer browsers.• Video 2 is compatible only on Google Chrome browser.• Video 3 is compatible on both Internet explorer and Google Chrome.On mobile, we tested the video experience on four different Android devices (version 4.0+), four iOS devices (version 6.0+) and two Windows Phone devices (version 8.0+). The video player works without presenting any problem on Android and iOS. However, Windows Phone is not compatible with the proposed application, since it does not support HLS Adaptive Bitrate protocol.6.2 User experience evaluationThe second step of our analysis consists in the evaluation of the quality and utility of the proposed application. To this extent, we decided to conduct a user test and to collect users’ opinions through a survey. This section first describes at length the adopted methodology. Then, it presents the results of the analysis conducted on the collected data.6.2.1 Data collectionThe user experience analysis is based on a survey. Its structure consists in 16 ordered questions (see Appendix A) with the goal of investigating users’ usage of social networks and video premium services and collecting their opinion about the proposed application. This kind of methodology is reproducible but not replicable, since the questions of the survey can be easily answered and analyzed in the future but the same results are not guaranteed. Moreover, the validity of the answers is confirmed by the respondents themselves, because they have to declare that they have completely understood all the questions in the survey. Finally, the survey respects the main ethical principles, such as maintenance of privacy and confidentiality. A total of 30 responses has been analyzed. We tried to differentiated as much as possible the characteristics of the target users in terms of sex, age and profession in order to collect answers from different backgrounds. In fact, social media and video premium services are characterized by a very broad audience and they don’t focus on a specific user subset. However, the restricted number of respondents does not guarantee the generality of the results.52 6.2. USER EXPERIENCE EVALUATION6.2.2 User test descriptionAs anticipated above, the survey is based on a test that each user had to complete before starting to answer the questions. The goal of the test is to make them aware of the purpose and the goal of the proposed solution and to make them discover and experiment all the different use cases exposed in section 4.3.4 . Therefore, the test has been structured into the following steps:1. A general introduction is given to the user. The goal, the purpose and the functionality offered by the proposed application are explained and eventual questions are answered.2. When everything is clear, the user is invited to log into a Facebook account from a desktop browser and to access the Facebook page of a fake video provider. The Facebook page contains an advertising post for each of the 3 licensed videos described above. The posts follow the description given on section 4.3.1.3. The user selects a video among the proposed ones and is redirected to the authentication form in the Facebook Page Tab.4. The user is given authentication credentials in order to log into the service and visualize the protected content.5. The user authenticates to the service and starts the playback of the same video content from a mobile phone or tablet, experiencing the session fluidity between different devices.6. The user is given additional time in order to freely use the application.A part from the initial introduction, the participants work independently during the test and their application usage is analyzed in order to individuate eventual problems and/or imperfections in the application.6.2.3 Data analysisThe data analysis process has been divided into two different parts. In the first part each question is analyzed one by one in order to get information about the distribution of the results for each answer. On the other hand, in the second part of the analysis, the answers are analyzed respondent by respondent to individuate eventual common patterns in their answers.6.2.3.1 Global analysisGlobal analysis has been divided into five different parts:• The first step aims to classify the respondents based on their profile. This result is obtained by looking at the answers of questions 1, 2, and 3 of the questionnaire (see Appendix A), which request the users to express respectively their age, sex and profession.53 CHAPTER 6. ANALYSIS• Then, social networks’ usage of the respondents is analyzed. This has been accomplished by studying the answers to questions 4,5 and 6 (see Appendix A). Question 4 aims at individuate the most used social network. Question 5 investigates how much time each user spends on social media. Question 6 instead points out which is their favorite device to access social platforms.• The third step consists in investigating the video consumption habits of the respondents. To this extent, we analyzed questions 7, 10 and 11 (see Appendix A). By looking at question 7 it is possible to directly infer which are the most adopted premium services. From question 10 instead, we are able to individuate which are the devices preferred by the users to access video content. Question 11 instead investigates if the users prefer to watch videos shared by others or to choose on demand content whenever they want.• The next step is useful in order to infer the utility of the proposed solution. In fact, question 8,9 and 13 (see Appendix A) have the goal to investigate how much the application would be able to influence the user experience in terms of video consumption. Question 8 points out how much the respondents would like to access premium content from social media. Question 9 analyzes how much the users would be more encouraged to subscribe to premium video services, if accessible from social networks. Question 13 instead investigate if the users would be more likely to share video, in case they were accessible from social networks.• Finally, questions 12,14,15 and 16 (see Appendix A) are used to collect user’s opinion on the application itself. Questions 12 and 14 are useful to individuate if the users would prefer a social authentication and if they would be interested to access premium content directly from the News Feed. Question 15 and 16 are instead useful to highlight how much the users appreciate the proposed solution.6.2.3.2 Pattern analysisThe second part of the analysis aims to divide the respondents into groups. The goal of this process is to individuate common patterns looking at the commonalities in their answers. To achieve this purpose, the main criteria adopted in the groups separation are the following:• Grade conferred to the proposed solution• Final comment expressed at question number 16 (see Appendix A)After having divided the users into different groups, the rest of the answers have been analyzed one by one for each respondent. Finally, the answers presenting high correlation between respondents of the same groups have been taken in consideration in order to individuate a common profile.54 6.2. USER EXPERIENCE EVALUATION6.2.4 ResultsIn this section, the results are presented in the same order of the data analysis process. The results for each single question have been also reported in Appendix A.6.2.4.1 Global resultsFigure 6.1 reports the information related to age, sex and profession of the respondents.FIGURE 6.1. Summary of the information related to the age, sex and profession of the survey respondentsThe most important results coming out from the analysis of social networks usage are showed in figure 6.2. In particular, we have that:(a) The most used social network is definitely Facebook, with 96,7 percent of votes.(b) The majority of the users spend between 30 and 60 minutes on social media every day.(c) Almost all the respondents access social networks mostly from Smartphone. No one chose Tablet as favorite device.Regarding the analysis of video usage, we obtained the following results (see figure 6.3):(a) We decided to group the premium services in two different categories: on demand (videos can be retrieved at any time on user request) and live TV (broadcast of TV channels in real-time). The result is that, 80 % of the respondents is currently subscribed to a premium video provider. Among them, 80 % is subscribed to at least an on demand video service, while 42,3 % is subscribed to at least a live TV premium service.(b) The most used device to access video content is the computer.55 CHAPTER 6. ANALYSIS(a)(b)(c)FIGURE 6.2. Graphical representation of the survey’ s answers related to social networks usage of the respondents. In particular, the questions corresponding to each figure are (see appendix A): (a) Question 5 (b) Question 4 (c) Question 656 6.2. USER EXPERIENCE EVALUATION(a)(b)(c)FIGURE 6.3. Graphical representation of the survey’ s answers related to the video consumption habits of the respondents. In particular, the questions corresponding to each figure are (see appendix A): (a) Question 7 (b) Question 10 (c) Question 11 57 CHAPTER 6. ANALYSIS(c) Regarding the favorite kind of video, the preference is biased towards video on demand. However, a few users expressed a clear preference.Figure 6.4 shows the results concerning the utility of our application. In particular we obtained that:• The majority of the users subscribed to a premium video provider expressed a medium or high interest about the idea of accessing premium content from social networks.• Only 40 percent of the users admitted that they would be more likely to subscribe to a premium video provider, if their services were accessible from social networks.• A clear majority of respondents claimed that they would be more likely to share premium videos, if they were accessible from social networks.FIGURE 6.4. Graphical representation of the survey’ s answers related to the utility of the proposed applicationFinally, the results related to the quality of the proposed solution are summarized in figure 6.5. In particular, we can notice the following results:(a) The preference between authentication through social login button and personal credentials is not clear. However, the former received a slightly higher preference.(b) 76,6 percent of the respondents expressed their preference about the presence of protected videos in the News Feed.(c) 56,7 percent of the users attributed a grade above the average to the proposed application. 30 percent instead expressed indifference and they decided to not take a specific position.58 6.2. USER EXPERIENCE EVALUATION(a)(b)(c)FIGURE 6.5. Graphical representation of the survey’ s answers related to the quality of the proposed application. In particular, the questions corresponding to each figure are (see appendix A): (a) Question 12 (b) Question 14 (c) Question 15 59 CHAPTER 6. ANALYSIS6.2.4.2 Pattern resultsFollowing the strategy described in section 6.2.3.2, we were able to divide the respondents into 4 different groups. Then, some answers presenting an high correlations between the components of the same groups were used to delineate a general profile. Figure 6.6 shows those answers divided by groups.1. Group 1: this pattern identifies users attributing a high grade to the overall application. Many respondents of this group explicitly say that it can become a new way to reach contents because it simplifies the access to recommended videos and premium videos. Their profile corresponds to a user spending on average between 30 and 60 minutes on social media every day and accessing video content mostly from computer. The majority of them would also be more likely to subscribe to premium content services and to share premium videos, if both were accessible from Facebook. This is the largest group, since it represents 14 respondents.2. Group 2: this pattern identifies users attributing a medium or high grade to the application. From answers to question number 14 and 16, the respondents belonging to this group result disappointed of the fact that premium videos cannot be directly played in the News Feed. Their profile is characterized by an evident preference for video on demand. Furthermore, they all claim to be more likely to share a video if they could directly access it from the social media. In total, 5 respondents belongs to this group.3. Group 3: this pattern identifies users attributing a medium or low grade to the application. Their profile is characterized by a low usage of social networks and by the subscription to zero or maximum one premium video service. From answers to question 16, they express a personal disinterest about one of the two technologies. Moreover, all of them declare not to be more encouraged to subscribe to a specific premium service, if the contents were accessible from social networks. This group represents overall 6 respondents.4. Group 4: this pattern identifies users attributing a general low grade to the application. From their comments to question number 16 we can infer that the main reason of their dissent is a personal preference in keeping the concepts of premium video and social networks separated. In support to this thesis, we can notice in figure 6.6(a) that their favorite devices for accessing video content (TV, console or computer) either do not support social media or are in contrast with their favorite device used to access social networks, which is the smartphone. Moreover, their profile is characterized by a high usage of social networks and a very low willingness to subscribe to premium content services and to share premium videos, if both were accessible from Facebook. 5 respondents belong to this group.60 6.2. USER EXPERIENCE EVALUATION(a) (b)(c) (d)(e) (f)(g)FIGURE 6.6. Histograms representing the survey’ s answers of the questions used to delineate user profiles, divided by group. In particular, the questions corresponding to each figure are (see appendix A): (a) Question 10 (b) Question 4 (c) Question 11 (d) Question 9 (e) Question 13 (f) Question 8 (g) Question 1661 CHAPTER 6. ANALYSIS6.3 DiscussionIn this section, we discuss the results obtained by the aforementioned portability and user experience tests.6.3.1 PortabilityRegarding the results of the portability test, we can say that they confirm the expected results. On desktop, the provided licensed videos are compatible with the respective browsers according to the description given in section 2.4. As mentioned above, we could not test all the existing DRM systems, since we could not find free licensed videos for testing purposes. However, our tests verified the validity of the standards mentioned in section 3.3. Therefore, even without testing all the specific DRM systems one by one, we can affirm that the proposed solution is fully portable on all desktop browsers with a valid CDM (see section 3.3.3), provided that the backend architecture supports all the respective DRM license systems. On mobile platforms, the proposed solution works perfectly on Android and iOS. However, as expected it is not compatible on Windows Phone, since it does not support HLS protocol. From the following research [24], we can see that currently iOS and Android share together about 90 percent of the mobile market. Therefore, we can say that the proposed solution is portable overall on 90 percent of mobile and tablet devices.6.3.2 User experienceThe results coming out from the data analysis gave us the opportunity to make interesting considerations. First of all, apart from one respondent, Facebook has been unanimously chosen as the most used social network. Therefore, the fact that only Facebook (and eventually Tumblr) can support the proposed solution should be not considered as an important restriction. Moreover, a large majority of respondents prefers accessing social media through smartphone. This result confirms the importance of mobile platforms for social media and it justifies the efforts that have been done during the project to reach both desktop and mobile environments. Regarding the video experience, the results confirmed that a large majority of users is interested in premium video content, since many of them are subscribed to more than one service. In particular, their preference seems to be biased towards on demand videos, rather than live TV services. Moreover, from answers to question number 11 it does not come out a particular preference neither for on demand content, nor for shared video content. Therefore, the proposed application could be an important solution in order to transform premium videos in easily shareable video resources. This is further confirmed by the results regarding the utility of the proposed application, which show that two thirds of the users would be more likely to share a video, if accessible from social network. By looking instead at the answers to question 8, we can see that the majority of the respondents have also expressed their desire to watch premium content in social networks. The62 6.3. DISCUSSION majority of users also thinks that they would not be more likely to subscribe to a premium service, if the contents were accessible from social network. However, 8 respondents out of 30 expressed a favorable opinion with regard to that question. So, this means that on a large scale the proposed application could also be efficacious in order to convince social user to subscribe to video premium services. In general, the respondents liked the proposed application, with 17 out of 30 respondents expressing a positive opinion. The global results of questions 12 and 14 suggest that the presence of protected videos directly in the News Feed, together with the addition of a social authentication could definitely improve the user experience. Thanks to the pattern analysis instead, we were able to divide the users into four distinct groups, based both on their social and video habits and on their judgment about the application. By looking at the results, we can do the following considerations:• Almost 47 percent of the respondents (group 1) show enthusiasm about the proposed solution. In particular, they are very interested about the integration of premium video in social media and in their final comments they show a positive overall evaluation. In a real case scenario, they would represent the percentage of users that most likely will use and appreciate the application.• 16,7 percent of respondents (group 2) express their interest regarding the proposed application. In general, they appreciate the idea of integrating premium video in social networks. However, the fact that premium videos cannot be played in the News Feed lead them to not the give maximum grade to the proposed solution.• 20 percent of respondents (group 3) include users not interested in the proposed application. They result not interested either in social networks or video premium on demand and therefore they are the users that do not correspond to the target of the proposed application. In fact, their lack of interest in one of the mentioned technologies lead them not to express enthusiasm for the proposed solution. Therefore, if the application was available, they would more likely not use it.• Finally, another 16,7 percent (group 4) express disagreement about the idea of integrating premium video in social media, since they prefer the separation of those technologies offered by the current market. So, as the group above, they would most probably not appreciate a "socialization" of premium video.63. Conclusions 7.1 1.4: section in 1.3? described section goals in the listed all characteristics completed the with question: player following video the a answering networks on focused we thesis this In 7.3 section in aspects business I • application proposed the implemented We • • W xlrdtesaeo h r ehooisi em fvdostreaming video of terms in • technologies art the of state the explored networks We social existing • currently the by offered opportunities the analyzed We • eitoueptnilftr ok.Fnly edsusehcl oitland societal in ethical, Then, discuss 7.1. we Finally, Section works. in future insights potential introduce main thesis we the this 7.2, during present Section work and our work from our drew summarize we We that project. conclusions the present we chapter, this n hn eas odce srts nodrt icvrhwuesprev h experience the perceive users how discover to order in test user a conducted also we Then, eeautdtepraiiyo u ouin ytsigisfntoigo ifrn devices. different on functioning its testing by solution, our of portability the evaluated We Facebook. in video protected DRM frontend social stream the to as and aiming Facebook architecture application backend chose an the of we both requirements limitations, detailed we mentioned Then, the reference. on of network and analysis the protected on DRM Based of integration easy media an social preventing in limitations content premium major the out found We 65 si osbet me nsocial in embed to possible it is oase hsqeto,we question, this answer To C ONCLUSION C HAPTER 7 CHAPTER 7. CONCLUSION offered by the proposed application. After the test, we collected data through a survey, taking into consideration not only their opinion on the quality and utility of the application, but also their attitude towards video consumption and social media. Finally, we conducted a detailed analysis on the collected data.The first conclusion is that our solution results portable on almost 90 percent of the existing mobile devices and on all the desktop browsers compliant with the standards presented in section 3.3. Regarding the user experience analysis instead, we obtained interesting conclusions about the quality and the utility of the proposed application and we were able to divide the users in four different groups, based on patterns individuated in their answers. In particular, our solution received a positive judgment by more than half of the respondents. Moreover, the respondents confirmed a very high interest for social media and video premium services and they expressed a higher preference for on demand videos. Facebook is without any doubts the favorite social network and smartphone resulted the preferred device in order to access social media. Moreover, the application has turned out to be a solution in order to transform premium videos in easily shareable video resources. The collected data show also possible potentialities in convincing people to subscribe to protected video contents. On the other hand, two drawbacks affect negatively the overall work:1. It is not possible to embed DRM protected videos inside the social News Feed.2. Playback of DRM protected videos cannot be supported by the mobile versions of the current existing social media.The first mentioned drawback results in a more complex user experience. In fact, for this reason a significant part of the respondents did not attribute a completely positive judgment to our application. The second drawback instead prevents some video provider to publish their content in the way we proposed, since the property of "Access Control" over the own video resources cannot be guaranteed in the mobile environment. However, apart from the mentioned limitations, we can say that we were able to answer positively to the aforementioned question, given the status of the current technologies.7.2 Future workIn this section, we present some further work that would be necessary to further improve our project and to ensure its validity on a worldwide scale. As we mentioned in section 6.2.1, the results achieved from the user test are still repre- sentative but they cannot be taken into consideration to draw definitive conclusions, since we collected only 30 results and we selected users from a restricted geographical area. So, it would be necessary to extend the same test to a wider audience and to people with different cultures66 7.3. BUSINESS, ETHICAL AND SOCIETAL ASPECTS and backgrounds. Then, a comparison of the new results with ours can confirm or refute the validity of our "restricted" test. Moreover, another interesting work is to detect user profiles from the new collected data and to see how much they will differ from the ones delineated by our test. Another possible work is to extend DRM technology to the mobile world and to integrate protected videos in the News Feed in order to resolve the drawbacks stated above. This can be done by social networks, following the suggestions that we gave in section 4.4. In alternative, DRM can be extended to mobile platforms in the proposed solution as soon as web views in social media will include DRM-capable browsers. Finally, the integration of premium video in social media embraces several different aspects. Our thesis focuses on the technical needs of integrating a video player with the characteristics mentioned in section 1.3 into social networks. An interesting work could be also to analyze this topic from the legal and business points of view. In fact, DRM is related to the Copyright law, which is subject of many restrictions and debates. Therefore, a deeper analysis in this direction would also be necessary before affirming that the proposed solution can be extended on a worldwide scale.7.3 Business, ethical and societal aspectsWith the upgrade of Internet networks and the rise of broadband subscriptions, new on-line video platforms have been created (i.e. Netflix, HBO, Amazone Prime, etc...). These platforms offer a pool of so called "premium" videos, which are protected video resources accessible with a few clicks, on demand, and at lower prices with respect to the ones offered by traditional pay-TV services or DVD. This thesis proposes an alternative and innovative way to access premium videos. The idea is to promote and make them easily sharable and accessible through social media, by maintaining the same level of protection on the contents. As we mentioned in section 1.2, the number of social network users is increasing worldwide, changing the video habits of both young and adult generations. Therefore, our solution can make it easier for small-budget companies such as innovative start-ups to benefit from the described advantages and spread their contents through the multitude of social users. We conducted an user experience test in order to analyse how the users perceive the experience provided by the proposed web application integrated in Facebook. The results evidence an high appreciation towards the proposed idea. Since we collected only the opinions of thirty users, it is not possible to draw definitive conclusions. However, the responses point out that the proposed application can become a low-cost solution to advertise contents and attract more users. Furthermore, the integration in Facebook can transform premium videos in easily sharable resources. Additional services can be also built on top of the proposed solution, in order to further67 CHAPTER 7. CONCLUSION improve the user experience, i.e. creating a social rating systems in which all the users can express their judgment for the different video resources or building new recommended systems based on personal and on friends video usage. To this extent, the results of this thesis can be useful to change the users’ attitude towards premium video contents. In fact, the usage of the proposed application permits a shift between an active approach in which the user has to look for specific contents, to a passive approach, in which the contents will be recommended based on personal or social friends’ preferences. On the other hand, all the mentioned advantages come to the expenses of a privacy loss. The usage of video resources from Facebook could indeed enable the social network to collect data related to the video consumption of each single user and use it to several purposes, i.e. to do market analysis or to personalize advertisements into the social network.68 h olwn usin eeicue nteqetonieue ocletdt eae othe to related data collect to used questionnaire the in included were questions following The plcto srexperience. user application Hwmc ied o pn nsca ewrseeydy naverage? on day, every networks social on spend you do time much How 4. question] [open profession? your is Which 3. sex? your is Which 2. Hwodaeyou? are old How 1. minutes £ £ £ Male 5-24 - 15 0minutes 10 < • • • • • • • • Other Administration Designer Manager Sales Developer Software Engineer Software Student 6,% ; (66,7%) 2,% ; (23,3%) (3,3%) (6,7%) (10,0%) (23,4%) (13,3%) (6,7%) ¤ Female 1,% ; (13,3%) 5-34 - 25 (13,3%) (33,3%) (26,7%); (13,3%) 0-3 minutes 30 - 10 (13,3%) ¤ 5-44 - 35 69 (26,7%); 3,% ; (36,7%) 5-54 - 45 0-6 minutes 60 - 30 (23,3%) ¤ APPENDIX A PPENDIX 4,% ; (46,7%) A 60 > A APPENDIXA.APPENDIXA5. Among the following social networks, which is the one that you use the most? £ Facebook (96,7%) ; Twitter (3,3%) ; Google+ (0%) ; Tumblr (0%) ¤6. Which device you mostly use to access social networks? £ Smartphone (86,7%) ; Computer (13,3%) ; Tablet (0%) ¤7. Are you currently subscribed to any "Premium" video provider? If yes, which one(s)? [open question - more than one answer is allowed]• Netflix (60%)• Via Play (26,7%)• HBO (16,7%)• Sky TV (10%)• TV4 (6,7%)• Cmore (3,3%)• No subscription (20%)8. If you are already subscribed to a "Premium" video service, do you like the idea of accessing the same content directly on your favorite social network? £ Not at all (7,7%); A little (19,3%); Indifferent (30%); Much (22%); Very Much (22%) ¤9. If you could access interesting premium content from your favorite social network, would you feel more encouraged to subscribe to a specific service? £ Not at all (26,7%) ; A little (16,7%) ; Indifferent (30%) ; Much (13,3%) ; Very Much (13,3%) ¤10. Which device you mostly use to access video content? £Computer (50%) ; TV (16,7%) ; Smartphone (13,3%) ; Tablet (13,3%) ; Console (6,7%) ; Others (0%) ¤11. Are you more likely to watch shared videos on social networks or to watch "on demand" video content on specific applications? £Only shared video (3,3%) ; Mostly shared video (26,7%) ; I don’t have a preference (20%) ; Mostly on demand video (46,7%) ; Only on demand video (3,3%) ¤12. Considering the proposed solution, would you prefer to authenticate by using your personal credentials (username and password) or through the social login button? £I prefer using my own credentials (36,7%) ; I don’t have a preference (10%) ; I prefer using social login button (53,3%) ¤70 13. Are you more likely to share a video if you can directly access it from the social media? £ Not at all (13,3%) ; A little (6,7%) ; Indifferent (13,3%) ; Much (30%) ; Very Much (36,7%) ¤14. Would you prefer to access premium video content directly from the Facebook News Feed? Or you prefer to retrieve the videos from a separated social page, as in the proposed solution?• No, I prefer the proposed solution (13,3%)• It’s exactly the same (10%)• Yes, but I don’t think it is an important requirement (53,4%)• Yes, it would be much better (23,3%)15. In general, which grade would you give to the quality of the proposed solution (from 1 to 5)? £ Very good (33,4%) ; Good (23,3%) ; Indifferent (30%) ; Bad (13,3%) ; Very bad (0%) ¤16. Can you briefly explain why have you chosen that grade? [open question]71BIBLIOGRAPHY[1] Benchmark sinatra-like web frameworks. https://github.com/mroth/phoenix-showdown#comparative-benchmark-numbers. (Visited on 02/02/2016).[2] Phoenix framework homepage. http://www.phoenixframework.org/docs/overview. (Visited on 01/29/2016).[3] Theatrical market statistics, report, Motion Picture Association of America, 2014.[4] J. ARMSTRONG, A history of erlang, Proceedings of the third ACM SIGPLAN conference on History of programming languages, New York (2007).[5] M.BUHL, Millennials boast huge social networking growth and engagement on smartphones, but older users surprisingly outpace them on tablets. http://bit.ly/1JWcqB7. (Visited on October 11, 2015).[6] E.C.COUNSIL, Computer Forensics: Investigating Network Intrusions and Cybercrime, Cengage Learning, 2009.[7] I. J. COX, Digital Watermarking and Steganography, Morgan Kaufmann, Burlington, MA, USA, 2008.[8]R.DAMPHOUSSE, Build secure user interfaces using json web tokens, (2015).[9] E.DIEHL, Content protection: in this digital age, protecting your assets is essential., Broad- cast Engineering, World edition (2008).[10] E.DIEHL, Securing Digital Video: Techniques for DRM and Content Protection, Springer, 2010.[11] DRMTODAY.COM, Platforms - drmtoday. http://www.drmtoday.com/platforms/. (Visited on 10/27/2015).73 BIBLIOGRAPHY[12] EBIZMBA.COM, Top 15 most popular social networking sites | october 2015. http://www.ebizmba.com/articles/social-networking-websites. (Visited on 10/27/2015).[13]C.G.I.G ROUP, Public Key Encryption and Digital Signature: How do they work?, 2004.[14] P. HANACHEK, Problem of Tamper Resistant software.[15] Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files, standard, International Organization for Standardization, Feb. 2016.[16] Information technology – Dynamic adaptive streaming over HTTP (DASH) , standard, International Organization for Standardization, May 2014.[17]D.J AMES, Penny arcade - news - the origin of the cd-keys, part three. https://www.penny-arcade.com/news/post/2008/9/29, September 2008. (Visited on 01/27/2016).[18] M.JONES, J. BRADLEY, AND J. SAKIMURA, JSON Web Token, RFC 7519, RFC Editor, May 2015.[19] D.KUNDURAND K.KARTHIKP, Video fingerprinting and encryption principles for digital rights management, Proceedings of the IEEE, 92 (2004).[20] S.LEWIS, Economics of information security, Advances in Information Security, 12 (2014), pp. 53 – 57.[21] LIN,LAGENDIJK, AND DELP, Advances in digital video content protection, Proceedings of the IEEE, 93 (2005).[22] K.LUMPUR, Security analysis of salt||password hashes, Advanced Computer Science Applications and Technologies (ACSAT), International Conference on, (2012).[23] MICHALKO,BOBKO, AND FOGAS, Protected streaming of video content to mobile devices, Multidisciplinary Journals in Science and Technology, Journal of Selected Areas in Telecommunications (JSAT), 14 (2014).[24] NETMARKETSHARE, Mobile/tablet operating system market share. https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=8& qpcustomd=1, March 2016. (Visited on 02/02/2016).[25]R.P AREKH, Principles of Multimedia, MCGraw-Hill, 2008.74 BIBLIOGRAPHY[26] P. RESNIKOFF, Study finds that piracy is growing rapidly and becoming more profitable. http://www.digitalmusicnews.com/2013/10/21/studymediapiracy/, October 2013. (Visited on 11/09/2015).[27] W. ROSENBLATT,S.MOONEY, AND W. TRIPPE, Digital rights management: business and technology, Wiley, New York, 2001.[28] H.SCHULZRINNE,S.CASNER,R.FREDERICK, AND V. JACOBSON, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, RFC Editor, January 1996.[29] H.SCHULZRINNE,A.RAO, AND R.LANPHIER, RTP: A Transport Protocol for Real-Time Applications, RFC 2326, RFC Editor, April 1998.[30]S TATISTA, Number of social network users worldwide from 2010 to 2018. http://statista.com/statistics/278414/number-of-worldwide-social-network-users/. (Visited on October 11, 2015).[31] TWITTER, Player card | twitter developers. https://dev.twitter.com/cards/types/player#What_the_approval_team_looks_ for. (Visited on 10/29/2015).[32]A.W ALGROVE, The explosive growth of online video, in 5 charts. http://bit.ly/1No0Joy, July 2015. (Visited on 11/12/2015).[33] M.WATSON,A.COLWELL, AND A.BATEMAN, Media source extensions, candidate recom- mendation, W3C, July 2014. http://www.w3.org/TR/2014/CR-media-source-20140717/.[34] M.WATSON,D.DORWIN, AND A.BATEMAN, Encrypted media extensions, W3C working draft, W3C, Feb. 2014. http://www.w3.org/TR/2014/WD-encrypted-media-20140218/.[35]X.Z HANG, A survey of digital rights management technologies, November 2011.75TRITA TRITA-ICT-EX-2016:17 www.kth.se </div> </article> </div> </div> </div> <script type="text/javascript" async crossorigin="anonymous" src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-8519364510543070"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" crossorigin="anonymous" referrerpolicy="no-referrer"></script> <script> var docId = 'b47cd49a2e0106206852136c80c671e0'; var endPage = 1; var totalPage = 90; var pfLoading = false; window.addEventListener('scroll', function () { if (pfLoading) return; var $now = $('.article-imgview .pf').eq(endPage - 1); if (document.documentElement.scrollTop + $(window).height() > $now.offset().top) { pfLoading = true; endPage++; if (endPage > totalPage) return; var imgEle = new Image(); var imgsrc = "//data.docslib.org/img/b47cd49a2e0106206852136c80c671e0-" + endPage + (endPage > 3 ? ".jpg" : ".webp"); imgEle.src = imgsrc; var $imgLoad = $('<div class="pf" id="pf' + endPage + '"><img src="/loading.gif"></div>'); $('.article-imgview').append($imgLoad); imgEle.addEventListener('load', function () { $imgLoad.find('img').attr('src', imgsrc); pfLoading = false }); if (endPage < 7) { adcall('pf' + endPage); } } }, { passive: true }); </script> <script> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script src="https://www.statcounter.com/counter/counter.js" async></script> </html><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>