Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 123, views: 22.498 •

De HTML Working Group van het World Wide Web Consortium heeft zijn eerste draft van de Encrypted Media Extension-specificatie uitgebracht. De controversiŽle specificatie beschrijft een manier waarop browsers plug-ins voor drm aan kunnen roepen.

De draft van de W3C beschrijft zelf geen drm-systeem, maar wel een gemeenschapelijke api waar browsers dergelijke systemen mee kunnen ontdekken en kiezen en ermee kunnen interacteren. De api ondersteunt een beperkte set encryptiemogelijkheden, waarbij de authenticatie bij de beheerder van de web-app ligt. Onder andere Netflix, Microsoft en Google steunen het voorstel om mogelijkheden voor contentbescherming op deze manier naar html5 te brengen. Google heeft de specificatie al in Chrome geïmplementeerd terwijl Netflix aan een html5-speler werkt.

Er is echter zware kritiek op het voorstel van onder andere de Free Software Foundation en de Electronic Frontier Foundation. Een petitie van de organisaties leverde 26.000 handtekeningen tegen de plannen op. De organisaties claimen dat het voorstel indruist tegen de kernwaarden van de W3C voor interoperabiliteit en een open web zonder de noodzaak software van derden te hoeven draaien. "Nu Flash en Silverlight eindelijk uitsterven, moeten we die niet vervangen door nieuwe fantasieën van mediagiganten om grip op het web te krijgen", aldus de FSF.

De ceo van het W3C, Jeff Jaffe, reageert op de kritiek met de claim dat een open web plaats moet bieden aan allerlei soorten content en dat creatief werk gecompenseerd moet kunnen worden. "Zonder contentbescherming zullen aanbieders het open web onthouden van belangrijke content", zegt Jaffe, "Hoewel de drm-systemen duidelijk niet open zijn, moet een open web die mechanismes wel ondersteunen." Het onwenselijke alternatief is volgens hem dat bedrijven de content af gaan schermen in hun eigen walled gardens.

Reacties (123)

Reactiefilter:-11230112+192+213+30
Tja, dat was te verwachten vele $$$$$ van Microsoft, Google en Hollywood aan W3C en ze willen wel.

Geld = macht in deze wereld, en daar kan je zoveel petities als je wil tegenaan gooien. Het helpt echt helemaal niets.

[Reactie gewijzigd door sanderev66 op 10 mei 2013 17:48]

Maar wat is dan het alternatief? Het is ondenkbaar dat men de content zo maar zonder DRM op het net gaat zetten. Wanneer we TV series en films snel na release online willen kunnen bekijken dan is DRM spijtig genoeg een noodzaak, anders is er geen enkele manier om er geld aan te verdienen. En ja, dat geld verdienen moet ook gebeuren, het maken van die content is ook niet gratis.
Helaas ga je de mist in. Het is wel degelijk denkbaar. En ik denk dat het ook goed te doen is.

Maar DRM in HTML is gewoon niet goed. Wat je krijgt is het Apple model dat je je film alleen op de tv beneden mag afspelen van 9 tot 16uur op maandag 13 januari. Wil je de film opnieuw zien of op de tv boven, dan mag dat. Wel betalen.

De alternatieven zijn legio. Ik noem er maar 1. Je kan bv ook een film zo goedkoop aanbieden dat illegaal downloaden niet meer interessant is. Als ze een film voor 1 of 2 euro aanbieden, met NL ondertiteling, dan ga ik die officieel betalen. Want de moeite voor het vinden van een ondertitel en syncen kost ook al gauw een kwartier tot een half uur.

Het web is vooruitgang geweest. DRM in HTML is echt achteruitgang.
Het is meestal niet de prijs, maar het gemak. Het is sinds films digitaal te downloaden zijn altijd makkelijker geweest dit zonder te betalen te doen dan terwijl je wel moet betalen.

Voorbeeld met torrent:

1. Bedenk wat je wou zien en zoek het op met een goede torrent search engine
2. Kies de kwaliteit die je graag wil, en druk op de magnet link

Daarna kan je je content gewoon waar en wanneer je maar wil afspelen.

Er is gewoon geen inloggen, onzekerheid over content of een grote hoeveelheid andere stappen. En dat is wat mensen willen.

Ja, er zal altijd een groep mensen zijn die niet wil of kan betalen, maar dat is niet de groep waar een DRM systeem op kan richten, want dat is een groep die sowieso al niet zou betalen om rechten te krijgen.

[Reactie gewijzigd door johnkeates op 10 mei 2013 19:22]

Ja, er zal altijd een groep mensen zijn die niet wil of kan betalen, maar dat is niet de groep waar een DRM systeem op kan richten, want dat is een groep die sowieso al niet zou betalen om rechten te krijgen.
Je bent een beetje aan het dromen als je denkt dat de meeste mensen betalen als ze wat gratis kunnen krijgen.

Welke game was het ook al weer dat een paar jaar geleden DRM vrij op de markt kwam?
En in plaats van dat mensen wilde betalen, was het de meest gedownloade game van het jaar.

En als ik eerlijk ben, heb de laatste 10 jaar geen CD, DVD of BR gekocht, heb een +30TB server staan vol met films series en muziek.

Enige waar ik wel voor betaal is de bios, sommige films zijn gewoon beter op een 20~30M breed scherm.

En ik ben zeker niet de enige, DRM is iets wat ik ook niet wil, maar begrijp best dat content providers hun eigendom willen beschermen tegen mensen zo als ik, en die groep is best aanzienlijk.
Als je een half uur op zoek bent naar een ondertitel doe je toch echt iets verkeerd. De naam van de film en de groep wiens release je hebt gedownloadt in google copypasten levert altijd tussen de eerste drie gedownloade subs een perfecte match.

[Reactie gewijzigd door Origin64 op 10 mei 2013 19:35]

