Years ago when the web was young, Netscape (Google it, noobs!) decided on its metaphor for the browser: it was a “navigator”.
The logo and imagery borrowed heavily from the metaphor of navigation, really coming to the fore with the release of Navigator 2.0, but continuing — with some brief interruptions — late into its product life.
I’m not a sailor, but I always took the lines in the various logos to be a reference to the craft of navigating by star charts. Images of maps and lighthouses also made appearances. I know the name and the brand was likely the work of some ad exec, but I’ve always liked this idea — the browser was supposed to make uncharted waters navigable. It wasn’t just a viewer, but an instrumented craft, guiding you through a sometimes confusing seascape.
So what happened? It’s a serious question. Early in the history of the browser various features were introduced that helped with navigation: bookmarks, bookmark organization, browsable history, omnibar search, URL autocomplete (which ended up eroding bookmark use). Icons showing when a connection was secure. Malicious site blocking. But as the web developed, the main focus of the browser wars ended up being less the browser as a navigation device and more the browser as an application platform. The interaction designs and renderings browsers support still advance year over year but the browser as a piece of user-focused software stalled decades ago. Mobile use, with it’s thin, crippled UI, just compounded that trend. Extensions were proposed as a solution for extensibility, but the nature of them just served to further impoverish core development. (Hat tip to TS Waterman who has been exploring extension-based solutions to this stuff, but it needs to be in core).
I think it’s time for the browser to put navigation of the information environment back at the center of its mission. Here’s some simple things that could be offered through the interface:
Hover for the original photo source. One of the most useful tricks in Chrome and Firefox is the right-click search for photo, which allows users to find original versions of photos fairly quickly and see if they have been modified. It’s a clunky process but it works. A hover function over a photo that tuned search to find the original (and not just “related photos”) could bring this practice into broader use.
Site info: Browsers expose some site info, but it’s ridiculously limited. Here’s some site info that you could easily provide users: date domain first purchased, first crawl of URL by Google or archive.org, related Wikipedia article on organization (and please financially support Wikipedia if doing this), any IFCN or press certification. Journal impact factor. Date last updated. Even better: provide some subset of this info when hovering over links.
Likely original reporting source: For a news story that is being re-re-re-reported by a thousand clickbait artists, use network and content analysis to find what the likely original reporting source is and suggest people take a look at that.
Likely original research source: For a scientific finding that is being shipped all over the internet with a thousand explosive and absolutely wrong hot takes, surface what looks like the original journal source. If an article talks about many findings, produce the best possible list of sources referred to in the article by looking at links, quotes, and names of quoted experts.
Likely original data source: when you see a statistic, where’s it from? What’s the original context? What public stores of data are available?
OCR images, and do all this for images too: A lot of disinfo is now in the form of images.
OCR that text on the image, and make the same features available. What is the “Possible research source” of this? And if it tells me “Research source not found” is that a problem?
Related Sites: In what universe does this site reside? Alternet, Breitbart, or National Geographic? What links into this page, and do those links in confer authority or suggest bias?
There’s actually a lot more they could do as well. If you want, you can read the newly award-winning book Web Literacy for Student Fact-Checkers, look at each verification process described, and ask “How could the browser make that easier?” Most of the things in there can be relatively easily automated.
Boost the Antibodies
I get that such features will often break, and sometimes expose wrong information about source. Basically, the Google snippets problem. And I get that most people won’t use these tools. But my model of how this impacts society is not that everyone makes use of these tools, but that the five percent of people who do create a herd immunity that helps protect others from the worst nonsense. We can’t make every cell invulnerable, but we can boost the antibodies that are already in the system.
It’s also true that his should be done at the social media platform level as well. And in apps. I’ll take it anywhere. But it seems to me that browser providers are in a unique position to set user expectations around capabilities, and provide an interface that can deal with misinformation across its life cycle. It could also push these tools into social platforms that have been reluctant to provide this sort of functionality, for fear of dampening “virality” and “engagement”. Plus, the sort of users likely to fight disinfo already hover over links, look for SSL indicators, and use omnibar search. Giving them more tools to make their community better could have an outsized impact on the information environments we all inhabit. My work has shown me there are plenty of people out there that want to improve the information environment of the web. Isn’t it time we built a browser to help them do that?
5 thoughts on “We Should Put Fact-Checking Tools In the Core Browser”
I love this, and I think if you’re not already working with Tristan Harris, you should be! Build the ethics (here: misinformation watchdog) into the tech itself. Yes, and yes!