Názory k článku
DoS zranitelnost prohlížeče Chrome a všech derivátů

Mají jeho e-mail na blacklistu... - nebo se jim prostě něco nelíbilo.
Žel, na Google řešeních poslední dobou celkem běžná věc.

Ze byl email dorucen do sfery vlivu prijemce si odesilatel overit muze v celku snadno. A pokud to ve svere prijemce bylo pozrano nekde dal, je to problem na strane prijemce. RFC jasne rika, ze kdyz email prijmete, nesete odpovednost za jeho dalsi zpracovani. A jestli se tim Google neridi, je to... ehm, jeho problem.

Ovšem že to bylo Googlu oznámeno e-mailem je vaše ničím nepodložená domněnka. Navíc do sféry vlivu příjemce (Googlu) spadá i hlavní účetní okrašlovacího spolku zaměstnanců Maďarské pobočky Googlu, nicméně poslat jí e-mail s chybou v Chrome bych nepovažoval za řádný způsob oznámení bezpečnostní chyby.

Google má pro hlášení bezpečnostních chyb formulář, Chromium má také svůj formulář pro hlášení bezpečnostních chyb. Pochybuju, že by na hlášení chyb přes tyto formuláře nepřišla žádná reakce.

Zajiste, ono se nikdy v zadnem korporatu neco nekde nezabordelilo :-) A ted nam jeste povezte pohadku O Cervene Karkulce.

Ale kdyz je tak rad obhajujete, tak tady mate jiny priklad toho, kdy Google oznameni nejdrive bagatelizoval ;-) A vcil mudrujte...

Danny: A zase to vaše demagogické ohýbání diskuse. Nereagovat na oznámení a bagatelizovat ho jsou dvě odlišné věci.

Vlivem bagatelizace oznameni muze nastat i stav, kdy se vubec nezareaguje zeano. Ale to vy, coby sociopat chapat nemuzete :)

Jenze to by google mail musel fungovat. Tento tyden jsem poslal par souboru zakaznikovi - v mail logu bylo jasne prevzeti - a prijemce to nedostal. Nemel to ani ve spamu... takze tolik k odpovednosti u SMTP :)

Google je hnuj nejvetsi. Pravdy se tam nedohledate.

Tohle je u Google dlouhodobé chování. Nepředvidatelná "antispam" AI, která v klidu vrátí 250, aby ten mail prostě z nějakého důvodu smazala. A supportu se ani odesilatel, ani zákazník, samozřejmě nedovolá.

Tohle je sice od konkurenční platformy, ale soudím, že u Google to bude zrovna tak. (Zestručněno - radikálně.)
Po dlouhém dobývání se na podporu e-mailu:
- Nebyl mi doručen e-mail, na který čekám. Ani do spamu ne.
- Jak můžete vědět, že vám byl vůbec doručen? Co když jej odesílatel prostě neodeslal?
- Odesílatelem jsem já, na jiném systému. Zpráva byla normálně odeslána až na váš server.
- Naše servery mohou podezřelé zprávy odmítnout. O důvodu posílají zpět krátkou informaci. Prosím, přepošlete nám tuto zprávu, abychom zjistili důvod odmítnutí.
- Žádnou takovou zprávu jsem nedostal, e-mail byl normálně předán na server.
- Není možné, že tuto zprávu váš server odmítl?
- Možné by to bylo, ale já v logu vidím, že zpráva byla na váš server předána v pořádku. Nic dalšího.
- Ve výjimečných případech je možné, že z bezpečnostních důvodů se zpráva neposílá, například jako prevence DDoS útoků, nebo pokud přichází ze serverů, zneužívaných k rozesílání spamu.
- Tohle byla obyčejná, nekomplikovaná zpráva z velkého e-mailového providera. Můžete mi sdělit, zda je blokován, či zda není omylem blokován e-mail odesílatele?
- To nelze, tato informace by byla zneužitelná.
- Můžete mi zaručit, že se to nebude opakovat? Že se na náš (placený) e-mailový server doručí všechny zprávy, které potřebujeme?
- Ne, ale zaručujeme vám, že filtrování zpráv podléhá důkladnému posouzení, aby se zabránilo doručení potenciálně nebezpečných či obtěžujících zpráv. Je to pro dobro našich zákazníků..