beetje oefenen met Engels kan ook helpen (tenzij je met de hele familie gaat kijken)
Engelstalige series/films kijk ik altijd zonder ondertiteling, en bij andere talen(voornamelijk Japans) zit er vrijwel altijd (Engelse) ondertiteling onder geplakt.
Gaat nog vaak genoeg fout hoor. Misschien niet bij de mega-bekende blockbusters, maar als je wat minder bekende of oudere films zoekt, dan heb je vaak niet veel te kiezen. Dan moet je ondertitels (die ook nog eens vaak vol fouten zitten) die van een dvd geript zijn gaan stretchen om ze gelijk te laten lopen met je mkv.

Dat gaat al mis omdat er bij een dvd vaak nog een leader van de filmmaatschappij voor zit, dus dan kun je nog zo netjes gestretched hebben, maar lopen je ondertitels alsnog 10 seconden voor of achter. Voordat je die ellende allemaal al hebt uitgepluisd ben je inderdaad vaak een kwartier verder en heb je het begin van de film al 10x gezien. Dan hebben we het nog niet over je gasten die zich ondertussen de pleuris zitten te vervelen. En als je dan pech hebt gaat het halverwege alsnog mis omdat er bv een scene uit is geknipt of is toegevoegd. Zit je tijdens de film weer met dezelfde ellende.

Wat ik ook altijd _heel_ vervelend vindt bij geripte subtitles, maar dat is misschien persoonlijk, is dat er aan het eind altijd staat 'downloaded from' etc. Die mededeling is op zich niet erg, maar hij komt vaak voordat je beseft dat de film is afgelopen. Wat mij betreft is het einde dan verpest. En als je vantevoren met een editor controleert of die melding erin zit, dan moet je verdomd goed uitkijken dat je niet gespoilt wordt doordat je de laatste ondertitel van de film zelf leest.

Nee, ik ben het er helemaal mee eens, zorg dat men voor een habbekrats een film kan downloaden. Je kunt weldegelijk concurreren met gratis door goede kwaliteit te bieden. Als ik voor een euro een HD-film kan downloaden, met correcte ondertitels en afspeelbaar op het apparaat van mijn keuze, dan zou ik er niet over nadenken, dan is de keus veel makkelijker...
DRM is niet meteen beperken van content. Het kan ook de content zelf beschermen zodat downloaden niet mogelijk is. Dit is natuurlijk erg logisch, want je verzorgd de bandbreedte en inhoud natuurlijk niet voor niets.

Het is nog maar de vraag of ze hiermee verder gaan, maar ik kan begrijpen dat ze willen voldoen aan de vraag uit de branche. Het HTML is ook uitgebreid doordat er vraag was naar betere manieren om opmaak te verzorgen of bepaalde functionaliteiten makkelijker te maken. Dan is het toevoegen van DRM helemaal niet zo'n gek idee. Het is eerder aan de diverse internetautoriteiten om in te grijpen als dit toch tegen de principes en ideeŽn ingaat.

DRM staat voor het beheren van inhoudsrechten, niet het beperken ervan. Ik verwacht ook niet dat dit zal staan voor het beperken van aantal keer afspelen (al moet je je afvragen hoe erg dat is als je een kleine prijs moet betalen), maar eerder dat men niet zomaar de filmpjes kan rippen waarna er helemaal niets meer aan verdiend kan worden.
"DRM staat voor het beheren van inhoudsrechten, niet het beperken ervan." Ben ik het niet mee eens. Het beperkt. Als Apple wil dat ik de film alleen op een Apple tv kan afspelen dan zal dat niet op een Philips tv lukken.
Spijker op zijn kop. Micro-payment is de manier. En laten we wel zijn, ik zou er al geld voor over hebben om een film te kunnen bekijken *zonder* verplichte unskippable headers, producenten logo's, previews, reclame en andere zooi. Gewoon een Euro in de gleuf, op start drukken en klaar.
Er is wel degelijk een manier om geld aan content te verdienen, ook zonder DRM. Kijk bijvoorbeeld naar iTunes. Al hun muziek is tegenwoordig DRM-vrij. Kijk bijvoorbeeld naar Magnatune, betaalde content van indie artiesten, maar wel DRM-vrij en ze moedigen zelfs aan om (op beperkte schaal) met je vrienden te delen. Er zijn legio voorbeelden van betaalde content zonder DRM.
Het onwenselijke alternatief is volgens hem dat bedrijven de content af gaan schermen in hun eigen walled gardens.
Volgens mij heeft Jeff Jaffe hier duidelijk een bord voor z'n kop. De specificatie die ze nu ontwikkelen faciliteert namelijk expliciet het afschermen van content binnen een walled garden. Wat is Netflix anders dan een walled garden? Dat is juist de definitie van een walled garden, hun content is afgeschermd achter een betaalmuur.

Persoonlijk vind ik een walled garden ook helemaal niet erg. Neem iTunes, Netflix, de App Store, Google Play. Dit zijn allemaal walled gardens, en zolang de service maar goed is zijn mensen best bereid te betalen. Waar ik moeite mee heb is dat ze daar bovenop nog een laag DRM willen hebben die de rechten die ik als consument heb juist kunstmatig beperken. Waarom zou ik mijn content niet mee kunnen nemen naar een nieuw apparaat? Waarom val ik buiten de boot als ik Linux gebruik? Dit zijn de scenario's die specifiek door DRM onmogelijk worden gemaakt en die het W3C nu wil faciliteren.
Maar dat is nu net het voordeel van DRM specificaties in HTML5, hiermee wordt het dus mogelijk om fatsoenlijk DRM op alle platformen te implementeren dus ook jouw geliefde linux.. Ik ben juist blij dat ze dit in de specificaties opnemen, dan zijn we sowieso af van dingen als flash en silverlight..

En dan nog, wie ben jij om te beslissen voor anderen wat zij met HUN content doen, dat is niet aan jou, dat is aan hun.. ga anders zelf lekker content produceren en gratis zonder drm aanbieden, eens kijken hoe lang jij het volhoudt om nog meer content te produceren..
Volgens mij begrijp je niet helemaal wat deze specificatie omhelst. Die maakt het dus nog steeds niet mogelijk om cross-platform content af te spelen, aangezien deze by design communiceert met closed source platform-specifieke DRM plugins.

