Filmtjenesten Netflix er blant aktørene som ønsker seg DRM-løsninger som kan brukes i HTML direkte.

Foreslår DRM-løsning for HTML

Kan ytterligere slå beina under plugins, men møter betydelig motstand.

En viktig årsak til at mange musikk-, video- og tv-tjenester på nettet ikke har tatt i bruk HTML5-video – altså avspilling av lyd- og videoinnhold direkte i nettlesere ved hjelp av audio- og video-elementene i HTML, i stedet for bruk av plugins – er at løsningen ikke har noen støtte for DRM (Digital Rights Management), også kalt kopisperre. Dette støttes av pluginsteknologier som Flash og Silverlight, som derfor benyttes av så godt som alle som tilbyr betalt musikk-, film-, tv- og video-innhold på weben.

Denne uken har det blitt presentert et uoffisielt utkast til en W3C-spesifikasjon for nettopp å kunne spille av beskyttet innhold direkte i nettleseren. Spesifikasjonen kalles for «Encrypted Media Extensions» og er skrevet av tre personer i henholdsvis Google, Microsoft og filmtjenesten Netflix.

Spesifikasjonen beskriver en utvidelse av dagens HTMLMediaElement for å spille av beskyttet innhold. Lisens- og nøkkelutveksling kontrolleres av applikasjonen og skal forenkle utviklingen av robuste avspillingsapplikasjoner som støtter et spekter av teknologier for innholdskryptering og -beskyttelse.

Det presenteres flere mål for spesifikasjonen, inkludert enkel kryptering uten behov for DRM-servere, støtte for et bredt utvalgt av mediecontainere og -codecer, samt minimalisering av funksjonaliteten som må bygges inn i nettleserne.

Eksempel på hvordan Encrypted Media Extensions kan brukes til å levere DRM-beskyttet innhold.
Eksempel på hvordan Encrypted Media Extensions kan brukes til å levere DRM-beskyttet innhold. Bilde: W3C

De tre forfatterne inviterer til diskusjon om forslaget her, og kommentarene har ikke uteblitt.

Chris Pearce i Mozilla skriver at han kjenner igjen tilbakemeldingene fra innholdsleverandører og applikasjonsutviklere om de ikke kan bruke audio- og video-elementene i HTML fordi HTML mangler robust innholdsbeskyttelse. Han spør hvordan dette kan implementeres i en åpen kildekode-basert nettleser. Spørsmålet er om svaret fra Mark Watson i Netflix er tilfredsstillende. Han nevner blant annet at noe funksjonalitet kan være implementert i maskinvaren eller fastvaren til enheten som nettleseren kjøres på. Han mener også at det ikke er ukjent for åpen kildekode-produkter å bruke eller leveres med driverprogramvare med lukket kildekode. Det må nevnes at tanken ikke er at Encrypted Media Extensions ikke bare skal brukes i pc-baserte enheter, men også i for eksempel smartmobiler og forbrukerelektronikk.

Tab Atkins Jr., som etter alt å dømme er ansatt i Google, skriver at dette ikke løser problemet som ble brakt på bane forrige gang det ble foreslått å legge DRM til video-elementet.

– En nettleser som Mozilla (Firefox, red. anm) er rettslig forhindret fra faktisk implementering av DRM, fordi de er nødt til å avsløre all sin kode, inkludert dekrypteringskoden som inneholder hemmelighetene du bruker til å dekryptere. Vi bør ikke forsøke å putte noe i HTML som ikke kan implementeres av én av de større nettleserne, skriver Atkins.

Han viser til at nesten alle andre typer innhold på weben er DRM-fritt, inkludert bilder, musikk og mange bøker.

– Oppriktig talt er jeg skuffet over at selskapet mitt var villig til å være medutgiver av denne spesifikasjonen, skriver Atkins.

Han får et lengre svar fra Watson i Netflix, som mener at man vil måtte vente lenge på den DRM-frie framtiden som Atkins beskriver. Han ønsker å komme bort fra dagens løsninger fordi de er så kostbare, blant annet fordi investeringen er fragmenter og duplisert i stedet for å bli rettet mot én felles plattform.

Sterkest kritikk mot spesifikasjonsforslaget er det likevel Ian Hickson, den Google-ansatte redaktøren av både HTML-spesifikasjonen og den alternative HTML5-spesifikasjonen til WHATWG, som kommer med.

– Jeg mener at dette forslaget er uetisk og at vi ikke bør sysle mer med det. Forslaget over tilbyr ikke robust innholdsbeskyttelse, så selv om det ikke var uetisk, så vil det ikke kunne brukes til dette formålet (lyd- og videoavspilling av beskyttet innhold i HTML, red. anm.), skriver han.

    Les også:

Til toppen