( Hunger | 2011. 06. 24., p – 18:29 )

Ó bakker, írtam, hogy nem akarok a továbbiakban ezzel foglalkozni, de annyi baromságot hordtál össze, hogy kénytelen vagyok rájuk válaszolni...




A hozzászólásaid egy részében olyan dolog ellen érvelsz, amit senki nem állított.

LOL? Ha nem tűnt volna fel, akkor beidéztem az eredeti mondatokat, amik ellen érveltem.

Mindenki tudja, hogy a webgl új kockázatokat hoz.

Hatalmas tévedés. A felhasználók jórésze nem tudja. A legtöbb azt se tudja mi az a WebGL, mégis alapértelmezetten bekapcsolásra került a böngészőjükben, veszélynek kitéve őket.

A chrome-os csak azt állítja, hogy az MS véleményével szemben nem a Silverlight a válasz mindenre

Te itt valamit nagyon félreolvastál, mert az MS sehol se írta, hogy a Silverlight a válasz mindenre.

Szóval ugyanezzel a lendülettel a JS eltávolítása is indokolt

Biztos, hogy elolvastad amiket írtam? Egyrészről hatalmas csúsztatás összemosni egy JS végtelen ciklus miatt belassuló böngészőt, egy teljes desktop merevre fagyást okozó video driver buggal... Másrészről külön kiemeltem, hogy a DoS itt a legkisebb probléma.

Igazából a Silverlight melletti kardoskodást nem értem

Te tényleg valamit nagyon félreolvastál. Itt nincs semmiféle Silverlight melletti kardoskodás. A Silverlight csupán egy példa, hogy meglehet ezt jobban és biztonságosabban is csinálni. Senki sem javasolta a Silverlightot a WebGL helyett.

Szóval DirectX egy wrapper a driver körül

Hát ennél a DirectX egy picivel több. :)

Szerintem a DirectX sem arra készült, semmi garancia arra, hogy extra biztonságot ad, nem pedig csak a látszatát

Tekintve, hogy a DirectX több komponensét is használják már sok éve (Direct2D, DirectInput, DirectSound, DirectX Video Acceleration, stb.) a webes kiegészítők (mint pl. az Adobe Flash, vagy az Adobe Shockwave) és még sose használtak ki rajta keresztül video driver hibát, ezért mindegy, hogy szerinted a DirectX sem arra készült... Amit fel kellene fogni, hogy a DirectX egy külön absztrakciós réteg, míg a WebGL az magának a video drivernek az OpenGL interfacével beszélget, ami viszont mindig is katasztrófális volt biztonság szempontjából. Konkrétan annál valóban sose volt szempont a biztonsága.

Nem is véletlen, hogy a Google is nézelődik inkább abba az irányba, hogy Windowson legalább a DirectX-en keresztül hívja meg az OpenGL ES2.0 API-kat.

A Chrome nyilván nem tud mindent validálni, ahogy a Silverlight sem

Tehát mégegyszer: a Silverlight ellenben nem a video driver OpenGL interfacével beszélget direktben.

Hm, épp az előbb írtad valakinek, hogy a webgl-t a firefox nightly build-ekben kézzel kell bekapcsolni.

Igen, a nightly buildekben, ott is csak kb. 1 hete. A stabil változatokban továbbra is alapértelmezetten be van kapcsolva. Nyilván a Mozillánál is rájöttek időközben, hogy elég veszélyes ez így és most a fejlesztői ágban már nincs alapból bekapcsolva. Remélhetőleg a következő nagyobb verzióváltásnál már a userek jórésze által használt stabil változatban is a kikapcsolt lesz a default.

Ez amúgy sem jó érv, nyilván a 99%-os penetrációra hajt a Silverlight is.

És? Hol az összefüggés? A Silverlight nem része egyik böngészőnek sem alapértelemezetten, külön kell telepítenie a felhasználónak. Anélkül nem veszélyeztetheti a usert, ellenben a WebGL-el, amely szépen le lett nyomva userek torkán, a tudtuk nélkül.

