To jen v pripade, ze by bylo zajisteno, aby se do jeho screenshotu nedostal zadny pixel, ktery nema (treba pixel z obsahu intranetove stranky v iframu, ke ktere JavaScript normalne nema pristup), coz by v pripade, kdy bude stranka poskladana z rady iframu (ty muzou byt navic jeste polopruhledne, ruzne pootocene a deformovane pomoci SVG atd.) znamenalo pri screenshotovani canvasem kazdy pixel velmi peclive zvazovat. Tahle uloha by pravdepodobne reseni mela, ale byl by to raj na bezpecnostni chyby v prohlizecich, bezpecna implementace by vubec nebyla snadna a rozhodne by se hned tak nepovedla.
Mezi dalsi dokumenty, ktery by prohlizec videl, jsou treba obrazky, ty muzou byt cenne samy o sobe nebo proste nest informacni hodnotu (grafy, interni fotografie atd.). Presnou URL utocnik vzdy nemusi znat, muze zkouset genericke URL z ruznych CMS, vyuzit pri tom navic CSS exploitu (historie adres v uzivatelove prohlizeci). Takove obrazky muze prohlizec z intranetu nacist uz dnes, ale vzhledem k tomu, ze se nedostane k jejich obsahu, to neni az takovy problem. Pri screenshotovani by to byla dalsi vec, ktere by se muselo predejit.
napokon neviem či to vôbec webbrowsery povoľujú, vkladať do dokumentov na internetových doménach obsah z intranetu.Ony to muzou povolit, protoze prohlizec nemusi mit vzdy vubec paru, co je internetova a co intranetova zona.
A to se stale divame na tenhle problem izolovane, kdyz bychom si ho zkombinovali se stavajicimi bezpecnostnimi problemy, kdo vi, jake moznosti bychom jeste objevili. Obecne by se implementaci screenshotovani canvasem vytvorilo velmi rizikove misto, coz je ted asi to posledni, co web potrebuje a nedivim se, ze to bylo zamitnuto.
