I worked on this over the weekend. I got all the services (standard BrowserBox services: audio streaming, secure doc viewer, remote devtools service) plus the main browser service to convert to being run as onion services.

Some difficulties were:

- services run on unix ports, but onion expects each service to have its own URL without ports, so a bit of internal plumbing had to be patched to accommodate this so services could reference one another.

- services all require https, but on tor there is no free cert authority that will issue certs (even tho entirely possible and permitted), so my solution was to use mkcert, but provide the rootCA.pem for the installation on an endpoint for download, with instructs on how to import it, for those users who want to get rid of warnings and use audio (tag would not stream source without valid cert even if exemption had been made, it could only be trusted at OS level).

- i agonized over getting the wording right on the instructs, warnings, and guidance for importing a root ca, because it is important, but primarily i knew that people on HN would try to eat me alive if i didn't provide adequate warnings to users about risks.

- audio was a bitch to set up. previously i dedicated much time to finessing the audio streaming (over a period of months, almost a year ago). for ages could not rid the final 1 - 2 seconds of lag. i discovered that primary sources of lag were: encoding to mp3 (i thought that the smaller size would ensure faster streaming and less lag, but actually the additional encoding time required counteracted any gains from lower bandwidth usage. so, paradoxically, wav PCM was the best format; and failing to renice the audio recording process to the correct near realtime priority level. in this set up, i ditched both: simple keep-alive HTTP streamed audio tags (accumulating latency getting out of sync with video); and, streaming chunks on websocket (an improvement, but still the same accumulating latency desync), and webrtc (too unreliable and jittery for audio), and went with websockets sending binary wav chunks with an ack, and a unit length send buffer. the ack ensured we didn't overload the channel, the unit buffer meant we could drop all frames we couldn't get fast. The final finesse was an ack with a value > 1 so that multiple frames could be sent before waiting for a wasteful complete frame><ack roundtrip to get the next frame. This worked great, and was adaptive. So, you can tell, i was very attached to it (after struggling with random 6 - 14 seconds of latency / drift for a long time before implementing the ameliorations above. but, for tor browser, had to ditch all that. why? tor browser doesn't accept web audio, and you need that api to put the chunks back together on the client. so i went with a straight audio tag fed with the latest since time of connect from a keep alive socket. works good! but was tricky to get working. crucially tho, it requires a valid TLS cert, otherwise tor will abort the media loud, and, cabrón, no sound. Doubly crucially, ha, you cannot exempt your way to streaming an audio tag in the tor browser. it's a finicky and fussy beast, and will only accept your finest root level trust certificates.

- 3rd-party cookies. for now at least, many browser will still happily gulp down 3rd-party cookies so long as SameSite is None and Secure is on. not the tor browser tho. oh no, tor browser has other ideas about that. entirely blocked. so my whole fantastic temporary iframe web of token logins yielding cookies that could then be sent with all future requests? done for. at least in tor. so now i do crazy token auth the entire time. there's even, insanely, a token tacked on as an implicit, later to be removed, path parameter, in the secure authenticate proxy i use to deliver remote devtools (which normally is very innocent and accepts connections only over ws, not wss, and always without any auth. naughty native implementation).

so it was an epic 40 hour sprint from friday afternoon through early money morning, the likes of which i have never experienced. but i quite enjoyed my monk like purity, very redemptive, the intense focus and knowledge that i was being driven by, after being convinced by and choosing to commit to assisting, an idea that was ready to be born. how or why it picked me will never know. but it was a fun weekend, for all its austere lack of comforts and endless hours solving problems and creating. i've done sprints before plenty. but never anything like this. this was so different. i only left work for bare minimum. eat, sleep, relieve. and when i physically couldn't work any more i'd take some chill time. So i worked 40 hours out of the 60 in that span. it was crazy. but i loved it.

so that's basically how i cooked all this magic together to bring the very cool and crazy and fun browserbox project (multiplayer embedded browser), together with the equally cool (but way more crazy if u ask me) tor project. together at last. it truly is an idea that wanted to be born.

and it was coming full circle for me because, when i first started browserbox 5 years ago, the first customer to reach out to me asked about tor, and tails, and socks5 and OSes on USB sticks. and all this crazy jazz that went over my head at the time. i thought tor was just for perverts and criminals. so i avoided it. and i thought this guy probably was, too. but maybe he wasn't! or maybe he was. but eventually recently i realized how cool and important tor is (it came from and is funded by the us government, crazily, and i suspect they probably use a hardened fork in their internal parallel private secret military internet. i suspect that might be basically tor+, but who knows? no i, right now for sure.), anyway, i began to think that perhaps tor could be used by real legitimate customers as well. and more than that, there just seemed something undeniably cool about it. the tech, to not need DNS hostnames, to hide the location, to protect the traffic (except at exit, which is why you still need tls), to basically create this massive, uniquely addressed...blah blah etc. it's pretty cool. and i have now unified browserbox with tor.

i am very proud of myself for doing that. and i felt so satisfied when it was done. and i'm happy to post it here for all to share. particularly cool and notable about this is it is a "live demo" in the sense that all you need to do to get your own copy of BB running as a tor hidden service right now, is put the repo on GH somehow (fork, generate, or clone into private ~~ and not give me the fork stats ya bastard haha :)), and hit the Issues Page -> New Issue and pick the right issue template (name is obvious), and Submit New Issue. This will trigger an action (all GH account get 3000 action mins a month, UIAM), which will set it ALL up for you. It will then post your login link complete with bonafide onion address in the comments of that issue. Advantage of priv repo is you can hide your login links (but maybe priv repo mins cost? shrug don't know).

Anyway, y'all enjoy and be safe. have a good one! :) ~Cris :) ;p xxx ;p