Chromium Doesnt give your Freedom of Modifications
Chromium has chrome://flags which is similar to about:config. For the example mentioned, there is the #legacy-tls-enforced option.
Distribution of Adobe “Pepper” Flash Player proprietary plugin
Chromium hasn’t shipped with Flash for a long time.
Chromium reduced capabilities to plugin with adblocker
The goal of manifest v3 is not to neuter ad blockers. It allows content filtering in a more secure way while also not allowing extensions to spy on users extensively. It doesn’t kill ad blocking - it only provides a safer way of doing it. Manifest v3 removes the legacy webRequest and replaces it with declarativeNetRequest.
Besides, this hasn’t even been implemented yet and likely won’t be for a long time. Other browsers will probably follow suit too. For example, this is how it already works in Safari.
Chromium: secretly stores referrer and URL for downloaded files
Chromium: unconditionally downloads binary blob
These are bugs that were fixed.
Questionable Chromium Privacy
Chromium has some telemetry by default but it can all be disabled in the settings. By default, it’s actually less invasive than others like Firefox.
Google Chrome and (weird) DNS requests
This isn’t weird. It improves page load time and is a standard thing that’s done in other browsers like Firefox. It can also be disabled.
Also, most of Brave changes are just altering the defaults of already configurable settings or resolving fingerprinting issues. There isn’t any telemetry they disable that couldn’t already be done by changing some of Chromium’s settings.
When Chrome is started it will lookup domain names for previously opened web pages early in the startup process so if the user clicks on one of those links Chrome can connect to the target site immediately. This is part of chromium/chrome design [12] [13].
madaidan reply:
This isn’t weird. It improves page load time and is a standard thing that’s done in other browsers like Firefox. It can also be disabled.
https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections
I have modified chromium comparison of chrome://flags to about:config:
For both examples mentioned, Chromium has the #legacy-tls-enforced option to disable legacy TLS ciphers (disabling legacy TLS ciphers is not useful anyway [1]) and has a more robust WebRTC IP handling policy to mitigate its privacy risks. WebRTC isn’t that big of an issue anyway. VPN clients can choose not to allow WebRTC traffic. It’s only leaky clients that have this issue.
[1]: Browser automatically choose the strongest TLS version that the website supports to connect to it. Disabling TLS ciphers, if anything worsens security. If a website only supports TLS 1.1 and you disable it, it will fall back to HTTP which is less secure. The only actual reason to do this is to push websites to switch to newer versions but this will only work if it’s done on a global level (i.e. Chrome and Firefox disable them by default). A few users disabling them won’t do anything. It could be useful to better prevent MITM attacks but only when you also enforce only HTTPS connections which is rarely done.
about:config has more settings than chrome://flags, sure but can you give any practical examples? The majority of them aren’t useful for the average user and are only used in incredibly niche situations.
I guess the threat model @nurmagoz might have in mind here are TLS downgrade attacks. Suppose an adversary could break TLS 1.1 but not TLS 1.2.
(This is supposed to be a timeless argument. I.e. please don’t concentrate on 1.0 or 1.1 vs 1.2 etc.)
There used to be downgrade attacks where an MITM can force downgrade such as from y.y to x.x.
By disabling TLS 1.0 in theory before major browsers disabled TLS 1.0 by default one might have dodged such a downgrade attack?
Not necessarily.
Server side caused breakage: Website might even break since it does not allow non-https, http connections.
Browser side caused breakage: HSTS (preload) - if set up by that website - might also prevent non-https, http connections.
I guess the main motivation by @nurmagoz might not be to force websites to but to increase personal end user security? It might prevent a (at this time) unknown TLS1.3 to TLS1.2 downgrade attack. Thereby connection to that server might be more secure.
legacy-tls-enforced option is about TLS version (TLS 1.0,1.1), im
talking about TLS ciphers SHA1,SHA256…
webRTC is leaky to the internal IP address even with Tor doesnt matter
what kind of protocol you gonna use. (if you search the internet for
what options should disabled in the web browser first one you gonna see
is webRTC. And i know there are workarounds for that like disabling JS
with noscript or use extension but that doesnt solve the main issue i
was talking about)
Despite that to not go into separate discussion of the usefulness or not
of disabling/enabling these options the concept is still valid that
chromium restrict or doesnt provide freedom of modification similar to
firefox.
Modern TLS versions prevent downgrade attacks in the protocol itself.
Downgrade protection: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack (see [BBFGKZ16], Definitions 8 and 9).
I guess an argument could be made about downgrading from TLS <1.3? I’m not sure if those versions have downgrade protection.
SHA isn’t cipher, it’s a hash function. Newer TLS versions don’t support old ciphers or hash functions. By dropping legacy TLS versions, you are dropping legacy ciphers.
Again, VPN clients can choose not to allow WebRTC traffic. It’s an issue present in a few VPN clients, not the browser itself. Besides, Chromium has robust safeguards against this.
Who cares that Firefox allows you to modify X random setting that nobody is ever going to use? Chromium isn’t worse just because it doesn’t bombard the user with thousands of settings that 99% of people are never going to use anyway.
SHA isn’t cipher, it’s a hash function. Newer TLS versions don’t
support old ciphers or hash functions. By dropping legacy TLS versions,
you are dropping legacy ciphers.
The option #legacy-tls-enforced in chromium doesnt disable TLS 1.0,1.1
they are still active despite activating it, it just enforces not to use
them. In FF they are totally disabled when choosing not to read that.
weak ciphers as: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ,
TLS_RSA_WITH_AES_128_GCM_SHA256 … cant be disabled within chromium and
there is no option to do that. Can be done through FF.
Who cares that Firefox allows you to modify X random setting that
nobody is ever going to use? Chromium isn’t worse just because it
doesn’t bombard the user with thousands of settings that 99% of people
are never going to use anyway.
Well it add a layer of control on the behavior of the browser even you
can disable JS readings from websites without the need to add new
extension (cant be done in chromium)…etc This is freedom,Control that
Chromium misses simple as that.
Neither of those are “weak ciphers”. AES-128 is still perfectly fine. Those examples aren’t the strongest cipher suites but that doesn’t mean they’re “weak”. They have never been broken.
Screenshot of Chromium with #legacy-tls-enforced enabled:
The WebRTC IP handling policy I mentioned earlier. It exposes multiple options on how to handle WebRTC connections, with the most strict being disabling non-proxied UDP.
JS can be disabled on Chromium via Settings → Site settings → JavaScript. It’s actually much easier, robust and more user-facing than anything in Firefox. It supports per-website rules and you don’t even need to go to chrome://flags.
It’s still not very useful for the average user. You have yet to give a single example that has a practical application.
Neither of those are “weak ciphers”. AES-128 is still perfectly fine.
Those examples aren’t the strongest cipher suites but that doesn’t
mean they’re “weak”. They have never been broken.
the weak problem is with the SHA, and weak doesnt mean broken because
thats going to be insecure.
Screenshot of Chromium with #legacy-tls-enforced enabled:
on my end tried it with chromium over debian doesnt block it, better
test on debian/kicksecure environments.
The WebRTC IP handling policy I mentioned earlier. It exposes
multiple options on how to handle WebRTC connections, with the most
strict being disabling non-proxied UDP.
oh but thats unrelated to the case im talking about disabling it
completely.
JS can be disabled on Chromium via Settings → Site settings →
JavaScript. It’s actually much easier, robust and more user-facing than
anything in Firefox. It supports per-website rules and you don’t even
need to go to chrome://flags.
ah so flags doest represent or has access to all options.
It’s still not very useful for the average user. You have yet to give
a single example that has a practical application.
Who talked about average user useful for him or not? doesnt matter, what
matter the controlability/freedom space of modification thats the only
point i raised.
There are more issues with those cipher suites than just SHA-1 (e.g. the first one uses CBC, the second one has no PFS, both use smaller AES key sizes). I still wouldn’t call it “weak” or say that it deserves to be disabled though. It’s not going to be realistically attacked currently.
I get the exact same result on both Arch Linux and Whonix/Kicksecure/Debian. You’re likely doing something wrong.
It’s not unrelated. This option does disable it.
No, and that was never the intention. Everything you’ll need will be in the ordinary settings or flags.
And that doesn’t really matter. Nearly the entire user base is going to be unaffected so it’s a weak point.
