W3C publiceert eerste draft voor drm in html5

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

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

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

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

Reacties (123)

[Surkow]

Het eigenlijke probleem is dat de DRM oplossingen platform gebonden zullen zijn. Denk aan x86 DRM binaries welke niet op embedded systemen kunnen werken (ARM, MIPS) en gebonden zijn aan een enkel besturingssysteem. Dit is nu al een struikelblok voor Silverlight en lost het probleem niet op.

[ATS]

Je maakt een uitstekend punt hier. Juist door alleen de API voor plugins te specificeren, zal je gaan zien dat je weer DRM systemen gaat krijgen die alleen op een recente windows of misschien op mac werken, maar die verder niet beschikbaar zijn. Die kant moeten we niet op willen.

[Sorcerer8472]

Klopt helemaal, maar als het niet platform-gebonden was dan was het helemaal open-source, en DRM + open-source is geen goede combinatie

[Verwijderd]

als het niet platform-gebonden was dan was het helemaal open-source

De link die jij hier legt bestaat volgens mij niet. De binary drivers van AMD en Nvidia zijn op alle platforms beschikbaar, maar zeker niet open-source. Steam gaat nu ook die kant op, en ook zeker niet open-source.

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

Ik geloof meer in een Linux met Mixed source. Geen enkel probleem, zolang de aanbieder maar niet vergeet dat ik als consument ook rechten heb. En als ik die niet krijg, dat ik dan wel ander kanalen zoek, desnoods illegale.

[Rafe]

Ik snap dat niet iedereen blij wordt van bepaalde vormen van DRM, maar als het gewoon werkt zou een dergelijke specificatie zou er voor zorgen dat bijvoorbeeld uitzendinggemist.nl eindelijk eens af kan stappen van plug-ins (Silverlight) die de DRM verzorgen. In de context van Jaffe's opmerkingen zou ik dit toch wel als een klein stapje vooruit beschouwen.

[Amanoo]

Gewoon werken is hier dan wel het sleutelwoord. Als ik de standaard niet zelf werkend kan krijgen op een zelfgemaakt OS dat draait op een zelfgemaakte CPU, dan ben ik niet van mening dat het "gewoon werkt". En volledige platform independency is juist een van die sterke kanten van HTML. Bij DRM heb je grote kans dat er ineens een binary blob in je standaard zit, die alleen bruikbaar is voor enkele platforms. Dat geeft weer kans dat een heel obscuur platform het niet ondersteunt, maar misschien geldt dat ook voor bepaalde settopboxen, bepaalde game consoles, misschien zelfs FreeBSD of zelfs voor Linux. En als gebruiker van net dat platform kan je daar heel erg chagrijnig om worden. Daarom moet het ook op dat hypothetische door mij gebouwde platform werken. Als het in principe daarop aan de praat te krijgen is, dan is het overal op aan de praat te krijgen.

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

[Reactie gewijzigd door Amanoo op 29 juli 2024 05:19]

[Juup]

Waarom specificeert het W3C dan niet ook de implementatie, zodat deze opensource kan zijn?

[Sorcerer8472]

Da's een beetje een probleem met DRM he: zodra de implementatie open-source is, is deze per definitie ook te kraken. Dat is nu trouwens met veel DRM-systemen ook al zo; het is vooral een barrière om controle over media te houden bij gebruikers die er niet veel verstand van hebben.

Op zich ben ik wel voorstander, DRM gaat niet zomaar weg en kan nog steeds nuttig zijn, en dit zorgt ervoor dat je dit soort content zonder Flash/Silverlight kan bekijken straks. De krachtigste "handtekening" is gewoon dat je geen gebruik maakt van DRM-diensten.

[.oisyn]

Da's een beetje een probleem met DRM he: zodra de implementatie open-source is, is deze per definitie ook te kraken

Dat is echt complete nonsens. Encryptie stoelt op het geheim zijn van de sleutel, niet van het algoritme waarmee de boel versleuteld wordt.

[DCK]

Juist hetgeen wat jij zegt hier is "complete nonsens" in de context van deze discussie - geval "klok horen luiden, niet weten waar de klepel hangt".

DRM vereist twee eigenschappen om de toegang tot de videodata te beperken.

• Alleen de DRM kan de versleutelde datastroom ontsleutelen
• De ontsleutelde video wordt direct op het scherm weergegen, en de datastroom gaat nergens anders heen.

Het probleem van een open source product is dat de gebruiker zelf het gedrag van de software kan aanpassen, waardoor deze twee eigenschappen niet meer gelden. Een open source implementatie van de eerste eigenschap houdt in dat iedereen de code en de implementatie van sleuteldistributie ontvangt - alles wat je nodig hebt om de datastroom te ontsleutelen.

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

