Chrome 76 turėjo „FileSystem“ API diegimo spraga, leidžianti iš žiniatinklio programos nustatyti, ar naudojamas inkognito režimas. Pradedant nuo 76 versijos „Chrome“, užuot blokavusi prieigą prie „FileSystem“ API, kuri buvo naudojama kaip inkognito režimo veiklos ženklas, naršyklė neberiboja „FileSystem“ API, bet išvalo po seanso atliktus pakeitimus. Kaip paaiškėjo, naujas įgyvendinimas trūkumai, leidžiantys nustatyti inkognito režimo aktyvumą kaip ir anksčiau.
Problemos esmė ta, kad seansas su FileSystem API inkognito režimu yra laikinas, o duomenys neišsaugomi diske ir laikomi RAM. Atitinkamai, duomenų išsaugojimo per FileSystem API laikas ir atsirandantys nukrypimai (išsaugant RAM fiksuojamos pastovios charakteristikos, o rašant į diską vėlavimai keičiasi) galite drąsiai spręsti, ar puslapis žiūrimas inkognito režimu ar ne . Šio metodo trūkumas yra gana ilgas nuokrypių matavimo procesas, kuris gali trukti apie minutę ().
Tuo pačiu metu „Chrome 76“ lieka nepataisytas dar vienas dalykas , kuri leidžia spręsti apie inkognito režimo veiklą, remiantis API nustatytų apribojimų įvertinimu . Laikinai saugyklai, naudojamai inkognito režimu, nustatomos kitokios ribos nei visam saugojimui diske.
Priminsime, kad svetainės, veikiančios pagal pilnos prieigos suteikimo per mokamą prenumeratą (mokėjimo sieną) modelį, domisi inkognito režimo apibrėžimu. Siekdamos pritraukti naują auditoriją, tokios svetainės suteikia naujiems vartotojams tam tikrą laiką demonstracinę pilną prieigą, kuri aktyviai naudojama norint apeiti mokamas sienas. Lengviausias būdas prieiti prie mokamo turinio tokiose sistemose – naudoti inkognito režimą, kai svetainė mano, kad vartotojas puslapį atidarė pirmą kartą. Leidėjai nėra patenkinti tokiu elgesiu, todėl jie aktyviai naudojo spragą, susijusią su „FileSystem“ API, kad nustatytų reikalavimą išjungti inkognito režimą, kad būtų galima tęsti naršymą.
Šaltinis: opennet.ru
