Chromium’s influence on Chromium alternatives
6 October 2024 | 3:40 pm

I don’t think most people realize how Firefox and Safari depend on Google for more than “just” revenue from default search engine deals and prototyping new web platform features.

Off the top of my head, Safari and Firefox use the following Chromium libraries: libwebrtc, libbrotli, libvpx, libwebp, some color management libraries, libjxl (Chromium may eventually contribute a Rust JPEG-XL implementation to Firefox; it’s a hard image format to implement!), much of Safari’s cryptography (from BoringSSL), Firefox’s 2D renderer (Skia)…the list goes on. Much of Firefox’s security overhaul in recent years (process isolation, site isolation, user namespace sandboxes, effort on building with ControlFlowIntegrity) is directly inspired by Chromium’s architecture.

Interdependence for independent components can be mutually beneficial. For something to be part of Chromium, it needs to build and test with a battery of sanitizers and receive continuous fuzzing. Mozilla and Safari do something similar. All benefit from libraries getting patched to meet each others’ security requirements. Without Google, Mozilla and Apple must assume responsibility to maintain these libraries to a browser-grade standard.

I see many advocates for Chromium alternatives say the Web would be better without Chromium. That may be true, but Chromium alternatives may also be worse.

For completeness: Firefox and Safari’s influence on Chromium in recent years includes the addition of memory-safe languages, partitioned site storage, declarative content blocking (from Safari), and a vague multi-year repeatedly-delayed intent to phase out third-party cookies. Chromium would be no better off without other browser projects.


Post-OCSP certificate revocation in the Web PKI
25 September 2024 | 3:29 pm

OCSP, including OCSP Stapling, is leaving the Web PKI. Here's a complete look at revocation beyond OCSP: its past, present, and possible futures.

Lose-able keys are a feature
13 September 2024 | 12:30 am

In opsec, duress (“rubber-hose”) attacks are famously hard to address. Cryptographic keys that cannot be lost have poor protections against duress.

Travelers can leave key fobs at home should they be accosted. A victim of a break-in can conveniently “lose” or smash a hardware key, erasing any encrypted data. Yes, I know about cold-boot attacks; I don’t recommend at-risk people to leave things decrypted for long durations. I like the idea of spring-loaded key fobs that can’t be left plugged in.

People talking about key fob body implants don’t usually plan for removing them in seconds with plausible deniability.



More News from this Feed See Full Web Site