Live data from Hacker News

Apple adds a tracker blocker to desktop Safari

techcrunch.com

171–180 of 301 posts

Re: Apple adds a tracker blocker to desktop Safari

#172
post #119

Earlier quoted context omitted.

They don't prevent me from doing my job. It makes it harder. Oh no, I have to work harder.

Why is it wrong to want to make your job easier? I guess I don't see your point of view..

I would like it to be easier. I also know that I am not entitled to that. This isn't difficult to grasp for most of HN based on the comments...

Re: Apple adds a tracker blocker to desktop Safari

#173
post #105

Earlier quoted context omitted.

They are completely different beasts. Internet Explorer merely offers the option to enable[1] "Do Not Track", which websites and advertisers are free to ignore[2], while Safari's new ad tracker blocker "uses machine learning to identify trackers, segregate the cross-site scripting data, put it away so now your privacy — your browsing history — is your own"[3]. [1] https://en.wikipedia.org/wiki/Do_Not_Track#Internet_E…

You are actually incorrect. Tracking Protection refers to an IE feature that lets you set "Tracking Protection Lists", which block traffic to specified domains and URLs. You can see a bit about them here: https://msdn.microsoft.com/en-us/library/hh273400(v=vs.85).a... 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.

I don't know why this has been downvoted. Tracking Protection Lists are one of the best and unsung features of IE. People don't realize that they're different from Do Not Track.

Re: Apple adds a tracker blocker to desktop Safari

#174
post #47

Earlier quoted context omitted.

Internet Explorer has tracking protection since IE9.

Going to my IE right now to activate it, I have to say this is a janky solution. It opens the Add-ons window, where you can see you have no Tracking Protection Lists. Then you can click to browse the add-on gallery for them, and then you have to scroll down and pick a list from a set of options. While this is flexible, open, and that's all good, the lack of a common sense default and a multi-step setup process is pro…

If you're interested, I created and maintain a tracking protection list based on the Ghostery and Disconnect filter lists. It's concise, fast, and better than anything in the IE gallery. https://amtopel.github.io/tpl/

Re: Apple adds a tracker blocker to desktop Safari

#175
post #154

Earlier quoted context omitted.

Your original post here made a bold claim with no qualification and no supporting details. You're not providing any backing to your claim but at the same time you're asking me to give details. Plus you've repeatedly thrown in anti-exploit tech which wasn't the original point of contention. 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 w…

My contention was that Safari is less safe than Chrome, not that Safari's sandbox was in particular worse than Chrome's. Nevertheless, on balance, Safari's sandbox is significantly worse than Chrome's. I think --- but you'd know better than I would --- that this is because browser security is a platform problem for Apple, and an application problem at Google. Apple's platform-level mitigations are very powerful on iO…

You actually did make a claim that Safari's sandbox was in particular worse than Chrome's, in the post I directly replied to. That is what got my dander up. Elsewhere you implied that the Safari sandbox comparable to the Java sandbox. I hope you will now agree that the Safari sandbox is closer to Chrome's than to Java's.

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.

Re: Apple adds a tracker blocker to desktop Safari

#176
post #174

Earlier quoted context omitted.

Going to my IE right now to activate it, I have to say this is a janky solution. It opens the Add-ons window, where you can see you have no Tracking Protection Lists. Then you can click to browse the add-on gallery for them, and then you have to scroll down and pick a list from a set of options. While this is flexible, open, and that's all good, the lack of a common sense default and a multi-step setup process is pro…

If you're interested, I created and maintain a tracking protection list based on the Ghostery and Disconnect filter lists. It's concise, fast, and better than anything in the IE gallery. https://amtopel.github.io/tpl/

IE isn't really a browser I use heavily personally. Has Microsoft carried the feature forward to Edge, or are they relying on extensions from the Store for that?

Re: Apple adds a tracker blocker to desktop Safari

#178
post #174

Earlier quoted context omitted.

If you're interested, I created and maintain a tracking protection list based on the Ghostery and Disconnect filter lists. It's concise, fast, and better than anything in the IE gallery. https://amtopel.github.io/tpl/

IE isn't really a browser I use heavily personally. Has Microsoft carried the feature forward to Edge, or are they relying on extensions from the Store for that?

They discontinued it in Edge, unfortunately.

Re: Apple adds a tracker blocker to desktop Safari

#179
post #159

Earlier quoted context omitted.

Just to add some context, on macOS you can look at the seat-belt policy as a rough analog of for basic sandboxing guarantees, where the fewer exceptions you have the stronger your sandbox is. From that perspective, Chrome's policy has around 1/10th the exceptions of Safari. * Safari SB policy: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit2/... * Chrome SB policy: https://cs.chromium.org/chromium/src/cont…

The question is a bit complex than a simple reading of these files. Mac OS sandboxing allows dynamic extension of the sandbox, which would not be reflected in the profile (I'd bet Safari does more of this than Blink though). Also, as you mentioned, it's relevant to look at what's factored into separate processes, and how those processes are sandboxed. Safari's Network process has been networked since 2013, so I don't…

I don't keep up too much on Safari these days, so congrats on moving the network stack out of the content process. But looking at the current WebProcess seat-belt policy and what gets initialized, it looks like there's still far too much attack surface relative to Chrome. Things like audio/video capture and other permissioned Web APIs appear to be permitted directly inside the sandbox. And the GPU attack surface alone is a giant vector for escape--plus all the other potential escape vectors posed by that very long list of mach services.

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.

Re: Apple adds a tracker blocker to desktop Safari

#180

Thumbs up for Apple distinguishing themselves by their pro-privacy stance, as opposed to MS, who don't have anything to win by Win10's excessive "telemetry" IMHO.

It's also a real shame they're doing this before Mozilla. Mozilla already has Tracking Protection but only for Private Windows.

It's like Mozilla can't even embrace its privacy stance fully.

Post reply on HN