Clearly we’re talking about browser exploits in this particular line of comments, not privacy, and with exploits so defined Chrome is far superior to FF.
Most people here who use a Chrome based browser would almost certainly use a Chromium derivative anyway, like Brave.
You could've re-read the thread before posting such an obviously false comment.
Here's the first mention of privacy and security in this thread:
> I think firefox focusing on performance, customization, and security/privacy is smart.
I also heavily disagree with your view that spyware has nothing to do with security, and your extremely narrow view of what counts as security exploits. The Chromium specific APIs are riddled with security issues as I mentioned in my other reply.
Security and privacy are not the same thing, nor are they directly related. Lack of privacy can literally be designed into a secure system, which is one way of describing how Chrome works. It doesn't really matter how you choose to esoterically define the words if everybody else's meaning is different.
When people talk about Chrome being secure, they're talking about the browser's resistance to being compromised by a third party. It's that simple. Nobody cares that you have some esoteric view whereby Google's inherent lack of privacy protections, wherein Google is able to collect information about the user through their browsing habits, is also part of the browser. That is a matter of privacy, not security, and Google very clearly sets out all the ways it collects information about the user in its various policies. Security relates to whether third parties - using the browser architecture itself as a conduit - are able to compromise the browser in such a way as to obtain or manipulate user information, data, or elements of how the user interacts with the system, in a way that is not approved by the user and about which he is likely unaware. Every user of Chrome agrees to Google's collection and use of certain data, and ergo such data collection does not involve security issues whatsoever. That you might disagree with Google's privacy policies is not to the point. Note that if the aggregated user data were to be surreptitiously accessed by a third party, this WOULD be a security issue - but that isn't what we're talking about, is it?
If talking about security, Chromium has been the most secure browser for at least a decade. Safari and Firefox are significantly worse at security than Chromium browsers are. That's not really debatable - just go look at results of the various hacking contests, look at the number of active exploits and how long they are in the wild and unpatched, etc.
On privacy, Firefox is undoubtedly better, although Mozilla has had snafus over the years. Mozilla also literally makes something like 99% of its revenues through agreements it has with Google search, so go figure.
One final note - as has been the case for at least 15 years now, Firefox with uBlock Origin and NoScript and a few other addons are probably the most secure you can get, albeit at significant cost to usability and convenience. When discussing security I think it's inherent that people are discussing the vanilla, out of the box install of a browser. Having said that, I currently use Brave and find it to be the best mix of features of Chrome without the rest of the Google privacy problems; despite being a very long time Firefox user, it just isn't good enough these days, although if Google succeeds in killing adblockers in Chrome I'll have to move to Firefox regardless.
Good day.
> Note that if the aggregated user data were to be surreptitiously accessed by a third party, this WOULD be a security issue - but that isn't what we're talking about, is it?
But we are talking about third parties gaining access? The mentioned Web APIs are intended for use by third parties. It's not even aggregated user data, but individual ones.
WebUSB made it possible to work around Yubikey phishing protection [1]. WebMIDI allows websites to overwrite device firmware, which is a dangerous capability that could result in a sandbox escape [2]. Granting a website WebNFC permissions makes it possible to read TOTP tokens stored on Yubikeys at any point later on [3], which is worrying because ordinary users can't possibly deduce that from permission prompts. Battery Status API was heavily abused for fingerprinting when by the time it was removed from Firefox [4]. I'm amazed that you dismissed that as a "hypothetical" concern, because if anything, it's the legitimate uses of the API that was hypothetical [5]. Uber used it to "inflate Uber prices for desperate users with low batteries." [5] [6].
But one don't even need theses examples to see how bad theses APIs are. Hardware are mostly designed to work with local applications. To expose them to websites is a fundamentally flawed idea. Google justifies them by adding permission prompts each time a problem emerges, but users can't possibly be expected to be fully aware of the consequences of allowing raw hardware access to websites with mere dialogs that they blindly click through.
And oh I wish there were only 3 bad APIs like you hinted. There are more than that. WebMIDI, WebNFC, WebSerial, WebHID, Generic Sensor API, File System Access, Low-level Sockets API, Network Information API, and the list goes on.
These aren't isolated examples. It's part of a broader pattern where Google ships an anti-feature, asks for "feedback" which means nothing because "devs already depend on it," and "standardizes" it despite opposition from the remaining browser vendors [7] [8].
I’ll judge browser security based on a broad set of examples rather than a cherry-picked one every time.
[1]: https://www.wired.com/story/chrome-yubikey-phishing-webusb/
[2]: https://github.com/mozilla/standards-positions/issues/58
[3]: https://github.com/mozilla/standards-positions/issues/238
[4]: https://www.cs.princeton.edu/~arvindn/publications/battery-s...
[5]: https://groups.google.com/g/mozilla.dev.platform/c/5U8NHoUY-...
[6]: http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low...
[7]: https://github.com/mozilla/standards-positions/issues/459
[8]: https://twitter.com/rich_harris/status/1220412711768666114
At this point I can only assume that your conflating of security and privacy is pathological, and I very much doubt that we can have a fruitful discussion about this.
example.com wants to
Control and reprogram your MIDI devices (SysEx)
[Block] [Allow]
I am so glad both Apple and Mozilla doesn't subscribe to you or Google's definition of "security." These gaping security holes can cause so much damage, and to see these as "features working as intended" shows how disconnected you are with actual users. A browser should never ever include capabilities for full system compromise as one of its features. No permission prompt should ever let that happen.
You also need to consider the inherent danger of exposing hardware to websites when considering whether permission prompts are adequate. Again, hardware aren't designed with the expectation that they'll be exposed to websites. Browser vendors can't possibly be aware of the security implications of doing so for every device out there either. That was one of the core arguments of my previous reply and I wish you hadn't omitted that. Unfortunately, my point about the permission prompt was taken out of context and spun into a "pathological" view that "everybody in the world besides myself" would laugh at.
Lastly, you might want to actually look at the examples I posted. Some of them don't involve permission prompts and enables attack by third parties. Which I believe to be a security issue even under your terms.