[Reactie gewijzigd door DCK op 29 juli 2024 05:19]

[MadEgg]

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

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

Het is dus ook zonde als dergelijke technieken een plek krijgen in HTML, want het is alleen maar vervuiling die weinig concreets zal gaan bereiken.

[pvcholten]

Behalve dan dat bij DRM de gebruiker per definitie de sleutel heeft. (Anders zou hij het ook niet af kunnen spelen.)

[Reactie gewijzigd door pvcholten op 29 juli 2024 05:19]

[TheNephilim]

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

Ik ben benieuwd hoe ze dit willen oplossen!

[mad_max234]

Ze zouden een verplichte online drm check kunnen inbouwen en autorisatie dus server side word gedaan en niet eens aan de client side, dat zorgt er wel voor dat dus niet offline kan afspelen, alleen als in internet verbinding hebt. Wat ook het originele plan voor blu ray spelers was, verplicht internet verbinding om drm check uit te voeren.

[mad_max234]

Dat betekend nog niet dat algoritme niet openbaar kan zijn en dat het dan per definitie onveiliger maakt. Sleutel voert men toch pas later toe, dat kan in een apparaat firmware zijn die op zij beurt weer hardwarematig is afgesloten, of online staan bij de makers.

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

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

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

[Reactie gewijzigd door mad_max234 op 29 juli 2024 05:19]

[sfranken]

Dit gaat over een specificatie voor HTML. Daar komen dus geen DRM chips aan te pas anders hebben oudere devices straks allemaal een probleem.

[mad_max234]

Ja dat snap ik, was maar één van de voorbeelden dat je niet zomaar bij de key kan als moet je die wel in je bezig hebben om iets af te spelen.

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

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

[Reactie gewijzigd door mad_max234 op 29 juli 2024 05:19]

[Sorcerer8472]

Mooi hoe mijn reactie omlaag wordt gemod en de jouwe omhoog wordt gemod .oisyn, geeft toch maar aan hoe weinig kennis users op Tweakers hebben van DRM.

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

De reden dat ik in mijn post verder zeg voorstander van DRM te zijn is niet dat ik DRM een goed principe vind (integendeel)... Ik denk dat het nodig is totdat content-eigenaars eindelijk tot het inzicht komen dat de huidige modellen niet meer werken. Tot die tijd is maximale beschikbaarheid van content wel belangrijk, en een standaard als deze draagt daaraan bij.

[Verwijderd]

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

[Reactie gewijzigd door Verwijderd op 29 juli 2024 05:19]

[Stoney3K]

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

Uiteindelijk moet het toch als een 2D plaatje van een blok pixels op een scherm worden weergegeven, anders kunnen je ogen het niet oppikken.

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

De enige manier om dan nog DRM af te dwingen is mensen een chip in hun hoofd implanteren en de schermen voeren met een versleutelde berg ruis. Maar daar word je denk ik niet heel vrolijk van

[Aloys]

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

Open-source algoritmen zoals RSA zijn simpel genoeg om door een gewone software developer geïmplementeerd te kunnen worden. Met die algoritmen wordt jouw connectie met de bank en mail (als je SSL gebruikt) beveiligd.

[MSalters]

En precies daarom wordt DRM niet tot (serieuze) encryptie gerekend. DRM probeert af te dwingen dat je met bits bepaalde dingen wel mag doen, en andere dingen niet. Dat laat de wiskunde simpelweg niet toe.

[PolarBear]

AES is volledig open source, en toch niet te kraken.

[Martinspire]

Het zal best te kraken zijn, maar op dit moment zijn computers nog niet snel genoeg om alles te proberen. Tijd lijkt de grootste medestander van AES te zijn op dit moment, maar dat zal in de toekomst ook wel weer veranderen.

[MadEgg]

Kraken is wat anders dan brute-forcen he? Als je maar lang genoeg sleutels blijft proberen is elke encryptie-techniek te brute-forcen. Dat betekent nog niet dat de encryptiemethode te kraken is. Mocht je dat consequent kunnen redden in overzienbare tijd dan is alleen de sleutel wellicht niet lang genoeg.

[Amanoo]

