Attached: 2 images
I have no idea why people use #Chrome. #Firefox looks so much better, and their theme actually works! Even their hidden compact theme looks perfect, the padding around elements is always the same... meanwhile Chromium uses tons of different shapes and they are all incoherent and the padding is off.
Apart from the fact that Firefox is #efficient has core components rewritten in #rust and supports #wayland for way longer.
#Librewolf is a perfect addition to Firefox, I highly recommend to use it!
A little admiration of how easy UI customization is on Firefox, and how shitty Chromium looks.
Firefox shipped sandboxing on Android years ago (before chrome) and then removed it. I’m not sure you gain much from it on Android. It eats up ram making performance crap on cheap phones and apps already run in their own app user context to isolate what they can access.
If you’re referencing an isolatedProccess implementation, the benefit is that each site is isolated in its own process, and any exploit would only have access to its own process (the data that the site sees anyways) without further escape (kernel exploit or meltdown, for instance). Without this isolation flag, sites are not sandboxed from each other or from the browser’s process itself, meaning an exploit could access any data from any other active site or from the browser’s process (such as accessing browser settings, bookmarks, history, or the built-in browser password manager). This has a massive implication on security. I’m unaware of the sandboxing you mentioned before Chrome, so I can’t comment on that, but you gain a lot of security from proper per-site process isolation. Yes, the app lives inside its own sandbox, but there’s plenty of data within that sandbox that you may not want a site to access, hence the importance of the isolatedProcess flag.
Firefox shipped sandboxing on Android years ago (before chrome) and then removed it. I’m not sure you gain much from it on Android. It eats up ram making performance crap on cheap phones and apps already run in their own app user context to isolate what they can access.
If you’re referencing an isolatedProccess implementation, the benefit is that each site is isolated in its own process, and any exploit would only have access to its own process (the data that the site sees anyways) without further escape (kernel exploit or meltdown, for instance). Without this isolation flag, sites are not sandboxed from each other or from the browser’s process itself, meaning an exploit could access any data from any other active site or from the browser’s process (such as accessing browser settings, bookmarks, history, or the built-in browser password manager). This has a massive implication on security. I’m unaware of the sandboxing you mentioned before Chrome, so I can’t comment on that, but you gain a lot of security from proper per-site process isolation. Yes, the app lives inside its own sandbox, but there’s plenty of data within that sandbox that you may not want a site to access, hence the importance of the isolatedProcess flag.