BrowserBoxPro VS libavif

I'm using this type of simple approach to build a SaaS right now. We need to spin up many VPS and provision them, and the fastest way to do that is with rsync and ssh.

But we didn't stop there: this SaaS for our open source browser product is entirely built like this^0: behind the scenes it's a collection of bash scripts that implement and execute the business operation of the SaaS.

So basically, it's a command-line interface to the SaaS. Think of it this way, say I didn't have a website, with login, and "click a button to open a browser", but instead people would write me letters, send me cheques, or call me on the phone. Then I can serve their requests manually, at the command line.

The reason I made it like this was:

- clear separation between thin web front-end and actual business logic

- nice command-line interface (options, usage, help, clear error messages) to business logic for maintenance and support to jump on and fix things

- inheritance of operating system permissions and user process isolation

- highly testable implementation

Maybe this is dumb, but I really like it. To me it's an architecture and approach that makes sense.

I'm sure this is not new, and I think a lot of good quality operations must be built via this way. I highly align with the author's stance of the composition of a few simple command line tools to get the job done.

Perhaps we can call this "unix driven development", or "unix-philosophy backend engineering"

0: https://github.com/dosyago/BrowserBoxPro (saas coming soonish)

If you're concerned about these kinds of bugs on your local OS platform you may consider "abstracting away" your local connection point via a remote browser. This way, whatever your local machine and OS, you can have a dedicated server that you run your browsing through. Granted it doesn't enclose your entire network connection: only your browsing, but what it does there is change your IP address, mask your location, and add protection from browser 0 days.

We're constantly adding new features add BrowserBox to respect and protect privacy and improve the overall experience. It's open source so you can change it how you want too. If you don't like AGPL-3.0 you can get a commercial license. Come take us for a spin: https://github.com/dosyago/BrowserBoxPro

If you don't want something open source, but prefer the joy of a large company I think Mullvad also has their Mullvad Browser which does something similar!

Agree. This is one of the reasons it's better to go with older and more reliable JPEG for viewport streaming. An exploit chain would need to penetrate screen capture images to pass to the client. Browser zero days do occur and this is why it's important to have protection. For added protection consider browser isolation. Check out open source Zero Trust browser isolation at BrowserBox using JPEG (now WebP) now: https://github.com/dosyago/BrowserBoxPro

Technically, we did try using WebP due to its significant bandwidth gains. However, the compute overhead for encoding versus JPEG introduced unacceptable latency into our streaming pipeline, so for now, we're still against it. Security is an additional mark against the newer standard, as good as it is!

Notes

renice: https://stackdiary.com/linux-docs/renice/

audio server code: https://github.com/dosyago/BrowserBoxPro/blob/boss/src/servi...

audio client code: https://github.com/dosyago/BrowserBoxPro/blob/boss/src/publi...

-------

FAQ

What real time prio did you renice to? We tried a few around -16 but settled on -15.

Did you try WebRTC for the audio? Yes, we tried the channel for streaming chunks, but in this case WS was more reliable and faster (I guess it was because we were producing small chunks at a consistent rate). I'm interested in exploring WebRTC audio channel streaming if anyone knows, come and contribute: https://github.com/dosyago/BrowserBoxPro or get in touch at [email protected]

Why are you using WAV not MP3 for audio? Because we're chunking it. I didn't know how you can slice MP3 into tiny pieces for custom ACK-based streaming like we are doing, and I'm not even sure if it's possible: when I tried the MP3 became corrupted, but WAV worked fine, (I guess because it's linear not a compressed self-referential format like MP3). In tests the reduction in bandwidth due to MP3, was somewhat lost to the increase in latency / compute on the server to encode it. If anyone knows a better way to stream audio (or MP3) in this case come contribute: https://github.com/dosyago/BrowserBoxPro or get in touch at [email protected]

People have requested this for years. I finally got around to it. This is a WIP but tested on MacOS and Linux it worked.

Pull the image and follow the run instructions: https://github.com/dosyago/BrowserBoxPro/pkgs/container/brow...

How to Use GitHub Actions and ngrok to Test a Remote Browser, BrowserBoxPro

It's worth noting the following method will work for any web application, it's just surprising to me that it worked with one which uses WebSockets, WebRTC and has a significant back-end component!

I've recently made an exciting breakthrough with my project, BrowserBox, a remote browser application that supports WebSockets and WebRTC. Amazingly, I was able to run and test it successfully in the context of a GitHub Action, even browsing the web as normal! If you're curious about running your own remote browser for testing purposes, here's how you can do it too:

How can you do this yourself?

1. Fork the repo

https://github.com/dosyago/BrowserBoxPro/fork

2. Add your ngrok auth token to your fork's repository secrets under NGROK_AUTH_TOKEN (you need to sign up for an ngrok free account if you don't have one)

3. Go to your fork's Actions page and run the CI action.

4. Wait a couple minutes for the setup to run and click on the URL produced by the "Print ngrok URL" step.

5. Play around with the remote browser! Just click on the big + to create a new tab and enter a search query or an address in the address bar and you're away!

