Új hozzászólás Aktív témák
-
Samus
addikt
Ne támogassák. Megint csináljanak egy saját keretrendszert, és használják azt, hogy ha esetleg egy évben egyszer olyan helyre keverednék egy videó miatt, ne tudjam megnézni, mert Silverlight kell hozzá (ami egyébként azóta fent van, az Update felpakolta...). Véletlenül se legyen semmi egységes. Minek, nemsokára úgyis világvége lesz...
-
ddekany
veterán
Ha jól tudom WebGL esetéln OpenGL-szintű utasításokat adsz ki. Azt gondolnám az valóban nagyobb támadási felületet ad, mint mondjuk egy scene-alapú 3D-s API (ahol tehát van +1 absztrakciós réteg). A fennmaradó kérdés, hogy vajon az MS-féle alternatíva (mert gondolom véééletlenül lesz majd ilyen), egész pontosan milyen API-t fog alkalmazni. Vagy szerintük nem lesz weben normális teljesítményű 3D soha, mert az veszélyes?
Vagy... esetleg előbb a grafikus megjelenítésnek (driver-model, stb) kéne fejlődnie, hogy mehessen ez is rendesen sandbox-ban... De ilyesmikről (konstruktív dolgok) itt nem beszéltek. -
DraXoN
addikt
Az a baj ha a grafikuskártyához való közvetlen hozzáférést kivennék a teljesítmény a töredékére esne.. így viszont nem lehetne az egész egy platformfüggetlen alkalmazásfejlesztéshez megfelelő felület.. legalábbis grafikailag teljesítményigényes alkalmazások (főképp itt a játékokra érdemes gondolni) sokkal kevesebb erőforráshoz férhetnének hozzá.. vagyis a teljesítmény jelentős része kárba veszne a plusz rétegtől.
Egyértelmű, hogy ez utóbbi a microsoftnak csak jó lenne, mert így az ő platformjukról továbbra is nehezebb lenne a kitörés.. így viszont ha webgl-es játékok jelennének meg az mehetne bármilyen platformon ahol a követelmények adottak (pl. megfelelő méretű kijelző és teljesítmény).
-
-
lapa
veterán
és ami a hírből kimaradt:
-mivel a nyilván malicsúz kódokat főleg linuxos webszerverekről töltik a gépre, kezdeményezik még a linux betiltását is.
-és oroszország sem túl szimpi, azt is betiltják.
-hát a flasht meg főleg, különbenis hogy képzeli a flash.
ezeket a következő havi malicsúz removal tool mind leszedi majd a gépekről*.
* = oké, oroszokat csak a bingo mapszből fogják kiradírozni.
-
#56
Namelesske
addikt
Namelesske
addikt
Most lehet hülyeséget mondok, de Vista óta nem futnak kernel szinten a videó driverek.
-
P.H.
senior tag
Teljesen jó, hogy a Microsoft-nál "felfedezték" azt, hogy a GPU-k egyelőre nem képesek sem hardveres multitaskingra, ezáltal "védett módra" sem. Ezt akárki, aki nem csak játékra használt GPU-t eddig, már régóta tudja és várja a megoldást.
Simán "lefagyaszt" egy akármilyen GPGPU-s program egy gépet, ha ugyanarra az alkatrészre bízunk számítást, ami a megjelenítésért is felelős (persze az OS él alatta, csak egy-egy kattintásra vagy billentyűleütésre adott 5-6 perces válaszidők nem szokatlanok, GDI-alapú rendszerban legalábbis).
Az meg, hogy a GPU-kban nincs kidolgozva semmilyen hardveres védelem az egymás mellett/egymás után futtatott task-okra, nem hiszem, hogy újdonság a Microsoft számára; kb. win3.1 szintű (cooperative multitasking) együttműködést lehet megvalósítani GPU-n jelenleg. Persze amíg ez játékokról szól, addig ezzel semmi baj nincs, de amikor a web kerül képbe, akkor nem mindegy, milyen adatok jutnak el a GPU-hoz (mondjuk az összesGPU-t használó programot egy közös driver-címtérben futó kód kezeli?).Nyilván ez fejlődni fog hamarosan hardveresen (pl. virtuális címtér az alkalmazásoknak CUDA vagy OpenCL alatt), addig meg ez van, ez nem WebGL-sajátosság. Csak mondjuk a WebGL megelőzi a korát, ilyesmi lopható adatokat nem szerencsés bízni nem védett hardverre.
-
Ez volt már?
"The Future of Microsoft Silverlight: [...] Immediate mode graphics API allows direct rendering to the GPU." -
" Jön a hiba. Ügyfél bejelenti a Microsoft-nak. Microsoft kideríti, hogy eszkalálni kell a bejelentést 3PP-nek. 3PP szüttyög rajta az SLA szerinti időt maximálisan kihasználva. Workaround nincs, a javítás a következő driver verzióban. Ja, de a code-freeze-t lekéstük, már csak a következő havi kiadásba mehet a patch."
Ez nem tűnik egy nagyon hihető szituációnak:
1. Az ilyen nem az ügyfelek szokták jelenteni.
2. A hibajelentések nagyon specifikusak szoktak lenne, nem a MS-nek kell kitalálnia, hogy itt most a videodrivert támadták meg.
3. Erősen kétlem, hogy az ATI/NVidia meg a MS között bármi SLA lenne.
4. A videodriverek patcheit nem a MS adja ki. -
Sofian
őstag
Nálam is gond nélkül fut, de a cpu/gpu terhelése egy komplex játékéval vetekszik....
Nem vagyok ellensége a dolognak, csak optimalizálják megfelelően...
Nomeg félelmeim között szerepel, hogy a mindent tudó webfejlesztők flash-ről átvándorló csapata, milyen böszme dolgokat próbál majd összerakni....
-
floatr
veterán
Node végre itt vagy és mondhatod a frankót
Gondolom ez a havi iteráció a gyártócégek alapító okiratába van foglalva, hogy ettől már ebben az életben nem tudnának eltérni. Most is ugyanúgy van nekik bugtrekkerük, csak senki nem kényszeríti őket se pozitív se negatív értelemben a gyakoribb release-re.
Az meg hogy a script mire képes... sosem fogjuk megtudni, amíg rá nem fekszenek próbálkozó kedvű jómunkások. Egyelőre az a nagy probléma ezzel, hogy a js-hez értők és a játékfejleszteni tudók halmaza közt nem elég nagy a metszet. A múltkor teszteltünk 2d-s trafót, és a v8/crankshaft hozta a c++/c# sebességét, tehát olyan nagy teljesítményzavar nem kéne hogy legyen, de még ha egy-két nagyságrendi különbség is lenne, akkor sem a flash szintjére süllyedne a dolog, inkább 5-8 évvel ezelőtti játékok/alkalmazások szintjét hozná.
(#41) Sofian ez is változhat, bár nekem egy fosos 7600gt-n probléma nélkül fut. A böngészők néha használnak driver blacklist-et most is (ami akkora fejtörést okoz most a ms-nak), könnyen elképzelhető, hogy nálad ez a gond.
-
julius666
addikt
Ok, akkor a WebGL veszélyforrás az inkompetens videókártya-gyártók miatt. Nézzük meg milyen alternatív megoldások vannak helyette a böngészőkbe, amik jelenleg is használatban vannak, az MS által támogatottan:
- flash
- egyéb beépülő plugin ami lényegében rendes különálló alkalmazás csak böngészőből indítható.Muhahahaha.
Mégis mi a jó életről beszélünk? Ezeknél a megoldásoknál még csak le se kell piszkálni a grafikus kártyáig ha valaki disznólkodni akar. Tökéletesen igaza van floatr-nak, természetesen mindannyian tudtuk előre, hogy ez lesz a dolog vége (egyszerűen ellenérdekelt az MS a WebGL elterjedésében, hülye is lenne ha máshogy tenne), de azért ennél valami értelmesebbet is kitalálhattak volna (vagy egyszerűen tarthatták volna a pofájukat és sunyin lapíthattak volna), mert ez így nem kicsit nevetséges.
-
Sofian
őstag
Nekem inkább az a bajom, hogy performancia tekintetében borzalmas a WebGL pillanatnyilag...
példa: http://www.ro.me
Egyszerű primitív modelleket használ és így is gyilkolja a gépet....
-
airwin
csendes tag
válasz
Cathfaern
#29
üzenetére
"nyilván nem fűlik a foga egy olyan szabvány támogatásához, amivel "bármilyen" oprendszeren lehetne 3D-s játékokkal játszani (normális grafika és sebesség mellett)."
Szerintem te félreértesz valamit. A WebGL kizárólag a megjelenítésért felelős. A játék kódját pedig mibe képzeled, javascriptben?
Ugyanilyen megoldás már eddig is létezett, úgy hívják hogy Adobe Flash. A WebGL legfeljebb annak jelent konkurenciát. Vagy annak sem, amíg nincs teljes képernyős megjelenítésre kapcsolás HTML-ből... -
airwin
csendes tag
Ennyi okos hozzászólás...
A legfőbb probléma az, hogy a grafikus meghajtót író cégek nincsenek felkészülve arra, hogy 0-day exploitokat javítsanak a szoftverükban.
Mert ugye... Jön a hiba. Ügyfél bejelenti a Microsoft-nak. Microsoft kideríti, hogy eszkalálni kell a bejelentést 3PP-nek. 3PP szüttyög rajta az SLA szerinti időt maximálisan kihasználva. Workaround nincs, a javítás a következő driver verzióban. Ja, de a code-freeze-t lekéstük, már csak a következő havi kiadásba mehet a patch.
Király.
-
#37
WonderCSabo
félisten
WonderCSabo
félisten
Kéne vmit kezdeni ezzel a problémával, mert a WebGL-ben egyébként nagy a potenciál.
Egyébként annyira nem lehet olyan nehéz kiszűrni az eldurvuló shader szkripteket...Szerk.: Ez a hiba is elég durva, viszont ez nem a WebGL spec hibája, hanem az Fx4 implementációjáé. Ezt már javították Fx5-ben.
-
-
bbenoe
csendes tag
Megismétlem: a MS nem jót szólt. Biztos h lesznek WebGL-es oldalak, mert a Google akarja. Azokat majd nem IE-vel nézik, hanem Chrome-mal, Safarival, Firefoxszal, ami nem érdeke a MS-nek.
Ha meg lesznek elcseszett, vagy rosszindulatú ilyen oldalak, a Google mejd jól ráteszi őket a feketelistájára és kész.
Továbbá az egész issue, mint már a kommentfolyam elején kiderült, a kliens baja, oldja meg.
-
floatr
veterán
válasz
Cathfaern
#29
üzenetére
A nagyobbik probléma az, hogy erre inkább a gpu driver gyártóinak kéne lépni valamit, nem pedig a ms-nak kéne sheriffet játszania. Implementálhatnának egy biztonsági mechanizmust a gpu-k környékére, amivel egy lépéssel megnehezíthetnék a támadók dolgát. Ezt tudják ők is, de akár még olyan driver modellt is alkalmazhatnának, ami ebben segít, csak nyilván az ő dolguk az, hogy hanyatt vágják magukat minden vélt vagy valós probléma okán.
Sőt abban sem akadályozza őket senki, hogy az opengl/es-hez adjanak kódot, vagy javaslatokat. Node sebaj, lesz az exploder részesedése még ennél is kisebb, bár a win8 interfészével próbálnak javítani az arányokon.
-
bbenoe
csendes tag
válasz
Cathfaern
#24
üzenetére
Ez csak egy tréfás kérdés: miért fáj neked a WebGL, ha ilyen régi a géped?
(Egyébként igen, az én laptopomra sem találok 2008-nál újabb Ati drivert, az egész WebGL téma azért került a szemem elé, mert a Google Body Browsert akartam rajta megnézni, és nem ment.)<off> Egy másik, Win7-es gépen meg béta Ati szoftvert (ati_catalyst_10.3_ogl4_preview_win7_vista_march29) kellett felrakni, mert egy régi tervezőszoftver éppen az OpenGL miatt nem futott a legújabb driverrel. Szóval driverszutyokság van elég. BTW a WebGL meg megy ezzel a bétával, mert 10.3-as, és a Chrome csak a 10.2-t és korábbiakat vágja ki...)
-
hadm
csendes tag
Itt nem a driver összeomlása a gond. Az már megoldott dolog, hogy a driver összeomlása nem rántja magával a rendszert. A gond pont akkor van, ha nem omlik össze a driver, hanem azon keresztül szépen hozzáférnek mindenhez.
Mi az ami ilyen könnyen és közvetlenül a webről tudna kódot pumpálni driverbe?
-
válasz
Cathfaern
#24
üzenetére
Mondjuk pont a dos elegge erdektelen, mert egy bongeszot dosolni nem nagy varazslat, javascriptben is lehet irni vegtelen ciklust meg szazmillioszor szazmillio pixeles kepet is lehet csinalni (amit szerveroldalon par byte-ra lehet tomoriteni).
Az meg, ha a grafikus driverben lyuk van, az akkor is problema, ha nincs webgl, ahogy azt mar elottem bambano is kifejtette, max. akkor nem remote, hanem local exploit, de ez mar olyan sokat nem szamit.
-
Cathfaern
nagyúr
Elmagyarázták, tisztán látszik az ábrán. Úgy, hogy a webGL hozzáfér a kernel módban futó VGA driverhez. Nyilván itt nem arról van szó, hogy jelenleg exploitolni lehetne, hanem arról, hogy tervezési hiba van benne (lásd még: ha a egy épületből kihagysz néhány oszlopot, lehet nem dől össze, de jó eséllyel idővel össze fog), vagy legalábbis designilag biztonsági rést tartalmaz.
"ie9-et is webgl nélkül lazán megtörik"
Épp arról van szó, hogy a webgl lényegében megkerüli a böngészőt, tehát lényegtelen, hogy az IE-t mennyire könnyű vagy nem könnyű megtörni.bambano:
Ja félreértés ne essék, nem akarom védeni az MS-t, nyilván nem fűlik a foga egy olyan szabvány támogatásához, amivel "bármilyen" oprendszeren lehetne 3D-s játékokkal játszani (normális grafika és sebesség mellett).
Ettől függetlenül amit megfogalmaz kritikát, az jogos. -
bambano
titán
én úgy emlékszem, olvastam olyat, hogy azért kellett újratervezni a driver modellt, hogyha megakad egy driver, az oprendszer összeomlása nélkül megoldják a problémát, akár újra is indíthassák azt. akkor meg mi a gond? megomlik a driver, megomlik, nem oszt, nem szoroz.
másrészt továbbra is azt forszíroznám, hogy nem a böngésző az egyetlen, amelyik támadó kódot tolhatna a videokártyába, tehát ezt a problémát úgy egyébként a böngészőtől függetlenül is meg kell oldani. következmény: a webgl nem támogatása mögött egyéb, nem biztonsági indokok vannak.
(#24) Cathfaern: egyet is tudnék érteni azzal, amit írtál, ha kizárólag a böngésző lenne az egyetlen probléma az átlagos windowsos gépen.
-
hohoo
senior tag
válasz
Cathfaern
#24
üzenetére
1. először azt kéne bizonyítani, és megmagyarázni, hogy webgl-en hogy lehet hozzáférni kritikus dolgokhoz. Mert ez az m$ közlemény egy bullshit, emellett ha rendesen leírták volna akkor is az ms szavahihetősége GyF-el vetekszik... másrészt még mindig nem látszik mi a különbség ebben a webgl és a directx között, harmadrészt az ie9-et is webgl nélkül lazán megtörik...
-
hadm
csendes tag
-
Cathfaern
nagyúr
A fő problémák a következőek:
1. WebGL esetén, ha tegyük fel a MS megírja úgy a böngészőt, hogy 0 hiba van benne, de szar a VGA driver, akkor be lehet jutni a gépre. Ki lesz ezért a hibás? "Há' neteztem, szóval szar az IE".
2. Rendben van, hogy videókártya gyártó van mondjuk 2, viszont bizonyos OEM partnerek VGA-jára a "központi" drivert nem lehet felrakni (laptopok tipikus eset). Innentől kezdve az a kettő felszaporodik 10-20-ra. Ráadásul OEM-eknek szokása, hogy nem adnak ki drivert, csak ha nagy gebasz van. Laptopomhoz utolsó driver több éves. Biztos lehetsz benne, hogy az OEM gyártók nem fogják ezután se összetörni magukat.
3. Az IE frissítését a MS központilag tudja irányítani, fel tudja hívni a figyelmet, kiírathatja az IE-ben, vagy visíthat a Windows, hogy van friss IE. A VGA driverek frissítésére semmi befolyása.
4. DoS-t úgy lehet végrehajtani, hogy egyetlen egy kérést küldesz a kliensnek, nem kell támadni. Ráadásul a böngésző bezárása sem feltétlen állítja meg (nyilván driver hiba kihasználása esetén). -
bbenoe
csendes tag
Azt hiszem a sandboxolás a CPU-ban történik, itt pedig a GPU-tól félnek.
A cikk túl finom mesh-t emleget - simán állhat egy közönséges kocka is 12 millió háromszögből, amit a szerencsétlen GPU egyenként akar árnyékolni és fényezni. Vagy ha ennél intelligensebb, akkor ezek a háromszögek 0,001 radiánnyit ferdék egymához képest. Aljas geometriát könnyű csinálni... gondolj a partneredre...
-
bambano
titán
A lényeg az, hogy ahelyett, hogy kijavítanák az alapvető hibákat, megint egyénieskedni akarnak és megint nem akarnak szabványkövetők lenni. Ez már az ie6-nál sem vált be, csak a mostani piaci részesedéseknél lehet, hogy hamarabb bebukják.
Egyébként is a böngészők elég sok helyen használnak ma már hardveres gyorsítást. Ergo teljesen mindegy, hogy először a böngészőt kell megtörni (ahogy némelyik kinéz, pl. ie, nem is nagy munka) és utána abból borítják meg a videodrivert, vagy közvetlenül mennek a videora. Másrészt meg nem a böngésző az egyetlen, ami hozzáférhet a videokártyához, tehát az, hogy a böngésző miatt nem csináljuk meg, csak üres mosakodás. Akkor csinálják meg a többi program miatt. Flasht, pdf-et, egyebet is törtek már meg, ezek is használnak hw gyorsítós apikat.
Még egy kérdés: nem azért tervezték újra a teljes driver modellt vista-nál, és nem azért sandboxolják a böngészőket, hogy ebből ne legyen probléma? Ha mégis van, milyen munkát végeztek eddig?
-
bbenoe
csendes tag
Egyébként pedig a Microsoft óriási öngólt rúg, majdnem akkorát, mintha a Google Maps nem futna IE alatt.
Lásd pl.: http://bodybrowser.googlelabs.com/ (10.6 nál újabb Ati driverrel, Chrome 12 alatt)További egyébként a zembereket nem érdekli a biztonság, a színes üvegcserép sokkal inkább.
-
hadm
csendes tag
Igen, valóban a hiba kihasználása valóban a driverben történik, de itt nem ez a lényeg. A lényeg, hogy a WebGL közvetlen hozzáférést enged a web felől olyan mélyen lévő rétegekhez ami a driver hibák nélkül is kockázatot jelent. Driver hibák pedig mindig lesznek a WHQL ellenőrzések ellenére is.
-
#19
hohoo
senior tag
attila9988
#16
hohoo
senior tag
válasz
attila9988
#16
üzenetére
nem csak a króm felé lehetne menni, hanem makkos, és bármilyen linux felé. Emulálni is úgy lehetne, hogy minden játék száguldana d3d nélkül, még akkor is ha maga a program még mindig wines, ugyanis a d3d a gátja annak hogy más platformokon nem lehet elegendő sebességgel wines játékot futtatni, hiszen erre készült az egész directx.
-
hohoo
senior tag
Még egyszer: hogyan fér hozzá egy api egy driverhez? Akkor a directx-et miért használják? hogy lehet dosolni webgl-el? (még a videokártyát sem terhelhetik túl, mert a szoftveres után már ha jólt tudom mind2 gyártónál hardveres védelem van erre, ati-nál biztosan...
Ha figyelembe vesszük, hogy whql-es driverek tudnak kékhalált meg mindenfélét okozni, ordító hibákkal, látható hogy a microsoftnál nem igazán kompetensek a témában...
Mindig mondom, az ms jobb ha marad a patent trollkodásnál, összevásárolt cuccok változatlan formában továbbadásánál, kenőpénzelésnél, mert ezekhez értenek, máshoz nem nagyon. -
bbenoe
csendes tag
Nodehát akkor a kockázat hordozója nem a WebGL, hanem a szutyok driver.
WHQL pedig mintha már lett volna. Vagy van is.
Továbbá.
Hány videókártya-gyártó van jelenleg? Kettő? Esetleg három? Ha nagyion optimista vagyok, akkor öt?
Akkor pedig mit is mondott a Microsoft? Sztem csak annyit, hogy "közöljétek, geekek, mindenhol" , amit buzgón meg is tettek. -
#16
attila9988
őstag
floatr
#12
attila9988
őstag
Ha ennek engednek, akkor megadják a lehetőséget a játékfejlesztőknek, hogy kiszabaduljanak a platformról, és akkor a chrome os-é a világ
Mintha scifi regényt olvasnék...
Azért ennyire ne essünk túlzásokba. Nem nagyon hiszem hogy mindenki rohanna a google karmaiba, ha netán az ms támogatná a webgl -t. Főleg hogy "nyíltságot" állítod itt szembe a csúnya gonosz "zárt" microsoft -al, holott egy felhős os -nél zártabb, megkötésekkel, és kellemetlenségekkel tarkított megoldást el sem lehet képzelni. Chrome os -hez képest a windows maga a szabadság... -
hadm
csendes tag
Szerintem itt a kisebbik gond az, hogy DOS támadás indítható. A nagyobbik, hogy kernelmódban futó driverekhez ad közvetlen hozzáférést. Nyílván nem arra fogják ezt felhasználni, hogy Kiszel Tündével rémisszenek. Ha azt is figyelembe vesszük, hogy mennyire szutyok drivereket tudnak kiadni még a nagyobb gyártók is, akkor azt hiszem azért látható, hogy van alapja a dolognak.
-
floatr
veterán
Biztos vagyok benne, hogy meg sem próbálják megoldani a problémát, akár javaslatokkal, akár tevőlegesen. A saját html/DOM/jscript aberrációik jelentősége eltörpül a d3d-é mellett. Ez gyakorlatilag az egyik legnagyobb ütőkártyájuk a win használata mellett. Ha ennek engednek, akkor megadják a lehetőséget a játékfejlesztőknek, hogy kiszabaduljanak a platformról, és akkor a chrome os-é a világ. Ennyi, semmiféle érdemi technikai problem nem releváns, mert ennyi erővel a canvas-ba is belerúghattak volna egyet.
(#11) hohoo a shader script az ugatás tárgya.
-
lgb
tag
Jaja, sorry a TCP/IP-s pelda kapcsan irtam eppen servert, nem a WebGL kapcsan, es az egesz a peldam miatt jott ide: ha van egy szervered nyilvan tul sok keres le fogja benitani.
Mindenesetre pl a DDoS-t mar nehezebb kivedeni. De nem is ez a lenyeg, hanem az, hogy voltakeppen minden megoldas ami kapcsolodik a halozatos dolgokhoz, az egyben biztonsagi kockazatot is jelent, es nem mindig egyszeru vedekezni ellene. Ha WebGL-nel maradunk, ilyen elven az is hasonlo temadas, hogy pl egy olyan jatekot akar futtatni az ember ami tulterheli a GPU-t. A kulonbseg annyi, hogy azert egy weboldal meglatogatasa egyszerubb, es kevesbe realizalodik a felhasznaloban is, hogy ez problemahoz vezethet, mig egy jatek telepitese/futtatasa az nem szokott "veletlenul" tortenni. Ha erted mire gondolok. Mindezek ellenere, imho hasonlo (ha nem is olyan nagy) problema, ha egy eroforrasigenyes oldalt latogat meg az ember (oldal merete, JavaScript kodok tomkellege, stb), amivel esetleg tulsagosan leterheli a gepet (sot egyes esetekben JS engine-ek hibajabol akar hasznalhatatlanna is valik a browser, es "ki kell loni" - erre is lattunk peldat). Az persze nemi kulonbseg, hogy itt kisse alacsonyabb szintre helyezi a tamadhatosagi feluletet a WebGL, akar egeszen a GPU szintjere. Viszont eleg nehez olyasmit krealni, ami performanciaban oke, platform fuggetlen, weben at mux stb, es nem hordoz semmifele kockazatot, eleve maga a web is ezt teszi hw/sw-tol fuggetlenul, az emberi tenyezot is megcelozva: lasd pl adathalaszat stb. Ez mondjuk mar inkabb filozofiai kerdes innentol, es kevesbe temaba vago, bocsi.
-
FTeR
addikt
a pronléma itt inkább a kliens gép túlterhelésén van, semmint egy szervernél.
kliensen a TCP/IP alapú DoS-t prózai egyszerűséggel ki lehet védni.
itt az a probléma, hogy egy response okozza a DoS-t.#1
persze. mint láthatjuk sok más példánál (mint html5), ms teljesen szembe megy az iparággal, saját önös érdekből.
biztos vagyok benne, ha ms cuccában lenne ilyen alapvető, tervezési hiba, akkor te lennél az első a topikban, aki anyázna : )#5
inkább örülhetnél, h tanulnak a hibáikból.
milyen jó lesz, ha majd alapból tiltani kell WebGL-t, olyanért, amiért az ActiveX-et is. -
lgb
tag
MS-nek TCP/IP-t se kene implementalnia. Ugyanis az is lehetove teszi a gep DoS-olasat kulso forrasokbol, ergo nem biztonsagos, nem kell halozat, az mind kockazati tenyezo! :-D Amugy a dologban persze van igazsag, de vegulis minden dolog meglete egyben kockazat is: ha nem kapcsoljuk be a szervert, eleg nehez megtamadni, ergo ne is kapcsoljuk be. Azert ez kisse szelsoseges allaspont, igazsagtartalma ellenere is, imho.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
- Milyen routert?
- GoodSpeed: AMD Ryzen 7 7700X vs AMD Ryzen 9 9900X Cinebench R23 & R24 Benchmarkokban mérve
- Autós topik
- Milyen billentyűzetet vegyek?
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- Először égett le egy újságnál a GeForce RTX 5090
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Magyarországra jött az ultravékony S25 Edge
- Épített vízhűtés (nem kompakt) topic
- Kerékpársportok
- További aktív témák...
- BESZÁMÍTÁS! Gigabyte H510M i5 10400F 16GB DDR4 512GB SSD 1TB HDD RX 6600 8GB Zalman S2 TG EVGA 600W
- BESZÁMÍTÁS! Gigabyte H510M i5 10400F 16GB DDR4 512GB SSD 1TB HDD RTX 2060S 8GB Rampage SHIVA 600W
- Zelda Breat of Wild
- Lenovo ThinkCentre M90q Gen 4 Mini PC - i5-13400 16GB DDR5 / 512GB SSD - ÚJ! Wifi 6, BT 5.3, DP
- Ritkaság! Samsung Galaxy Z Flip 6 512GB Olympic Edition, 1 év globális garanciával!
- iKing.Hu Samsung Galaxy S25 Plus Navy 12/256 GB Használt, karcmentes állapotban 3 hónap garanciával!
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA ADATA XPG 600W
- 13-14" Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- Lenovo ThinkPad X13 Yoga i5-10310U 16GB RAM 512GB SSD 13.3 FHD Touch 2in1
Állásajánlatok
Cég: FOTC
Város: Budapest