ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel
  • »
  • Technology»
  • Internet & the Web

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

Updated on February 13, 2017

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!

Comments

    0 of 8192 characters used
    Post Comment

    No comments yet.

    working

    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: "https://hubpages.com/privacy-policy#gdpr"

    Show Details
    Necessary
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
    Features
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Marketing
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Statistics
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)