Op zich had je dat ook al kunnen weten als je de moeite had genomen de allereerste alinea van het artikel te lezen:
De controversiŽle specificatie beschrijft een manier waarop browsers plug-ins voor drm aan kunnen roepen.
En dan nog, ik ben een consument. Dus ik beslis wat ik wel en wat ik niet consumeer, en mijn beslissing is dus om DRM te vermijden wanneer mij dat onredelijk beperkt in m'n rechten. Dat is geheel mijn keus, dank je wel.
iTMS is inderdaad DRM vrij, en heeft de iTMS ooit een deuk weten te maken in het illegale aanbod?

En neen, DRM op zich maakt die situaties niet onmogelijk, het is de implementatie van de gekozen DRM methode die dat doet. Met DRM op zich is niets mis wanneer het goed geÔmplementeerd word.
Idd, *geen enkele consument* wil DRM. Veel consumenten willen best betalen voor kwaliteit, maar dat is het punt.. DRM verlaagt de kwaliteit. Jammer dat dit er komt dus.
Inderdaad DRM vermijd ik, sinds ik een game officieel kocht "anno 1404", door een probleem met pc , herinstallatie, een paar maal installeren en ik kreeg het niet meer geactiveerd. Enkele mails naar Ubisoft , geen antwoord uiteraard.
Heb dan maar het spel gedownload. Werkt perfect zonder problemen.
Tuurlijk wil ik gerust DRM gebruiken, zolang het niet in mijn weg zit. Neem nu bijvoorbeeld Steam, een prima platform dat o.a. als DRM mechanisme dient.
Mijn handtekening hebben ze ook.
Waarom specificeert het W3C dan niet ook de implementatie, zodat deze opensource kan zijn?
Da's een beetje een probleem met DRM he: zodra de implementatie open-source is, is deze per definitie ook te kraken. Dat is nu trouwens met veel DRM-systemen ook al zo; het is vooral een barriŤre om controle over media te houden bij gebruikers die er niet veel verstand van hebben.

Op zich ben ik wel voorstander, DRM gaat niet zomaar weg en kan nog steeds nuttig zijn, en dit zorgt ervoor dat je dit soort content zonder Flash/Silverlight kan bekijken straks. De krachtigste "handtekening" is gewoon dat je geen gebruik maakt van DRM-diensten.
Da's een beetje een probleem met DRM he: zodra de implementatie open-source is, is deze per definitie ook te kraken
Dat is echt complete nonsens. Encryptie stoelt op het geheim zijn van de sleutel, niet van het algoritme waarmee de boel versleuteld wordt.
Behalve dan dat bij DRM de gebruiker per definitie de sleutel heeft. (Anders zou hij het ook niet af kunnen spelen.)

[Reactie gewijzigd door pvcholten op 10 mei 2013 18:01]

Dat is inderdaad denk ik het grootste probleem, het is een client-sided systeem en dus is de sleutel eigenlijk al zichtbaar. Een sleutel per gebruiker is ideaal, maar dan doemen er weer nieuwe problemen op.

Ik ben benieuwd hoe ze dit willen oplossen!
Ze zouden een verplichte online drm check kunnen inbouwen en autorisatie dus server side word gedaan en niet eens aan de client side, dat zorgt er wel voor dat dus niet offline kan afspelen, alleen als in internet verbinding hebt. Wat ook het originele plan voor blu ray spelers was, verplicht internet verbinding om drm check uit te voeren.
Dat betekend nog niet dat algoritme niet openbaar kan zijn en dat het dan per definitie onveiliger maakt. Sleutel voert men toch pas later toe, dat kan in een apparaat firmware zijn die op zij beurt weer hardwarematig is afgesloten, of online staan bij de makers.

Dat bij afspelen de sleutel nodig is bij de eind gebruiker betekend nog niet dat je er zomaar bij kan, zal de hardware in veel gevallen moeten hacken of servers van makers om aan de sleutel te komen.

Edit/
In veel gevallen zit er niks anders op dan de chip fysiek te hacken(Invasive attack), en dan letterlijk fysiek. Bij atmel chips moet je chip zelf gaan etsen en laag voor laag weghalen om zo bij geheugen blokken te komen en kijken welke cel op 1 of 0 staan en zo dus geheugen fysiek uitlezen. Dat is vrij lastig om te doen en bij nieuwer chips al zo goed als onmogelijk gemaakt. Verder is het nog niemand gelukt om beveiliging van de chips te breken op softwarematig manier.

En dan heb ik het over simpel micro controllers, speciale beveiliging chips zullen speciaal ontworpen zijn dat zelfs fysiek hacken van de chip erg lastig word of zelfs onmogelijk met huidig kennis.

[Reactie gewijzigd door mad_max234 op 10 mei 2013 19:18]

Dit gaat over een specificatie voor HTML. Daar komen dus geen DRM chips aan te pas anders hebben oudere devices straks allemaal een probleem.
Ja dat snap ik, was maar ťťn van de voorbeelden dat je niet zomaar bij de key kan als moet je die wel in je bezig hebben om iets af te spelen.

Zullen ongetwijfeld manier bedacht hebben dat je niet bij de key kan(althans dat is de bedoeling), anders kunnen ze net zo goed geen drm systeem bouwen. ;)

En chip gebruiken betekend niet dat je niet backwards compatibel systeem kan maken, dat zal geheel afhangen van systeem dat je maakt. Chip is maar chip, en doet wat jij wilt dat die doet.

[Reactie gewijzigd door mad_max234 op 11 mei 2013 17:32]

Sterker nog, over het algemeen zijn open-source beveiligingsmethoden beter te vertrouwen. Er zijn immers meer mensen die het algoritme hebben bestudeerd en eventuele bugs gefixt. In de beveiliging worden algoritmen waarvan de broncode niet beschikbaar is per definitie als onveilig beschouwd.

