The Case of Ad Blocking: From Manual to Automatic
Before everyone had AdBlock Plus installed on their copies of Firefox, we had to engage in a variety of methods to block ads. The transition from these methods to the passive method of AdBlock Plus parallels the innovation that I advocate in private browsing.
Before AdBlock with automatic updating of regular expression lists maintained by third parties, we relied on several types of hacks. First, hard-coding the hosts file with URLs and IP addresses of known ad servers. Second, blocking images based on standard ad height-width sizes. Third, manually right-clicking on ads that made it through these filters to remove them.
These methods require action on the part of the user in each case: writing the hosts file and making sure to update it manually, removing any false positives or error-causing entries; working around false-positives produced by blocking images by size; and, manually removing ads.
What AdBlock Plus pioneered was 1) fine-grained control and 2) passive functionality.
Using regular expressions allows for finer ad-targeting than more brutish and broad brush blocking schemes. Ads from subdirectories or subdomains from certain IP addresses can be blocked. Directory names (e.g. "/ads/") can be blocked. And individual sites can be whitelisted.
But the most important aspect is that AdBlock is passive. Once installed and a block-list provider is chosen, the user no longer has to think about ad blocking. No action is required and no updates need to be manually retrieved. Because the lists are externally maintained and automatically updated, most of the false positive testing and correction is done by others and then propagated to all users.
Private Browsing's History
The problem with current implementations of private browsing is that it is either not fine-grained or that it requires active user intervention, sometimes both.
First, utilities or browser features would offer the ability to wipe one's personal data: history, downloads, cookies, sessions, cached files, passwords, and so on. If you visited pornographic sites, you would have to wipe out all of your data. You'd lose all your other data that was saved for convenience: your browser history for URL completion, site-specific preferences stored in cookies, cached files for speeding up performance, saved passwords for email and perpetually-dying-collaborative-media-websites.
Second, browsers developed "private browsing" modes. These would preemptively prevent the browser from keeping the above personal data as long as private browsing mode was activated.
The first method was both broad brush and required active intervention from the user. Not only would it wipe data indiscriminately, it also required the user to remember to clear their tracks after viewing http://www.hardcore-gay-amputee-interracial-midget-porn.com. The second method was a slight improvement: as long as you remembered to turn it on, and you didn't do any non-porn browsing during the session, it did not indiscriminately destroy your data. Still, it requires active user intervention to remember to turn it on each time they have the urge, and to turn it off once they're done. However, since "private browsing" is modal, you are prevented from casually looking at porn amongst your plethora of open tabs. Indeed, Firefox 3.1b2's hideous implementation of private browsing is extremely modal, hiding all other non-private open tabs and opening an entirely new window for private browsing. Your non-private tabs are hidden until you manually exit from private browsing mode.
Google's Chrome provided a third innovation in private browsing: being able to set each window's mode individually. This solves the problem of modality. Now you can browse porn while reading several articles from The Atlantic and writing an email to your great aunt about the pictures of the kids from Easter. Nevertheless, per-window privacy settings still require active user intervention to turn on and off.
The Next Stage for Private Browsing
Just as ad blocking moved toward finer-grained control over blocked content and passive modes of blocking and updating, so too must private browsing implementations make the same progression.
What will this look like? Well... an awful lot like AdBlock Plus actually.
It would use an automatically updated list of adult websites (or possibly using the Google SafeSearch API), checking the sites you visit against the list. (This functionality is essentially the same as the Firefox/Google malware protection feature.) If the extension found a positive match, the website's URL and other metadata would not be written into Places/History, downloads would not be written into the download manager, elements of the website would not be cached, passwords entered would not be saved, and meanwhile cookies and sessions would be sandboxed and then erased. Further, bookmarked adult sites would not show up in the AwesomeBar.
Such an extension would solve the problem of indiscriminate data destruction: by having an accurate list in advance, only known adult sites would be prevented from being stored in your browser's history. All of your other browsing would function normally. There would be no need to actively intervene to switch modes on or off. You would never forget to switch modes, leading to embarrassment or the need to wipe all your private data. As such, the problem of creating a passive system would also be solved effectively.
This type of private browsing is the future of the concept, at least as applied to pornographic content viewing. It will not help you if your aim is, of course, merely to shop for surprise gifts for your loved ones, unless those gifts are butt plugs and edible underwear.
Various options might include: blocking only results form appearing in the AwesomeBar, full blocking of adult websites from appearing in history and other private data, and probably a whitelist in case of false positives.
Now all that remains is finding a technically savvy forum in which to propose this, such that people who can actually write code will whip up an alpha.