I Chrome 76 blev i implementeringen af FileSystem API, der gjorde det muligt for webapplikationer at bestemme, om inkognito-tilstand var aktiv. Fra og med Chrome 76 er der i stedet for at blokere adgangen til FileSystem API, som tidligere blev brugt som et tegn på aktivering af inkognito-tilstand, stoppet med at begrænse FileSystem API, men ændringerne blev renset efter sessionen. Det viste sig, at den nye implementering mangler, der som tidligere gør det muligt at bestemme aktiviteten af inkognito-tilstand.
Essensen af problemet er, at sessionen med FileSystem API i inkognito-tilstand er midlertidig, og data gemmes ikke på disken, men holdes i RAM. Derfor, tiden for at gemme data via FileSystem API og de afvigelser, der opstår (når der gemmes i RAM, registreres konstant karakteristika, mens forsinkelserne ændres ved skrivning på disken), kan man ret sikkert bedømme, om den viste side er i inkognito-tilstand eller ej. Ulempen ved metoden er, at det er en ret langvarig proces at måle afvigelser, som kan tage omkring et minut ().
Samtidig forbliver der endnu en uopdaget , som gør det muligt at vurdere aktiviteten af inkognito-tilstand baseret på vurdering af de begrænsninger, der anvendes gennem API'en . For det midlertidige lager, der anvendes i inkognito-tilstand, er der fastsat andre grænser end ved fuld opbevaring på disken.
Husk, at websteder, der er interesseret i at bestemme inkognito-tilstand, ofte arbejder på en model med fuld adgang mod betaling (paywall). For at tiltrække nyt publikum giver sådanne websteder nye brugere gratis fuld adgang i en kort periode, hvilket aktivt udnyttes til at omgå paywall. Den nemmeste måde at få adgang til betalt indhold i sådanne systemer er at bruge inkognito-tilstand, hvor webstedet tror, at brugeren åbner siden for første gang. Udgiverne er ikke tilfredse med denne adfærd, og derfor har de aktivt udnyttet den relaterede bagdør i FileSystem API til at kræve, at inkognito-tilstand slås fra for at fortsætte visningen.
Kilde: opennet.ru