Open-source algoritmen zoals RSA zijn simpel genoeg om door een gewone software developer geÔmplementeerd te kunnen worden. Met die algoritmen wordt jouw connectie met de bank en mail (als je SSL gebruikt) beveiligd. :)
En precies daarom wordt DRM niet tot (serieuze) encryptie gerekend. DRM probeert af te dwingen dat je met bits bepaalde dingen wel mag doen, en andere dingen niet. Dat laat de wiskunde simpelweg niet toe.
Juist hetgeen wat jij zegt hier is "complete nonsens" in de context van deze discussie - geval "klok horen luiden, niet weten waar de klepel hangt".

DRM vereist twee eigenschappen om de toegang tot de videodata te beperken.
  • Alleen de DRM kan de versleutelde datastroom ontsleutelen
  • De ontsleutelde video wordt direct op het scherm weergegen, en de datastroom gaat nergens anders heen.
Het probleem van een open source product is dat de gebruiker zelf het gedrag van de software kan aanpassen, waardoor deze twee eigenschappen niet meer gelden. Een open source implementatie van de eerste eigenschap houdt in dat iedereen de code en de implementatie van sleuteldistributie ontvangt - alles wat je nodig hebt om de datastroom te ontsleutelen.

De tweede eigenschap is op zeker niet te implementeren in een open source product - ieder open source product kan namelijk worden aangepast om de videostream niet op het scherm weer te geven maar bijvoorbeeld in plaats daarvan te schrijven naar een bestand. Daarom wordt DRM nu ook bijvoorbeeld veel geimplementeerd in hardware om te voorkomen dat de sleutel uit het geheugen is uit te lezen en dat de machinecode gepatcht kan worden om de videostream naar een bestand te schrijven.

[Reactie gewijzigd door DCK op 10 mei 2013 18:59]

Het blijf toch heel simpel: zolang de gebruiker de data die met DRM beveiligd is op een gegeven moment kan afspelen, zijn op datzelfde moment de niet-geencodeerde data ergens in een geheugen beschikbaar. Ze kunnen het lastiger maken om dit eruit te halen, maar op geen enkele manier onmogelijk maken. Dat is gewoon geen mogelijkheid, maar dat weigeren ze in te zien.

Zelfs als alles met HDMI / HDCP naar de TV moet zou je de unencrypted stream nog wel weer uit de TV kunnen aftappen. Het is gewoon vechten tegen de bierkaai, maar de media-industrie wil het niet inzien.

Het is dus ook zonde als dergelijke technieken een plek krijgen in HTML, want het is alleen maar vervuiling die weinig concreets zal gaan bereiken.
Mooi hoe mijn reactie omlaag wordt gemod en de jouwe omhoog wordt gemod .oisyn, geeft toch maar aan hoe weinig kennis users op Tweakers hebben van DRM.

Zoals DCK aangeeft is het wel degelijk een probleem dat de DRM-software opensource is. Het punt is niet de encryptie, het punt is juist dat je de videostream (bijvoorbeeld) wel moet kunnen afspelen op je pc; je hebt die key dus, die kun je niet geheim houden. Je open-source implementatie moet hem kunnen lezen om de video af te spelen, en zodra een open-source implementatie hem kan lezen is die ook om te bouwen om de video op te slaan...

De reden dat ik in mijn post verder zeg voorstander van DRM te zijn is niet dat ik DRM een goed principe vind (integendeel)... Ik denk dat het nodig is totdat content-eigenaars eindelijk tot het inzicht komen dat de huidige modellen niet meer werken. Tot die tijd is maximale beschikbaarheid van content wel belangrijk, en een standaard als deze draagt daaraan bij.
Is het niet zo dat in elke vorm van drm de video op het scherm getoond word en daarom in je video geheugen word geladen en daarom altijd wel kan worden opgeslagen. Je video kaart kan alleen maar rgb waarden renderen. Dus het is onmogelijk om tegelijk een serie 2d arrays met rgb waardes aan te bieden en tegelijk te verbergen. Je kan het alleen iets moeilijker maken. Open source drm maakt het misschien alleen wat makkelijker.

[Reactie gewijzigd door kajdijkstra op 11 mei 2013 10:52]

Is het niet zo dat in elke vorm van drm de video op het scherm getoond word en daarom in je video geheugen word geladen en daarom altijd wel kan worden opgeslagen. Je video kaart kan alleen maar rgb waarden renderen. Dus het is onmogelijk om tegelijk een serie 2d arrays met rgb waardes aan te bieden en tegelijk te verbergen. Je kan het alleen iets moeilijker maken. Open source drm maakt het misschien alleen wat makkelijker.
Uiteindelijk moet het toch als een 2D plaatje van een blok pixels op een scherm worden weergegeven, anders kunnen je ogen het niet oppikken.

En als een menselijk oog het kan waarnemen, dan kan een digitaal oog (een camera) dat ook.

De enige manier om dan nog DRM af te dwingen is mensen een chip in hun hoofd implanteren en de schermen voeren met een versleutelde berg ruis. Maar daar word je denk ik niet heel vrolijk van :+
AES is volledig open source, en toch niet te kraken.
Het zal best te kraken zijn, maar op dit moment zijn computers nog niet snel genoeg om alles te proberen. Tijd lijkt de grootste medestander van AES te zijn op dit moment, maar dat zal in de toekomst ook wel weer veranderen.
Kraken is wat anders dan brute-forcen he? Als je maar lang genoeg sleutels blijft proberen is elke encryptie-techniek te brute-forcen. Dat betekent nog niet dat de encryptiemethode te kraken is. Mocht je dat consequent kunnen redden in overzienbare tijd dan is alleen de sleutel wellicht niet lang genoeg.
Juist een van DE grote ideŽn binnen cryptografie is dat een encryptie pas veilig is als je kan zeggen dat het niet te kraken is als je niet het wachtwoord hebt, zelfs als alles over een systeem bekend is. Dit is de enige reden waarom RSA nog als veilig wordt gezien. Je mag er bij dat algoritme van uit gaan dat iedereen op deze planeet weet hoe het werkt (uiteraard niet helemaal waar, maar iedereen met toegang tot een bibliotheek of tot internet en de verstandelijke vermogens om te begrijpen hoe het werkt kan het leren), maar tot nu toe zijn zaken die met RSA zijn versleuteld enkel te kraken met brute force methoden. RSA is zeer waarschijnlijk het enige wat tussen jouw bankrekening en een groep hackers in zit.

