Web-Environment-Integrity VS BrowserBoxPro

Repo has be archived - "NOTE: This proposal is no longer pursued."

https://github.com/RupertBenWiser/Web-Environment-Integrity

[2] - https://github.com/RupertBenWiser/Web-Environment-Integrity/...

I think the best issue raised is: Why would I, as a user, want this?

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

There were proposals for protecting against this in the WEI explainer under "Open Questions" https://github.com/RupertBenWiser/Web-Environment-Integrity/...

The Web Environment Integrity is yet another Google proposal for making the web worse for everyone but them.

Point me to anything which would give websites access to that information via WEI. There is nothing. I have seen nothing except FUD. Aside from that, this only attests for the device. Ad-blockers can be external. This does nothing for external ad-blockers.

Explicit non-goals for WEI:

"Enforce or interfere with browser functionality, including plugins and extensions."

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

That also applies to Javascript, or being forced to use some form of an up-to-date browser. What is different with WEI?

I didn't see many people debating the actual text of the WEI explainer[0] on the HN posts about WEI, and that's probably because they were links to articles about WEI. The HN post for the explainer with the most upvotes only has 89[1], likely because most of HN treats the upvote as "I agree/like this" instead of "boost this topic for discussion".

0: https://github.com/RupertBenWiser/Web-Environment-Integrity/...

1: https://news.ycombinator.com/item?id=36785516

> If you don't want my browser to render content as it sees fit, don't serve the content over a protocol where that dynamic is inherent.

to play the devil's advocate, this is why google proposed the WEI (https://github.com/RupertBenWiser/Web-Environment-Integrity/...). Be careful what you wish for...

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

I stopped reading after the explainer’s intro section. The first example is making it easier for websites to sell adds (lmao) and the other 3 are extremely questionable whether if the proposed remedy even helps. And it’s presented as a benevolent alternative to browser fingerprinting, as if we must choose between these two awful choices. It’s an absolute joke of a proposal.

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...