Dostane se DRM do HTML?

Mezinárodní konsorcium W3C (World Wide Web Consortium) zveřejnilo první návrh rozšíření pro podporu šifrovaných médii (Encrypted Media Extensions). V oznámení i vlastním návrhu se zmiňuje prémiový obsah a správa digitálních práv (DRM). Rozpoutala se bouřlivá diskuse. Dle některých by se konsorcium W3C tímto vůbec nemělo zabývat. Jiní, například BBC, s návrhem souhlasí. Problémem je také CDM (Content Decryption Module), modul pro správu klíčů a licencí k vlastnímu dešifrování obsahu. Původní návrh počítal s CDM s otevřeným zdrojovým kódem. S tím dodavatelé chráněného obsahu nesouhlasí. Prosazují binární blob, který budou mít pod kontrolou.

14.2.2013 00:46 | Ladislav Hagara | Zajímavý článek

Komentáře

[VM]

Záliba posílat vlastním zákazníkům zašifrované video a klíč v divných formátech přehratelných jen někdy, někde a v polofunkčních přehrávačích, působit jim tak problémy s používáním, motivovat je ke stahování a šíření pirátských verzí bez DRM a následně bědovat, jak se to pirátství šíří - ještě je to baví? Není to už nějaká psychiatrická diagnóza?

[michi]

Nabízet obsah, který by uživatelům stál za přirozené placení bez obcházení? Ale kdeže, rozšíříme si binární blob.

[Ovocníček]

'Prémiový' je reklamní patvar, fuj pryč! Správně se to překládá *placený obsah*.

[VM]

"Prémie" je v češtině něco co dostanu navíc, většinou bez dalšího placení. Tak proč se diví, že jim za to lidi nechtějí platit?

[little.owl]

To se objevilo jiz pred rokem a uz tehdy to bylo kritizovano, jak se zda bez uspechu ... .

[xkucf03]

Proč vymýšlet kolo? Vždyť mají Flash. Kdo chce, ať si ho používá, pro ostatní jsou tady otevřené formáty.

[VM]

Flash postupně mizí, na některých platformách nikdy nebyl, teď ho Adobe přestává vyvíjet i pro ty kde byl (např. Linux). Tenhle návrh snad v dohledné době nikdo nerozchodí, a Mezinárodní Federace Pornografického Průmyslu (IFPI) a spol. prosazují vlastní neprůchodné řešení (už vidím Mozillu a spol., kteří šílí z pádů Flashe a děr v Javě, jak přidávají další ještě horší binární blob). Myslím že problém s DRM je tím skoro vyřešen, zůstane na blackboxech co se připojují přes HDMI/HDCP k televizi a které moc lidí nepoužívá.

[Ilfirin]

pro linux nepřestal být vyvíjen

[Ladislav Hagara]

Aktuálně: Budoucnost Adobe Flash na unixových platformách:
Adobe se rozhodlo ukončit vydávání nových verzí klasického Flash Playeru pro Linux - bude jen udržována stávající verze 11.2, takže zde nebude možné očekávat vylepšení (jako menší zátěž procesoru) nebo podporu budoucích verzí SWF.

[Ilfirin]

Adobe Flash Player - Verze: 11.6.602.167

[Jakub Lucký]

A kde se to dá sebrat?

[little.owl]

Flash pro Linux bude, ale jen s "Pepper" API zabalene v Google Chrome. Da se to z nej vyrabovat a pouzit v Chromium. Mozilla Pepper nechce a Flash podporujici NPAPI jiz skutecne nebude, takze Firefox ma asi smulu - nebo stesti .

[Jakub Lucký]

Jo, takže nová verze Flashplayeru není... Je jen cosi uvnitř nějakého Googlího bastlu, nic pro všechny prohlížeče

[Ilfirin]

To záleží na úhlu pohledu. Je to Linuxí binárka, je vyvíjená? Ano, NPAPI skončilo 11.2, ale Flash pro Linux jen změnil podobu (může se to nelíbit), nikoliv skončil.

[Jakub Lucký]

A musím(!) si ho vykuchat z nějakého prohlížeče... WTF?

[Michal Kubeček]

Flash postupně mizí, na některých platformách nikdy nebyl, teď ho Adobe přestává vyvíjet i pro ty kde byl (např. Linux).