Juist een van DE grote ideën binnen cryptografie is dat een encryptie pas veilig is als je kan zeggen dat het niet te kraken is als je niet het wachtwoord hebt, zelfs als alles over een systeem bekend is. Dit is de enige reden waarom RSA nog als veilig wordt gezien. Je mag er bij dat algoritme van uit gaan dat iedereen op deze planeet weet hoe het werkt (uiteraard niet helemaal waar, maar iedereen met toegang tot een bibliotheek of tot internet en de verstandelijke vermogens om te begrijpen hoe het werkt kan het leren), maar tot nu toe zijn zaken die met RSA zijn versleuteld enkel te kraken met brute force methoden. RSA is zeer waarschijnlijk het enige wat tussen jouw bankrekening en een groep hackers in zit.

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

[Reactie gewijzigd door Amanoo op 29 juli 2024 05:19]

[pvcholten]

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

Als er een open-source player zou bestaan die DRM-beveiligde content kan afspelen, kan je heel makkelijk de source downloaden, en aan de hand daarvan een versie maken die de DRM stript.

[Blokker_1999]

DRM en OSS sluiten elkaar helemaal niet uit. Het is dat wij dat er van maken. Waarom denk je dat bijvoorbeeld HDCP is uitgevonden?

[mkessels]

DRM en OSS sluiten elkaar wel uit. Volgens wikipedia: "Each HDCP-capable device has a unique set of 40 56-bit keys. Failure to keep them secret violates the license agreement.". Als de broncode open is, is het niet mogelijk om deze set van sleutels geheim te houden.

[SuperDre]

uhm sleutels en broncode zijn 2 compleet verschillende dingen, de broncode kan rustig opensource zijn...

[Stoney3K]

uhm sleutels en broncode zijn 2 compleet verschillende dingen, de broncode kan rustig opensource zijn...

Het probleem met open-source DRM algoritmes is dat er hoe dan ook ergens een sleutel moet worden uitgewisseld, anders kan de gebruiker het hele handeltje gewoon niet zien.

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

Hoe je het ook wil implementeren, als je het open-source maakt ondermijn je het hele idee van DRM: De controle leggen bij de content-uitgever, niet bij de gebruiker.

[mkessels]

Dat klopt, alleen is het probleem dat bij drm de sleutel op een of andere manier aan de eindgebruiker gegeven moet worden, anders kan hij de media niet zien. Bij alle drm oplossingen (ook hdcp) moet er ergens dus in de keten een stuk software zijn die voor de eindgebruiker niet te doorgronden is, en de content decodeert met de meegeleverde sleutel. Als dat stuk software open source is, dan kan ik als eindgebruiker die software aanpassen zodat ik deze sleutel kan gebruiken om de media zelf te decoderen.

[Loller1]

"Google heeft de specificatie al in Chrome geïmplementeerd"

Wat? En het is nu nog maar een draft? Er kan nog van alles veranderen en Chrome implementeerd het al?

[Svennetjee]

Het begint een beetje een Internet Explorer verhaal te worden bij Chrome. Zelf dingen bedenken en implementeren terwijl de specificatie niet of nauwelijks af is.

[Oxidda]

Daar hebben ze hele leuke termen vorm als POC (Proof of Concept) , zoals de naam al zegt is zo'n POC ervoor bedoeld om te kijken of de ingeslagen weg uberhaupt haalbaar is.

[Martinspire]

Probleem is echter dat ze het meteen toevoegen aan de normale versies (ipv alleen in de dev-versies) waardoor het zijn doel voorbij schiet. Daardoor heb je dat op den duur bepaalde sites al zaken gaan implementeren waardoor je weer verschillen krijgt. Dat is de reden dat je nu voor een heleboel websites een slechte weergave krijgt in andere browsers, puur door al die prefixen van Chrome e.d.

[arendjr]

Als het alleen in de development versie zou zitten zou niemand er voor z'n sites gebruik van kunnen maken. Dan wordt het dus ook nooit op een grotere schaal getest dan enkele proof of concepts. Bovendien zou er dan nog meer teruggegrepen worden op Flash-based oplossingen omdat dan plots heel erg veel nieuwe (maar vaak inderdaad experimentele) functionaliteit simpelweg niet beschikbaar is.

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

Waar het pas fout gaat is als developers de prefixed versies gebruiken zonder de nodige effort erin te steken om zaken aan te passen als de specs veranderen (want dat kan nog in de draft phase) en niet goed met alle browsers testen. Dat is inderdaad soms een probleem, maar het alternatief zou betekenen dat we allemaal nog HTML4 en Flash moeten gebruiken en dat HTML5 voorbehouden blijft aan tech previews.

[Martinspire]

Het is een draft, die hoort ook nog niet in productie te worden genomen. Leuk dat je het alvast wilt testen, maar zo werkt dat dus niet. Een concept-auto komt ook niet meteen op de markt.

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

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

