EFF tekent officieel protest aan tegen drm in html5

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.

De 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)

[vaagisdenaam]

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.

[Amanoo]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[kramer65]

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.

[Dreamvoid]

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.

[Marcks]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[CyBeR]

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

[Dreamvoid]

Jij weet de key niet, de decoding library weet de key.

[CyBeR]

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 23 juli 2024 06:58]

[Marcks]

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.

[Dreamvoid]

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?

[CyBeR]

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 23 juli 2024 06:58]

[Stoney3K]

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.

[Dreamvoid]

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.

[The Zep Man]

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 23 juli 2024 06:58]

[Marcelloz]

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 23 juli 2024 06:58]

[jrfloor]

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.

[Marcelloz]

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 ;-)

[killercow]

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.

[mjtdevries]

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.

[BenGenaaid]

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

[ronaldmathies]

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.

[Sorcerer8472]

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

[Verwijderd]

... 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 Verwijderd op 23 juli 2024 06:58]

[mashell]

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.

[PPie]

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

[Mr_gadget]

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

[Cambion Daystar]

Ja en nu we flash/silverlight hiervoor moeten gebruiken gaat het zoveel beter...

[Wilke]

Inderdaad, want Silverlight komt sowieso de deur niet in, en Flash staat standaard achter click to play. Problem solved.

[Amanoo]

Ik denk dat eigenlijk de vraag moet worden gesteld "Kan een willekeurig persoon op een zelf ontworpen CPU, met een zelfontworpen OS op een zelfontworpen browser de HTML5 standaard volledig implementeren, zonder licentiekosten, lastige bureaucratie en dergelijke?", ervan uitgaande dat de betreffende persoon uiteraard hiertoe de nodige kennis bezit (mogelijk zijn er wel enkele studenten aan een universiteit die dit kunnen). En kan van dit platform de bronbestanden (CPU-ontwerp, source codes) vrij worden gedistribueerd? Indien hierop gewoon ja kan worden geantwoord zijn er weinig problemen met dit. Helaas is DRM zo goed als inherent verbonden aan geslotenheid, al is het alleen maar omdat niet iedereen mag weten waar een key is opgeslagen. In het absurdste geval wordt de key deels gegenereerd op basis van CPU-architectuur en/of OS. Als op een van de vragen nee, of zelfs "ja, maar", wordt geantwoord, zoals dus zeer waarschijnlijk het geval zal zijn, is er sprake van platformafhankelijkheid. En dat betekent weer dat niet iedereen volledig HTML5 kan gebruiken, en dus niet volledige toegang heeft tot de delen van het WWW waar je gewoon recht op hebt. En dat mag gewoon niet met het WWW gebeuren, dat hoort in te gaan tegen alles waar het W3C voor hoort te staan. Hoe zou jij het vinden als je videomateriaal niet kan zien omdat je toevallig Mac OS gebruikt, toevallig een tablet hebt of toevallig een ander platform? Er zullen geheid mensen zijn die hier tegenaan zullen lopen.

Als dit alles niet te garanderen is (en dat is het niet, zoals hierboven gezegd: DRM = encryptie + gebruiksbeperking, en juist die gebruiksbeperking heeft geen plaats in HTML) moet je maar een losse DRM plugin maken, net zoals Flash en Silverlight nu plugins zijn.

[Reactie gewijzigd door Amanoo op 23 juli 2024 06:58]

[Verwijderd]

Zucht.. Gaat de entertainment-industrie dan nooit leren dat alles wat op een scherm getoond wordt en/of via een speaker naar buiten komt, dat dat simpelweg altijd te kopieren is en dat zaken als DRM een wassen neus zijn?

Virtual soundcard driver, virtual videocard driver.. kopieerbaar. punt.

Waarom geld steken in technologie die de brave burgers onder ons alleen maar kan hinderen, terwijl de minder brave burgers er geen moment meer ongemak aan zullen beleven.

Steek je geld en energie in je content en de manieren waarop mensen het nog makkelijker en sneller kunnen consumeren. Levert je vast meer geld op dan te proberen met loze technieken een groepje minder brave mensen proberen dwars te zitten die er toch geen last van gaan hebben.

[bob harley]

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?

[Herko_ter_Horst]

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 23 juli 2024 06:58]

[Korben]

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.

[Durandal]

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.

