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: 104, views: 14.956 •

De Electronic Frontier Foundation heeft formeel bezwaar gemaakt bij de W3C tegen het opnemen van drm-technologie in de html5-standaard. Volgens de beweging leidt het voornemen tot minder webinnovatie en hindert het de vrije toegang tot content.

EFFDe HTML Working Group van het World Wide Web Consortium publiceerde onlangs zijn eerste draft over hoe drm-mechanismes via een api door een browser ontdekt en ingezet kunnen worden. De voorgestelde specificatie, Encrypted Media Extension, bevat zelf geen drm-systeem.

Het invoegen van een drm-mechanisme in de html5-standaard wordt ondersteund door grote partijen, waaronder Microsoft, Netflix en Google. Laatstgenoemde heeft de specificatie al in zijn Chrome-browser verwerkt. Toch kwam er ook veel kritiek, onder andere van de Free Software Foundation en de Electronic Frontier Foundation, omdat het invoegen van een drm-systeem in open webstandaarden zou ingaan tegen de kernwaarden van de W3C.

Inmiddels heeft de EFF na het verzamelen van handtekeningen een officieel bezwaarschrift ingediend bij de W3C. Volgens de digitale burgerrechtenbeweging, die lid is van de W3C, wordt met het invoegen van drm-technologie in de html5-standaard voor de eerste maal een 'zwarte doos' gecreëerd volgens de wensen van de entertainmentindustrie. Bovendien zou drm in de praktijk nauwelijks beveiliging bieden en hindert het juist gebruikers om toegang te krijgen tot content, zo redeneert de organisatie.

De EFF vreest dat implementatie van de Encrypted Media Extension-api er andere contentpartijen ook toe aanzet om drm te gaan implementeren. Hierdoor zouden bijvoorbeeld afbeeldingen en tekst niet langer doorzoekbaar kunnen worden en kunnen gebruikers niet langer advertenties blokkeren, zo stelt de organisatie. Ook zouden softwareontwikkelaars minder innovatieve software kunnen ontwikkelen.

Reacties (104)

Reactiefilter:-11040103+179+219+31
Weet niet zeker wat ik hier van moet vinden. Aan de ene kant goed dat er beveiliging zit in de HTML5 standaard, maar aan de andere kant jammer. Het is een beetje... Tja... Mes snijdt aan twee kanten. Als ik een persoonlijke voorkeur mocht uitspreken zou ik het er niet instoppen, maar dan zit je weer met het probleem dat DRM in Flash geregeld moet gaan worden en zo heb je dus niets aan al die mooie nieuwe HTML5 functies! :)

Moeilijk, moeilijk, moeilijk...

[Reactie gewijzigd door KoploperMau op 30 mei 2013 13:37]

Het is helemaal niet moeilijk. Het is heel simpel.
Natuurlijk is dat mijn mening. Ik vind gewoon dat DRM niet in HTML5 hoort en sta in deze volledig achter het initiatief van de FSF. En jij hebt jouw mening. Niks mis mee toch? Je mag toch gewoon van mening verschillen.
Je laat in jou reactie anders duidelijk zien dat het heel simpel IS. maar een mening kan nooit bepalen of iets overall simpel is of niet. dus heeft hij natuurlijk wel een puntje, je mening uiten is wat anders als je mening als enige waarheid bestempelen, en zo kwam het wel over
Ik snap niet wat je wil zeggen.
... maar een mening kan nooit bepalen of iets overall simpel is of niet.
???
... je mening uiten is wat anders als je mening als enige waarheid bestempelen, en zo kwam het wel over
Als ik tegen kernbommen ben, dan zeg ik toch: Nee, het is simpel, geen kernbommen.
En als ik tegen DRM in HTML5 ben, dan zeg ik: Nee, het is simpel, stop het er niet in.
Is dat de enige waarheid?
En als ik tegen DRM in HTML5 ben, dan zeg ik: Nee, het is simpel, stop het er niet in.
Je kunt alleen zeggen: "Ik vind het simpel", want dat is een mening, geen feit.


Voorbeeld:
Een ding is 10 kg.
Dit is een feit, even massa vs gewicht buiten beschouwing gelaten.

Je mag dus zeggen:
Het ding is 10 kg.

Je mag niet zeggen:
Het ding is zwaar.

Want voor jou is 10 kg misschien zwaar, maar voor iemand anders misschien niet.

Je mag wel zeggen:
Ik vind het ding zwaar.


Tevens: Heb je argumenten bij je statement 'Het is helemaal niet moeilijk. Het is heel simpel.'?
?????
Je kunt alleen zeggen: "Ik vind het simpel", want dat is een mening, geen feit.
BS
Voorbeeld:
Een ding is 10 kg.
Dit is een feit, even massa vs gewicht buiten beschouwing gelaten.

Je mag dus zeggen:
Het ding is 10 kg.
Of course
Je mag niet zeggen:
Het ding is zwaar.
Moet jij eens opletten. Het ding is zwaar.

En als ik het op jouw tenen laat vallen doet het pijn. Net zoals het invoeren van DRM in HTML5 pijn gaat doen.
Tevens: Heb je argumenten bij je statement 'Het is helemaal niet moeilijk. Het is heel simpel.'?
Ja, in de vorm van een link (ook in het oorspronkelijke bericht).

[Reactie gewijzigd door 505261 op 31 mei 2013 13:10]

BS
Jammer dat je geen onderscheid kan of wil maken tussen een statement met een jouw eigen mening en een feit.
Moet jij eens opletten. Het ding is zwaar.
Vind je?
Waarom?
Waar vergelijk je dat dan mee?
Is het ding een auto? Dan is 10 kg veel minder zwaar dan gemiddeld.
Is het ding een laptop? Dan is 10 kg veel zwaarder dan gemiddeld.
En als ik het op jouw tenen laat vallen doet het pijn.
Dat hangt af van de lengte van de val en het soort schoeisel wat ik dan aan heb.
Net zoals het invoeren van DRM in HTML5 pijn gaat doen.
Waarom?
Je geeft geen uitleg of argumenten, dus is het een mening.
Quote PPie:
Tevens: Heb je argumenten bij je statement 'Het is helemaal niet moeilijk. Het is heel simpel.'?
End Quote.

Ja, in de vorm van een link (ook in het oorspronkelijke bericht).
Aha. Ik had al even snel op die link gekeken en geconstateerd dat ze daar niet een 'Argumenten hier' linkje hadden staan.
Niet erg bruikbaar dus.
De originele link uit het Tweakers artikel draagt meer bij aan een discussie.