[sfranken]

@Martinspire
Deze "draft" implementatie moet je anders zelf aanzetten in chrome://flags

En elke behoorlijke sitebouwer prefixt zijn code met -webkit, -moz, -ms, -o en optioneel -khtml, gevolgd door de non-prefixed variant.

[Martinspire]

Ok, dat wist ik dan niet, maar dat is dan wel 1 van de weinige waar ze dat zo mee gedaan hebben.

[Loller1]

Elke behoorlijke sitebouwer hoort ook te weten dat hij prefixes beter uit de weg kan gaan.

[Blokker_1999]

Tja, een spec word zelfs pas een standaard nadat er verschillende implementaties zijn van de spec. HTML5 zal bijvoorbeeld nog jaren nodig hebben om een standaard te worden en de spec van HTML5 is vandaag ook nog altijd niet volledig. Zullen we dan ineens alle browser beginnen afschieten?

[Gerco]

W3C is nogal traag. Het duurt jaren voor een specificatie van draft naar final status gaat. Als browsers zouden wachten op de final van de spec voor ze met implementatie beginnen hadden we nu op de browsertechnologie van 3-4 jaar geleden gezeten.

[Verwijderd]

Traag? Misschien. Maar vooral erg grondig, elk aspect wordt uitgebreid getest waardoor de standaard ook een goede standaard is.

[ATS]

En om te testen... moet je het implementeren! Sterker nog, meestal wordt iets geen standaard totdat er twee onafhankelijke referentieimplementaties van zijn.

[Loller1]

Hebben ze daar niet een goede reden voor? Een standaard als HTML5 doe je niet zomaar even overnieuw omdat je te weinig tijd nam om het grondig te testen.

[SuperDre]

maar 'HTML5' is nog geen definitieve standaard voor het geval je het nog niet wist, eigenlijk is het zelfs te gek om los te lopen dat er al zoveel gebruik gemaakt wordt van een standaard die in ontwikkeling is...

[sfranken]

Het W3C is net als het Debian team: ze brengen iets uit en zeggen "dit is nog niet helemaal stabiel". Ondertussen is het knetterstabiel (debian testing...)

[Loller1]

HTML5 in zijn geheel nog niet, maar specifieke onderdelen zijn wel al volledig voltooid.

[sgt frankieboy]

Als er geen implementatie is hoe kunnen ze het dan testen zodat er verbeteringen kunnen worden gemaakt?

[Loller1]

Denk je dat het W3C hun specificaties niet zelf testen?

[Verwijderd]

Als er geen implementatie is hoe kunnen ze het dan testen zodat er verbeteringen kunnen worden gemaakt?

In de praktijk gebeurd het bijna altijd, dat het eerst geïmplementeerd word en op basis van de implementatie de draft geschreven word, omdat je tegen allemaal dingen aan loopt in de implementatie waar je van tevoren nooit aan denkt. Het is vaak een dynamisch proces waar w3c en bijvoorbeeld google en apple devs nauw samenwerken, De schrijver van de draft is ook altijd iemand van google of apple of een ander groot bedrijf die vaak al een hoop research gedaan heeft op het gebied van de desbetreffende draft. En de teams erachter bestaan ook uit devs van deze bedrijven. Het is niet zo dat W3C dicteert. Zij functioneren meer als manager tussen alle grote bedrijven, En W3C zorgt er daadwerkelijk voor dat nieuwe technologien worden doorgedrukt en niet worden tegengehouden omdat het even niet in het belang van een bedrijf is, Dan heeft het bedrijf gewoon pech.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 05:19]

[Verwijderd]

Grootste gedeelte van HTML 5 is nog maar een draft

[kjast]

Is het in Chrome geimplementeerd of in Chrome Canary? Dat is nogal een verschil..

[SuperDre]

Uhm.. Je weet toch wel dat HTML5 zelf ook nog steeds niet definitief is, en dat de HTML5 die geimplementeerd is in de browser allemaal nog kan veranderen, daarom zit je nu ook nog als devver behoorlijk opgescheept met heel veel vendor-prefixes...

[Loller1]

HTML5 in zijn geheel is inderdaad nog niet af, maar onderdelen daarvan zijn wel al gewoon stabiel.

[Verwijderd]

Ben je jaloers ofzo dat Chrome en Firefox gewoon alles snel implementeren??? Doet jou precious internet explorer dat niet?

[Verwijderd]