Ez épp olyan, mint amikor azt állítja valaki, hogy a Linux biztonságos, mert senki nem használja, ezért nincs rá vírus sem.

Ugyan itt se látom az összefüggést, de amit leírtál így van. 1% desktop Linuxra nem éri meg botnetet építeni.

Gondolom te sem tartozol abba a táborba.

Ez nem tábor kérdése, hanem az objektív gondolkodásé.

A DirectX épp úgy a gyártók drivereitől függ, mint az OpenGL.

Csak az előbbit jópár nagyságrenddel többen használják. OpenGL annyira halott, hogy jópár driver nem is tartalmazza. Ez a másik indok, amiért a Google is a DirectX-en keresztül használná inkább a WebGL-t.

Ha a driver bugos, itt is, ott is a gyártónak kell javítania.

Persze, csak egy rakás hiba van, amely DirectX-en keresztül nem triggerelhető, OpenGL interfacen keresztül meg igen. Ráadásul a DirectX-en keresztül sokkal inkább tesztelik, mert jobbára mindenki azt használja már több mint 10 éve.

Ha a gyártó nem javítja, akkor a workaround lehetséges itt is, ott is.

A DirectX ad egy stabil, független layert amit használnak, ami adott esetben jópár video driver problémát eltakar. Ez biztonsági szempontból jó, ha DirectX-en keresztül érhetők csak el a funkciók, viszont ha a DirectX-et megkerülik - mint WebGL esetében -, akkor egy mozdulattal borul az egész kártyapakli. Azért is írtam, hogy eddig is probléma volt, mert lokálisan kihasználhatók voltak eddig is a video driverek hibái, viszont így egy mozdulattal távolról is kihasználhatóvá tették...

Úgy írsz néha a DirectX-ről, mintha az nem lenne kiszolgáltva hardware drivereknek

Tehát mégegyszer: az a driver ami DirectX-en keresztül kapásból észrevehető problémákat okoz előbb kibukik, hisz minden QA erre van ráállva. Mindenki DirectX-en keresztül tesztel, benchmarkol Windows platformon manapság már.

Arról nem is beszélve, hogy az Xbox-nál is.

a webgl-ről pedig úgy, mintha nem lenne lehetséges minden utasítás szűrése.

Lehetni lehetséges, a probléma pont abban volt, hogy ez még elég kezdetleges, ha egyáltalán van...
Firefox fejlesztői ágba most került be nem rég egyáltalán egy alap shader validator, eddig nem is létezett.

Az, hogy jelenleg nem szűr eléggé a Chrome, a Chrome hibája, nem a webgl-é

Ez már megint a specifikáció vs. implementáció kérdéskör, amin turul16 is rugózott. Olvasd el ott erre mit írtam, nem akarom újra leírni.

Más kérdés, hogy jelenleg tudtommal nincsenek tipikus webgl támadások

Persze, gondolom még most ocsudnak fel az IT seces emberek a csodálkozásból és köpni-nyelni nem tudnak.

így egyelőre nincs tapasztalat arról, hogy mit is kell kiszűrni

Jah, de azért ki lett rakva pármillió ember veszélynek, a default WebGL-el.

Egyébként ezt is írtam turul16-nak. Előbb fel kellett volna tárni a WebGL miatt megjelenő új veszélyforrásokat, meg kellett volna érteni a feltártakat és a specifikációban rögzíteni az elkerülésükhöz szükséges alapokat. Nem pedig utólag fejet vakarni és implementálgatni ilyen-olyan szűrőket, hogy azok majd talán megoldják a problémát. Agyrém.

de nem lehet mondani, hogy nem próbálkoznak.

Jah, eső után köpönyeg.

Emlékszem még, amikor napokig vagy hetekig kellett kritikus flash sebezhetőséggel kellett szántani a webet

Apple vs. Oranges. A flash úgy szar ahogy van, de legalább nem egylépésben lehetett rajta keresztül támadni a kernelt, mint jelenleg a WebGL-nél.