Apple adds a tracker blocker to desktop Safari(techcrunch.com) |
Apple adds a tracker blocker to desktop Safari(techcrunch.com) |
Uhhh, not really. Even if the behavior is unwanted, the web will not "behave" the same - otherwise the feature does nothing.
There is no option to turn off phoning home to Apple in Apple's pre-installed operating systems. Every user of iOS is constantly pinging Apple servers all day every day.
Connect an iOS device to the internet and watch the network. The user is given no control over this. All users are assumed to need Apple's help setting the system time.
The networking functionality of NeXT/Apple's operating systems is based on open source BSD operating system code.
But BSD does not phone home to some organization when you install it. Why not? Surely Apple's approach is the best one for all users, right?
It is amusing to watch these companies proclaim they will block others from tracking and serving ads while continuing to siphon user data themselves, often in ways that are all but transparent to users. Apple can block everyone else, then I can block Apple. OK by me.
Someone in this thread made some comment about Microsoft Edge not tracking users. Do people seriously believe nonsense like that? MS was dumping debug output via DrWatson to the network long before collecting user data for profit was even a strategy.
Connect a Windows computer to the internet and watch the network. All on by default. Unlike Apple, they have no prepared explanation/justification why they need to do this.
And even if they did, who cares? Users prefer not to be tracked. Companies are admitting they know this.
Users could opt-in to tracking if they believed they were getting some benefit.
But that is not how this game works. There is no "opt-in". It is on by default. There was no intention to make tracking a "choice".
Probably because companies know what the choice of users would be and it would not be favorable to the company.
But that is not something we are allowed to discuss.
I suspect you'd have fewer down votes (and thus perhaps some discussion) without this. Congratulations on the self-fulfilling prophecy.
Apple Pay does something called tokenization, and the goal is more fraud protection than privacy. It generates one new number at card enrollment and uses that exclusively. By using a unique account number which can only be issued by Apple Pay devices, it means it doesn't matter if someone hacks the merchant and steals your number. They can't use it without the associated Apple Pay generated cryptogram, secured by your PIN / fingerprint.
Honestly the enhanced security of Apple Pay is underhyped. It's really great.
Maybe it is magical in the American sense, but i can't say i get the big whoop from the European side of the Atlantic...
Recently too I've noticed that Amazon is putting ads in my Instagram feed for specifically things that I've looked at on Amazon within the last day or two. I'll literally click a link to a book or do a search, and then four hours later it'll show up in an ad in the app.
Aside from being kind of pointless (I already know about these items, why are you showing them to me later that day?), it's also all kinds of creepy and unsettling to see Amazon advertising six things I've seen recently, and not even on the same device I was viewing them on.
It would be really cool if it generated new numbers each time and had an amount coded to that number. So when I wave my Apple Pay device over the reader it would display the amount on the device, I would approve, and then a number would be handed back that's only good for that amount.
But would you rather see ads for something you might be interested in (however tangentially) or something completely random? Personally I prefer the former, as long as there is some basic sanity filtering involved.
Does this mean browser fingerprint is somehow scrambled before it is sent to the tracker instead of blocking?
It might be homogenized instead of scrambled. Every iOS device could be given (barring IP etc.) the same fingerprint.
1. Search Google for hockey sticks
2. Click on search result hockeystick.com
3. hockeystick.com issues a 302 to adcompany.com which then issues a 302 back to hockeystick.com
Why the 302? Because in Safari, you could only access cookies in a 3rd party context if you've seen a domain in a 1st party context. Setting a cookie in adcompany.com in a 1st party context gives you the ability to read that cookie in a 3rd party context which could be used for tracking purposes.
website.com
ad.com?u=website.com
website.com?loaded
They're just being a little sophisticated in how they block third-party cookies. This will hardly stop other tracking scripts, tracking images, widely-used fingerprinting techniques and related js calls. So nothing remotely close to even Brave let alone a TOR or the Epic Privacy Browser.
This blocks more than just cookies by the way, it affects all client-side state. And client-side state is still the primary and most reliable tool used for tracking, even though other methods exist, such as browser fingerprinting, behavioral fingerprinting, and IP-based tracking.
So Google may lose data because then they can't track you all over the web, but the websites don't because they still see you as one user.
I say this as someone who does a lot of analytical research and re-targeting and would be hurt if this was rolled out on a larger scale; I just don't think I have a right to the data.
> segregate the _cross-site_ scripting data
So if you "just want to quantify your traffic", use self-hosted Piwik (i.e. not cross-site), as many of us do already.
> Siri now suggests searches in Safari based on what you were just reading. And when you confirm an appointment or a flight on a travel website, Siri asks if you want to add it to your calendar.
Search for "Smarter about you." on this page: https://www.apple.com/ios/ios-11-preview/ Looks like it's done on the device though, End-to-end encrypted with your other devices.
It makes me wonder how many publishers at national newspapers and magazines are even aware of what’s going on.
As in 192.168.0.2o7.net. Remember, "SWF" stands for Small Web File. Yes, they actually tried to get users to swallow this when Shockwave Flash started to be used in devious ways, such as to track users.
Omniture's business is third party tracking cookies similar to Google Analytics or KISSmetrics. Not sure and don't care whether Flash is used so much anymore. If too young to rememeber search and ye shall find information about "permanent, Flash cookies" that could not be removed.
Apple is not saying "We will not engage with companies selling third party tracking cookie services." Clearly they are not opposed to third party tracking cookies in principle.
Instead they are announcing some change to their browser. Wow, exciting. It is not clear what exactly this announcement accomplishes for users. Probably nothing. If you are trying to avoid ads and tracking, popular browsers (without extensions, etc.) are not your friends.
Then we have a problem where the industry is reliant enough on CDN's that browsers can't simply block access.
That being said, and I've never used Cortana or Alexa, but I hear they're pretty decent compared to Siri.
https://arstechnica.com/tech-policy/2017/03/isps-say-your-we...
> CTIA is the main lobbyist group representing mobile broadband providers such as AT&T, Verizon Wireless, T-Mobile USA, and Sprint.
It doesn't just represent them, Apple is also a member:
It's like Mozilla can't even embrace its privacy stance fully.
> We believe these additions will help us take the next step toward shipping Tracking Protection in Firefox beyond Private Browsing Mode. Look for that study in late 2017.
[1] https://en.wikipedia.org/wiki/Do_Not_Track#Internet_Explorer...
[2] https://en.wikipedia.org/wiki/Do_Not_Track#Effectiveness
[3] https://techcrunch.com/2017/06/05/apple-adds-a-tracker-block...
While this is flexible, open, and that's all good, the lack of a common sense default and a multi-step setup process is probably why like... even I am not using this right now.
If Apple does this by default, it's gonna make a huge dent in Google Analytics' numbers, whereas probably almost nobody uses the feature in IE.
* Safari SB policy: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit2/...
* Chrome SB policy: https://cs.chromium.org/chromium/src/content/renderer/render...
And of course, that's before we get into more complex forms of isolation that Chrome implements, such as the sandboxed GPU process, or ongoing work into things like network sandboxing, the macOS bootstrap sandbox, and site isolation (origin-bound renderer sandboxing).
Another thing Chrome does out of the box that Safari doesn't is U2F.
Still another is Chrome's industry-leading TLS management, including the pioneering of HPKP and the Chrome/Firefox pin list, and the aggressive policing of the WebPKI CAs.
I've been pretty aggressively terse in this thread, because I didn't even realize this was a live argument anymore. Safari is simply not as secure as Chrome, and it's less secure in ways that are meaningful to normal users.
Again: iOS, different story.
If you add these things up, the difference in practical effectiveness is not as wide as one might think.
edit: they're fixed now
One specific area where Safari is better than Chrome is in private browsing mode. In Safari, each tab is completely separate, and the cookies aren't shared (as far as I can tell) whereas in Chrome, it's only separate as a whole "private browsing session." They each have their pros/cons but I prefer Safari's model.
https://medium.com/@justin.schuh/securing-browsers-through-i...
Then try to work back either Edge's or Chrome's approach to security to specific Safari features and design.
The Chrome security team is probably the most sophisticated software security team in the industry (lest you think I'm in the tank for Google, I'd say the iOS platform security team is a close 2nd --- and, to be clear: Safari is a different story on iOS).
Chrome may be relatively decent at preventing a webpage from compromising your OS, but in the modern era, a compromised browser is as bad or worse anyways, since that's where most of your sensitive activity goes.
While many HN readers will know to avoid the perils of this crud, I don't feel Chrome can be recommended over IE6 to the wider Internet while this remains so commonplace. Safe use of Chrome requires constant vigilance.
In light of Chrome's issues, I feel like a claim that switching to Chrome is important for security to require an exceptional evidence of vulnerability in the other browser.
Or is it just assumed to be an easy target/too niche/no money from Apple?
Test your browser: https://panopticlick.eff.org/
I found this one rather interesting, it was the most unique of the ones listed:
HTTP_ACCEPT Headers
One in several thousand have the same headers as me. But the headers themselves are quite a small little string, I'm surprised it is that unique.
Why isn't this illegal already?
Admittedly being out of battery is a hard problem, but I chose my phone partly because it has decent battery life.
Two, if "faffing about" is your concern (thank you for that expression by the way, i'm going to start using it), pulling out a card is not really much different from pulling out a phone. But the Apple Watch supports Apple Pay, and that way you don't have to pull out anything. It's really convenient.
If you're wondering how it works securely with the watch, it's pretty smart. You unlock the watch with a PIN when you put it on. It senses when you've removed it from your wrist, so it just stays unlocked until that point. Therefore all Apple Pay purchases are PIN authorized without having to prompt you for it or a fingerprint. All you have to do is wave your wrist by the terminal and confirm.
So, not only can a single merchant track you, but all merchants can cross-reference the data they have about you and track your whereabouts, purchasing habits etc. They just don't know who you are anymore, because that information is not transmitted. Unless one merchant asks for your email or home address, and this merchant then adds that email to a shared database, at which point we're back to step 1 and the merchants know everything about you.
Honest question. I'm not logging anything about my websites' visitors on principle, so I don't have insight into that area.
I don't intent to provoke FUD, I seriously don't know. This would sound like rational choice for Google since they need this data to run their business.
[1] https://support.mozilla.org/en-US/kb/settings-privacy-browsi...
I love contactless payment, and this occasional complication doesn't cause enough trouble, but it's still really annoying because I'd expect exactly what you describe to be the case.
Anyway, If they're pro-privacy, it would also make sense for them to raise hell about the group they're part of for some other reason is arguing that browsing data shouldn't be considered private, of all things.
"As someone who investigates lots of crimes, it's totally fine if someone invokes the fifth amendment, I don't have the right to compel them to answer."
"I mean if you don't care about something prevents you from doing your job, why even join the force?"
The whole "Do Not Track" default thing was, of course, a huge fiasco, as Google and others chose to ignore IE's default usage of it.
According to another comment you work on the Chrome team. So unlike most everyone here, you're actually in a position to fix one of the two options.
So yeah, the seat belt policies alone aren't determinative, which is why I called them "a rough analog". And it's hard to say what gets pulled in through warmup (which is why we'll be eliminating it with our v2 bootstrap sandbox). Accepting that, it's pretty clear that there's just dramatically less attack surface exposed from inside Chrome's sandbox versus Safari's.
You're right that separate GPU process is a huge advantage for Chrome. Kudos on that, and we'll likely have to move in the same direction sooner or later.
Audio/video capture is temporary and not in currently shipping Safari. It was just the simplest path to getting WebRTC up and running. We plan to fix it before we ship. I agree with you that it's risky attack surface.
Also agree with you that we expose more mach services and for lots of them it would be better not to expose them. A tradeoff here is that Chrome (as I understand it) provides most of those facilities via brokers that are often not sandboxed themselves. It used to be many of those things were just done by the application process.
I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.
FWIW, Chrome's network stack doesn't live in the content process either. It's not currently sandboxed, but it's in a process that has no scripting runtime or other dynamic content, so it's still pretty high bar for exploit. The exact reasons for the current situation have to do with some legacy Windows support that has since been removed, which is why the sandboxing work is now moving forward. So, I definitely appreciate your situation with adding some sandbox exceptions for WebRTC.
> I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.
Fair. But I will say that Chrome being cross-platform tends to naturally push us in the direction of eliminating sandbox attack surface. Our supported platforms just differ so much that it's easiest to lock down the OS as much as possible and implement narrower, origin-bound capability brokers inside Chrome. If I were more tightly bound to a given OS implementation, I expect I'd have a lot more fights about sandboxing, because it's easier for devs to just standardize on what the OS gives you.
Is the money that lobby groups works with organized in such a way that Apple's money doesn't go towards this particular thing? If not, what does "not supporting that stance" even mean? That they outsourced their fight for it, so that they can have the nasty outcome and stay morally pure, that as long as there is some bending over backwards possibility of Apple being against it, they're against it?
> There are a lot of members of CTIA,
Apple is a giant, not just one member among hundreds. If they are quiet on this, it has their support. Or are you saying they might not even be aware? Just didn't find it important enough to scream bloody murder about it? No matter how you try to spin it, can you spin it into something really good?
> and CTIA presumably lobbies for a lot of things, not just ISP privacy rules.
Unless you're meaning to say the also have a part of the budged for lobbying for the opposite of this effort I can only ask "yes, and?".
Very unlikely, since almost nobody uses desktop Safari.
Apple’s Mac sales have doubled since 2008 and is in the top 5 when it comes to PC shipments: http://www.asymco.com/2016/11/02/wherefore-art-thou-macintos...
Shipping ~30 million Macs a year certainly isn't almost nobody.
[0] : https://www.netmarketshare.com/browser-market-share.aspx?qpr...
As I said in one of my comments, it's a bit janky to set up because you have to select one of the Tracking Protection Lists from their add-on gallery to turn it on, there's no default list pre-selected.
On our end, it's natural to sandbox every new process we introduce, but also easy to fudge what is allowed in sandbox profiles. Sometimes we have a choice of accessing a service through a separate process, or working to make sure that service itself is more secure (sandboxed itself, offers thinner and properly validated IPC interface, etc). In many cases, the real right choice may be to do both. As well as fuzzing the heck out of every IPC boundary.
Complaining about losing data is in no way the same as assuming entitlement status or forcing someone to do something. The job of a police officer is to enforce laws, and exercise human judgement. The issue with the fifth amendment would be handled by lawyers in courts, not by the officers on the ground. IT jobs have completely different parameters. The comparison with police officer is entirely irrelevant and as such I don't want to continue that discussion.
But that doesn't affect iOS, because you can't install fonts on iOS.
Custom fonts can be installed via custom configuration profiles[0], which is what some font applications do[1]
I'm not sure if this is exposed via Safari or not, so it could still be a moot point.
[0] - https://developer.apple.com/library/content/featuredarticles...
Alternately: why not anonymize CSSOM return values? Your browser might have access to OS fonts A+B+C, but if your JS asked the CSSOM about the size of characters on the page, the answer it would give would come from an "alternate world" where the browser only has access to the web-safe fonts, and so is using one of them.
Unfortunately the Chrome security team can't provide the kind of security I care about - security from Google's tracking.
If that's true, then I'd rather go down fighting (no matter how futile that is) than willingly give up any more private information to Google. I think the time for pragmatism when it comes to privacy is long over.
Were any of you even aware of the information? I looked at that list out of curiosity, and was surprised to see Apple. I was less surprised to see others, but Apple did surprise me. Not as surprising as the pathetic reaction here so far, but still surprising. And I don't take Apple seriously since the 1 button mouses, you know? I still believed their "privacy in our walled garden" stance, it's not like that required flattering them.
> the tech company with the best track record for privacy
I simply never bought into the premise that I have to pick among the presented turds. At that level of size and desire to be a middleman just to be a middleman, they're all trash sadly, and if you think criticizing one means bolstering the others, that's your outlook, another premise I don't share.
ETA: we'd appreciate info about specific info wrong with Safari's sandboxing. We are definitely looking to improve it.
This subthread is about the sandbox so I'm not sure why you threw in "and anti-exploit features". I'd probably say without qualification that Chrome has better memory corruption mitigations.
I hoped you might have concrete feedback on what aspects of our sandbox we should shore up. We have our own ideas but of course an informed outside view would be valuable.
You then, unprompted, create a comparison of all the major browsers again with no citations or supportive reasoning.
It's all very strange.
For a specific example, it's more pleasing to split a long line of text in a way that all the split lines have roughly the same length - "a a a b b b" -> "a a a\nb b b". But CSS only gives you one way to split lines - as much text as possible in all but the last line and whatever's leftover in the last line - "a a a b b\nb". This means a renderer library has to be able to measure the width of text to be able to insert linebreaks itself.
Changing line-lengths will cause odd bits of layout breakage, so just giving bogus results as if rendered with a different set of fonts won't work properly either.
Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
This a totally custom, self-compiled build--and there is absolutely no reflection of that in the UA. Also note that the Mozilla/5.0 and Gecko/20100101 fields are frozen and are only there because sites break if they're not there.
Is there a reason why you don't have auto-update enabled in your browser?
Also, auto-updaters don't apply updates right away, so as long as you're not a few versions behind the latest, you will blend into the crowd.
* Browser
* Browser version
* OS
* OS version
* Machine architecture such as x86, x86-64, or ARM
* User locale
* IP address
* DNT flag
Example:
Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2979.0 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.10 Safari/537.36
Mozilla/5.0 (iPhone; CPU iPhone OS 10_0_1 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/14A403 Safari/602.1
Safari on iOS obviously has significantly higher market share on mobile and the intelligent tracker blocking is part of iOS 11 beta.
Pretty sure you should read the remainder of the comments and see which person is having trouble understanding everyone else.
Looking at the conversation as an outsider, it seems to me you are the one who have things backwards.
But do Chrome's protections also protect you equally from intercession by Google? I just want to clarify this point in my mind.
I'd say yes, unless Chrome has specific backdoors for Google. If that was ever discovered, I'd imagine a huge shitstorm happening.
I think we disagree who to really worry about. I worry more about persistent low-level corporate surveillance more than hacker attacks because while the latter is more acute and can cause great financial harm, the former is whats going to damage my freedom and right to privacy once the government decides it wants to firehose all that data.
This is the same stuff Apple asks for permissions on.
Microsoft doesn't let you turn off telemetry data entirely. Things like hardware configurations and installed drivers are still send, albeit anonymously so that Microsoft can better support the OS.
Again Apple does something similar. Spotlight and Safari send data back to Apple even when you're making queries against other services (e.g. DuckDuckGo Searches). And like Microsoft, there's no UI to disabled it.
Spotlight and Safari send anonymous data back that is parsed and separated so that it can't be used to identify the machine, user, or account that they came from. That's wildly different from the MS approach even after all the changes made on MS's end.
I understand that Apple has publicly disclosed how they anonymize data and roll identifiers but Microsoft hasn't so you really can't say if telemetry data can be tied back to a user or not because you don't know.
Cortana can also be disabled by quickly deleting or renaming a file somewhere, after killing a process. Specifics can be googled.
The same goes for Apple's collection mechanisms.
How would you compare Safari's anti-exploit technology (allocator hardening, Javascript engine hardening, &c) to that of Chrome? Do you think you do anything better than Chrome does on that front?
It would be easy to get the impression that you're trying to shift the burden of proof and move the goal posts. Despite this, I will try to assume good faith.
I think you original post gave the impression that Safari either has no sandbox, or has a wildly ineffective sandbox. You didn't directly state it, but at least some users understandably took away that implication. I think this is inaccurate and unfair.
One piece of evidence we have is grey market prices for end-to-end Safari exploits (with full sandbox escape). By this metric, breaking out of our sandbox on Mac or iOS is not trivial, and is at least comparable in difficulty to Chrome or Edge on Mac, Windows or Android. On the flip side, it seems to be significantly easier to get inside-the-sandbox remote code execution in Safari if you go by market prices, hacking contests, etc. That's something we're working on. Chrome and Edge definitely have materially better mitigations here (as I said in my earlier post).
And finally, to answer your question: One small way Safari has better sandboxing is the we sandbox our network process (something that Chrome is still working on).
I think if you create a breakdown of all the facets of browser security, it will look something like this:
Isolation: Chrome > Edge | Safari > Firefox
Anti-Exploit: Edge > Chrome > Firefox > Safari
UX: Chrome > Firefox > Safari > Edge (U2F, password manager)
TLS: Chrome > Firefox > Safari | Edge
Library Security: Chrome > Edge > Firefox > Safari
If you want to add privacy controls here, you'll get an easy win for Safari, but privacy isn't security.
You're close to this stuff though, so if you disagree with any of these informal rankings, or think I've got the rankings wrong, please correct me.
I don't know enough about the full spectrum of security technologies in all the browsers to have an informed opinion on your rating scorecard, but some thoughts:
Your assumption is that browser security is (only) a platform problem for Apple is wrong. If that was true, we wouldn't have dedicated sandbox profiles for the WebKit content process and its various helpers, which are much tighter than the system default app sandbox on both macOS and iOS. All, macOS has significant system-level defenses, though obviously not as strong as iOS.
Safari and Chrome both use the same underlying OS facilities on macOS to implement their respective sandboxes, so I don't think it's right that "Chrome's sandboxing is specific to Chrome itself" to any greater than Safari's (or really, WebKit's). It's also not more fine-grained. My understanding of the Chrome sandbox model is that their ideal is to deny everything, based on designing around the very coarse grained mechanisms in Windows. The macOS/iOS sandbox model is intrinsically built around fine-grained permissions, and Safari grants more of them to our content process. So if anything Safari's sandbox is more fine-grained (but I am not sure this is an advantage).
On the scorecard itself:
- It's really hard to compare sandboxing technologies across platforms. My vague impression is that Safari's is stronger than Edge's and macOS Chrome has perhaps a small overall edge over macOS Safari in terms of effectiveness. I'm also not totally sure you can even do a linear ranking. For instance, only Edge puts their JIT outside the content process, but I am not sure this means they have the strongest sandbox overall.
- Anti-exploit: agree with the top two, not sure I'd put Firefox over Safari.
- UX: I'm not totally sure how you are grading, but you should be aware that Safari has a really good built-in password manager. Passwords are securely stored in Keychain and we offer to generate random per-site passwords at account creation or password change time. I don't even know the vast majority of my website passwords. With iOS 11 this will be expanded to sharing website passwords with corresponding native apps for those sites, removing the main remaining reason to have a simple password.
- TLS: Not knowledgable enough here but note that we're moving to boingssl in the upcoming OSes and have cert pinning and HSTS and all that good stuff.
- Library security: not entirely sure what you mean by that.
I broadly agree with Justin Schuch's point in the post you linked that isolation technologies are more important on a philosophical level. Also I would give kudos to Chrome and Edge for having excellent overall security.
First, regarding isolation: using the same OS facility to block system calls is a superficial similarity between Chromium and Safari. Chromium and Safari are divided into process components differently, and block different system calls. Chromium exposes much less to its renderer process than Safari does to WebProcess. Not only that, but Chromium has finer-grained components; the GPU isn't exposed to Chromium renderers the way it is to Safari WebProcesses. This isn't a theoretical difference, as you know (but readers here don't): IOKit has been a source of WebProcess sandbox escapes for Safari. Safari isolates the network process and Chrome doesn't, but the network process is a low-priority attack surface. The highest priority attack surface is the one reachable directly from content-controlled Javascript. You say Chromium's edge over Safari is "small overall". We agree that the edge exists, but I strongly disagree that the delta is small.
We agree on anti-exploitation. In fact, if Safari got better here, I'd be less nervous about people running Safari. What are the plans here? The combination of (1) general purpose operating system, (2) rich attack surface exposed to WebProcess, and (3) lack of serious runtime hardening is most of my argument against using Safari. The rest of this list is "nice to have" stuff.
Regarding UX: Chromium has a well-regarded security UX team. Does Apple staff a dedicated security UX team for Safari? Chromium supports U2F natively. When will Safari? I think Chromium, Safari, and Firefox are closer together here than the browsers are on other facets of this list; I don't think Safari does a bad job here, just not as good of a job as Chromium.
Regarding TLS: Adopting Google's BoringSSL library is a fine start and I know Apple has strong crypto people on the Secure Transport team. But does Safari support HPKP? (If so, when did that happen?) Why is it virtually always Google's TLS team detecting and punishing rogue CAs? What CA BR violations were detected by the Safari team, or any other team at Apple? Has Safari done anything like the Google PQ handshake experiment? It feels a little unfair holding Apple to the standard of what is basically the most sophisticated Web PKI team on the planet, but that's a real part of browser security.
Regarding "Library Security": I don't know what to call this item and so I'm not surprised that you're confused, but: how does Apple's work fuzzing and doing vulnerability research in the underlying libraries that the browser depends on compare to Google's work doing the same thing? I think we both know the answer: nothing Apple is doing is close to what Google's in-house offensive researchers are doing. Apple benefits from the work Google does here and so can draft off Google's team here, but Google prioritizes their in-house offensive work to help Chromium.
I could make a similar scorecard for iOS versus Android and I think you'd see the reverse on these rankings, with Apple in the lead on basically everything. But browser security isn't hardware security, and on macOS, I don't think Safari and Chrome are close. I think Chrome is significantly more secure.
Could you give more details on these plans?