Op die EFF link vind ik de 3 statements van de EFF trouwens zwak:
(1) exclude an entire class of platforms and user agents from full conformance with the HTML5 standard and the W3C's vision of the Open Web
Deze is apart. De EME wil een standaard manier voor een API beschrijven.
Deze kan dus gewoon geïmplementeerd worden in een browser en daarmee ben je als platform HTML5. Dat een plug-in niet voor een platform beschikbaar is, is geen zorg van de W3C. Dat is nu ook met andere plug-ins het geval.
Op dit moment zal content beschikbaar worden gemaakt in een walled garden 'App' , dus al helemaal buiten de browser om...
Trouwens: Het lijkt mij dat de W3C dan alle plug-ins wil gaan verbieden voor HTML? Anders zou je DRM kunnen doen via een plug-in zoals Flash...
(2) encourage the reduction of the amount of content accessible to users via the Web
Hier zeggen de content makers natuurlijk dat er meer content beschikbaar zal kunnen komen, waarom zou dit dan minder worden?
Ik denk eerder dat de content makers inderdaad nu hun eigen walled gardens gaan blijven houden, dus hoe draagt dat bij aan meer content op het web?
(3) create serious future impediments to W3C's core mission of promoting interoperability, voluntary standards compliance, and access for all.
Deze vind ik ook niet zo sterk. Hoe zorgt het ondersteunen van een API om plug-ins te kunnen vinden en aanroepen ervoor dat in de toekomst geen standaarden voor het web kunnen worden gemaakt?


(Ik ben trouwens wel van mening dat DRM niet gaat werken en gekraakt gaat worden, maar ongefundeerd roepen helpt niet...)
Wat ik eigenlijk wilde zeggen is dat dit een technische (geeky) site is, geen kleuterklasje. Ik weet verdomde goed wat ik heb geschreven en heb echt geen behoefte aan een wijzend vingertje, en daarmee bedoel ik "je mag niet zeggen...".

Ik ben verdomme een ervaren ingenieur, techneut en autist, geen diplomaat.

Als ik me in een conversatie meng, weet ik waar ik het over heb. Dan kan je nog van mening / inzicht verschillen en dat is goed, daar leer je van. Maar dat is heel wat anders dan de pietleuterige dingen waar jij mee aankomt.

En de rest van jouw argumenten: Het zal wel, ik heb ze niet bekeken.

[Reactie gewijzigd door 505261 op 1 juni 2013 07:39]

DRM heeft helemaal niets met beveiliging te maken. Het hoort dan ook totaal niet thuis in een standaard. Instanties die daar wel behoefte aan hebben of in de misconceptie leven dat DRM een nuttig iets is kunnen dit zelf toevoegen.
Wanneer de manier waarop een browser met de DRM moet samenwerken gestandariseerd word betekend dit dat content aanbieders op een heel eenvoudige en uniforme wijze hun content kunnen beschermen naar de eindgebruiker toe zonder van de eindgebruiker te verwachten dat deze eerst nog extra software gaat installeren. Men verhoogd net het gebruiksgemak van de eindgebruiker zodat deze net minder van de DRM zal merken. Een wereld zonder DRM zal er niet snel komen, waarom de ervaring dan niet zo pijnloos mogelijk maken?
Maar de HTML5 EME is juist gemaakt om de gebruiker wel extra software te laten installeren. De browser implementeerd zelf geen DRM, alleen een plugin systeem voor third-party software die DRM kan implementeren.
mee eens, als ze nu een specifiek / licentie vrije drm-varient hadden gekozen en die in elke browser hadden toegevoegd maar in plaats daarvan kiezen ze een systeem waarvan je bij voorbaat al weet dat het platform afhankelijk zal blijken, geen support voor linux, niet voor firefoxos of sailfish of blackberry10 want die zijn allemaal te klein, en bij sommige content niet eens voor apple of juist alleen voor apple.

HET web is daar dus niet bij gediend.
Een wereld zonder DRM bestaat al: China.
leg mij eens uit waarom drm niet in een standaard thuis hoort? ik kan namelijk geen reden bedenken. er is sowieso behoefte aan de mogelijkheid voor drm, anders werd het niet voorgesteld.
Het probleem nu is dat drm vaak te vervelend is voor gebruikers die wél betalen. Zolang drm in HTML5 niet hindelijk is, kan ik dit alleen maar aanmoedigen.
Het probleem van kopieren en thuiskopieheffingen is dat er té weinig legaal aanbod is. Als netflix met drm in HTML5 daarvoor kan zorgen, dan vind ik dat dit een mooie vorm van drm is.
Als het ten koste gaan van de doorzoekbaarheid van bijvoorbeeld afbeeldingen dan komt er vanzelf een oplossing voor neem ik aan, dat ligt aan de mnier waarop de drm werkt lijkt me.
DRM in HTML5 is per definitie hinderlijk. Iedere gebruiker dient volledig HTML5 te kunnen gebruiken. Hiervoor MOET de standaard open source zijn. Je kan niet platform-afhankelijke of geheime delen in de standaard achterlaten, want dan heb je gebruikers die net een niet-ondersteund platform gebruiken, en daarom geen volledige toegang hebben tot het WWW. DRM kan echter niet volledig open, want geheid dat mensen weten waar keys zijn en hoe keys worden geregeld, waarna ze eenvoudig uit te wisselen zijn. Dit maakt piraterij eerder makkelijker dan moeilijker. Het resultaat van deze DRM is uiteindelijk niet dat illegale circuits het moeilijker krijgen; die gaan rustig hun gang op torrent-netwerken en newsgroups, maar het effect is dat niet elk platform HTML5 kan implementeren, en dus niet iedere gebruiker HTML5 kan gebruiken. Dat staat HAAKS op de doelstellingen van het W3C.
De standaard kan heel goed open zijn, alleen de keys niet. Zo is het bv ook met SSL: een open standaard, maar private/public keys.

(edit: uiteraard werkt DRM met private/private keys, maar het principe is hetzelfde: het kan met open source software, met open standaarden)

[Reactie gewijzigd door Dreamvoid op 30 mei 2013 17:59]

De standaard kan heel goed open zijn, alleen de keys niet. Zo is het bv ook met SSL: een open standaard, maar private/public keys.
Het probleem wat Amanoo aansnijdt is dat met een open standaard de locatie van de sleutels bekend is. Hierdoor faalt DRM al bij opzet, omdat het client platform de content moet kunnen decoderen met behulp van die sleutel. Als de sleutel bekend is op de client en de content is gecodeerd beschikbaar, dan is het geen probleem om de content te decoderen en ongecodeerd op te slaan.

Natuurlijk kan dit ook met een gesloten standaard. Dat de standaard echter open is maakt de boel wat makkelijker. ;) De standaard kan ruimte overhouden voor browsers om zelf te bepalen waar ze hun sleutels opslaan en hoe ze ermee omgaan, maar er zullen open-source browsers zijn die dit gaan implementeren. Wellicht kunnen sites met trucs deze browsers blokkeren, maar dat is nou juist niet de bedoeling van HTML5.

[Reactie gewijzigd door The Zep Man op 30 mei 2013 14:36]

De standaard kan heel goed open zijn, alleen de keys niet. Zo is het bv ook met SSL: een open standaard, maar private/public keys.
Het grote verschil tussen ssl en drm is dat het bij ssl de bedoeling is dat de ontvanger de boel kan ontsleutelen, maar bij drm niet, of iig niet volledig. Zo moet je wel de media kunnen zien/horen, maar niet opslaan. Dat is natuurlijk een onbegonnen werk, dus willen ze weer teruggrijpen op het oude vertrouwde "security through obscurity", alias: de manier waarop de versleuteling werkt willen ze geheim maken, ipv de relevant key.