Tak my to vime, ze bordel je u nich... ale k Jirsakum to nedoteklo a tak nam tu omlouva Google, sec mu sily staci... :-)

Jasně, „bezpečnostní odborník“ se stará hlavně pro to, aby objevené chybě dal jméno, vytvořil pro ní web a poslal to do médií – ale že by třeba zaregistroval CVE, to ne. Proč bych si měl myslet, že to Google oznámil tak, jak se mají hlásit bezpečnostní chyby? Pro hlášení bezpečnostních chyb má Chrome i Chromium webové formuláře. Ale Danny tady bude pořád plácat hlouposti o e-mailech. Asi jste v tom hledání formuláře pro hlášení bezpečnostních chyb stejně dobrý, jako Jose Pino.

K ziskani CVE se musite obratit na partnera (CNA). A tim je zrovnatak krom jineho i Google. Jasne, ale podle vasi "pseudologiky" by byrokracii za Google mel asi vyrizovat nekdo jiny (tedy jina CNA), ze? ;-) Plus se dozadujete zkoumat korporatni vymysly typu "specialni formular", ktery zacina tim, ze to po vas chce prihlaseni Google uctem. Takze aby meli u Jirsaku klid, vsichni si musi zaridit ucet u Google, ze? ;-) No je videt, ze teoretizujete, ale jak ten vas formular funguje nevite.

Já vím, že v tom formuláři je odkaz pro případ, že se nemůžete přihlásit Google účtem. Takže mne zase obviňujete z neznalosti, přitom to ale nevíte sám.

https://www.google.com/.well-known/security.txt

Contact: https://g.co/vulnz
Contact: mailto:securi­ty@google.com
Encryption: https://services.google.com/corporate/publickey.txt
Acknowledgments: https://bughunters.google.com/
Policy: https://g.co/vrp
Hiring: https://g.co/SecurityPrivacyEngJobs
Expires: 2030-04-01T00:00:00z

Wasper: To se týká webu google.com, ne prohlížeče.

1. 11. 2025, 21:13 editováno autorem komentáře

https://www.rfc-editor.org/rfc/rfc9116.txt

Ano, doporučuji zaměřit se zejména a sekci 3 a 3.1.

A tak jo... :-) Mozna byste si to mel precist lip...
A "security.txt" file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains. A "security.txt" file MAY also apply to products and services provided by the organization publishing the file.

Chcete nam rict, ze https://www.google.com/intl/cs_CZ/chrome/ neni domenou/URI, ktereho se vyse odkazovany security.txt tyka? :-) Vas vyklad RFC9116 se zda byti skutecne bizarni.

Danny: Očekával jsem, že vy se budete tvářit, že tam to MAY buď vůbec nevidíte, nebo nechápete, co MAY v RFC znamená.

A on to publikovany security.txt nejak omezuje? Kdyz si jeho formy vsimnete, obsahuje dva kontakty - prvnim je odkaz na ten vas formular, druhym... badumtss... prave email. Z pohledu RFC9116 jsou kontakty rovnocenne, RFC pouze rika ze preference protistrany je dana jejich poradim. Ale z toho nelze dovozovat, ze ten druhy pouzit nemuzete. To je od pocatku vas chybny konstrukt.

Danny: Zase vaše typická reakce na úplně něco jiného, než o čem byl váš původní komentář a moje reakce na něj.

Tak vy tu porad blabolite neco o tom, ze formular na webu je jedina spravna forma kontaktu, ale ono to tak proste a jednoduse neni. Pokud jako bezpecnostni vyzkumnik najdu v security.txt kontaktni email, tak jej pro sve hlaseni pouzit muzu, zvlast pokud narazim na bariery typu "nutnost disponovat uctem" - viz nize....

Použít pro hlášení chyb můžete co chcete, můžete to poslat třeba poštou do televize. Akorát se pak nesmíte divit, že o té chybě neví ten, kdo by ji mohl opravit.

