IncogniDO: History on the Do's and Dont's of Chrome's Incognito Mode

The web's PEBCAC silver tuna has been around since the dawn of the industry and "it lies between the pit of [customers]'s fears and the summit of his knowledge". While advancements in ISP performance and minification practices have battled the need for caching, the demand for instant seamless performance keeps it around alive and well. Clearing cache has forever been the disclaimer that plagues post-launch confirmation and while industry professionals have become accustomed to impatient users, the simplicity of one-click imitators, such as Chrome's Incognito mode, has made our lives easier but taken us 1 small step backwards, so let's correct that!

The history of caching goes back to the advent of virtual memory in the 1960s and evolved with the growing disparity between processor and memory speed, through the introduction of instruction caching in the early 1980's. By the mid-to-late 1980's, several microprocessors were equipped with 256 byte data caching and grew alongside the weight of kernels, GUIs, hardware, and striping advancements, among others. By present day, it has expanded its role with eDRAM to the likes of 128MB and growing. While CPU cache was gradually expanding, the web was exploding.

Beginning with the first web browser, Nexus (1990), by Tim Berners-Lee, entire industries of information, commerce, marketing, design, and technology (and more) were founded. By date of this post, over 1 billion hosts are served worldwide. As these industries grew, demands for performance grew with it. Bigger and higher resolution screens led to higher resolution graphics and video. Increased dependence upon Javascript led to micro-management of DOM load times, and the list goes on and on. By the early 2000's, an industry of distributed caching solutions (server-side) was born and continues to grow with names like Memcached, Hadoop, and CloudFlare. This brings us to 2017, at which point Chrome's default data cache (client-side) is now up to 1GB in storage and while scores of designers and developers pump out updates for web applications and marketing sites, old data remains and must be destroyed!

It used to be that clearing cache and cookies was a sufficient solution for viewing the most up-to-date assets. As users became ingrained in the variety and addiction of web applications and social networks, the magnitude of re-entering credentials and the arduous 3 step clearing methods became too daunting for the average professional. Enter "privacy mode" or as it's branded today, in Google Chrome, "Incognito Mode".

Developed initially in May 2005, Safari's privacy mode was intended to improve security by protecting its users from storing and sharing their browsing history. The feature caught on to competitor browsers by 2008, flash player by 2010, and soon became a staple of QA practices. The idea was that by opening a new private session, a tester would view a clean session with no relevant cache nor cookies, to automatically view the latest updates, with minimal effort. At first this seemed to work well, as while private sessions weren't truly clean and did store trusted certificates, browsing history was not being recorded, as verified by Stanford University's investigation of Firefox in 2010. However, by 2015, the same investigation determined that potentially thousands of browser extensions were in breach of privacy mode. While this did impact security, it wasn't necessarily a concern for testing the latest updates, so what exactly is the issue?

In the year 2016, Google queries regarding the definition and use of Incognito mode rose an average of 100% from the year prior and tens of thousands of articles questioning the security and efficacy of incognito mode were published. While attempts to educate users on their browsing privacy were addressed, education on how to properly use the tool for testing, was largely overlooked. In my own recent investigations, I've found that the majority of industry professionals are of the impression that Incognito-mode is a cache-less browsing experience, which is a misconception that often leads to false positives when testing updates. At the industry level, this can lead to inflated QA and communications costs, as well as tensions within teams. That said, let's nip this in the bud.

The way that incognito mode works is by setting temporary data such as your history, downloads, cache, and cookies, to a temporary folder. When closing the Incognito window, these files then delete, thus allowing you to view the latest updates (cache-cleared browsing) upon launching a new Incognito window. The first thing to recognize is that Incognito mode is not cookie-less nor cache-less. Once you open an Incognito window, those cache files and cookies are created and will remain until the Incognito browser is closed. Opening new Incognito tabs or windows while your initial Incognito window remains open will not show you anything different, because those temporary files and cookies remain until you close all active Incognito windows/tabs and begin anew. The second thing to realize is that Incognito mode isn't a proxy, your activity is entirely track-able, all you're doing is preventing your browser from storing your browsing history. For example your activity can continue to be tracked by your ISP, your employer, the websites you visit, the browser extensions you use, and so on. This also goes for Google accounts, which can track your history, certificates, bookmarks, and so forth, within your account, despite clearing temporary files. Outside of Incognito mode, there are also a few other factors to consider, regarding caching.

In spite of incognito mode efforts, it's important to remember that your web server has the capability to dictate cache expiration. Apache, for instance, allows expires headers through .htaccess files or Apache's configuration, to allow you to dictate the default duration for file caching and even the length of time that a specific file-type should be cached (ie. JS, Images, HTML, CSS, etc). Your job may be made less stressful by reducing these expiration lengths alongside major updates, in order to ensure that your customers and their visitors are not reporting false-positives. In addition, it's important to consider the history of caching and its evolution to the web. More directly, remember that there may be many forms of caching which are not strictly on your users' browsers. Distributed caching services (ie. Memcached), opcode cache (ie. PHP), NoSQL proxies layers on relational databases (ie. MongoDB), and flat data solutions (ie. Magento) are all caching temporary files for reduced latency. These typically need to be flushed alongside database and backend code updates.

So, what are the main take-aways from this?

• If you're testing multiple frontend updates through Incognito mode, remember to close your Incognito browser and start fresh, before testing a new update or different behavior.
• Incognito mode is not cache-less nor cookie-less browsing. The sooner we professionals understand that, the sooner we can stop misinforming our customers.
• If you're hiding from something... use a proxy, Incognito mode isn't really doing much for you.
• When pushing updates, try reducing the expires headers, temporarily. to keep your visitors viewing fresh assets and content. It may slow down performance for the time being but it'll prevent false positives.
• Don't forget to clear your other caching methods! If you're deploying server-side changes (backend scripting or DB changes), flush your server-side caching methods and test thoroughly, before announcing your work completed

Now that you have the keys to IncogniDO's and dont's, go out there and share the news!