Pochybuji, že tohle autory webů ve větší míře odradí. Každou chvíli někde narazím na upozornění, že pro zobrazení obsahu si mám stáhnout Silverlight - a ten je rozšířený ještě hůř než flash.

[D.A.Tiger]

Starý dobrý HTML 4.0. Tehdy to byl ještě značkovací jazyk pro tvorbu hypertextu. Dneska do se do něj cpou kde jaký kraviny a jeho původní účel, jednoduchost, použitelnost a nenáročnost je v podstatě ta tam. Copak na tvorbu "COOL moderních, všeumějících" Webových stránek a aplikací nestačí Rozšíření prohlížečů (např, integrace s flash, audio/video přehrávači, a pod..), JS, CSS, Java, PHP a pod...? Proč musí zanášet HTML takovými zbytečnostmi? :'-(

(SARKASMUS) Nebylo by jednoduší se na to tedy rovnou vykváknout, zabudovat do prohlížečů rovnou podporu nějakého binárního formátu, nebo rovnou založit internetové stránky na nějakém offisovém balíku?(SARKASMUS)

[Zopper]

Myslím, že na to PROČ mám odpověď:

Problém je v tom, že ta Rozšíření jsou obvykle mimo kontrolu výrobce prohlížeče (známe bezpečnost třeba u takové Javy), způsobují většinu problémů... tak jsou pochopitelně snahy ta rozšíření obejít. (PHP v tomto kontextu nemá žádný smysl, to je serverový jazyk, jehož výstupem je nejčastěji právě nějaké to HTML). A abych byl upřímný, spousta věcí se mi na HTML5 líbí - třeba i taková drobnost, jako že user-end kontrola formulářů (je to datum validní?) bude na bedrech autorů prohlížeče a ne mých.

V důsledku si za tohle můžeme jako zákazníci sami - chceme aby aplikace fungovaly na našem oblíbeném systému, nechceme používat ten jeden vybraný výrobcem nějaké aplikace - a nejsnadněji to zajistí právě webové aplikace, kde si ale zase stěžujeme na to bezpečnost, na pády prohlížečů, na to, že to neumí to a to... Poptávka a nabídka.

[mirec]

Z dizajnérskeho hľadiska je kontrola inputov v prehliadači blbosť, ktorá sa bude riešiť javascriptom (zase) keďže nikto pri návrhu nemyslel, že by niekto mohol chcieť chybové hlášky, alebo placeholdery ofarbičkovať.

[Honza Jaroš]

Vy se vážně chcete spoléhat při validaci vstupů na software, který neznáte a na serveru už nic kontrolovat nebudete? To je odvážné. Velmi odvážné...

[stativ]

Nemyslel to Zoper tak, že nebude muset řešit příslušné UI? Protože když člověk chce nějaké rozumné UI např. pro výběr data v HTML4, musí na to použít JavaScript, kdežto v HTML5 je to v podstatě zadarmo.

[Honza Jaroš]

V tom případě jsem to pochopil špatně. Na mě to působilo dojmem, že chce validaci na straně serveru úplně pustit k vodě.

[Zopper]

Jak píše Stativ - šlo mi jen o tu client-side live validaci, na serveru samozřejmě budu validovat taky. Ale nebudu muset řešit zvýraznění chyb a cpát kvůli tomu do stránky tunu javascriptu - kolikrát jen kvůli té live validaci.

[Honza Jaroš]

Tak to pak jo...

[xkucf03]

XForms…

[D.A.Tiger]

K tomu PHP - vím, měl jsem na mysli různé nástroje( třeba to PHP), nebo celé skupiny (rozšíření prohlížečů), které umožní tvůrcům stránek - dle mého názoru - takové stránky tvořit, aniž by bylo nutno přidávat subsystémy nesouvisející s textem do HTML (třeba integrace s multimedií, canvas, atd...) a teď nejnověji DRM. Skoro to vypadá jako by reklamní loby měla svoje prsty i ve W3C

Na jednu stranu tyto argumenty chápu, na druhou stranu, si myslím, že každá aplikace by měla dělat věc pro kterou je určena a skládá-li se její úloha z dalších, ale netriviálních podúkolů, nebo komplexních celků, neměla by se tím zabývat sama, ale přenechat jejich vykonání samostatným projektům (minimálně ve formě externích knihoven, pluginů). Zadrátováním takových subsystémů přímo do aplikace se nejenže chybám nevyhnete, ale ve finální podobě se zvyšuje molochojidnost výsledné aplikace, Ztíží se hledání oněch nedostatků a navíc odeberu uživateli možnost volby ( odebrat je, popř zaměnit, není-li s nimi spokojen - tedy existuje-li alternativa).

