No Chrome 76, foi uma brecha na implementação da FileSystem API, permitindo identificar a partir de uma aplicação web o uso do modo incógnito. A partir do Chrome 76, em vez de bloquear o acesso à FileSystem API, que era utilizada como um sinal de atividade no modo incógnito, o navegador deixou de restringir a FileSystem API, mas limpava as alterações feitas após a sessão. Como se revelou, a nova implementação defeitos que permitem, como antes, identificar a atividade do modo incógnito.
A essência do problema é que a sessão com a FileSystem API no modo incógnito é temporária, e os dados não são salvos no disco, permanecendo na memória RAM. Portanto, o tempo de salvamento de dados via FileSystem API e as variações que surgem (durante o salvamento na RAM, características constantes são registradas, enquanto ao gravar no disco, as latências mudam), pode-se julgar com bastante confiança se a página está sendo visualizada no modo incógnito ou não. A desvantagem do método é que o processo de medição das variações pode durar cerca de um minuto ().
Ainda assim, no Chrome 76, permanece outra , que permite avaliar a atividade do modo incógnito com base na análise das restrições impostas através da API . Para o armazenamento temporário utilizado no modo incógnito, são estabelecidos limites diferentes do armazenamento completo no disco.
Vale lembrar que, na definição do modo incógnito, interessam-se sites que operam com o modelo de acesso completo por assinatura paga (paywall). Para atrair uma nova audiência, esses sites oferecem aos novos usuários acesso completo de demonstração por um tempo, o que é amplamente utilizado para contornar o paywall. A maneira mais simples de acessar conteúdo pago nessas plataformas é através do modo incógnito, onde o site acredita que o usuário abriu a página pela primeira vez. Esse comportamento não agrada os editores, que por isso utilizam ativamente a brecha relacionada à FileSystem API para exigir a desativação do modo incógnito para continuar a visualização.
Fonte: opennet.ru