Pořád to nic nemění na tom, že kontakty uvedené v odkazovaném security.txt nejsou kontakty určené k hlášení bezpečnostních chyb v Google Chrome. Což zjistí každý, kdo si přečte RFC 9116, zejména sekce 3 a 3.1, přečte si soubor https://www.google.com/.well-known/security.txt a v něm odkazovanou politiku https://bughunters.google.com/about/rules/google-friends/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules Jenže vy chcete jenom útočit a znalosti by vás v tom zbytečně omezovaly, že.

A taky ma dalsi dokumentaci, kde i na email odkazuje. A podle vas je teda pri tom sermu odkazy v poradku, ze vse co odkazujete vyzaduje prihlaseni Google uctem? ;-) Tedy mimo jine odsouhlasit dalsi na to navazane veci. Utocite predevsim vy, kdyz chronicky zpochybnujete oznameni bezpecniho incidentu pomoci emailu. Akorat vase argumentace kulha na obe nohy.

Utocite predevsim vy, kdyz chronicky zpochybnujete oznameni bezpecniho incidentu pomoci emailu.
Aha, a na koho tím útočím?

Jinak pokud lze bezpečnostní chyby hlásit přes webový formulář, dokonce je to preferovaná cesta, pak je na místě zpochybňovat vaše ničím nepodložené tvrzení, že určitě zašantročili e-mail.

Ale vůbec mne nepřekvapuje, že právě vy obhajujete uznávaného bezpečnostního odborníka, jehož hlavní starostí je, aby chyba měla název, logo a web, ale oprava chyby ho nijak moc nezajímá.

Howgh.

No, argumentujete tu tim, ze Google neco nevedel a cely konstrukt tocite kolem toho, ze to slo emailem a nikoliv pres nejaky pripitomely formular, ke kteremu se bez Google uctu ani nedostanete. Jenze ono Google nekolik tech security-related emailu ma a pokud si to uvnitr korporatu neumi spravne predat, je to proste jejich problem - a ne problem toho, kdo bezpecnostni incident reportuje zpusobem, ktery nenarazi na umele bariery - mj. na nutnost disponovat uctem u Google.

Ano, na tom "novem" je If you are unable to log in, use our old form instead. Na "starem" kdyz vyberu I want to report a technical security or an abuse risk related bug in a Google product, a zde po vyplneni jmena a emalu vyberu Google Chrome, Chrome OS... tak tam zadny formular k vyplneni neni, je tam jen text hovorici o Chrome Vulnerability Rewards Program, kde na nahlaseni tam je odkaz, kde zacinate... badumtss... prihlasenim ke google uctu :-)

Jo, tak to vypada, kdyz borec z korporatu se snazi obhajit korporatni bordel a pritom sam nevi, jaky bordel v tom korporatu maji :-)

Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.

Akorát že to nijak nesouvisí s implementací v prohlížečích.

Občas se to mění tak, že se specifikace změní podle skutečné implementace.
To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.

> Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.

To ani nemusím. I bez těch "Editorial: Fix markup + wording" commitů se mění takhle často. Za poslední týden se změnila 31. října, 29. října a 28. října. A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.

> To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.

To je možné, ale pak se to mění tak, že nové chování není zpětně kompatibilní se starým. Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.

A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.
Kdybyste se na ty commity podíval, jedno je změna formátování, jedno je upřesnění (které nesouvisí s implementací) a jenom jedno je upřesnění, které by se čistě teoreticky mohlo v implementaci projevit.

Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.
Abych vám to věřil, chtěl bych vidět příklad takového „třeba se stane“.

To by nebylo moc praktické, zahodit všechny současné weby i s tím, že obsah je přístupný i pro jiné formy konzumace, než je zobrazení, a nahradit to vykreslováním přes WebGPU. Takové pokusy už tu byly třeba s Flashem a všichni jsou rádi, že to zaniklo.