Tyhle věci by se vůbec neměli týkat HTML jako jazyka, notabene jazyka určeného pro formátování a odkazování textu. A už vůbec by neměli být vnucovány přes tento jazyk. Říká se, že "pokrok nezastavíš", ale obávám se zda tohle je ten správný pokrok. HTML mělo zůstat takové jaké je, nejlépe jej ještě zjednodušovat. Když už mohli zkusit oživit XHTML (a tam zas takové věci podle mě potřeba nejsou).

Vede to i k děsivým obskurnostem : Engine LOVE pro 2D hry asi znáte. A víte, že umožňuje ve verzi 0.8.0 vytvářet i hry pro WEB? Jo, jak jsem to pochopil je to JavaScript který simuluje engine a ta hra musí být navíc na to speciálně vytvořená a jednotlivé herní framy generuje jako HTML5 kód. Místo toho, aby se udělal plugin do prohlížečů, který vytvoří frame, v němž spustí normální LOVE engine a natáhne naprosto normální *.love soubor, uložený na serveru.... No, proč to dělat jednoduše, když to jde i složitě...

[xkucf03]

JavaScript který simuluje engine

Dneska se často vytváří počítač uvnitř počítače resp. uvnitř prohlížeče. Je to hnané nějakou naivní představou, že problémy, které vznikaly na desktopu (např. DLL hell, bezpečnostní díry, složité a pracné instalace, nekompatibilita atd.) na webu nevzniknou. Někdy mi přijde, že ti lidé neznají historii (někteří to asi opravdu nezažili) a jsou tedy nuceni ji prožít znovu. Nebo možná někomu chybí ty zběsilé optimalizace, kdy bylo potřeba se vejít do malé RAMky, na disketu, vyjít s pár takty procesoru nebo přenášet data po pomalé lince… a tak si vytvářejí omezené prostředí, výkon osekávají nadbytečnými vrstvami a znovu dělají to, co se dělalo na nějakých osmibitech…

Tím, že vytvoříme nový svět uvnitř toho starého, situaci nezlepšíme. Jestli je něco špatně, tak je potřeba opravovat ten skutečný svět.

Jinak budeme narážet na to, že jedna část aplikace nebo dílčí framework vyžaduje určitou verzi jQuery a jiná část jinou, nebo nějakou nekompatibilní knihovnu… resp. už se tak dnes děje. Jestliže hodně aplikací uteklo od vlastních protokolů (TCP, UDP, SCTP…) na web a k HTTP, protože jim někdo firewalloval jejich porty, budou řešit úplně tu samou situaci znovu, protože i firewally jdou s dobou a nebudou koukat jen na číslo portu, ale budou strkat rypák i dovnitř HTTP protokolu a propouštět jen určité požadavky/odpovědi. Není to řešení, stojíme na místě a akorát se vyplýtvala spousta výpočetního výkonu a lidské práce.

[D.A.Tiger]

Asi jsem pochopil co jsi psal, ale nevím teď na koho byla ta kritika mířena. Na tvůrce LOVE a jejich webovou verzi v JavaScriptu, nebo na můj návrch spouštět normální lokální LOVE engine v rámci prohlížeče (podobně jako např. flashplayer)?

[xkucf03]

To byla spíš taková poznámka bokem, než kritika tvého příspěvku

Na jednu stranu je hezké, co všechno jde překompilovat do JS a co se dá provozovat v prohlížeči, na druhou stranu to ale nic moc neřeší.

[D.A.Tiger]

Jo souhlasím.

V tomto konkrétním případě (LOVE 2D Engine) to nepřináší stejně žádnou hodnotu navíc ani pro vývojáře - musí udržovat další jiný, ale stejně zaměřené projekt + další kopie resources. A nevidím v tom ani profit pro případné webmastery, či koncové uživatele. Špatné, špatné řešení. Ale je to COOL

[frEon]

kontrola na strane prohlizece je super....



dokud nepouziju curl

[Zopper]

