Implement a feature to modify HTTP Headers (natively) in Brave [Feature Request]

[ghost]

I know this is an ambitious Feature Request to have it natively in a browser like Brave, because it might be seen as 'security risk' by some, but I think it would be good to add a natively solution to modify the Response and Request Headers right inside the browser.

Of course, it should be labeled FOR ADVANCED USERS ONLY. But for example, there is this is issue by @antonok-edm #25586 to allow users to load custom Scriptlets, which would be in the same level of 'risk' and meant for advanced users only, so there is no reason why 'security risk' should be the reason not to consider a feature like this in the future.

Inssman, Requestly or Modheader are great extensions to do this and get inspiration from.
For example, I like what Inssman offers; it is simple in the interface, and that means it is meant for advanced users, because you have to set things manually, unlike Modheader, which gives you suggestions and makes things too easy for anyone to mess it up, Inssman is just an input bar and manually type it all.

The problem with extensions is that they often affect Browsers performance, plus more extensions equals more fingerprinting, and biggest issue is how Brave on Android doesn't even support extensions, which means you can't even install these extensions there.
And for what I understand, it would be cheaper to add a feature like this inside Brave like you did with the Adblocker, than adding and maintaining full Extensions API to Android, making native features a better option.

The most important thing about a future like this is that it can help improving more Privacy, while the term Privacy is not perfect, a feature like this can help in many situations.

• First Simplest case: User-Agent

Right now, if you want to use Bing Chat AI, they will force you to use Edge Browser to be able to use it, and that means a lot of information will be sent to Microsoft when opening Edge just for using Bing Chat AI.
Changing the User-Agent HTTP Request header, is easy, but can only be done natively through Devtools, which means any change will be removed when closing Devtools.

And just like Bing Chat AI, many other websites will require you to use the whatever Browser they want you to use based on the User-Agent, of course, since Brave used the same User-Agent as Chrome, maybe the issue is less seen, but some people want to use Bing Chat AI and other services like that which will require you to use the browser they want you to use, taking away the freedom of Browser choice people should have.

I already made a Scriptlet to set any User-Agent I want, and it works just by using ##+js(user-agent, example) though using Object.defineProperty(navigator, 'userAgent'{} and Object.defineProperty(navigator, 'appVersion'{}, but since it is JS it will never do the job like replacing the User-Agent in the HTTP Request Header.

It still works in websites like Outlook to stop Outlook from telling me I should switch to Edge because "it is a better Browser", and now I only get promotions for OneDrive and how I can get Microsoft 365, etc etc.

So, modifying the User-Agent through Javascript, will not work for Bing Chat AI, or in those "What's my user-agent" pages or anything like that, making the adblocker useless for that.

• Second and more complex and better case: Cookies

While the adblocker can set and remove cookies, it uses JS to do it (not a surprise), which is problematic for two reasons.

1. JS cookies will be limited to be set for 7 days by default by Brave (Limit JS set cookie lifetime to 7 days #3443).
2. Adblocker(s) with Javascript, are limited, if the Cookie has the HTTPOnly attribute (https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie#security)

The HTTPOnly cookie attribute can help to mitigate this attack by preventing access to cookie value through JavaScript. Read more about Cookies and Security.

So, there are some cookies that are impossible to be removed by JS, because they have the HTTPOnly attribue or because they get set repeatedly, so even if you use the Cookie-Remover scriptlet, it will never do the job proerly.

A good example about a cookie that tracks users, store the information in their server and users have no control about it, can be found in Youtube.

If you go to Youtube and open Devtools you will see there is a cookie named VISITOR_INFO1_LIVE, which acts like an account for unlogged users to track watched videos, and give the progress bar from them and give you recommendations based on videos you watch, just like if you were logged. You can even go to https://www.youtube.com/feed/library and reset your history and search history, the only thing is you can't see videos you watched like a logged user would.

The problem with that cookie should be obvious, the information is stored in Youtube servers and you have no way to control it, that means that if you used Private Windows or deleted Youtube cookies, all the watched videos would be left in Youtube servers through that cookie, orphaned or harvested? we won't know, but unless people delete the History, there is no way to know control that once it is set.

To test this:

1. go to www.youtube.com in private window to make sure the user data is new.
2. go to Devtools -> Application -> Cookies
3. change the VISITOR_INFO1_LIVE to Xta_14dAx1s
4. now, visit this Youtube Playlist Link

Result:?

You will see how this playlist had watched elements you obviously never watched, because the whole history is based on that little Cookie, you can delete every other cookie or storage item and database and you will always see that playlist with watched videos, like if you were logged.

So the cookie is there, tracking users, which yes, can give suggestions and nice feature if you don't have a youtube account, but the information is not stored local, and there is no way to stop it, unless you remove that cookie!

Now, the problem is that the Cookie being set by youtube is that it has the HTTPOnly attribute. So, if you try to do a document.cookie="VISITOR_INFO1_LIVE=;domain=.youtube.com;" or or use the adblocker for that, it will not work, the only way to manipulate it through JS is to uncheck the HTTPOnly in Devtools.

This whole thing can be fixed easily by using Set-Cookie as a Response Header with the value: VISITOR_INFO1_LIVE=; Domain=.youtube.com; path=/; Max-Age=-1 and that will remove it, while giving a blank value so Youtube can't use it at all to track users on what they watch, especially if they use InPrivate windows to watch a video and don't care about suggestions or recommendations or watched videos or anything, because it will be gone once the Private window is closed.

This means that implementing a way to modify the HTTP headers can allow better ways to improve Cookie notices removal and other privacy concerns that will benefit every user and not just the advanced ones like me who want to modify a header to allow advanced things without the need of extensions.

[ShivanKaul]

We discussed that this would be a great adblock feature to have, so we can specify and modify request/response headers for specific websites. I created an issue here: brave/adblock-rust#306. We also decided that it would be a lot of effort to have extension-like UI for this, and an advanced user could use adblock rules anyway.