> To by nebylo moc praktické, zahodit všechny současné weby i s tím, že obsah je přístupný i pro jiné formy konzumace, než je zobrazení, a nahradit to vykreslováním přes WebGPU.

Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně. Tím by se značně zjednodušila implementace prohlížeče a aplikace by mohla říct, jakou verzi očekává, takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly. Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.

Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně.
Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.

Tím by se značně zjednodušila implementace prohlížeče
Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.

takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly.
Což se reálně neděje ani teď, takže je zbytečné to řešit.

Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.
Podle mne je důležité, že existuje víc vykreslovacích jader prohlížečů – a bylo by lepší, kdyby Blink dominoval méně.

Implementovat jedno vykreslovací jádro, které by používali všichni, a ještě v JavaScriptu, by byla pozoruhodná kombinace několika naprosto nesouvisejících špatných rozhodnutí. Můžu si taky něco přihodit? Já bych doporučil, aby takové jádro mělo dokumentaci a názvy proměnných, funkcí a objektů v Katalánštině.

> Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.

To nemusí být pravda. Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.

> Což se reálně neděje ani teď, takže je zbytečné to řešit.

To se děje, protože se nedrží zpětná kompatibilita.

> Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.

Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.

Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.
Takže by dokonce každá webová stránka měla své vlastní vykreslovací jádro prohlížeče napsané v JavaScriptu. Už předchozí váš komentář byl hodně dada, ale vidím, že jste se ještě překonal.

To se děje, protože se nedrží zpětná kompatibilita.
Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.

Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.
Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/We­bAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.

Každopádně třeba takové Servo se vyvíjí už několik let, a pořád z toho není kompletně hotové vykreslovací jádro prohlížeče. A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly. Jak dlouho by to asi trvalo?

Navíc nekompatibilita vykreslovacích jader je váš virtuální problém. V praxi takový problém neexistuje. Co se řeší v praxi je nepodpora nebo částečná podpora různých Web API. Nejblíž tomu vašemu virtuálnímu světu by byla chybějící podpora některých CSS funkcionalit, to je to jediné, co by to vaše nové vykreslovací teoreticky mohlo řešit. Akorát že to málokdy opravdu vadí, obvykle to znamená jen to, že v nepodporovaném prohlížeči je něco o něco ošklivější.

> Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.

Haha. Děje se to dost často, protože ta specifikace se mění často. Už i upřesnění může znamenat ztrátu zpětné kompatibility. Příkladů za pár posledních let je hromada - třeba Chrome odebral Mutation events, nebo vlastnosti selectionStart a selectionEnd přestaly existovat na některých inputech.

> Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/We­bAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.

O přepis vůbec nejde. Jde o to, že by to běželo v sandboxu na úrovni aplikace. Teď to běží na úrovni prohlížeče.

> A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly.

Neřekl jsem úplně nové. Stačí upravit existující, aby používalo WebGPU API (+ nějaké API pro přístupnost) a přeložit ho pomocí Emscripten.

vlastnosti selectionStart a selectionEnd přestaly existovat na některých inputech
Ve které verzi specifikace byly na více inputech, než dnes?

Stačí upravit existující, aby používalo WebGPU API (+ nějaké API pro přístupnost) a přeložit ho pomocí Emscripten.
:-D

> Ve které verzi specifikace byly na více inputech, než dnes?

Určitě to bylo méně než 20 let, o kterých jste mluvil. Tipl bych tak 15.

Jestli to bylo v nějakém draftu v roce 2010, tak je to celkem jedno, protože specifikace HTML5 byla vydána až v roce 2014.

Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.
Byl bych mnohem radši, kdyby nebyly tak optimalisované - třeba by vedlo k jejich méně častému používání.
Vyloženě mi vadí, že k zobrazení informací ve stylu text a obrázky občas potřebuji vysoce optimalisované knihovny pro přehrávání videa, zvuky, složité efekty, apod.

Překrývající věci jsou zpravidla kvůli zpětné kompatibilitě – s novým API lze dělat víc, než se starým, ale to staré zůstane kvůli zpětné kompatibilitě. Menší API se stejnou funkcionalitou by vůbec ničemu nepomohlo.