Nebo Links nebo vypnutý JS... Jenže v tuhle chvíli vám nebude vadit, že se vám vygeneruje stránka "This value is requested", místo vykřičníku a zamknutého tlačítka "odeslat". Já vůbec nepouštím k vodě serverovou validaci, jen nebudu mít tu javascriptovou u klienta, protože to udělá prohlížeč.

[little.owl]

kontrola na strane prohlizece je super....

Tam jde o to, abyste nebyl schopen streamovany obsah ulozit, coz bez "trusted OS" ci "dedicated HW" nepujde, FOSS by asi mel smulu.

[koudy]

To prece nejde zarucit ani s trusted HW+OS.

Nekde na konci MUSI byt video rozkodovane - nerikam, ze to bude naprosto trivialni, ale z principu to musi jit.

[little.owl]

Zapominate na integrovane GPU a fakt ze HDMI stream muze byt az do monitoru zasifrovan.

[koudy]

No dobra, ale monitor si to pak musi rozkodovat a nejak prevest na blikajici obrazky.

[little.owl]

Jenze to uz monitory umeji.

[Jendа]

A na elektronové trysce je ten signál taky zašifrovaný?

[little.owl]

Neni. Ale kvalita je jinde a hlavne, ono se vam to bez komptibilni zarizeni odmitne vubec prehrat, na stare CRT zapomente.

[Mrkva]

Tak s/elektronová tryska/řadič TFT/ :)

[little.owl]

A videl jste nekdy integrovany TFT radic a to co z nej leze?

[VM]

To je celkem jedno, v nejhorším se to nahraje kamerou z obrazovky, což bude horší než originál, ale při dobrém vybavení a práci pořád použitelné. Chytit to kdekoliv dřív jsou plus body na kvalitu.

[little.owl]

Ano .... to je jedine jednoduche reseni .... pokud to neni 3D ...

[Zopper]

Jaký je problém dát před kameru filtr, který pustí jen jedno oko a natočit to nadvakrát (a nebo si udělat udělátko s polopropustným zrcadlem, co bude mít jeden objektiv, ale dvě kamery, jednu pro každé oko)?

Problém by byl s 3D, co nepotřebuje brýlé, ale to jsou spíš jen experimenty a ve chvíli, kdy se rozšíří, se určitě objeví možnost, jak to obejít. Hned z placu mě napadá udělat umělý ksicht co bude mít v místě očí objektivy (to pro případ, že by televize byla "chytrá" a hledala, kde uživatel sedí - i když jinak asi zobrazování udělat nepůjde).

[koudy]

Chaaa.. Presne TOHLE jsem mel na mysli http://hackaday.com/2009/10/01/tv-hack-bypasses-hdcp/

[xkucf03]

Pěkné

BTW: kolik práce dá tohle:

an unencrypted output that could then be received by a PC for later replay.

[Jendа]

BTW: kolik práce dá tohle:

Asi $100

[xkucf03]

[koudy]

Byla to jen otazka casu... Man-in-the-midle utok.. Neumim moc dobre nemecky, tak si to radej nechte kazdej prelozit google translate ;) http://www.heise.de/security/meldung/HDCP-Kopierschutz-ausgehebelt-1807866.html

Tady jeste En verze http://hackaday.com/2011/11/30/hdcp-falls-to-fpga-based-man-in-the-middle-attack/

[koudy]

Jako ze si budete v podstate ukladat kazdou obrazovku ze sbernice monitoru.

[smazáno]

V nejhorsim klidne i tak, staci, kdyz to udela jedna "release group" a hodi na torrenty.

[xkucf03]

Nejvtipnější na tom je, že jakkoli je tato operace pracná, stačí ji udělat jen jednou a pak už celý svět může sdílet tu nešifrovanou a DRM nepostiženou kopii

[Jendа]

Tady přece nejde o bezpečnost, ale o to, že uživatele chceš upozornit, že se spletl.

[xkucf03]

Kontroly na straně prohlížeče mají uživateli pomáhat a upozornit ho na chybu, než odešle data na server – je to užitečná věc, která zvyšuje pohodlí a snižuje nároky na zdroje (přenesená data, zátěž serveru). Na serveru musí být ty kontroly taky.

[Jendа]

Jenže jakmile se začneš možnostmi JS přibližovat k možnostem Javy, začneš mít úplně ty stejné bezpečnostní problémy. Už teď je v prohlížečích děr dost.

[Franta]