Security through obscurity daarentegen is geen security. Zodra ťťn persoon weet hoe iets werkt dat volgens dit idee is gebouwd mag je het te beveiligen object als volledig onbeveiligd beschouwen omdat dan meteen iedereen kan inbreken.

[Reactie gewijzigd door Amanoo op 10 mei 2013 18:22]

DRM en open source sluiten elkaar zo'n beetje uit.

Als er een open-source player zou bestaan die DRM-beveiligde content kan afspelen, kan je heel makkelijk de source downloaden, en aan de hand daarvan een versie maken die de DRM stript.
DRM en OSS sluiten elkaar helemaal niet uit. Het is dat wij dat er van maken. Waarom denk je dat bijvoorbeeld HDCP is uitgevonden?
DRM en OSS sluiten elkaar wel uit. Volgens wikipedia: "Each HDCP-capable device has a unique set of 40 56-bit keys. Failure to keep them secret violates the license agreement.". Als de broncode open is, is het niet mogelijk om deze set van sleutels geheim te houden.
uhm sleutels en broncode zijn 2 compleet verschillende dingen, de broncode kan rustig opensource zijn...
Dat klopt, alleen is het probleem dat bij drm de sleutel op een of andere manier aan de eindgebruiker gegeven moet worden, anders kan hij de media niet zien. Bij alle drm oplossingen (ook hdcp) moet er ergens dus in de keten een stuk software zijn die voor de eindgebruiker niet te doorgronden is, en de content decodeert met de meegeleverde sleutel. Als dat stuk software open source is, dan kan ik als eindgebruiker die software aanpassen zodat ik deze sleutel kan gebruiken om de media zelf te decoderen.
uhm sleutels en broncode zijn 2 compleet verschillende dingen, de broncode kan rustig opensource zijn...
Het probleem met open-source DRM algoritmes is dat er hoe dan ook ergens een sleutel moet worden uitgewisseld, anders kan de gebruiker het hele handeltje gewoon niet zien.

Bij een open-source algoritme is het natuurlijk veel te makkelijk om er een routine in te zetten die die sleutel aftapt en de boel opnieuw te compileren. Of de uitvoer van je DRM-ontsleutel-plugin niet naar een scherm te sturen maar gewoon te dumpen naar een bestand op je schijf... of gewoon rechtstreeks naar TPB ;)

Hoe je het ook wil implementeren, als je het open-source maakt ondermijn je het hele idee van DRM: De controle leggen bij de content-uitgever, niet bij de gebruiker.
"Google heeft de specificatie al in Chrome geÔmplementeerd"

Wat? En het is nu nog maar een draft? Er kan nog van alles veranderen en Chrome implementeerd het al?
Als er geen implementatie is hoe kunnen ze het dan testen zodat er verbeteringen kunnen worden gemaakt?
Denk je dat het W3C hun specificaties niet zelf testen?
Als er geen implementatie is hoe kunnen ze het dan testen zodat er verbeteringen kunnen worden gemaakt?
In de praktijk gebeurd het bijna altijd, dat het eerst geÔmplementeerd word en op basis van de implementatie de draft geschreven word, omdat je tegen allemaal dingen aan loopt in de implementatie waar je van tevoren nooit aan denkt. Het is vaak een dynamisch proces waar w3c en bijvoorbeeld google en apple devs nauw samenwerken, De schrijver van de draft is ook altijd iemand van google of apple of een ander groot bedrijf die vaak al een hoop research gedaan heeft op het gebied van de desbetreffende draft. En de teams erachter bestaan ook uit devs van deze bedrijven. Het is niet zo dat W3C dicteert. Zij functioneren meer als manager tussen alle grote bedrijven, En W3C zorgt er daadwerkelijk voor dat nieuwe technologien worden doorgedrukt en niet worden tegengehouden omdat het even niet in het belang van een bedrijf is, Dan heeft het bedrijf gewoon pech.

[Reactie gewijzigd door kajdijkstra op 11 mei 2013 11:12]

Grootste gedeelte van HTML 5 is nog maar een draft ;)
Het begint een beetje een Internet Explorer verhaal te worden bij Chrome. Zelf dingen bedenken en implementeren terwijl de specificatie niet of nauwelijks af is.
Daar hebben ze hele leuke termen vorm als POC (Proof of Concept) , zoals de naam al zegt is zo'n POC ervoor bedoeld om te kijken of de ingeslagen weg uberhaupt haalbaar is.
Probleem is echter dat ze het meteen toevoegen aan de normale versies (ipv alleen in de dev-versies) waardoor het zijn doel voorbij schiet. Daardoor heb je dat op den duur bepaalde sites al zaken gaan implementeren waardoor je weer verschillen krijgt. Dat is de reden dat je nu voor een heleboel websites een slechte weergave krijgt in andere browsers, puur door al die prefixen van Chrome e.d.
Als het alleen in de development versie zou zitten zou niemand er voor z'n sites gebruik van kunnen maken. Dan wordt het dus ook nooit op een grotere schaal getest dan enkele proof of concepts. Bovendien zou er dan nog meer teruggegrepen worden op Flash-based oplossingen omdat dan plots heel erg veel nieuwe (maar vaak inderdaad experimentele) functionaliteit simpelweg niet beschikbaar is.

Als developer heb je nu de keuze: Of je gebruikt die prefixes niet en beperkt je tot de stabiele standaarden. Of je maakt gebruik van vendor-specifieke prefixes en instabiele standaarden met het risico dat het meer onderhoud kost voor je site, maar je kunt wel aanzienlijk meer functionaliteit gebruiken. Gezien de hoeveelheid developers die de prefixes gebruiken is er veel vraag naar die functionaliteit en is het dus fijn dat Chrome e.d. deze al aanbieden.

