Privacy Browser Android

I agree that technically the referer is of no value, but some websites do require it being enabled for CSRF on certain login pages, and payment sites, so that is why I do suggest a whitelist approach allowing for root domain referer forging...

I would consider that such exceptionally poor web design that it would rise to the level of a bug in the website that should be fixed by the web developers instead of being worked around in the browser. Especially because referers can easily be spoofed by a malicious client without any way for a web server to verify, so anyone who is using it as some sort of security check should permanently be banned from developing anything that touches the internet.

There may be something in the future that changes my mind, but as things currently stand I will completely remove referer functionality from Privacy Browser as soon as that becomes an option for me.

Again I agree...totally retarded design...but Amazon authentication is a prominent example at least in my experience...https://www.amazon.com/gp/navigation/redirector.html

As an example of warnings about totally blocking referers without using a whitelist option for select sites, is in the main Chrome extension which offers this functionality (Referer Control) https://chrome.google.com/webstore/detail/hnkcfpcejkafcihlgbojoidoihckciin which states in its configuration interface "if blocking referers by default, and this includes blocking not only of 3rd party referers, but also 1st party, some sites may stop working!"

While referers are totally useless from a security perspective, and not of any value at all really, if you can't authenticate to a major website without referers (often forged ones work well), users will not use your browser, and switch to something else which either "just works" or offers sufficient flexibility. I think offering as much flexibility, modularity, and configurability to users, while warning of the potential consequences in the interface is the best policy...of course you could argue that power users who want this could just edit the source and compile the browser themselves, but I think encouraging users who aren't going to recompile to actually learn and understand their browser, and to offer flexibility to them is of value...

I know this is totally off topic, but you might want to check out what Daniel Micay is doing with Vanadium/GrapheneOS (https://grapheneos.org , https://github.com/GrapheneOS, https://github.com/GrapheneOS/Vanadium). He has mentioned use of https:// github.com/bromite/bromite as a reference (which I personally don't think offers much configurability/privacy despite its claims) for Vanadium. I don't know if it interests you, and whether Micay would necessarily be either, but given GrapheneOS (the successor to CopperheadOS) from my experience is a great start for a hardened AOSP ROM, it would perhaps benefit both projects if you maybe approached him or checked out what he has been doing to harden Chromium, but again it is just a thought! (sorry again for this part being off topic)

The most important thing I am trying to do with Privacy Browser is to change the accepted behavior of how web pages interact with web browsers. Let me give you a couple of examples.

1. Privacy Browser does not allow mixed content (loading an HTTP resource from an HTTPS base URL). There is no way to modify this behavior. This breaks a few websites, but it is a bug that they should fix. There is never any good reason for a website to use mixed content.

2. Privacy Browser currently defaults to having JavaScript disabled, but it is possible to enable it. This is because too much of the web breaks when JavaScript is disabled, and because there are a few useful things JavaScript can accomplish that currently are not possible to do otherwise. In the medium term, when I get access to fine grained JavaScript controls, it will be possible to enable some JavaScript controls while disabling others. At that point, I will probably completely remove some of the more egregious JavaScript functions that have no purpose but to invade the privacy of users. In the long term (perhaps 20 years), I would like to see JavaScript completely disabled.

3. Privacy Browser has the ability to block all third-party requests, but it is disabled by default because it breaks even more of the internet than having JavaScript disabled. It also currently considers all subdomains as not being a third-party request. At some point in the future, I intend to enable blocking of third-party requests by default, and have an additional option to block all requests that aren't an exact domain match. Perhaps there will come a point where all third-party requests are blocked and there is no way to disable it.

All of this involves redefining what is acceptable in web development in order to redesign the internet so that privacy is baked in. It is a long term project that I will likely spend the rest of my life fighting for. Along the way, I am willing to break access to some web sites, even big websites like Amazon.com. When an organization wants to invade a user's privacy to that degree, they out to have to go use a different browser to do so.

Regarding Bromite SystemWebView, you might find what I have written at https://www.stoutner.com/geckoview/ interesting.

The main reason I suggested checking out Vanadium was more for the code hardening and hardened compiler flags including ASAN, fstack-protector-strong, etc that Micay applies to Chromium as opposed to the privacy enhancements, at least for the moment, but he is supposedly going to work on this so I thought there might be some ideas or inspiration there, especially on the code hardening and compile side.

Regarding referers, I see what you are saying, but then again, I feel like the swiss army knife argument also has some value...I'd rather be able to just send forged referers to Amazon which doesn't impact privacy at all since it is just sending a referer of "amazon.com" (you could probably even just send a blank referer so long as you have the header) (of course Amazon does sell user data and shares it with CDNs, governments, etc in bad ways, but all ecommerce sites seem to and I'd rather use Amazon than eBay or Alibaba/AliExpress) and Amazon actually doesn't require JS right now which is sort of rare, let alone a phone number (cause when you have to give a phone number, given SS7 and its successor's issues and the business of selling data extracted from these protocols (large tech probably already have direct access), you are basically giving up your location in real time).

Amazon uses the referer header to help track users as they move around the site, even if they are not logged it.