IMPORTANT! I'm not sure if this violates the GitHub terms doing this (it may do! Any GitHub employees please email me at [email protected] and I will remove this Action if it does!), but it's logical that just using this to browse the web would be wasting resources from the Actions runners intended purpose, so don't overdo it! To try to help with this I've set the Action to only run the browser for 5 minutes.

If anyone wants to port this to GitLab or another CI platform, we would very much welcome your contribution!

Anyway, I was really happy and surprised to discover that we can use the generous free compute from Microsoft and GitHub, and the free tunnel from ngrok, to really do some useful things, and you can check up on those and integration test using ngrok and GitHub Actions!

Many comments on here are about this protecting the ad business model, but I think it's actually about protecting against competitor browsers.

If official Google Chrome is the only browser that passes this attestation proposal, you can effectively own the market and prevent new competitors.^0

I'm sure the technical specifics will be slithered over with enough worm-tongue to make it vague and innocent enough to not trigger anti-competitive lawsuits or whatever, but that might still be an option.

From a legal view, isn't this worse than microsoft force bundling IE into its OS? Taken to its full realization, it seems attestation is Alphabet force bundling Chrome into the whole web (that ubiquitous, "global OS", used my almost everyone). It's not there yet, but is it impossible to go from current zero to very-scary one?

As a maker of a competing browser technology (that uses Chrome under the hood), I'm worried about this, but heartened by the fact that as we are also an open-source product, the solution (that I've talked about elsewhere in this thread), if it's possible, will be distributed and built by people.

It's plain that Alphabet faces a conundrum: how do they prevent their investment in the open-source product being used against them? How do they prevent competitors (like brave, and BrowserBox) benefiting from the code Alphabet pays its employees to write, essentially using Alphabet's money to gradually chip away at (or threaten chipping away at) Alphabet's Chrome market share.

I understand the paradox they face, but I don't think "DRM" level control of a global and ubiquitous "means of access" is the way to solve it. But as owner of an open-source company myself, I don't think the solution is one where Google can't capture any value from what they invest in creating.

In terms of the long term economics, I don't have a solution. But I don't think that matters. I think technically there will be solutions to this, and they'll be built in the open.

DOSYAGO is really not an activist company, nor do we seek to be. But some things are worth standing up for. Future of the web should be one, I think. If you'd like to get involved, come on over to BrowserBox and contribute!

https://github.com/dosyago/BrowserBoxPro

0: With a current "monopoly", these new competitors may seem theoretical, but I think internally their viewed as very real threats over the long term. Brave, etc. And the fact that anyone can use Chromium to build a new browser.

> Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22

The graph from Cloudinary uses libaom to do the encoding at speed preset 7 (s7), which is far from speed preset 0 and disables many AVIF coding tools. I do not know why this was chosen by the author, but it does not reflect AVIF performance. According to https://github.com/AOMediaCodec/libavif/issues/440#issuecomm... speed preset 8 loses 20-35% compression efficiency.

It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages?

Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc919033134...

I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3].

[1] -- https://code.videolan.org/videolan/dav1d

[2] -- https://github.com/AOMediaCodec/libavif

[3] -- https://github.com/AOMediaCodec/libiamf

Yep. Keep writing these in C; surely nothing will go wrong.

As far as I understand you are talking about this plugin. I don't know c++ and half of the code was like a black magic, but if I get it correctly, it encodes your images with libavif, and adds custom metadata ([solar/time of day] -> json -> base64).

So a few dozen comments, but so far it doesn't look like any mention the immediate thing that jumped out at me which was the claims vs AVIF:

>"In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format."

Huh? I'll admit I haven't been following codecs as super ultra closely as I used to, but I thought AOM was a pretty broad coalition of varying interests and AV1 an open, royalty free codec that was plenty open source friendly? I've heard plenty of reasonable arguments that JPEG XL has some real technical advantages over AVIF and as well as superior performance is much more feature rich and scalable. So I could see people being bummed for that. But this is the first time I've heard the assertion that it's somehow a Google project? I mean, AOM's libavif reference is BSD too [0]? I'd love some more details on that from anyone who has been following this more closely. I can even understand if AOM isn't as community friendly and an accusation that it's dominated by big corps, but in that case why single out Google alone? From wiki:

>The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent.

Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too.

----

0: https://github.com/AOMediaCodec/libavif

> You have a good point that AVIF layered image items can act like such P/B-frames. Do libavif (or other AVIF implementations if any) make use of them?

Seemingly. As search for "libavif progressive encoding" shows several issues about this, and a search for "progressive" in https://github.com/AOMediaCodec/libavif/blob/main/include/av... shows an enum for avifProgressiveState, appears to show support for it.

I mean, it already has it: https://github.com/AOMediaCodec/libavif/commit/570c42c2c10a878c8cc896f1c5daf1a955274142

Apart from mpv and ffplay, the only software I currently have installed that can play animated AVIF is Chromium. And from what I've read from this libavif bug report, I'm not sure if looping animated files in general is something that's just done by default by a lot of software regardless of whether the file is marked as a loop or not.

The support for progressive AVIF decoding has landed in libavif and in Chromium. But are there any docs on how to create and test progressive AVIF images?

The "for example" is the key here, because AVIF does support multi-layer coding per the spec now (though not currently implemented in libavif from what I can tell).