Recent searches
Search options
What a browser privacy policy should look like:
We acknowledge that your use of the browser is purely an interaction between you and the sites you explicitly attempt to connect to by following links or entering URLs, and does not involve any third parties unless you have explicitly added extensions to make it so.
We acknowledge that your settings are chosen by you to protect your privacy and accessibility needs, and will not attempt to override them with updates.
We acknowledge that attempting to subvert your privacy configuration through updates, either ones delivered through automatic channels you have opted in to or via publications indicating that an update is important to your security, constitutes unauthorized use of your computer and may be subject to prosecution (such as under the US CFAA).
...
@dalias what browser do you use now that Firefox has had its ‘don’t be evil’ moment?
I got librewolf yesterday
@theearthisapringle @dalias I am probably switching to LibreWolf as well, although with some reservations.
* it's dependent on firefox for upstream development
* the switch/transfer process from firefox is awful. Well really, it's nonexistent.
**edit**: Also, there's no mobile version. Desktop only.
@swordgeek @theearthisapringle @dalias I’d avoid downstream forks of browsers unless they have a record of pulling updates from upstream within days of upstream updates.
@alwayscurious @swordgeek @theearthisapringle I'd do the opposite. If they're just pulling everything immediately from upstream, they're not vetting changes and they're vulnerable to whatever latest shenanigans upstream pulls. Responsible fork is triaging upstream changes between critical security/safety, desirable new functionality that can be merged on relaxed schedule, and antifeatures that will be new difficulties in future merge conflicts.
@dalias @swordgeek @theearthisapringle The problem is the security patch gap. If one diverges too far from upstream then one risks not being able to release security patches in time.
@alwayscurious @swordgeek @theearthisapringle This is really a problem in philosophy of security fixes I've written about in detail before. It's harder to work around when you don't control upstream's bad behavior, but it should be possible to mitigate most security problems without even needing code changes, as long as you can document what functionality to gate to cut off the vector without excessive loss of functionality.
Most browser vulns are fixable with an extension blocking the garbage feature nobody asked for.
@alwayscurious @swordgeek @theearthisapringle For example "I'm vulnerable to WebRTC vuln attacks from the one Jitsi site I've allowlisted for a few weeks until I upgrade browser to a well tested new version" is far less exposure than "I'm always vulnerable to whatever new antifeatures and undocumented new attack surface Mozilla adds and pushes as an update".
@dalias @swordgeek @theearthisapringle In that case the safest option is to run the browser in a tightly sandboxed VM, so a browser exploit is not game over. That’s what Qubes OS does.
@alwayscurious @swordgeek @theearthisapringle That doesn't really help if all your valuable data is in the browser (e.g. a session token for your hosting control panel with logged in consoles) and the host OS is just there to host the browser... 
@dalias @swordgeek @theearthisapringle that’s why you have different VMs for different websites 
.
@alwayscurious @swordgeek @theearthisapringle Yes, that's a very viable model but the browser engines and window managers aren't well tuned to those workflows. Massive resource over usage & navigation difficulty.
If I ever do my dream browser, it will be built around the idea that you have a whole isolated instance per site & that offsite links always open in a new instance.
@dalias @swordgeek @theearthisapringle I think the HP Sure Click Secure Browser comes close to that. It’s sadly the only viable model with present browsing engines.
A partial solution is to use a mainstream browser (like up-to-date Chromium) for work that needs to be secure (like managing web hosting) and something else in a VM (ideally Tor) for general browsing.
@alwayscurious @swordgeek @theearthisapringle I don't really see it as a "sadly". The norm is that applications working with complex data from different privilege domains should run in different execution privilege domains.
Browsers just kinda evolved from simple low attack surface document readers to application platforms, and at the same time political norms against malicious behavior disappeared.
But in what they are now, it absolutely makes sense to put them in their own execution privilege domains. Not the fake way FF & Chrome do where there's still shared context with all the secrets in it. But entirely isolated.
@dalias @swordgeek @theearthisapringle For web compat postMessage() still needs to work for PayPal, as does ??? for Google. Might make sense to just hard-code those services as special-cases for legacy reasons, though.
@alwayscurious @swordgeek @theearthisapringle Not hard code but explicit user allowlist.
@dalias @swordgeek @theearthisapringle That’s fine if users are prompted to add sites to the allowlist as needed. Otherwise users just experience stuff breaking and have no idea what they need to do to fix it.
Also postMessage() is fully compatible with using a different VM for each site.