> An obvious one, getting an explanation from the vendor / upstream before we proceed to any decision.
I'd already addressed that. In fact you quoted it when you posted your condescending reply. An explanation is worthless if the code cannot be reviewed. Such a feature should either be opt-in and/or open source.
I couldn't care less what explanation Google give, I just don't want this built into my browser.
> It's normal to have a collection of patches in the package file / port.
It is, but then you're relying on your package maintainers to patch Chromium (or compile the software yourself). Thus personally I think it's easier just to use another browser which doesn't need to be patched to remove an unwanted feature.
An obvious one, getting an explanation from the vendor / upstream before we proceed to any decision.
Vendors do tend to care about us.
> 1. fork Chromium and remove the closed components
It's normal to have a collection of patches in the package file / port.
> 2. use another browser > 3. moan on the internet
Issue trackers (such as one in the aforementioned posts) allow attachments / patches. They tend to be constructive.