Hoewel DRM op zich naar mijn mening niet goed is, lijkt me dit toch wel een redelijke goede ontwikkeling. Anders stappen bijvoorbeeld Uitzending Gemist, RTL Gemist en KPN itv online nooit over op HTML en blijven hangen in Flash en Silverlight.

[Verwijderd]

Tsja, persoonlijk heb ik geen enkele last van Flash en Silverlight problemen in alle drie mijn browsers niet, heb nooit crashes of andere ongein gehad, dus van mij mag het blijven.

[Verwijderd]

Op telefoons en tablets werkt het niet, ja Flash is er wel voor android maar werkt niet echt goed. Tevens werkt Silverlight niet op Ubuntu.

[Verwijderd]

Je hebt helemaal gelijk en daar komt nog bij dat vanaf Jellybean 4.1 Flash op Android ook niet meer ondersteund wordt. Je schijnt nog wel een APK die voor ICS bedoeld is van internet te kunnen plukken. Maar ja dat is ook niet voor iedereen weggelegd. Verder wordt Flash voor Linux sinds 11.1.x ook niet meer actief ontwikkeld(alleen nog security updates dacht ik en misschien nog non-security bugfixes). Daarnaast heeft Adobe zelf ook toegeven dat Flash dood is en ze zijn zelf al begonnen met HTML5 tools te maken, zodat die op termijn de Flash dev tools kunnen gaan vervangen als inkomstenbron.

[Loller1]

Flash voor Android is ook geschrapt.

[Verwijderd]

Ik heb eigenlijk maar 1 antwoord en dat is: "Denk groter"

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

[Amanoo]

Pas als ik zeker kan zijn dat het op elk platform werkend te krijgen is, inclusief iets dat ik compleet zelf heb verzonnen, wil ik stoppen om een tegenstander te zijn. Ik wil geen binary blobs in een open web standaard zien, wat er alleen toe zal leiden dat de standaard alleen onder Windows, of alleen op ARM of alleen op ...... werkt. Je gaat dan geheid zien dat het gross van de aanbieders 1 of 2 platforms ondersteunen en dat er voor mij nog steeds geen alternatief is voor illegaal downloaden. De standaard moet of volledig open, of niet bestaan.

[Reactie gewijzigd door Amanoo op 29 juli 2024 05:19]

[joho]

Het is al een paar keer eerder gezegd, maar het lijkt alsof iedereen er overheen leest. DRM werkt niet als het algoritme bekend is en je de gebruiker ook de sleutel geeft. De werking van DRM is alleen te realiseren door:
- open software maar gesloten hardware (USB key, kaart lezer, etc)
- gesloten software (binare blob)
Beide met hun eigen beperkingen.
- gesloten hardware kan je niet overal op aansluiten (fysiek niet, of de driver is er niet in jouw smaak)
- gesloten software kan je niet overal uitvoeren (de blob is niet voor jouw platform gemaakt)
Dan gaan we weer naar waar we vandaan komen; 90% is Microsoft/Intel gebruiker.
Of om deze compatibiliteitsproblemen te omzeilen krijgen we een virtuele machine ala ACPI, Java VM, .NET CLR.
Leuk als je consumentisme aanhangt, maar minder grappig als je van vrijheid houd.
(De wet zou zo makkelijk kunnen zijn. Als je iets publiceert, dan is het vrij. Houd je het voor jezelf, dan is het geheim.)

[Reactie gewijzigd door joho op 29 juli 2024 05:19]

[computerjunky]

net als je denkt dat ze doorhebben dat drm slecht werkt nee hoor ze stoppen het in html...

[codebeat]

Laat W3C nou maar eens opschieten met acceptatie van de 'standaard' ipv weer van die halfbakken features toe te voegen. Op papier ziet het er allemaal leuk uit.......maar in de praktijk.....

[Reactie gewijzigd door codebeat op 29 juli 2024 05:19]

[SvMp]

Ze mogen die draft steken op een plek waar het licht niet schijnt. Ze moeten zich bezig houden met innovatie in plaats van beperking. Microsoft en Google zijn ordinaire verraders, en ook Tweakers vindt het prima. Uiteraard staat Firefox hier niet achter.

[Reactie gewijzigd door SvMp op 29 juli 2024 05:19]

[Verwijderd]

Klantvriendelijk. Marketing. De klant is koning. Etc. Is DRM klantbriendelijk? Nee, het is bedoeld voor de verkoper. Wat wil de klant. Dat interesseert de verkoper niet. DRM wil hij. Is drm klantvriendelijk. Nee, de verkoper wil bepalen hoe media door de klant wordt benaderd. Desnoods wordt drm als klantvriendelijk afgedwongen door veel marketing.