[Soggney]

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

[DLGandalf]

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?

[Verwijderd]

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.

[skatebiker]

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.

[Verwijderd]

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.

[Korben]

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.

[Amanoo]

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 23 juli 2024 06:58]

[Dreamvoid]

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.

[Stoney3K]

[...]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[Stoney3K]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[Stoney3K]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[Amanoo]

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.

[Sorcerer8472]

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.

[Dreamvoid]

Dat kan dan ook gewoon met open source.

Voorbeeld: een signed binary, compiled vanuit 100% open source code. Wel open source, niet reverse-engineerbaar.

[Hoopje]

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.

[Dreamvoid]

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 23 juli 2024 06:58]

[Hoopje]

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

[Jace / TBL]

DRM = restricties voor de gebruiker, die plaats moeten vinden (c.q. medewerking vereisen) aan de kant van diezelfde gebruiker.

Hoe verzin je het.

Iedereen begrijpt toch wel die onzin direct wordt omzeild via customized browsers die niet meewerken aan die kolder? Dat wil zeggen dat bepaalde restricties die men de gebruiker wil opdringen (zoals het wel kunnen bekijken van je content als het eenmaal gedecrypt is, maar niet kunnen opslaan) er domweg uitgesloopt worden.

[Dreamvoid]

Customized browsers zullen niet de private key hebben om de DRM decryptie library te signen.

[Stoney3K]

Customized browsers zullen niet de private key hebben om de DRM decryptie library te signen.

Even een kleine nuancering: Je blijft nu continu hameren op het signen van binaries door browsers.

In de hele EME standaard van HTML5 staat juist dat een browser dat niet hoeft te doen. Sterker nog, die browser hoeft helemaal van het DRM-gebeuren niks te weten, alleen dat er iets in zijn document zit wat via EME loopt en wat ie moet weergeven.

Vergelijk het met een PCI-slot in je computer waar je iets in steekt. Het moederbord (browser) zal het weinig uitmaken of dat nu een geluidskaart of een netwerkkaart is: het enige wat je moederbord zal doen is het ding blindelings data voeren en de kaart zal zelf afhandelen wat er nodig is.

De binaries die de daadwerkelijke ontsleuteling doen worden door de uitgevers van content geleverd, maar ze bieden allemaal dezelfde API aan naar de browsers toe. Dus of je nu een 'Flash' DRM of een 'Silverlight' DRM gebruikt, het kan allemaal in hetzelfde hokje.

Je blijft dan wel het probleem houden dat je een berg binaries nodig hebt om die EME-enabled content af te kunnen spelen, waardoor niet alle platforms worden ondersteund.

Ook die ontsleutel-library zou je open source kunnen maken, maar dat is iets heel doms omdat je dan weet hoe een DRM-mechanisme werkt en waar een library zijn sleutels vandaan haalt, waar ze opgeslagen worden en waar precies de authenticatie gebeurt. Dan wordt het dus ook heel makkelijk om in die plugin in te breken en allerlei dingen te gaan veranderen of af te vangen.

Zelf een binary builden zal niet veel uithalen, want je kan hem als eigen bouwer niet signen met je eigen sleutel. Maar aan de andere kant, als alles open-source is (dus zowel browser als plugin) kun je ook zeggen dat ie die checks gewoon over moet slaan en de plugin blindelings uit moet voeren. Waardoor je dus zelfs een mooie man-in-the-middle aanval kan doen om zowel sleutels, het ge(de)codeerde beeld, als het hele authenticatie-proces af te vangen en te foppen.

[Dreamvoid]

Ook als je weet hoe de library code eruit ziet, dat wil nog niet zeggen dat je de embedded key eruit kan halen. De key zelf kan bv met memory randomization verborgen worden tijdens het decoding proces, en ook in de binary zelf op allerlei manieren encoded zijn. Ook al heb je de volledige source, dan nog weet je niet met welke parameters hij bv is compiled.

Hoe kan de browser een man-in-the-middle aanval uitvoeren? Hij ziet niets anders dan een encoded stream, die hij doorgeeft aan EME. Pas in de EME library is er een decryptie proces, dus als je in wilt breken moet dat daar gebeuren. Maar dat is niet zo triviaal, bv als het protected video/audio API van het OS een signed EME library verwacht kan je niet zo makkelijk zelf een MitM sniffer ertussen zetten. Ook de framebuffer van het De gpu uitlezen is met HDCP etc nog niet zo makkelijk.

