Protecting private browsing in Chrome
Update (7/21/2020): As of July 2020, Chrome is gradually rolling out a previously announced fix to address a loophole that could be used by websites to detect Chrome Incognito Mode sessions. The change (Chromium issue #1017120) was first announced in January and will apply to users with Chrome 81+. (Another change announced in January, Chromium issue #990592, rolled out with Chrome 80 in February.)
Chrome’s Incognito Mode is based on the principle that you should have the choice to browse the web privately. At the end of July, Chrome will remedy a loophole that has allowed sites to detect people who are browsing in Incognito Mode. This will affect some publishers who have used the loophole to deter metered paywall circumvention, so we’d like to explain the background and context of the change.
Private browsing principles
People choose to browse the web privately for many reasons. Some wish to protect their privacy on shared or borrowed devices, or to exclude certain activities from their browsing histories. In situations such as political oppression or domestic abuse, people may have important safety reasons for concealing their web activity and their use of private browsing features.
We want you to be able to access the web privately, with the assurance that your choice to do so is private as well. These principles are consistent with emerging web standards for private browsing modes.
Closing the FileSystem API loophole
Today, some sites use an unintended loophole to detect when people are browsing in Incognito Mode. Chrome’s FileSystem API is disabled in Incognito Mode to avoid leaving traces of activity on someone’s device. Sites can check for the availability of the FileSystem API and, if they receive an error message, determine that a private session is occurring and give the user a different experience.
With the release of Chrome 76 scheduled for July 30, the behavior of the FileSystem API will be modified to remedy this method of Incognito Mode detection. Chrome will likewise work to remedy any other current or future means of Incognito Mode detection.
Publisher impact and strategies
The change will affect sites that use the FileSystem API to intercept Incognito Mode sessions and require people to log in or switch to normal browsing mode, on the assumption that these individuals are attempting to circumvent metered paywalls.
Unlike hard paywalls or registration walls, which require people to log in to view any content, meters offer a number of free articles before you must log in. This model is inherently porous, as it relies on a site’s ability to track the number of free articles someone has viewed, typically using cookies. Private browsing modes are one of several tactics people use to manage their cookies and thereby "reset" the meter count.
Sites that wish to deter meter circumvention have options such as reducing the number of free articles someone can view before logging in, requiring free registration to view any content, or hardening their paywalls. Other sites offer more generous meters as a way to develop affinity among potential subscribers, recognizing some people will always look for workarounds. We suggest publishers monitor the effect of the FileSystem API change before taking reactive measures since any impact on user behavior may be different than expected and any change in meter strategy will impact all users, not just those using Incognito Mode.
Our News teams support sites with meter strategies and recognize the goal of reducing meter circumvention, however any approach based on private browsing detection undermines the principles of Incognito Mode. We remain open to exploring solutions that are consistent with user trust and private browsing principles.