XHTML je dobře rozšiřitelné – libovolný obsah se dá vkládat pomocí <object/> nebo použít vlastní XML značky umístěné do vlastního jmenného prostoru – a přitom samotný značkovací jazyk a základní standard může být jednoduchý (ideálně sémantický). Souhlasím, že není potřeba všechnu funkcionalitu nacpat do základu.

[D.A.Tiger]

+100 Přesně tak to myslím...

[Zopper]

Jo, jenže XML se prostě neujalo. :(

[D.A.Tiger]

A proto vymysleli jako součást taky XHTML5?

[Franta]

HTML5 je se svými Data Attributes naprostý mrzák (někdo tak moc nesnášel XML, že místo aby použil jmenné prostory, si vymyslel atributy jejichž jméno začíná na "data-" a pak následuje libovolný řetězec – a takových zvráceností je tam víc)

[D.A.Tiger]

Takže vzato kolem a kolem W3C prasí co jde Mimochodem ty pitomosti co vytýkám HTML5 se nevyhnuly ani XHTML5. Což je katastrofa sama o sobě. Právě aplikace XML jko HTM měla zabránit zanášení HTML přidáváním nadbytečných funkcí a tagů. A oni tam prostě narvou konkrétní elementy, které navíc s původním HTML a jeho zaměřením nemají nic společného.

Jak jsem psal, tohle řešení je podle mě řádná pitomost.

[x]

Taky jmenne prostory v XML nejsou nic nez bastl co si zaslouzi okamzite zemrit ;) A to jsi jeste neslysel o tom, ze si lide budou moci deklarovat vlastni tagy, huaaa! ;)

[Franta]

Proč by měly být jmenné prostory v XML bastl? Umožňují globálně jedinečnou identifikaci a přitom se zapisují jednoduše – a v místě použití už píšeš jen prefix (jeden nebo pár znaků, zvolíš si sám) nebo si nastavíš výchozí jmenný prostor.

Na rozdíl od nějakého data-* je to dobré řešení.

[David Jaša]

modprobe irony ?

[danaketh]

Díky bohu za to.

[Jendа]

Můžete mi někdo vysvětlit, jak by to mělo fungovat? Já to prostě nechápu. Co zabrání uživateli si to prostě uložit?

[Jakub Lucký]

v lepším případě (pro nás) to bude nějaký blob, který bude dešifrovat zašifrovaný obsah a snažit se ho co nejkratší cestou procpat někam, odkud se bude blbě tahat (do paměti nebo do paměti GPU)

v horším případě to bude propojené s nějakým HW a vše půjde o blbě odchytitelných cestách (šifrované HDMI apod.)

[wtf]

Z hlediska kryptografie je DRM snaha o known plaintext/known ciphertext/known key/unknown plaintext šifrování. Kombinace zcela komická, která dlouhodobě fungovat nemůže. Krátkodobě může fungovat drastickým omezením uživatelského přístupu k hardware a software a tím, že se klíč propašuje do hardware buď potají na začátku přehrávání či při výrobě.

[little.owl]

Krátkodobě může fungovat drastickým omezením uživatelského přístupu k hardware a software a tím, že se klíč propašuje do hardware buď potají na začátku přehrávání či při výrobě.

Zacina to Secure Bootem ....

[Jendа]

Já chápu, že může existovat alespoň náznak fungování („krátkodobě“) u nějakého brutálně obfuskovaného rootkitnutého blobu - třeba než si nad to sedne reverzní inženýr a po měsíci to crackne. Když toho výrobce bude chrlit dost, třeba ho časem přejde nálada.

Ale naprosto nechápu, jak může fungovat „open DRM“ - tam přece ve specifikaci musí jasně napsat „tady je klíč a dešifruje se to takovým algoritmem“.

[Bystroushaak]

Ale naprosto nechápu, jak může fungovat „open DRM“ - tam přece ve specifikaci musí jasně napsat „tady je klíč a dešifruje se to takovým algoritmem“.

Hm. Secure multi-party computation (pěkně vysvětleno v phracku 68, sekce 2.4).

[Jendа]

Ale na konci přece stejně musím dostat spočítané framy, které zobrazím.

[Zopper]

Jenže ty framy se zase zašifrují a pošlou do monitoru, který si je teprve rozšifruje, aby je zobrazil, a bez podpory DRM přes HDMI se vám to odmítne přehrát. Už se to tu řešilo někde nahoře.

[Jendа]

…což vyžaduje tamperproofnost monitoru.