Er wordt heel makkelijk over gedaan, maar zo eenvoudig als het lijkt is het echt niet.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 06:58]

[Stoney3K]

Ook als je weet hoe de library code eruit ziet, dat wil nog niet zeggen dat je de embedded key eruit kan halen.

In de meeste DRM-schema's heb je niet eens een key IN de binary zitten, alleen al omdat dat een risico is om die key weer te ontfutselen. Die sleutel wordt dan via een vertrouwd pad van afstand opgehaald en is per sessie anders.

Hoe kan de browser een man-in-the-middle aanval uitvoeren? Hij ziet niets anders dan een encoded stream, die hij doorgeeft aan EME. Pas in de EME library is er een decryptie proces, dus als je in wilt breken moet dat daar gebeuren. Maar dat is niet zo triviaal, bv als het protected video/audio API van het OS een signed EME library verwacht kan je niet zo makkelijk zelf een MitM sniffer ertussen zetten.

In een open-source OS wat EME zou ondersteunen kan dit prima: Je modificeert gewoon de video API van het OS. Vroeg of laat zal er wel ergens een framebuffer uit móeten komen, anders zal je monitor er geen hol van snappen.

Als je een deel van het pad open-source houdt betekent dat ook dat je in dat gedeelte van het pad gewoon de versleuteling uit kan zetten. Tuurlijk zal de originele video-API van je OS wel een HDCP-enabled uitgang verwachten, maar die kun je makkelijk modificeren om die check over te slaan. Als je browser, en je OS, namelijk open-source zijn, kun je die als gebruiker zelf aanpassen en gewoon die plugin foppen dat er een 'vertrouwd' pad is naar je beeldscherm.

De enige manier om DRM te handhaven is juist door een pad voor de content te maken waar de gebruiker geen invloed op kán hebben. Dat is namelijk het hele idee van DRM, en het staat juist haaks op het principe van open-source software: Daar weet de gebruiker juist precies wat er onder de motorkap gebeurt en hoe je dat kan beïnvloeden om je eigen doel te bereiken.

Stel je voor de grap eens voor dat je hele client-pad met een EME-ondersteunde browser open-source zou zijn (inclusief dus, de firmware van de monitor die HDCP ondersteunt), hoe moeilijk is het dan om de gedecodeerde data op te slaan en de DRM te strippen?

[Jace / TBL]

Als geen enkele open source browser (waaronder Firefox en Chrome) het kan, wordt het sowieso 100% een flop. En als ook maar één open source browser het wel kan, zal er ook een customized versie komen.

[Dreamvoid]

Het gaat niet om open source, het gaat om de private key(s) die je nodig hebt om de DRM streams te kunnen decrypten. Google en Mozilla zullen bijvoorbeeld een DRM library in hun browser kunnen compilen met een private key erin. Jij kan wel met dezelfde source code Chrome of Firefox zelf gaan compilen, maar jij hebt de juiste private key niet.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 06:58]

[KoploperMau]

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 23 juli 2024 06:58]

[Verwijderd]

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.

[Blokker_1999]

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?

[Kewne]

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.

[i-chat]

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.

[GeoBeo]

Een wereld zonder DRM bestaat al: China.

[SuperDre]

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.

[Verwijderd]

Het is helemaal niet moeilijk. Het is heel simpel.

[Verwijderd]

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.

[huntedjohan]

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

[Verwijderd]

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?

[PPie]

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.'?

[Verwijderd]

?????

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 Verwijderd op 23 juli 2024 06:58]

[PPie]

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

[Verwijderd]

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 Verwijderd op 23 juli 2024 06:58]

[HerrPino]

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?

[Korben]

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.

[Jace / TBL]

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)

[Stoney3K]

[...]

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.

[Amanoo]

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.

[Dreamvoid]

Je hoeft ze niet closed source te maken. Je kan bv ook signed binaries van open source code maken.

[Surkow]

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 23 juli 2024 06:58]

[Dreamvoid]

In zoverre wel dat diverse partijen een binary kunnen compileren voor andere platforms, ipv alleen Microsoft.

[mrlammers]

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.

[MsG]

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.

[mashell]

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.

[mrlammers]

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 23 juli 2024 06:58]