Waar het pas fout gaat is als developers de prefixed versies gebruiken zonder de nodige effort erin te steken om zaken aan te passen als de specs veranderen (want dat kan nog in de draft phase) en niet goed met alle browsers testen. Dat is inderdaad soms een probleem, maar het alternatief zou betekenen dat we allemaal nog HTML4 en Flash moeten gebruiken en dat HTML5 voorbehouden blijft aan tech previews.
Het is een draft, die hoort ook nog niet in productie te worden genomen. Leuk dat je het alvast wilt testen, maar zo werkt dat dus niet. Een concept-auto komt ook niet meteen op de markt.

Het gebruiken van prefixes zorgt ervoor dat het web steeds verdeelder wordt en dat is natuurlijk niet de bedoeling. Het is buitengewoon irritant als je door al die prefixes een css bestand krijgt wat 3x groter is dan wat nodig hoort te zijn.

Juist dat laatste gebeurd erg veel en moet daardoor voorkomen worden door er maar lukraak dingen aan toe te voegen. Als Chrome nu dingen toevoegt maar anderen niet, wie zegt dat die developers ook alvast de andere items erbij gaan zetten om de site compatible te krijgen? Nu krijgt Chrome een oneerlijke voorsprong die dadelijk weer helemaal anders kan gaan. Want ze kunnen natuurlijk niet de implementatie helemaal aanpassen, juist omdat ze al een draft hebben gebruikt die mogelijk nog gaat veranderen.
@Martinspire
Deze "draft" implementatie moet je anders zelf aanzetten in chrome://flags

En elke behoorlijke sitebouwer prefixt zijn code met -webkit, -moz, -ms, -o en optioneel -khtml, gevolgd door de non-prefixed variant.
Elke behoorlijke sitebouwer hoort ook te weten dat hij prefixes beter uit de weg kan gaan.
Ok, dat wist ik dan niet, maar dat is dan wel 1 van de weinige waar ze dat zo mee gedaan hebben.
Tja, een spec word zelfs pas een standaard nadat er verschillende implementaties zijn van de spec. HTML5 zal bijvoorbeeld nog jaren nodig hebben om een standaard te worden en de spec van HTML5 is vandaag ook nog altijd niet volledig. Zullen we dan ineens alle browser beginnen afschieten?
W3C is nogal traag. Het duurt jaren voor een specificatie van draft naar final status gaat. Als browsers zouden wachten op de final van de spec voor ze met implementatie beginnen hadden we nu op de browsertechnologie van 3-4 jaar geleden gezeten.
Traag? Misschien. Maar vooral erg grondig, elk aspect wordt uitgebreid getest waardoor de standaard ook een goede standaard is.
En om te testen... moet je het implementeren! Sterker nog, meestal wordt iets geen standaard totdat er twee onafhankelijke referentieimplementaties van zijn.
Hebben ze daar niet een goede reden voor? Een standaard als HTML5 doe je niet zomaar even overnieuw omdat je te weinig tijd nam om het grondig te testen.
maar 'HTML5' is nog geen definitieve standaard voor het geval je het nog niet wist, eigenlijk is het zelfs te gek om los te lopen dat er al zoveel gebruik gemaakt wordt van een standaard die in ontwikkeling is...
Het W3C is net als het Debian team: ze brengen iets uit en zeggen "dit is nog niet helemaal stabiel". Ondertussen is het knetterstabiel (debian testing...)
HTML5 in zijn geheel nog niet, maar specifieke onderdelen zijn wel al volledig voltooid.
Is het in Chrome geimplementeerd of in Chrome Canary? Dat is nogal een verschil..
Uhm.. Je weet toch wel dat HTML5 zelf ook nog steeds niet definitief is, en dat de HTML5 die geimplementeerd is in de browser allemaal nog kan veranderen, daarom zit je nu ook nog als devver behoorlijk opgescheept met heel veel vendor-prefixes...
HTML5 in zijn geheel is inderdaad nog niet af, maar onderdelen daarvan zijn wel al gewoon stabiel.
Ben je jaloers ofzo dat Chrome en Firefox gewoon alles snel implementeren??? Doet jou precious internet explorer dat niet?
Ik denk dat het vooral hopen is dat Mozilla stand houd tegen deze specificaties, firefox is nog steeds groot genoeg om dit hopelijk te blokeren en gezien Mozilla zich altijd heeft ingezet voor een open internet lijkt het me zeer goed mogelijk dat ze dit proberen te blokkeren.
En jij denkt dat content providers dan opeens denken "oh wacht eens even, dan doen we het gewoon lekker zonder drm!". DRM hoort gewoon bij een Internet waar commerciŽle partijen bepaalde diensten aanbieden, punt.
Wees blij dat er een standaard manier is om er mee te werken i.p.v. voor elke source een andere implementatie te moeten verwerken.
Ik snap persoonlijk het gezeur van de Free Software Foundation en de Electronic Frontier Foundation niet zo. Ik denk persoonlijk dat DRM een van de rederen is dat Silverlight zo snel de video's overnam van Flash, en ook hetgeen is wat HTML5 video nu tegenhoud om op een masieve schaal gebruikt te gaan worden voor professionele (betaalde) content.

Daarnaast (en misschien interpreteer ik dat anders), vind ik het 'open web' juist ook betekenen dat dit ook kan, onbegrenste mogelijkheden in plaats van huilen dat alles persť open source moet zijn.

[Reactie gewijzigd door M3! op 10 mei 2013 18:02]

Helemaal mee eens, html5 is op dit moment te open voor services zoals netflix of spotify. Met alleen html5 is het te makkelijk om deze content te rippen en opnieuw te distribueren. Ik vind wel dat we niet moeten doorslaan en daarmee ook alle tekst, images, javascript en wat else ook achter deze drm muur zetten.

Beetje common sense zal erg belangrijk worden hiermee. ;)
feit is, dat commerciele drm partijen vaak nauwelijks oog hebben voor niet-windows systemen,