Dat een organisatie die staat voor open standaarden een dergelijk "obscuur" systeem wil implementeren staat zoals Amanoo al zegt natuurlijk totaal haaks op zijn eigen doelstellingen.
Ik snap niet dat dit +2 krijgt, want dit is gewoon niet zo. Je kan DRM prima implementeren met volledig open source code, alleen de decryption key moet geheim blijven. Dit is net zo goed "security through obscurity" als het geheim houden van een username/password.
Dat kan bij DRM niet. Het geheim houden van de decryption keys heeft immers tot gevolg dat de versleutelde content überhaupt niet af te spelen is. De gebruiker moet de beschikking hebben over de sleutels. Om toegang tot de content toch te frustreren, worden die sleutels verstopt, zodanig dat ze voor de gebruiker moeilijk te vinden zijn en ontwikkel je een eigen stukje software dat weet waar het de sleutels zoeken moet. Maak je die broncode van die software echter beschikbaar, dan is het een koud kunstje om uit te vogelen waar de sleutels gezocht worden, om ze daar vervolgens zelf ook aan te treffen.

Dat is de kern van DRM. Security through obscurity, dus. Sterker wordt de beveiliging niet. Middels cryptografie kan A immers veilig een bericht naar B sturen, dat wil zeggen, zodanig dat aanvaller C het bericht niet kan lezen, mocht hij het weten te onderscheppen, maar dat werkt niet als B en C dezelfde persoon zijn.
Je kan je eigen definities gaan verzinnen, maar het geheim houden van private keys is *niet* wat men doorgaans verstaat onder "security through obscurity". Het is perfect duidelijk waar de private key is en hoe het DRM proces werkt, je kan er alleen (als gebruiker) niet bij - ook hier weer, net zoals met SSL. Ik *weet* dat Google's private key op een secure Google server staat, ik kan er alleen niet bij. Bij een DRM library van een browser (of een plugin als Silverlight, Flash, etc) geldt hetzelfde: als gebruiker weet je dat de private key erin zit, je kan er alleen niet bij.

[Reactie gewijzigd door Dreamvoid op 30 mei 2013 19:20]

Bij een DRM library van een browser (of een plugin als Silverlight, Flash, etc) geldt hetzelfde: als gebruiker weet je dat de private key erin zit, je kan er alleen niet bij.
Als die library open source zou zijn, dan kun je hem dus ook met debug-informatie compileren. Dan kun je er wel bij, want je wéét dan op welke geheugenlokatie er een blok bytes staat waar die sleutel in is opgeslagen. Net zo goed als je dan ook weet waar de gedecodeerde (video en audio) data er uit gepoept wordt, en dan is het een koud kunstje om die data ook even naar een ander stukje geheugen of naar de schijf te kopiëren.
Dat weet je niet, want je kan randomization van de geheugenlokatie toevoegen.

En elk modern OS heeft een secure video/audio path. Natuurlijk kan je dat proberen te hacken en direct de stream uit de framebuffer trekken ofzo, maar dat kan nu ook al met Silverlight/Flash, dar heeft open source niets mee te maken.
Blijkbaar is niet perfect duidelijk hoe het DRM-proces werkt, want het is volstrekt niet zoals SSL. Ik kan inderdaad niet bij Google's private keys, maar dat is omdat ik buiten wordt gezet als ze me in een serverpark betrappen met een koevoet en een USB-stick.

Ik kan echter wel bij de 'geheime sleutels' die op mijn eigen computer zijn opgeslagen, ook al zitten daar browser plugins omheen. Mijn computer doet namelijk wat ik hem opdraag. Alles wat software op mijn computer kan, kan mijn computer en kan ik zelf dus ook; en als een mannetje van de beveiliging mij tegen probeert te houden, zet ik hem eruit, niet andersom.
Hoe wil je bij een private key komen die in een signed binary zit? En als je 'm eruit haalt, hoe zorg je dan dat jouw gehackte library weer netjes gesigned door Mozilla wordt?
Hoe wil je bij een private key komen die in een signed binary zit?
De symbols dumpen is een goede start.
En als je 'm eruit haalt, hoe zorg je dan dat jouw gehackte library weer netjes gesigned door Mozilla wordt?
Waarom zou dat nodig zijn? D'r is geen manier voor de andere kant om te controleren dat jij die signed library gebruikt ipv een eigen die precies die signed library nadoet. (En voor de key alleen hoef je de lib niet te haxx0ren.)

[Reactie gewijzigd door CyBeR op 31 mei 2013 02:51]

Het is perfect duidelijk waar de private key is en hoe het DRM proces werkt, je kan er alleen (als gebruiker) niet bij - ook hier weer, net zoals met SSL.
Nee, je kunt er als gebruiker wél bij. Sterker nog, je móet erbij kunnen want anders kun je de content niet decoderen en bekijken. Om vervolgens tegen te gaan dat jij dat doet op een manier die ze niet aanstaat, verstoppen ze de key. Dat is obscurity.

