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...
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.
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.
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.
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.
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.
That being said, and I've never used Cortana or Alexa, but I hear they're pretty decent compared to Siri.
> 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:
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.
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?".
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.
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.
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.
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.
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.
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.
 : https://www.netmarketshare.com/browser-market-share.aspx?qpr...
Safari on iOS obviously has significantly higher market share on mobile and the intelligent tracker blocking is part of iOS 11 beta.
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.
* 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.
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.
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.
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.
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).
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.
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.
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.
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.
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?
You then, unprompted, create a comparison of all the major browsers again with no citations or supportive reasoning.
It's all very strange.
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.
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.
(b) I do not disagree about Chrome's energy usage. It sucks.
Or is it just assumed to be an easy target/too niche/no money from Apple?
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.
But that doesn't affect iOS, because you can't install fonts on iOS.
Custom fonts can be installed via custom configuration profiles, which is what some font applications do
I'm not sure if this is exposed via Safari or not, so it could still be a moot point.
 - https://developer.apple.com/library/content/featuredarticles...
 - https://itunes.apple.com/us/app/anyfont/id821560738
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.
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.
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.
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 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.
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.
"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?"
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.
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.
> 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.
Honest question. I'm not logging anything about my websites' visitors on principle, so I don't have insight into that area.
> 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.
Test your browser: https://panopticlick.eff.org/
I found this one rather interesting, it was the most unique of the ones listed:
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.
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 version
* OS version
* Machine architecture such as x86, x86-64, or ARM
* User locale
* IP address
* DNT flag
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
Why isn't this illegal already?