To máte pravdu. Teď už je to tak složité, že už to nikdo správně nenaimplementuje. Je potřeba to celé zahodit a začít znovu. S tím, že ty původní aplikace by nad novým API mohly běžet tím způsobem, co jsem popsal.

Navíc hodně aplikací vlastně vůbec nezajímá přímo HTML nebo DOM - používají nějakou knihovnu (třeba React), která to nějak použije za ně. Tudíž těmto lidem by bylo jedno, zda ten React bude pracovat s DOMem nebo s něčím efektivnějším.

Pořád vymýšlíte, jak něco úplně předělat, ale proč byste to předělával? Co byste tím získal?

Jednodušší implementaci - prohlížeč by dokázal implementovat tým pár lidí, možná dokonce jeden člověk. Možná by pak mohlo existovat více prohlížečů s různými jádry. A věřím, že i lepší bezpečnost a vyšší spolehlivost.

Vždyť by nad tím pořád musela existovat ta vrstva emulující HTML a DOM. To by nebylo na implementaci jednodušší, nýbrž složitější.

HTML a DOM by mohly být nezávislé na prohlížeči. Některé aplikace, třeba ty v Reactu, by je ani nepotřebovaly - mohly by přímo krmit layout engine (který by také mohl být nezávislý na prohlížeči).

Jako že by SDL3 mohlo nahradit browser API?

Toto je prostě hodně naivní porovnání, sorry.

> Toto je prostě hodně naivní porovnání, sorry.

A existuje i nějaký argument proč?

A existuje i nějaký argument proč?
Ty argumenty vyžadují alespoň vzdáleně tušit co je web, co prohlížeč dělá, jaká poskytuje API, jak se takový prohlížeč programuje. Když tohle netušíte, ty argumenty nevidíte – i když už tady v diskusi zazněly.

1. 11. 2025, 19:55 editováno autorem komentáře

A proč byste to, co dělá prohlížeč, nemohl udělat přes API SDL3? Co vám tam chybí?

Mohl, teoreticky. Ale nic dobrého by to nepřineslo, jenom obrovské náklady a komplikace.

A proč byste to, co dělá prohlížeč, nemohl udělat přes API SDL3? Co vám tam chybí?

To je pokus o vtip? Vždyť SDL3 neumí ani vykreslit text...

Dál už bych nechtěl pokračovat. Toto je úplně nesmyslná diskuze.

> To je pokus o vtip? Vždyť SDL3 neumí ani vykreslit text...

To přeci nemusí být součást prohlížeče - může to být na úrovni Reactu apod. Point je, že to nad SDL 3 API snadno implementujete. A výše jsem i popsal jak.

může to být na úrovni Reactu
React ovšem pracuje s DOMem.

Point je, že to nad SDL 3 API snadno implementujete.
To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.

> To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.

Já bych tam implementoval prakticky všechno - od parsování HTML, CSS, přes DOM a layout engine až po vykreslování. To znamená velkou část. A získal bych menší prohlížeč, kde je menší prostor pro bezpečnostní chyby a je jednodušší jej implementovat.

Krom toho to vyřešené stále nemají, protože jsou v tom stále chyby nebo se to stále mění.

Nezískal byste menší prohlížeč, který je jednodušší implementovat. Tím, že napíšete nový prohlížeč s pomocí jiné technologie, nedocílíte toho, že by byl prohlížeč menší nebo jednodušší na implementaci.

Chyby jsou ve všem a mění se to tak, že se přidávají nové funkce – protože je po nich poptávka. Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.

> Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.

Ano, souhlasím. Klasické HTML pak může být jedna z těch aplikací, už nemusí být součástí prohlížeče. Konkrétně třeba u Chrome by se mohl odstranit celý Blink a Skia - čímž by se Chrome zjednodušil a zmenšil o několik milionů řádků kódu.

Navíc Skia pro WebAssembly už existuje, teď se přepisuje pro WebGPU - pro použití ve Flutteru, který by běžel v prohlížeči. Takže část té práce je už hotová.

Tím, že kód přesunete jinam, se nezmenší a nezjednoduší.