wat zou er gebeuren als MS weer eens een bedrijfje omkoopt om drm x niet uit te geven voor android, zijn we dan morgen allemaal 'verplicht' om windows telefoons en tablets te nemen, want dat alternatieve bedrijf krijgt gewoon geen rechten van warnerbross, dus naar de concurentie lopen kun je als klant wel vergeten...

gaan we nog een stapje verder, mensen die firefox-os of dat qt-gebaseerde os dat door-ontwikkeld op wat nokia met meago was begonnen. mogen zulke partijen dan maar fluiten naar de helft van alle internet content.

drm op het web is al erg genoeg, maar in de huidige implementatie kun je verwachten dat het een windows only ding word, en dat bijv linux gebruikers, na het flash en silverlight debakel nu weer met een drm-hell opgescheept worden.
Precies. Bovenstaande reactie is wat mij betreft de belangrijkste reactie van het hele artikel.Waren we als Linux gebruikers eens een keer niet achtergesteld, komen ze weer met Secure Boot en DRM in HTML5 aanzetten. Die mediabedrijven geven echt helemaal niks om Linux, dus dat wordt weer 3 keer niks natuurlijk. Ik ben principieel tegen DRM (voornamelijk omdat je bijna altijd dubbel betaald, koop je een boek op een iPad en wil je het op je eReader: koop het gerust nog maar een keer). Maar met de beperkingen die DRM in HTML5 oplegd kan ik op zich nog wel leven, mijn principieel standpunt die kan ik nog wel vergeten eventueel. Maar dat er straks weer OSen worden gediscrimineerd: daar ben ik klaar mee. Je zit nu al met die Adobe troep die niet native onder Linux werkt om je ebooks te krijgen, maar dat schijnt nog wel onder WINE te draaien.
Ik heb een paar maanden geleden een Windows telefoon gekocht, waarvan ik wist dat ik niet alle apps die ik op Android en daarvoor IOS had kan draaien. Dat was een bewuste keuze van mijzelf, net zoals het voor jou een keuze is om Linux te draaien. Een keuze waarvan je de consequenties wist.

[Reactie gewijzigd door M3! op 10 mei 2013 21:55]

Flash is ook een browser-based plug in.
Maakt dat het platform onafhankelijk?
Nee, en op dezelfde manier is elke plugin platform afhankelijk en zal er toch echt een specifieke linux versie van de desbetreffende plugin moeten worden ontwikkeld door de uitgevers van het desbetreffende DRM systeem.
Met andere woorden, precies dezelfde platformafhankelijkheden als flash en silverlight.
En wie zegt er dat het weer zoiets word als Silverlight? Als het in de HTML5 spec zit kan iedereen er een DRM plugin voor de browser voor maken, dan word het dus browser based ( = platform onafhankelijk).
Ware het niet dat er in Linux vooral open-source API's gebruikt worden waar je te pas en te onpas video-frames uit kan aftappen en dus de DRM van media af kan slopen.

Denk je nu echt dat er een derde partij zo gek zal zijn om een browser-plugin te schrijven die hun DRM implementeert?

De HTML5-standaard specificeert namelijk alleen de interface naar DRM-plugins van derden toe. Vergelijkbaar met de Common Interface-standaard voor DVB (satelliet en kabel) ontvangers.
Loller1, hoe bedoel je dingen die ze zelf verzinnen? Vertellen ze leugens? IMO vertellen ze gewoon hun problemen met closed source software en MS in het bijzonder.

Ze hebben ook goede dingen gedaan. GNU/Linux is wel een product van de FSF. Toch een hele prestatie vind ik.
@7gerard
Ho... GNU/Linux is GEEN product van meneer Stallman.
Linux is ontwikkeld door Linus Torvalds. De GNU delen door de FSF (geloof ik dat het zat). Het is dus een mix van twee delen, eerst was het de bedoeling dat GNU z'n eigen kernel kreeg (GNU Hurd) maar dat is, uhm, nog steeds in ontwikkeling dus zijn mensen maar GNU gaan mixen met de toen vrij beschikbare Linux kernel.
Klopt, maar ze hebben de basis gelegd. Of het ook zo'n succes was geworden als Linus Torvalds zich er niet mee had bemoeid weet ik niet.
Ik ga niet alle punten beantwoorden. Temeer ik ook niet met alles eens ben. Het is de visie van de FSF.

1. Volgens hen zou Microsoft de educatie van kinderen verstoren doordat ze reclame maken. Sinds wanneer is dat vreemd?
Sinds wanneer is dat goed?

4. Deze is simpelweg belachelijk: hoezo wordt je geforceerd te upgraden als er een nieuwe versie van Windows/Office uitkom? Windows verliest niet plots functionaliteit ofzo...
Dit is wel degelijk waar en wordt Vendor Lock-in genoemd. Ik heb het zelf meegemaakt toen een grote leverancier onaangekondigd met nieuwe bestandsformaten aan kwam zetten.

