> Pokud člověk, který se nezabývá bezpečností, tvrdí něco o bezpečnosti, nemá to žádnou vypovídající hodnotu
Tím myslíš koho? Sebe? Nemůžu než souhlasit.
> pro sha256/384 je teoreticky možné najít kolize pro jquery, překážkou je pouze cena/čas.
To je ale dobrá překážka. Bavíme se tu totiž o hodně velkých násobcích stáří vesmíru. Celá kryptografie na tomto stojí a padá.
ne, čtu mailing w3c skupiny a cross-site hashing byl zavrhnut, místo toho se doporučuje CORD a vzniká akorát resource Integrity hashing. Ti lidi předpokládám, že tomu rozumí a ví proč od toho prozatím upustili.
Celá kriptografie stojí na tom, že se vymění algoritmy dříve než jí technologie dožene.
Já zase čtu Čtyřlístek, co má jako být?
Nevím, co je CORD, možná myslíš CORS, ale připojení otisku k nalinkovanému zdroji už svůj Working Draft má taky: Subresource Integrity (SRI), dokonce s možností použít libovolný (nebo vícenásobný) druh otisku.
> Celá kriptografie stojí na tom, že se vymění algoritmy dříve než jí technologie dožene
SHA-256 se běžně používá v TLS, DNSSEC, DKIM, PGP … you name it.
Pokud obsahuje kritickou chybu, nějaké linkování javascriptů bude poslední starost, kterou budou administrátoři řešit.
Ty opravdu čekáš, že si někdo nechá diktovat, jaké má mít na webu UX? Web je otevřený, to je důvod jeho úspěchu.
Keš podle hashe není žádné bezpečnostní riziko. Jako autor říkám „hele, tento můj /jquery.js má hash XYZ123, možná už ho máš někde v paměti odjinud.“
HTTP/2 je nasaditelné okamžitě kdekoliv, kde o to provozovatel stojí. Podpora koncových stanic je už teď solidní a bude brzo vynikající.
já si říkal odkud ty bláboli máš a ono to je z čtyřlístku :-D.
Ano, myslel jsem CORS, který se postupně na velkých webech nasazuje a brání použití neautorizovaných zdrojů. SRI řeší ale pouze integridu a zatím nevypadá, že myšlenka podle toho hashovat se vůbec prosadí.
Bezpečnost v reálném čase a najítí po několika týdnech počítání konfliktního hashe k jedné knihovně je naprosto něco jiného.
Představ si, že máš volných 100k USD, najdeš konfliktní hash k používané knihovně, donutíš lidi, aby tvojí stránku navštívili a máš persistentní kód v prohlížeči, který se volá na velkém množství stránek. Zatím k tomuhle není vůle a obecná shoda a tohle je prozatím argument, proč se na tom nepracuje.
Řada firemních politik a doporučení právě tomuhle brání, užitek by nebyl tak moc velký, viz diskuze, které se o tomhle vedou.
Další zbytečný mikroformát. Přitom by stačilo vyřešit dvě věci: kešování souborů na základě obsahu nikoliv adresy a lepší kontrola priorit načítání zdrojů.
První věc by se dala řešit připojením informace o kontrolním součtu odkazovaného zdroje a druhou do jisté míry řeší HTTP/2
Nejedná se o mikroformát, cachování a priorita zdrojů není jediná věc, kterou to řeší. Současné mobilní weby nemají dobré UX a tohle je jedna z odpovědí, nelíbí, ignoruj, nepoužívej.
a jak to chceš řešit? Párování souboru podle hashu je bezpečnnostní riziko a prozatím bych to nedoporučil. Jinak zatím je spec pouze v draftu http://www.w3.org/TR/SRI/ a o možnosti právě cachování podle hashe se vede diskuze.
HTTP/2 ale není v současné době plošně nasaditelné a ještě to nějaký ten rok potrvá. Nebude to ale řešit případ, kdy chci načíst obrázky podle rozlišení nebo je nenačítat, když nejsou vidět.
UX je míra příjemnosti, snadnosti, efektivnosti, orientace na stránce, nejedná se o grafiku a ani nic konkrétního, je to pouze míra, kterou mohu konkretizovat jen uživatelskými testy. Design mám pod kontrolou.
Pokud člověk, který se nezabývá bezpečností, tvrdí něco o bezpečnosti, nemá to žádnou vypovídající hodnotu. Kolize hashů je problém, i pro sha256/384 je teoreticky možné najít kolize pro jquery, překážkou je pouze cena/čas.
HTTP/2 není stabilní a nasaditelné. Neexistují HW balancery, soft jsou v beta verzích, neexistuje dobrá podpora v frameworcích pro webové aplikace, vývojáři neznají možnosti a struktura aplikací neodpovídá možnostem a principem fungování http (preloading a sdílení spojení zejména).