Bij SSL weet jij overigens ook de key. Het verschil is dat iemand die níet mee mag luisteren die key niet weet. En het probleem met DRM is dus dat jij tegelijkertijd degene bent die niet mee mag luisteren (en dus de key niet mag weten), en degene die de content wél mag inzien (en dus de key móet weten).
Jij weet de key niet, de decoding library weet de key.
Als jouw computer iets weet, kun jij het (met min of meer moeite, afhankelijk van hoe goed ze 't verstopt hebben) ook weten. Je kunt geheugen dumpen, de instructies volgen, netwerkverkeer onderscheppen etc. Als je echt wilt kom je er achter.

[Reactie gewijzigd door CyBeR op 31 mei 2013 02:51]

Open source != Specificatie

Om het mogelijk te maken dat iedereen er gebruik van moet kunnen maken is het voldoende om de HTML5 Specificatie open te houden.

De daadwerkelijke implementatie hoeft helemaal niet open source te zijn. Het is niet de implementatie die er voor zorgt dat het door iedereen gebruikt kan worden want er zijn vele verschillende implementaties, sommige open, sommige gesloten.

De specificatie bepaald hoe iets werkt, hoe iets moet werken met welk gedrag etc...

En over het implementeren, het staat ieder bedrijf vrij om een implementatie van zijn / haar DRM mechaniek te leveren voor elk platform.

Dat ze dat niet doen is niet het probleem van de specificatie en van het W3C.
Even voor de goede orde, HTML5 is en blijft gewoon een open softwarestandaard. De standaard is gewoon open source. De implementatie ervan is een ander ding. De implementatie mag best open source zijn (Chrome) maar ook niet als een fabrikant daarvoor kiest (IE \ Safari),.

Verder is het de producent van content die de DRM mogelijkheid wil inzetten, en dat kan in mijn ogen meer dan valide zijn. Ik zit nu muziek via Deezer te luisteren, prima als ze de stream via DRM beveiligen. Ik heb er geen last van want de service wordt keurig netjes geleverd zoals beloofd.

HTML5 is dus enkel het vehikel waar een mogelijkheid tot DRM wordt aangeboden. Als dat niet gebeurd, dan worden er toch nog X manieren gevonden om te komen tot het doel wat zulke content providers willen: beveiliging van hun eigendom. En dat gaat dan gebeuren op een niet-standaard wijze waar iedereen de dupe van wordt omdat dat dan willekeurig wordt ondersteund. En zijn we weer terug bij het oude geneuzel en verschillen tussen browsers en ondersteuning die we nu hebben.

Prima dus dat het wordt ondersteund.

[Reactie gewijzigd door Marcelloz op 30 mei 2013 14:18]

Als dat niet gebeurd, dan worden er toch nog X manieren gevonden om te komen tot het doel wat zulke content providers willen: beveiliging van hun eigendom.
Leuk gedacht maar waneer heeft DRM er ooit voor gezorgd dat men via illegale wegen toch toegant krijgen tot die content? Je pest alleen maar mensen die het netjes willen doen, derhalve gaan die steeds meer naar illegale bronnen.
Ik heb er geen last van want de service wordt keurig netjes geleverd zoals beloofd.
Hoezo geen last? Denk je dat DRM gratis is? Beveiliging is duur. Het kost ontwikkeltijd, het kost server capaciteit, bandbreedte....Je hebt er wel last van, je weet alleen niet waar het je raakt.

Piracy is niet te bestrijden, maar de meeste mensen gedragen zich wel netjes. Je moet het mensen makkelijk maken. Bovendien, waneer je niet bakken met geld weggooit aan DRM en advocaten dan blijft er ook meer geld over aan het einde. Wie wint er bij DRM? Advocaten en programmeurs.
Leuk gedacht maar waneer heeft DRM er ooit voor gezorgd dat men via illegale wegen toch toegant krijgen tot die content? Je pest alleen maar mensen die het netjes willen doen, derhalve gaan die steeds meer naar illegale bronnen.
Illegaliteit is niet uit te bannen. Als het voor de consument niet hinderlijk is, dan is er toch niets aan de hand? Als jij iets niet mag zien omdat je er niet voor betaald hebt, dan is er toch geen probleem?

Je gaat pas illegaal downloaden als iets exclusief is waar je niet de prijs voor wilt betalen die de contentprovider vraagt. Dat de prijs van de meeste muziek, games en boeken kunstmatig tot grote hoogte wordt gedreven door grote uitgeverijen is mij ook een doorn in het oog. Een lagere prijs zorgt volgens mij voor meer consumptie. Maar da's een andere discussie ;-)
Hoezo geen last? Denk je dat DRM gratis is? Beveiliging is duur. Het kost ontwikkeltijd, het kost server capaciteit, bandbreedte....Je hebt er wel last van, je weet alleen niet waar het je raakt.
Fijn dat het daarom standaard in HTML5 zit, dan zijn de kosten extra laag lijkt me :)

Verder ben ik programmeur dus win ik er blijkbaar bij ;-)
Je gaat per direct illegale dingen download als je dingen voor jouw platform niet anders te benanderen zijn.

Uitzending gemist, ook "open", maar silverlight, en dus niet beschikbaar voor een boel platformen, en dus gaan mensen de content elders "illegaal" downloaden (heh, de content was toch gratis? ja, maar wel illegaal als de drm er niet op zit)

Gezien niet elke device / browser / client de drm keys kan en zal implementeren (want dat is niet 100% veilig mogelijk in een open omgeving, en dus krijg je ze niet als leverancier) zullen er mensen zijn die noodgedwongen de content elders gaan halen.

En ja, je wordt niet gedwongen, maar we hoeven niet te ontkennen dat t ontbreken van een legaal (en dus open) aanbod linearecta betekend dat niet iedereen het legaal zal consumeren.
Piracy is niet te bestrijden, maar de meeste mensen gedragen zich wel netjes
Pardon???

Maak dat de kat wijs. We weten allemaal donders goed dat de meeste mensen zich niet netjes gedragen.
Wanneer de meeste mensen zich niet netjes gedragen, is dat via het democratie beginsel automatisch wel netjes, want de meerderheid beslist in een democratie wat wel en niet netjes is... :+
Contenteigenaars gaan nu wellicht dus geen gebruik maken van HTML5 omdat ze liever Flash/Silverlight o.i.d. gebruiken waar ze hun proprietaire ei wel kwijt kunnen.

Ik denk namelijk niet dat het ze dwingt naar alternatieve businessmodellen te kijken. Daar hoopt de EFF namelijk op; dat ze daartoe gedwongen worden.

DRM en open-source gaan helaas per definitie niet samen omdat het doel van DRM is dat de eigenaar niet zelf kan bepalen wat er gebeurt met z'n content; bij een open-source DRM-programma is het echter heel eenvoudig om zelf wel andere dingen met die content te doen...
... maar het effect is dat niet elk platform HTML5 kan implementeren, en dus niet iedere gebruiker HTML5 kan gebruiken.
Je bedoelt: niet elk platform kan het DRM-gedeelte van HTML5 implementeren. Groot verschil.

Op dit moment kan ook niet elk platform silverlight en flash (en welke zooi heb je nog meer?) implementeren. Straks hoeft een platform maar 1 standaard te implementeren.

Ik ben juist wel voorstander van DRM in HTML5 want het zorgt er ten eerste voor dat ik geen irritante flash-player of silverlight meer hoef te downloaden, en dat de interface uniform is. Ten tweede denk ik (zoals jij al zegt) dat de DRM snel gekraakt zal worden, en dat vind ik eigenlijk ook een prima ontwikkeling: dat er een standaard is zorgt er dan alleen maar voor dat kraken een fluitje van een cent wordt, net als bij DVDs (en dat vinden we toch ook normaal?)

[Reactie gewijzigd door twop op 30 mei 2013 14:28]

In een wereld waarin miljoenen mobiele devices geen flash kunnen afspelen blijkt de beperkte inzetbaarheid geen enkel probleem te zijn. HTML 5 is dus prima te implementeren, zij het niet volledig. Dat is geen probleem dat is gewoon de realiteit. Het is juist fijn dat het W3C zich niet alleen laat leiden door hoogdravende ideologische wensen van de open source community maar ook ziet dat de techniek commercieel inzetbaar moet zijn.
Hiervoor MOET de standaard open source zijn.
De standaard wel, maar de implementatie hoeft dat zeker niet te zijn.
Kijk naar H.264. Dat is een open standaard, met meerdere implementaties in hardware en software, waar sommige implementaties open source zijn...
DRM kan echter niet volledig open, want geheid dat mensen weten waar keys zijn en hoe keys worden geregeld, waarna ze eenvoudig uit te wisselen zijn.
Maar als je ziet dat op de PC DRM van filmpjes vaak via Flash gaat, lijkt het mij niet zo moeilijk om Flash te reverse engineeren en zo de DRM van de content te verwijderen...
Het lijkt me ook erg irritant als het algemeen ingezet kan worden. Dan gaat het te pas en onpas gebruikt worden ook voor reclame. Op tweakers kan je de reclame afkopen maar dat kan lang niet overal..
Nu zijn er specifieke technieken die drm mogelijkheden hebben zoals silverlight die alleen voor video gebruikt worden. Maar als het een algemeen iets word is het vervelend. Net als die websites die de rechtermuis knop geblokkeerd hebben. In de veronderstelling dat je dan de plaatjes niet meer kan downloaden 8)7
Ja en nu we flash/silverlight hiervoor moeten gebruiken gaat het zoveel beter...
Inderdaad, want Silverlight komt sowieso de deur niet in, en Flash staat standaard achter click to play. Problem solved.
" eerste maal een 'zwarte doos' gecreëerd volgens de wensen van de entertainmentindustrie."