7. En het laatste: beveiliging. Je kan een hoop zeggen over dat bij Windows, maar Windows Vista en 7 waren grote vooruitgangen op dit punt (zo ook Windows . En als ik mij niet vergis heeft Linux er met Android ook wel een handje van in, in virussen, etc.
Qua virussen is voor zover ik weet het onderliggende besturingssysteem nooit het probleem geweest, maar lag het aan Android zelf. Maar pin me er niet aan vast.
Qua virussen is voor zover ik weet het onderliggende besturingssysteem nooit het probleem geweest
Sterker nog, bij Android is het 99,9 van de 100 keer de gebruiker zelf die de app de rechten geeft om zijn ding te doen.

Maar goed het gaat hier over DRM, niet over virussen.

Ik ben zelf geen voorstander van DRM maar het blijft een feit dat content aanbieders er om vragen. En zolang die content aanbieders er maar rekening mee houden dat ik dingen, die ik echt goed vindt, DRM vrij wil hebben hoor je mij niet klagen.

Daar wringt echter meestal de schoen. Content aanbieders willen vaak hun rechten tot het einde der tijden beschermen, waardoor ik geen rechten meer heb... Anders dan het recht om te slikken.
"Daar wringt echter meestal de schoen. Content aanbieders willen vaak hun rechten tot het einde der tijden beschermen, waardoor ik geen rechten meer heb... Anders dan het recht om te slikken."

Los van het technische aspect van DRM vind ik dit ook het grootste bezwaarpunt.
"Ik denk persoonlijk dat DRM een van de rederen is dat Silverlight zo snel de video's overnam van Flash,"

Eeh, en Silverlight werdt ook zooo ontzettend goed opgepakt door de industrie....
..not.
Ik snap dat niet iedereen blij wordt van bepaalde vormen van DRM, maar als het gewoon werkt zou een dergelijke specificatie zou er voor zorgen dat bijvoorbeeld uitzendinggemist.nl eindelijk eens af kan stappen van plug-ins (Silverlight) die de DRM verzorgen. In de context van Jaffe's opmerkingen zou ik dit toch wel als een klein stapje vooruit beschouwen.
Gewoon werken is hier dan wel het sleutelwoord. Als ik de standaard niet zelf werkend kan krijgen op een zelfgemaakt OS dat draait op een zelfgemaakte CPU, dan ben ik niet van mening dat het "gewoon werkt". En volledige platform independency is juist een van die sterke kanten van HTML. Bij DRM heb je grote kans dat er ineens een binary blob in je standaard zit, die alleen bruikbaar is voor enkele platforms. Dat geeft weer kans dat een heel obscuur platform het niet ondersteunt, maar misschien geldt dat ook voor bepaalde settopboxen, bepaalde game consoles, misschien zelfs FreeBSD of zelfs voor Linux. En als gebruiker van net dat platform kan je daar heel erg chagrijnig om worden. Daarom moet het ook op dat hypothetische door mij gebouwde platform werken. Als het in principe daarop aan de praat te krijgen is, dan is het overal op aan de praat te krijgen.

Persoonlijk ben ik dan ook wel zo vrij om te denken "als men mij niet de content wil leveren, dan haal ik het zelf wel", en vervolgens op de minder legale websites te gaan rondneuzen. Als dat nu ook in de HTML-standaard wordt ingebakken krijg ik des te meer die neiging. Er was dat ene ding dat Gabe Newell zei over hoe piraterij een service-probleem is. Dat is gewoon waar. Als men me van alles niet legaal wil aanbieden en mij legaal niet die service wil aanbieden die ik verlang heb ik met illegaal geen moeite. En het zou niet voor het eerst zijn dat DRM mij de richting van illegaal materiaal op duwt. Zo op ik apparatuur die incompatible is met de ebook DRM van Adobe. En laat die DRM nu net veel te populair zijn bij leveranciers. Driemaal raden wat voor soort ebooks ik gebruik. Als ze nu platform incompatibiliteit in HTML gaan inbouwen wordt ik dan ook echt niet blij.

[Reactie gewijzigd door Amanoo op 10 mei 2013 22:46]

Het eigenlijke probleem is dat de DRM oplossingen platform gebonden zullen zijn. Denk aan x86 DRM binaries welke niet op embedded systemen kunnen werken (ARM, MIPS) en gebonden zijn aan een enkel besturingssysteem. Dit is nu al een struikelblok voor Silverlight en lost het probleem niet op.
Je maakt een uitstekend punt hier. Juist door alleen de API voor plugins te specificeren, zal je gaan zien dat je weer DRM systemen gaat krijgen die alleen op een recente windows of misschien op mac werken, maar die verder niet beschikbaar zijn. Die kant moeten we niet op willen.
Klopt helemaal, maar als het niet platform-gebonden was dan was het helemaal open-source, en DRM + open-source is geen goede combinatie :+
als het niet platform-gebonden was dan was het helemaal open-source
De link die jij hier legt bestaat volgens mij niet. De binary drivers van AMD en Nvidia zijn op alle platforms beschikbaar, maar zeker niet open-source. Steam gaat nu ook die kant op, en ook zeker niet open-source.

De Linux fundies, ja die zijn tegen. Maar laten we eerlijk zijn, die zijn bijna tegen alles wat zelfs maar commercieel ruikt. In die club lijk je alleen te mogen verdienen aan je diensten, niet aan je code.

Ik geloof meer in een Linux met Mixed source. Geen enkel probleem, zolang de aanbieder maar niet vergeet dat ik als consument ook rechten heb. En als ik die niet krijg, dat ik dan wel ander kanalen zoek, desnoods illegale.
Hoewel DRM op zich naar mijn mening niet goed is, lijkt me dit toch wel een redelijke goede ontwikkeling. Anders stappen bijvoorbeeld Uitzending Gemist, RTL Gemist en KPN itv online nooit over op HTML en blijven hangen in Flash en Silverlight.
Tsja, persoonlijk heb ik geen enkele last van Flash en Silverlight problemen in alle drie mijn browsers niet, heb nooit crashes of andere ongein gehad, dus van mij mag het blijven. :)
Op telefoons en tablets werkt het niet, ja Flash is er wel voor android maar werkt niet echt goed. Tevens werkt Silverlight niet op Ubuntu.
Je hebt helemaal gelijk en daar komt nog bij dat vanaf Jellybean 4.1 Flash op Android ook niet meer ondersteund wordt. Je schijnt nog wel een APK die voor ICS bedoeld is van internet te kunnen plukken. Maar ja dat is ook niet voor iedereen weggelegd. Verder wordt Flash voor Linux sinds 11.1.x ook niet meer actief ontwikkeld(alleen nog security updates dacht ik en misschien nog non-security bugfixes). Daarnaast heeft Adobe zelf ook toegeven dat Flash dood is en ze zijn zelf al begonnen met HTML5 tools te maken, zodat die op termijn de Flash dev tools kunnen gaan vervangen als inkomstenbron.
Flash voor Android is ook geschrapt.
Ik heb eigenlijk maar 1 antwoord en dat is: "Denk groter"

Als de omroepen het willen is alles mogelijk. Het is een kwestie van willen.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBSalaris

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste website van het jaar 2014