Hlavní navigace

Vlákno názorů ke zprávičce EFF podala námitku vůči zahrnutí DRM do HTML5 od r23 - Pokud by bylo DRM postaveno tak, že bude...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 2. 6. 2013 20:09

    r23 (neregistrovaný)

    Pokud by bylo DRM postaveno tak, že bude jasně definované, aby bylo možné to implementovat kamkoliv, včetně, otevřeného sw, tak by to snad mohlo být jedině přínosem, pro všechny. Časem by to poslalo do háje většinu z nekompatibilních a obskurních technologií.
    Nevidím důvod, proč by nešlo mít otevřenou implementaci, kterou pak někdo jen podepíše, aby byla zaručena integrita a chování dle specifikace.

  • 2. 6. 2013 20:18

    Jenda (neregistrovaný)

    Protože DRM je založené na security-by-obscurity. Jakmila máš OSS implementaci, stačí přidat na správné místo fopen() a fwrite() a máš chráněný obsah uložený.

  • 2. 6. 2013 20:52

    r23 (neregistrovaný)

    Nesouhlasím. Implementace může být otevřená, jen pak zkompilovaný kód někdo podepíše pro použití, a tím zaručí, že tam přesně toto není.
    Třeba podobně, jako to děla sdružení kolem ReactOS s OS implementací windows driverů...

  • 2. 6. 2013 21:24

    r23 (neregistrovaný)

    Poskytovatel obsahu ? Ten už si může rozhodnout kdo je a není důvěryhodný.

  • 2. 6. 2013 21:49

    Radim Luža (neregistrovaný)

    Jenze... jak chcete kontrolovat ten podpis? Pokud bude mit uzivatel na disku binarky a server se zepta, zda je prava nebo ne, muze uzivatel resp. uzivatreluv SW lhat. Server treba muze vyzadat, aby mu uzivatel tu binarku poslal, server provede overeni podpisu a tim zjisti, jestli uzivatel ma spravnou binarku - ale uz nemuze zarucit, ze ji uzivatel k prehrati pouzije. Rozdil mezi driverem a touto situaci je v tom, ze u driveru jste vy ten, kdo overuje - vy si desifrujete data verejnym klicem poskytovatele a tim se overi, ze jsou data v poradku. Ale pokud chce poskytovatel overit, ze to, co mate, je v poradku, tak mu tento pristup nepomuze. Na strane klienta by muselo byt neco, co pro poskytovatele budto binarku overi, nebo alespon zajisti, ze uzivatel pouzije prave to, co poskytovateli poslal k overeni. A v tom je prave kamen urazu DRM - nic takoveho z principu zarucit nelze.

    Mozna mi neco unika, ale momentale me opravdu nenapada, jak by se to dalo udelat.

  • 2. 6. 2013 22:05

    r23 (neregistrovaný)

    Ono by to nebylo jistě zcela triviální, ale jsem přesvědčen, že možnosti jsou. Spíš jde o to, že se mi zdá, že nikdo ani na jedné straně nechce takové řešení hledat a sedí si na svém fanatickém pohledu.

  • 2. 6. 2013 22:16

    Radim Luža (neregistrovaný)

    Inu, ja se vazne obavam, ze takove reseni proste neexistuje. Nejde o to, ze bude tezke DRM naprogramovat a obfuskovat a jinak zneprijemnit crackovani, ale jde mi o princip - jak to v principu udelat, aby to principialne fungovalo. Napriklad tak, jak asymetricka kryptografie: take existuji ruzne utoky na ruzne sifry, ale princip je neprolomitelny - jedna se o chyby v implementaci, nebo matematicke chyby v konkretnich sifrach. U DRM jsem nejaky obecny princip nepotkal.

    Mozna by slo uzivateli v ramci sezeni posilat jen pro nej kompilovanou binarku s konkretnim klicem s tim, ze by jeji platnost byla casove omezena a tim by se nemuselo dat se soucasnym HW crackovani stihnout. Ale to by asi dost zatezovalo poskytovatele obsahu. A taky... ten, kdo do toho pujde, muze mit nejaky nekonvencni hardware.

    Dalsi problem DRM je ale take to, ze nestaci mit overenou binarku - musite mit overeny OS - jadro, knihovny, nahrane ovladace a moduly. Takze treba s Linuxem si vlastni jadro s podporou vaseho zanovniho HW a DRM neudelate. A zase je tu motivace piratit... :-)

  • 3. 6. 2013 0:17

    Jenda (neregistrovaný)

    „Mozna by slo uzivateli v ramci sezeni posilat jen pro nej kompilovanou binarku s konkretnim klicem s tim, ze by jeji platnost byla casove omezena a tim by se nemuselo dat se soucasnym HW crackovani stihnout.“

    A kde je ta otevřenost?

  • 3. 6. 2013 1:11

    Lael Ophir (neregistrovaný)

    DRM je v principu neslučitelné s principy open source. Pokud má někdo volný přístup ke kódu který dešifruje obsah, může s tím obsahem udělat cokoliv. Podobně pokud má někdo volný přístup k výstupu toho dekódování, může s ním udělat cokoliv. Ve Windows se to řeší digitálními podpisy celého řetězce - kernelu, dekodéru i driverů. Samozřejmě se dá ještě nahrávat výstup na HW úrovni, ale to je relativně komplikované.

  • 3. 6. 2013 11:13

    Radim Luza (neregistrovaný)

    Ano, presne tak se to musi delat. A tohle prave vylucuje jakekoliv uzivatelske zmeny v OS jako celku. Muzete proste pouzivat to, co vam certifikovany vyrobce doda - nic vic. Pokud si treba udelate driver pro vlastni video dekoder, ktery jste si syntetizoval na hradlovem poli a pripojil k pocitaci, tak to s DRM nejde - nemate ho jak podepsat. A samozrejme - v opensource svete to znamena konec vlastnich optimalizovanych kernelu, vlastnich modifikaci ovladacu (treba obrazeni bufferu v driveru USB kamery, aby se neprevracel obraz) a podobne. DRM zkratka neni aplikace, ktera se naprogramuje a funguje.

    Jinak utoky na HW taky nejsou az tak neproveditelne - naopak nektere implementace DRM byly prolomeny prave utokem na hardware (mam pocit, ze DVD i BlueRay) a jeho firmware, ktery je na tom co do kvality zabezbeceni obvykle hur, nez soucasne desktopove operacni systemy. To take ukazuje dalsi zalezitost: udelat robustni implementaci DRM do firmware levnych koncovych prehravacich zarizeni neni uplne trivialni zalezitost.

  • 3. 6. 2013 18:28

    Lael Ophir (neregistrovaný)

    Můžete toho používat daleko víc, než co vám dodá výrobce. Dál můžete běžet jakékoliv user-mode aplikace, a dokonce i drivery (ty jen nejdou použít k přehrávání obsahu chráněného DRM).

    Optimalizace kernelu překladem doma je dost nesmyslná. Daleko lepší je profilingem zjistit časově kritické části kódu, a ty pak napsat ve více verzích pro různé verze CPU (například s použitím různých SIMD instrukčních sad, změnou velikosti bufferů apod). Kód se pak přepne za běhu podle typu CPU, například zavedením správné knihovny, nalinkováním správné verze funkce, nebo prostě použijete jiný pointer na funkci. Takhle se ve Windows řeší například multimédia, interface pro syscall (int 2e vs sysenter) apod. Samozřejmě to chce trochu práce, ale získáte velmi dobrý výkon i bez překladu na konkrétním stroji.

  • 7. 6. 2013 14:01

    Radim Luža (neregistrovaný)

    Mno, takhle to jde, ale přináší to overhead. A navíc takto můžete podporovat jen malé množství konkrétních procesorů. Tohle si lze rozumně dovolit snad jen u x86 architektury, kde je Intel, AMD a VIA (kde každý z těchto výrobců má jednotky až desítky modelů CPU) a pak nějaké generic řešení. Ale stačí se podívat na ARM a je jasné, že tohle není v lidských silách. De-facto každé SoC s ARMem je originál - CPU vyrábí spousta výrobců a každý jinak - někdo použije NEON, jiný nějaké své FPU, u Tegry lze použít vestavěnou grafiku na nějaké akcelerace výpočtů a některý ARMy třeba nemají FPU vůbec a je nutné FP výpočty emulovat - ale téměř každé zařízení s ARMem je specifikcé. A to tu máme MIPS, IBM Cell, a různé procesory od Atmelu, Motoroly... kde je situace podobná. A do toho všeho tu máme různé typy zátěže systému. Někdo chce nízkolatenční stanici, která rychle obsluhuje PCI periferie (zvukaři např.), jiný chce rozumné krátké odezvy GUI a rozumný výkon, další chce maximální propustnost síťování a další chce obsloužit co nejvíce požadavků z jednotku času bez ohledu na latence. Bez kompilace kernelu i userspace na míru je to opravdu těžko řešitelné. Jasně, můžeme tam dát něco obecného pro danou kategorii zařízení nebo nějakou třídu zátěže a říct, že je to dobré, ale ti, co vyladí systém na míru budou mít v drtivé většině případů lepší výsledky.

  • 8. 6. 2013 2:03

    Lael Ophir (neregistrovaný)

    Proč by mělo natažení jiné knihovny, binding nebo použití jiného pointeru na funkci přinášet overhead?

    Optimalizace je zcela jistě v lidských silách, ale stojí to nějakou práci navíc. Naopak není v silách kompilátoru to udělat za autora aplikace. Pokud ručně napíšete třeba dekódování zvukového formátu bez použití FP, protože je to řekněme rychlejší než emulace, kompilátor to za vás nevyřeší. Podobně za vás nezvolí velikosti bufferů v závislosti na velikosti cache apod.

    Scheduler se dá přece řešit stejně jako optimalizace multimédií - pokud si požadavky odporují, prostě tam dáte nějaké konfigurační parametry. Pokud byste chtěl dosáhnout lepšího výsledku, opět nepomůže samotná rekompilace na typ procesoru. Musel byste mít větve kódu pro daný scénář. A když už je máte, tak není moc důvodů je aktivovat jen kompilací.

  • 13. 6. 2013 17:39

    Radim Luza (neregistrovaný)

    Proč by mělo natažení jiné knihovny, binding nebo použití jiného pointeru na funkci přinášet overhead?

    Protoze to muze byt zkompilovane staticky - bez dynamickych knihoven a tedy bez neprimych skoku. A zrovna v pripade jadra systemu u veci, ktere jsou silne exponovane, je rezie primeho vs. neprimeho skoku nezanedbatelna. Nehlede na to, jaky pruvan muze neprimy skok napachat v pameti pri dvojitem vypadku stranky:-)

    Jinak asi jsem se vyjadril nejednoznacne - netvrdim, ze kompilator nahradi inteligenci cloveka. Predpokladejme ale, ze mame kod obsahujici ruzne cesty provadeni pro ruzny HW - tedy clovek uz kod zoptimalizoval. Ty jednotlive cesty muzeme vybirat za chodu - pomoci podminenych skoku, muzeme z nich vytvorit dynamicke knihovny, kde se pro kazdy HW bude vybirat prave jedna konkretni - tu je ale problem s velkym mnozstvim knihoven u rozmaniteho HW a navic rezie dynamickych knihoven, nebo muzeme pomoci ifdefu proste zkompilovat kod pro dany HW - zadne dynamicke linkovani, minimum neprimych skoku a vubec rezie souvisejici s dynamickymi knihovnami. Ten treti zpusob ma dle meho nazoru potencial byt nejrychlejsi. Tedy - ja osobne duvodu k aktivaci vetvi kodu kompilaci vidim.

    V neposledni rade se take muze stat, ze optimalizace, kterou nekdo vymyslel za vas, neni idealni. Zjistite, ze by se pro vas typ uziti dalo najit lepsi reseni. Pokud kompiluji ze zdrojaku, mohu kod urpavit a zmenu provest. U nezmenitelnych binarek s tim nic nenadelam.

    Zkratka - nemyslim si, ze je to tak jednoduche.

  • 3. 6. 2013 11:25

    Pavel (neregistrovaný)

    Řešení existuje. https://en.wikipedia.org/wiki/Trusted_Computing

    Soudruzi maj i nějaký důkazy (ikdyž postavený na trhlých předpokladech:-). "Bohužel" tahle implementace je prolezlá vším od HW přes OS až do vzdáleného ověřování klíčů. Ale když už někdo tohle všechno naimplementuje a zajistí si majoritu na trhu, bude možné zajistit i velkou složitost přehrávání kopií.

    Osobní počítače pak budou úplně v moci "'Trusted' Third Party", ne uživatelů. Skoro jistě k tomu nikdy nedojde, protože restrikce jsou až moc vysoké.

  • 3. 6. 2013 11:58

    Radim Luza (neregistrovaný)

    Ano, to je implementace, ktera to castecne resi, ale je to spousta prace a mnoho omezeni - a stejne to by design jde obejit. Ono... muzeme mit sifrovany cely retezec zarizeni v pocitaci, ale minimalne draty vedouci z radice LCD k matici pixelu sifrovat nejde - a tam to lze vzdycky napichnout a ziskat tim alespon RIP v rozliseni displeje. To neni idealni, ale taky to neni spatne. Zvlast v pripade displeju s vysokym rozlisenim.

  • 3. 6. 2013 12:18

    Pavel (neregistrovaný)

    Samozřejmě. http://en.wikipedia.org/wiki/Analog_hole
    Nevím proč vůbec firmy a jejich sdružení vynakládaj tolik námahy a prostředků na předem prohranou válku.

  • 3. 6. 2013 14:06

    Karel (neregistrovaný)

    Protože jim někdo jimi placený říká, že to má smysl. Nejlepší jsou pak příklady. Skoro vždy se jedná o usvědčení "kopírovače" a jeho odsouzení. Nijak jsem v žádném takovém případě ale nezaznamenal, jak se na tom odhalení/odsouzení podílelo DRM.

  • 4. 6. 2013 0:16

    Lael Ophir (neregistrovaný)

    Je v tom ale přece jen rozdíl. V jednom případě si každý laik může stáhnout za pár minut aplikaci, a obsah hodinového filmu za 10 minut vytáhnout v nechráněné formě. V druhém případě potřebujete rozebrat monitor, vyvést signál, zpracovat ho, digitálně ho nahrát, provést rekompresi, film musíte pustit celý, a výsledek stejně nejspíš nebude mít kvalitu originálu. Ten druhý scénář zvládne jen pár lidí, a ty pak při troše štěstí pochytáte a posadíte za mříže.

  • 4. 6. 2013 8:40

    Seti (neregistrovaný)

    "Ten druhý scénář zvládne jen pár lidí, a ty pak při troše štěstí pochytáte a posadíte za mříže."

    Don Quijote de la Mancha :-D "pár lidí", to mi připomíná kydy tupounů, že ty linuxy "nikdo" nechce.

  • 3. 6. 2013 15:44

    j (neregistrovaný)

    Ne, takove reseni proste neexistuje - absolutne zadne. Dokud bude uzivatel spravcem svyho blackboxu, tak protistrane proste nevi a vedet nemuze jaky SW pouziva, nebo jak jej ma/nema modifikovany. To plati samo i pro uzavrene systemy jako jsou widle, ale 1000x vic pro otevrene, jako je tux. Kdyz si napisu jaderny modul, ktery mi bude ukladat na disk vse, co jde trebas na zvukovku, tak to absolutne zadna aplikace nezjisti. Nema totiz jak.

    Dtto jakykoli plugin do prohlizece. I kdyz nebude opensource, tak tu driv nebo pozdejs bude jeho emulace. A kdyz bude... je otazka nekolika hodin ho upravit tak, aby delal co chce uzivatel a ne co chtel tvurce.

  • 3. 6. 2013 20:37

    Seti (neregistrovaný)

    Souhlas. I s ostatními tady, co DRM odsuzují jako nesmysl.

    Oni si ti distributoři opravdu nezaslouží nic jiného, než zkrachovat. Oni neumí své zboží nabídnout tak, aby měli zákazníci zájem. Místo toho dělají potenciálního "piráta" z každého, i z poctivě platících zákazníků, těm ještě navíc za to, že zaplatili kolikrát "lidovou" cenu, znepříjemňují nebo dokonce úplně znemožní zaplacenou věc použít, a pak ještě navíc brečí, že jsou "okrádáni". O dalších jejich dalších špinavých praktikách se tu rozepisovat nebudu. To si mám od nich něco kupovat za takových podmínek? Nejsem padlý na hlavu :-)