Het is wel duidelijk wie hier aan de macht is voor zover we dat al niet wisten. Ik dacht toch dat ze ook al gemerkt hadden dat DRM niet werkt, maar dat is nog niet doorgedrongen bji de EI.
Als we het ook niet precies volgens hun regels doen :( Microsoft, Netflix en Google zullen het ook wel onder druk van ze hebben ingebouwd.

Als er echt DRM in komt dan wordt het geen success, zowel de DRM als HTML5 (hoe graag ze ook willen)

[Reactie gewijzigd door bonus op 30 mei 2013 13:39]

Ik ben hier ook niet direct blij mee. Maar kan ook de gevolgen niet zo overzien. Ik zie DRM nog vaak als een beperking en nadelig voor de legale gebruiker: cd's die niet overal af te spelen was, windows activatie waarbij de legale gebruiker vanalles moet doen en digitale dragers die niet makkelijk om te zetten waren op een ander medium voor onderweg oid.

Maar iBooks en de hele appstore van Apple vallen onder DRM. En dat werkt prima.

Then again: ik weet niet wat ik me voor moet stellen bij het web met drm.
DRM is zeer onwenselijk in een open web standaard. Je mag er haast wel van uit gaan dat het deels closed source is en dat je het daardoor niet op elk platform kan gebruiken. Dat hoort niet thuis in internetstandaarden, die door Jan en Alleman geïmplementeerd moeten kunnen worden in wat voor apparaat of besturingssysteem dan ook. Het dusdanig openstellen dat zoiets mogelijk wordt betekent bij DRM al vrij gauw dat iedereen elkaars keys voor DRM systemen kan uitwisselen, zodat het systeem zo lek als een mandje is. Closed source zijn mag bij individuele gebruikers, maar niet in een standaard of API. Ik heb niets tegen DRM als het niet beperkend is, maar je kan er op wedden dat er in HTML5 wel degelijk beperkingen aan zullen zitten. Ik als voornamelijk gebruiker van Linux (en af en toe Windows voor net dat ene non-Linux spelletje dat ik wil spelen) weet maar al te goed hoe lastig het kan zijn als individuele softwarepakketten je systeem niet ondersteunen. Nog lastiger als een standaard je systeem niet ondersteunt, en al helemaal als die standaard het WWW is. Dan kan je effectief niet meer internetten. Bedankt entertainmentindustrie.

DRM is in mijn mening ook vaak een doodgeboren kind. De entertainmentindustrie wint niet eens met deze zet. Vaak wordt DRM toch gekraakt, en anders zijn er wel alternatieve bronnen voor hetzelfde materiaal. Als ik Game of Thrones wil downloaden kan ik dat met HTML5-DRM ook wel doen. Illegale circuits beperk je niet eens. De enige winnaars zijn Apple, Microsoft en misschien Google, die hiermee weer een stapje dichterbij een alleenrecht op een functionerend besturingssysteem zitten, dankzij de beperking op een volledig functionerende HTML5-implementatie die net op hen niet van invloed is.

[Reactie gewijzigd door Amanoo op 30 mei 2013 13:53]

Je mag er haast wel van uit gaan dat het deels closed source is en dat je het daardoor niet op
elk platform kan gebruiken.
DRM heeft niets te maken met open of closed source. Je kan prima een volledig open encryptiestandaard hebben, zoals bv SSL.
Nee, dat kan niet!

Als de code om te decrypten en weer te geven open source is, dan betekent dat per definitie dat je die content ook kunt kopiëren/verspreiden.

Het punt is dat DRM gebruik van de content door de gebruiker wil beperken, maar met een open-source programma kan dat niet omdat dat eenvoudig is aan te passen om iets anders met de content te doen.

DRM = encryptie + gebruiksbeperking. Dat eerste kan wel open-source, dat tweede niet; de client mag niet aan te passen zijn en moet niet reverse-engineerbaar etc. zijn om de content te beschermen.
Dat kan dan ook gewoon met open source.

Voorbeeld: een signed binary, compiled vanuit 100% open source code. Wel open source, niet reverse-engineerbaar.
Dat kan dan ook gewoon met open source.

Voorbeeld: een signed binary, compiled vanuit 100% open source code. Wel open source, niet reverse-engineerbaar.
Ik weet niet wat jij onder open source verstaat, maar voor de Free Software Foundation en de Open Source Initiative is het kunnen inzien van de source code in ieder geval niet genoeg. Zij willen dat gebruikers de source code ook aan kunnen passen, hercompileren, en de aangepaste versie gebruiken. Het is vooral dat aspect van open source dat niet samengaat met DRM.

DRM probeert er voor te zorgen dat bepaalde content alleen door programma's kan worden bekeken, waarvan vaststaat dat ze geen verboden dingen met de content doen (zoals opslaan in een bestand). Het is dus niet de bedoeling dat aangepaste software zomaar dezelfde met DRM beschermde content af kan spelen. En dat is volkomen in tegenspraak met het idee achter open source en vrije software.
Dat is de aller extreemste vorm van open source definities, en alleen in GPLv3 zo, de meeste andere vrije softwarelicensies staan dat gewoon toe. Linux zelf is GPLv2 en daar mag het, en je kan moeilijk beweren dat Linux geen open source software is.

Als je zo'n decoding library schrijft onder GPLv2, Mozilla, BSD of Apache licensie dan kan je gewoon signed binaries verspreiden.

[Reactie gewijzigd door Dreamvoid op 31 mei 2013 00:49]

Zowel FSF definitie van free software (4e puntje) als de OSI definitie van open source (punt 3) noemen de mogelijk tot aanpassen als een van de basisprincipes.

De DRM die in GPLv3 verboden werd was dan ook iets anders: dat was DRM die gebruikt werd om slechts een specifieke versie van vrije software toe te staan (bijvoorbeeld alleen goedgekeurde versies van op vrije software gebaseerde firmware). Die DRM zelf hoeft niet open source te zijn. Overigens vindt de FSF de GPLv3 een verbeterde versie van de GPLv2.

Maar ook bij GPLv2 moet je alles meeleveren dat nodig is om de source opnieuw te compileren, inclusief evt. sleutels. Bij andere licenties ligt het wat genuanceerder omdat afgeleide werken niet meer vrije software hoeven te zijn. (Merk op dat de sleutels hier geen invoer van de gebruiker zijn, maar vast ingebakken in het programma.)
[...]

DRM heeft niets te maken met open of closed source. Je kan prima een volledig open encryptiestandaard hebben, zoals bv SSL.
Het verschil daarin is dat je bij SSL de communicatie naar de ándere kant wil beveiligen tegen afluisteren van een derde partij, en je de (private) key daar zelf in beheer hebt.

Bij DRM wil een andere partij de content beveiligen en hebben ze de sleutels in het beheer, tenzij ze die sleutel aan jou geven. Sinds je lokaal afspeelt, moeten allebei de sleutels dus bij de gebruiker liggen, anders krijg je je content niet ontsleuteld.

Daar ligt ook de crux: Als je een open-source DRM implementatie hebt betekent dat dat je de broncode op elk moment kan aanpassen om de sleutels óf de ontsleutelde content op een willekeurige manier te gebruiken. Een open-source DRM is dus al bij definitie 'gehackt' omdat je er als gebruiker mee mag doen wat je wil.

Dat is precies wat een uitgever van DRM juist niet wil. De uitgever wil kunnen bepalen wat jij, als gebruiker, met 'zijn' content mag doen. Open-source software staat daar precies haaks op: Die geeft jou als gebruiker controle over de broncode en dus over de content.

Kortweg: DRM beveiligt de uitgever tegen acties van de gebruiker. Bij SSL worden twee gebruikers beveiligt tegen inbreuk van een derde partij.

Bij SSL lukt dit wel omdat de private sleutel alleen aan de andere kant beschikbaar is, bij de partij van wie de sleutel is. Bovendien beveiligt SSL niet tegen het (door de gebruiker) opslaan van sleutels of verzonden gegevens.
Dit is dus wat ik al in meerdere reacties probeer te zeggen (Stoney3K en Sorcerer8472, bij deze dan ook oprecht bedankt voor het extra duidelijk maken van de zere plek). Het probleem is dus ook dat HTML en het WWW wel bedoeld zijn om dusdanig open te zijn. De pogingen van de entertainmentindustrie om dit te beperken kunnen dan ook gewoon niet door de beugel. Doe mij maar plugins. Flash en Silverlight vind ik grote rampen - de eerste is niet er stabiel of efficiënt en de tweede is Windows only - maar ze zijn in ieder geval geen deel van de open standaard en mogen wat mij betreft vrij DRM gebruiken.
Natuurlijk zijn DRM en SSL anders in opzet (private/private versus public/private keys), maar principieel niet. Niemand lijkt hier te (willen?) begrijpen dat open source software/open standaard *niets* te maken heeft met geheime encryptie sleutels |:(

Je kan een voor de gebruiker onzichtbare private key bijvoorbeeld in een signed binary library stoppen die rechtstreeks in de video API van het OS haakt. Die library kan 100% open source code zijn, en de encryptiestandaard kan een 100% open standaard zijn.

[Reactie gewijzigd door Dreamvoid op 30 mei 2013 17:49]

Natuurlijk zijn DRM en SSL anders in opzet (private/private versus public/private keys), maar principieel niet. Niemand lijkt hier te (willen?) begrijpen dat open source software/open standaard *niets* te maken heeft met geheime encryptie sleutels |:(

Je kan een voor de gebruiker onzichtbare private key bijvoorbeeld in een signed binary library stoppen die rechtstreeks in de video API van het OS haakt. Die library kan 100% open source code zijn, en de encryptiestandaard kan een 100% open standaard zijn.
Alleen haal je daarmee de doelstellingen van DRM totaal onderuit.

Als het een open-source library is dan moet de broncode dus ook voor de gebruiker beschikbaar zijn. Die gebruiker kan dus ook prima die broncode aanpassen en de koppeling naar de video API vervangen door één of andere disk-writer. Waardoor die DRM-library ineens zijn eigen DRM-stripper is geworden en dus volkomen nutteloos wordt.

En zelfs als je dat niet doet, weet je doordat je de broncode hebt ook precies welke interfaces je mooie DRM gebruikt, en daar kun je dus ook op inbreken zonder te moeten hercompileren en dus opnieuw te moeten signen.
Als gebruiker kan je geen binary van die open source library maken met de private key erin, als je die private key niet hebt.

Natuurlijk kan je het OS gaan hacken en de framebuffer proberen uit te lezen, maar dat kan met alle andere DRM methoden nu ook al.

[Reactie gewijzigd door Dreamvoid op 30 mei 2013 19:10]

Natuurlijk kan je het OS gaan hacken en de framebuffer proberen uit te lezen, maar dat kan met alle andere DRM methoden nu ook al.
En dat proberen andere DRM-methoden dan ook op OS-niveau te verhinderen, denk aan zaken als Trusted Computing en HDCP.

Als je een open-source library maakt, dan moet je die ook in compileerbaar formaat aanleveren. Als je dan ergens een key in een binary blob erin verstopt, dan ondermijn je dat hele principe van open-source weer.

Wat je wel kan doen is binaries uitgeven die je met je eigen sleutel hebt ondertekend. Als er dan iemand in knoeit, wordt de handtekening anders en zal de browser die plug-in gewoon niet uitvoeren.

Met een library die open-source is moet je als gebruiker je eigen build kunnen maken. Niemand die garandeert dat die dan werkt, maar een eigen build is wel een prachtige plattegrond die precies aangeeft waar de inputs en outputs van de plugin zich in het geheugen bevinden, en ook de sleutel zelf. Met die drie gegevens hoef je niet eens iets te hacken, je weet waar je moet zoeken en je kan dus gewoon 'over de schouder' van die plugin meekijken om de gedecodeerde data af te tappen. Zonder één bitje in de binary om te moeten gooien.

Het enige wat je kan doen om dat te verhinderen is om de hele plugin in een andere laag van het OS uit te voeren, dus in kernelspace ipv. in user-space. Maar dat betekent ook dat je een ontwikkelaar moet vertrouwen om zo'n plugin diep in je OS te laten installeren (denk aan de rootkits van Sony), iets wat veel gebruikers niet zullen doen of niet eens mogen omdat ze in een beheerde omgeving zitten.
Open source betekent niet dat je geheime keys ook moet vrijgeven! Als ik zo'n library schrijf en binaries met mijn key erin verspreid, dan moet de source openbaar zijn, zodat iedereen een binary met zijn eigen key kan maken, maar uiteraard niet met die van mij. Open source gaat over de programmacode, niet over de key.

[Reactie gewijzigd door Dreamvoid op 31 mei 2013 00:55]

Het lijkt me niet verstandig om dit toe te voegen, simpel en alleen al omdat het niet verenigbaar is met het doel van HTML5; namelijk meer functionaliteit en mogelijkheden bieden voor zowel gebruiker als ontwikkelaar.

Het toevoegen en inzetten van de DRM technologie is juist bedoeld om functionaliteit en mogelijkheden te beperken voor de gebruiker.

Daarnaast hebben zal dit tevens impact kunnen hebben op het gebruik en het draagvlak voor HTML5, gebruikers zullen proberen alternatieven te vinden voor de gemiste mogelijkheden. Als voldoende gebruikers dat doet kan dit zelfs een doodsteek voor je product of dienst zijn.

Persoonlijk vind ik het ubehaupt als raar dat een organisatie als W3C uberhaupt overweegt DRM toe te voegen. Ik denk dat zich hier helemaal niet mee bezig moeten houden en dat organisatie als W3C niet bedoeld zijn om de problemen van de enteraimentindustrie op te lossen.
oke misschien ligt het aan mij, maar internet is gratis en voor iedereen, waarom drm?
Wat is het nut ervan om iets te blokkeren als het internet een "open" structuur(zou moeten hebben)heeft?
oke misschien ligt het aan mij, maar internet is gratis en voor iedereen, waarom drm?
Je zegt het al; om het niet meer gratis te maken voor iedereen. Reclames niet kunnen blokkeren, moeten betalen voor filmpjes, foto's en zelfs text, maar bovenal totale controle van voor de media industrie.

Het enige waar je op kan hopen is een beweging die de media industrie afzweert. Er is genoeg goede content die gratis aan de samenleving wordt gedoneerd en dat zal dan alleen maar meer worden.
Vraag dat maar aan de media-industrie.
Deze "feature" is gelobbied en is bedacht eerder voor geldgewin dan innovatie.

Bekijk het als een van de stuiptrekkingen van een stervend business-model
Ik ben toch blij dat niet iedereen zo denkt, als ik nl een VPN open via het internet, blokkeer ik ook derden -- zou dit volgens jou niet stroken met het principe van een open internet?
Helaas is internet niet gratis en al helemaal niet voor iedereen.

Wie denk je dat dat allemaal betaald? Je betaald zelf al voor toegang, de meeste sites betaal je door de reclame te bekijken en de rest is premium content.
de meeste sites betaal je door de reclame te bekijken en de rest is premium content.
Die betaal je niet zolang je niet een product koopt van een van de adverteerders. Zolang je niks koopt kost het de adverteerder en jou extra bandbreedte.
Dat is veel te naïef. Ik ben het overigens wel met eerdere reacties eens dat DRM geen onderdeel zou moeten zijn van een open standaard.

Maar "Open" en "voor iedereen" is iets anders dan gratis. De technologie achter het internet (toegang, dataverkeer en hosting) is niet gratis, content is niet gratis. Het enige dat (zo goed als) gratis is, is het dupliceren van content.

Daar zit m.i. de crux. Veel mensen vinden dat alle content gratis zou moeten zijn, omdat het gratis te dupliceren is. Elke nieuw exemplaar van een auto kost geld in materialen en arbeid, elk nieuw exemplaar van een film niet. Dus logisch dat ik betaal voor een auto, maar waarom zou ik betalen voor een film?

Daarbij komt dat in veel gevallen de leveranciers van content (en dat zijn vaak niet de makers) een buitenproportioneel deel van de inkomsten naar zich toe lijken te trekken.

En verder zijn mensen natuurlijk gewoon hebberig. Waarom betalen als je het ook gratis kan krijgen?

De contentmakers en -leveranciers zien nog te weinig andere mogelijkheden om hun inkomsten zeker te stellen dan d.m.v. DRM, dus proberen ze dat overal door te drukken.

"You can't compete with free" wordt er wel eens gezegd. Maar is dat wel zo? Mensen blijken best bereid te betalen voor een snelle internetverbinding, toegang tot snelle newsservers met hoge binary-retention, Spotify, etc. om bij al die content te kunnen komen.

Waar de content-industrie m.i. op zou moeten concurreren, is op kwaliteit en gemak tegen een realistische prijs. Ik wil geen 15 euro per maand betalen voor een HBO-abonnement zodat ik elke maandag om 20:30 Game of Thrones op de buis kan zien, ik wil een paar cent per minuut betalen zodat ik op een door mij gewenst tijdstop de meest recente aflevering van Game of Thrones kan kijken. En ik wil overal toegang tot de content waar ik voor betaald heb, ook off-line.

[Reactie gewijzigd door Herko_ter_Horst op 30 mei 2013 14:28]

Waar de content-industrie m.i. op zou moeten concurreren, is op kwaliteit en gemak tegen een realistische prijs. Ik wil geen 15 euro per maand betalen voor een HBO-abonnement, ik wil een paar cent per minuut betalen voor de meest recente aflevering van Game of Thrones. En ik wil overal toegang tot de content waar ik voor betaald heb, ook off-line.
Wacht even, dus je wilt per minuut betalen, maar je wilt ook off-line toegang tot de content die je hebt 'gekocht'? Dat strookt een beetje met elkaar. Je kunt ofwel on-line, encrypted, toegang krijgen tot de content, ofwel het kopen en het dan off-line en overal mogen gebruiken.
Ik ben het overigens wel met eerdere reacties eens dat DRM geen onderdeel zou moeten zijn van een open standaard.
Waarom niet? Als de mechanismes waarmee je de content kunt unlocken compleet beschreven zijn in die open standaard zie ik het probleem niet zo.
Is DRM niet sowieso een wassenneus in een open source browser? Ik bedoel kan ik niet gewoon de source van Firefox pakken straks en de DRM controle/restricties eruit slopen?
Nee hoor, dat is heel simpel te voorkomen: je maakt delen closedsource. Het nadeel is dat vervolgens alleen een bepaalde selectie van alle gebruikers HTML5 volledig kunnen gebruiken, wat in dit soort standaarden onwenselijk is. Je krijgt dus effectief een platform-afhankelijk WWW. Heb je het verkeerde platform, dan kan je het WWW niet (goed/volledig) gebruiken.
Je hoeft ze niet closed source te maken. Je kan bv ook signed binaries van open source code maken.
Nee, want inherent aan DRM is ook (vaak) dat content encrypted wordt aangeleverd. Je vraagt dan aan een DRM-provider de sleutel om de content te mogen gebruiken en ook aangeven waar je die sleutel voor gaat gebruiken. Gaat die provider daar niet mee akkoord, omdat jij bijvoorbeeld de content niet hebt gekocht, of omdat je abonnement je geen recht geeft op die content, dan krijg je geen sleutel en heb je er niks aan.

Voordat je denkt dat je dan wel even bij iemand anders de sleutel kunt gaan lenen; zo werkt het niet. Vaak is bij DRM-systemen de content voor iedere gebruiker individueel versleuteld.
Nee, want inherent aan DRM is ook (vaak) dat content encrypted wordt aangeleverd. Je vraagt dan aan een DRM-provider de sleutel om de content te mogen gebruiken en ook aangeven waar je die sleutel voor gaat gebruiken. Gaat die provider daar niet mee akkoord, omdat jij bijvoorbeeld de content niet hebt gekocht, of omdat je abonnement je geen recht geeft op die content, dan krijg je geen sleutel en heb je er niks aan.

Voordat je denkt dat je dan wel even bij iemand anders de sleutel kunt gaan lenen; zo werkt het niet. Vaak is bij DRM-systemen de content voor iedere gebruiker individueel versleuteld.
Je leent uiteraard ook geen sleutel, die data wordt gewoon onversleuteld weer verspreid. Je omzeilt gewoon dat hele DRM.

Als mijn browser het kan afspelen, kan mijn browser* het ook onversleuteld opslaan en weer online gooien.

(* al dan niet een gehaxxorde 'customized' build)
[...]

Je leent uiteraard ook geen sleutel, die data wordt gewoon onversleuteld weer verspreid. Je omzeilt gewoon dat hele DRM.

Als mijn browser het kan afspelen, kan mijn browser* het ook onversleuteld opslaan en weer online gooien.
Dat kun je afvangen door in de interface een white-list te specificeren van browsers en binaries die 'legitiem' een sleutel krijgen. Knutsel jij dus je eigen browser die deze standaard implementeert, dan staat die niet op de lijst van goedgekeurde browsers en krijg je dus heel simpel geen beeld te zien.

Deze standaard is eigenlijk vergelijkbaar met de Common Interface-standaard die door exploitanten van digitale kabel en satelliet is ontwikkeld. Je kan een hoop decoders (browsers) hebben waar een CI-kaart (plugin) in past, en je hoeft niks te weten van hoe die kaart van binnen werkt. Gecodeerd beeld erin, gedecodeerd beeld eruit.

Op CI-kaarten hebben ze nu ook (via de CI+ standaard) een whitelist met decoders die je van de providers wel en niet mág gebruiken om te kijken. Gebruik je dus bijvoorbeeld een decoder die niet door CanalDigitaal is goedgekeurd met je CanalDigitaal CI+-kaart, dan krijg je geen beeld omdat er kans is dat je er zelf aan geknoeid hebt.

Simpelweg zeggen ze: We hebben geen controle over wat je met dat beeld uitvreet, dus dat beeld krijg je dan ook niet. Pas als we het hele pad van schotel tot scherm hebben 'goedgekeurd' en het op een whitelist staat, krijg je van ons de sleuteltjes.

Dat soort wantrouwen in de consument is het hele principe achter DRM. Geen wonder dat de consument dan ook de leveranciers gaat wantrouwen en dus de kont tegen de krib gooit: Er wordt alleen maar meer illegaal verspreid.
Encrypted Media Extensions (EME) zullen dit onmogelijk maken:
Encrypted Media Extensions (EME), a framework that will allow the delivery of DRM-protected media through the browser without the use of plugins such as Flash or Silverlight.
Kortom, zonder EME modules kan content niet gedecodeerd worden. En die maken dus geen onderdeel uit van de browser zelf.

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 het gebruik van Encrypted Media Extensions lost het probleem niet op.

[Reactie gewijzigd door Surkow op 30 mei 2013 14:11]

In zoverre wel dat diverse partijen een binary kunnen compileren voor andere platforms, ipv alleen Microsoft.
Ik ben er vooral bang voor dat er een virus mooi wordt gecodeerd zodat de virusscanner er niet bij kan en dan via deze DRM het op de website wordt getoond en met een 0-day lek wordt uitgevoerd. Ik ben geen specialist op dit gebied dus ik weet niet of het uberhaupt mogelijk is, maar als er advertenties kunnen worden getoond omdat een addblocker daar niet bij kan, dan kan er naar mijn idee ook een virus worden uitgevoerd zonder dat een virusscanner daar bij kan.
Daar heb je in principe geen DRM voor nodig. Als je bijvoorbeeld een lek in uitlezen van PNG-bestanden exploiteert, waardoor je eigen code kunt uitvoeren, kun je een virus op het systeem plaatsen.

Het probleem is echter dat op het moment dat jouw code dat virus op het systeem plaatst, de virusscanner dat zal zien en alsnog zal ingrijpen. Of, wanneer je geen real-time beveiliging hebt of gebruikt, de eerstvolgende keer dat je een scan van je systeem draait.

De vergelijking met ad-blockers houdt echter geen stand, want een ad-blocker is beperkt door hoe diep de browser een ad-blocker laat inspecteren wat er allemaal gebeurt. Daarnaast is het bepalen of iets al dan niet een advertentie een heuristisch proces, wat zoveel betekent als dat je ad-blocker een onderbouwde gok doet. Webdevelopers en ontwikkelaars van advertentiesystemen kunnen heel ver gaan om hun advertenties te maskeren.
EFF tekent officieel protest aan tegen drm in html5
En dat zou iedereen moeten doen! Digital Rights Management is eerder Digital Restriction Management.

Gekochte muziek, films e.d. moeten op -elk- apparaat afgespeeld kunnen worden. DRM is voornamelijk een beperking voor legitieme consumenten die als enige hinder ondervindt van deze 'oplossing'. Illegale verspreiding van mediabestanden wordt door DRM niet tegengehouden.
Ook blijft de DRM 'beveiliging' bestaan als de auteursrechten op media verlopen zijn, waardoor het publieke domein wordt aangetast.

Ergo: DRM is een verkrachting van de rechten van de eerlijke consument.
De verspreiding door professionele illegaliteitsgroepen wordt wellicht niet tegengehouden, maar door DRM krijg je wel dat niet elke buurman zomaar alles kan kopiëren. Dat je bij het kopiëren van een spel alsnog een CD-crack nodig hebt in plaats van dat de kopie zonder meer werkt, maakt dat het maar voor een select publiek te doen is. De grote massa zal het ook meer gaan doen als de barrières compleet weg zijn.
Gekochte muziek, films e.d. moeten op -elk- apparaat afgespeeld kunnen worden
Dat is een mening, geen wet. Ik heb er geen enkel probleem mee dat sommige van mijn iTunes aankopen alleen op Apple devices zijn af te spelen maar niet op mijn Philips TV of mijn wasmachine. Films en media worden gekocht om op een bepaald platform afgespeeld te worden, als dat werkt en je weet het van tevoren is er niets aan de hand.
Ik heb er geen enkel probleem mee dat sommige van mijn iTunes aankopen alleen op Apple devices zijn af te spelen
...en daar sta je dan redelijk alleen.

Niet alleen 'de groenen' en de geitenwollen sokken zijn tegen DRM, maar ook grote bedrijven hebben zich tegen DRM uitgesproken. Bill Gates zei ooit: "DRM is not where it should be, and causes problems for legitimate consumers while trying to distinguish between legitimate and illegitimate users"
Grappig dat je iTunes noemt. Apple verkoopt al sinds 2009 geen muziek meer met DRM.
De directeur van Valve, Gabe Newell, zei: "most DRM strategies are just dumb, because they only decrease the value of a game in the consumer's eyes."

Noem het een mening, maar DRM, het tast de rechten van consument aan en het raakt alleen de legale gebruiker. Daarnaast is DRM niet handig. Ik snap dat mensen naar een 'illegale' versie grijpen als DRM gebruik beperkt.

[Reactie gewijzigd door mrlammers op 31 mei 2013 21:51]

Op dit item kan niet meer gereageerd worden.



Populair: Gamescom 2014 Gamecontrollers Smartphones Apple Windows Sony Microsoft Games Besturingssystemen Consoles

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

Beste nieuwssite en prijsvergelijker van het jaar 2013