Chrome 76 hade ett kryphål i implementeringen av FileSystem API som låter dig avgöra från en webbapplikation användningen av inkognitoläge. Från och med Chrome 76, istället för att blockera åtkomst till FileSystem API, som användes som ett tecken på aktivitet i inkognitoläge, begränsar webbläsaren inte längre FileSystem API, utan rensar upp ändringar som gjorts efter sessionen. Som det visar sig, den nya implementeringen nackdelar som gör det möjligt att bestämma aktiviteten i inkognitoläget som tidigare.
Kärnan i problemet är att sessionen med FileSystem API i inkognitoläge är temporär, och data sparas inte på disk och hålls i RAM. Respektive, tidpunkten för att spara data via FileSystem API och de avvikelser som uppstår (vid lagring i RAM registreras konstanta egenskaper, medan fördröjningarna ändras vid skrivning till disk) kan du med säkerhet bedöma om sidan visas i inkognitoläge eller inte . Nackdelen med denna metod är den ganska långa processen att mäta avvikelser, som kan ta ungefär en minut ().
Samtidigt är ytterligare en sak ofixad i Chrome 76 , som låter dig bedöma aktiviteten i inkognitoläget baserat på en bedömning av de begränsningar som ställts in via API:et . För tillfällig lagring som används i inkognitoläge sätts andra gränser än för full lagring på disk.
Låt oss påminna dig om att webbplatser som arbetar efter modellen att ge full åtkomst via en betald prenumeration (betalvägg) är intresserade av att definiera inkognitoläge. För att locka en ny publik ger sådana webbplatser nya användare demofull tillgång under en tid, vilket aktivt används för att kringgå betalväggar. Det enklaste sättet att komma åt betalinnehåll i sådana system är att använda inkognitoläge, där sajten tror att användaren har öppnat sidan för första gången. Utgivare är inte nöjda med detta beteende, så de använde aktivt ett kryphål associerat med FileSystem API för att införa ett krav på att inkognitoläget ska inaktiveras för att fortsätta surfa.
Källa: opennet.ru