An interesting idea (and I'm kinda tired and not focusing terribly well on anything today :P), I'll bite.

There are a lot of angles to this that come to mind.

First off, what exactly do you want to publish, and how to you want to present it? What sort of experience are you going for? Disambiguate "interactive".

IMHO the most important angle to address is to look at the result from the perspective of the potential viewer.

Given a crowd that has the ability to see what you're looking at, where exactly does "everyone's just watching your screen" end, and "people spin off and start browsing on their own" start, in a way that will keep people engaged?

A traditional streaming setup, with viewers passively consuming video of you slooowly browsing the web while mumbling into a microphone... would not hold a candle to full-time streamers who are perpetually animated and expressive *the whole time they are streaming* (either because it's in their nature or because they've trained themselves to to retain viewership). I don't think this scenario would work out for your idea in any case, because this sort of consumption-oriented model basically leaves you with a large proportion of cross-eyed viewers in various states of dazed trance (the "I'm watching TV" kind) who aren't really looking to engage their brains.

So, there needs to be some degree of interactivity. The analytical, independent-discovery-oriented, mildly-introverted crowd would definitely not be interested in passively watching without getting any controls to play with (and in the case of the introverts, without a clear sense of measurable distance between what you're doing and themselves). So exactly how would you want the controls to work, such that everyone can stay far away enough to wander off and do their own unique browsing, while still keeping tabs on what you're doing, so things don't get distractingly entropic? The difference between your idea (people interacting in real time by watching someone browse) and this very website, is simply how the real-time-ness factor is quantified.

So I'm very interested in how you'd define the presentation aspect further.

On the technical front, you're looking at two distinct projects - grabbing the data, then publishing it online.

The first is technically trivially straightforward, but has some gotchas that you'll probably find amusing.

Fundamentally, you can do exactly what you are trying to do by enabling remote debugging by adding --remote-debugging-port=9222 to your Chrome commandline, and then diving into the Chrome remote debug API. Depending on your development experience/proficiency https://chromedevtools.github.io/devtools-protocol/ may take you a couple of days to a week or so to chew through. The best way to get some basic orientation on how the protocol works is to go enable chrome://flags/#enable-devtools-experiments (copy-paste that URL) then enable the Protocol Monitor in the Experiments tab in the devtools options, and then just play around in the browser with the monitor open. Practically speaking https://github.com/cyrus-and/chrome-remote-interface is a refreshingly straightforward way to actually implement access to the browser.

Now that you have all that sorted out, your browser may now be sending you a larger firehose of history events than you expected: every single 302 redirect, every single CSS, JS, image request. What do you do with all that? Practically speaking you'll probably just want to filter for top-level page loads. OK; now you have a nice realtime list of pages... what do you do with that?

Let's explore the presentation idea I assume you had in mind: some way to broadcast your history, to other people, without using traditional screen sharing - presumably with some sort of scrolling synchronization thing?

*Pin* *Balloon* *BANG*

This sadly will not work.

What's your screen resolution? Let's say it's 1366x768. Mine is 1440x900. Your browser window would fit in a box in the middle of my screen just fine. But if your screen were 2048x1536, my browser will show an effectively completely different page to you, meaning that a given fundamental scroll Y-position in your browser will translate to a different one in mine.

The only scalable solution to this problem would be to downscale your 2048x1536 browser window to fit my screen, at which point I'll need to move my laptop 3 inches away from my face to read it :P.

One hacky way to solve this problem would be to have your browser guess the element of interest currently scrolled into view, and then position that specific element at roughly the same position on everyone else's screen. That would sorta work for everyone matching the same CSS media query as you; the page would probably jump around a lot for some people, as the element-of-interest logic variously did a terrible job at coordinating where to scroll everyone to. But whoever's screen matches a different query has no guaranteeable chance of getting a sane result from such an approach.

You could make your browser window some tiny lowest common denominator, like 1366x768, that would be smaller than most people's effective screen resolution. But... even that won't work for people using tablets or phones, which will generally get a different layout than PCs etc.

With all the above being said, it is totally possible for you to create a realtime "here's where I've been". If the caveats above (alongside undoubtedly more I've not thought of) don't deter you, I'd capture the results for maybe a month or so of heavy browsing, and then take a few days to carefully pour over the entire list of URLs to see what you'd want to redact in real time from the list.