Hacker News Reader

> This makes me feel somewhat better, honestly. The fact that packet-level firewalls work is reassuring.

Yeah, actually it makes me feel like the complaints I was reading previously were inaccurate or at least overstated. If I understand the facts right, macOS has both a traditional firewall (like Linux does) and also a system-wide content blocking API (which Linux does not). If you make changes to the firewall, anything you block will be blocked, including requests from trusted Apple applications. Certain system applications bypass the content blocking API.

Honestly this seems entirely reasonable, in fact. They seem like two different tools for two different purposes. And given that most other operating systems don't have built in content-blocking APIs at all, as far as I know, I think the framing of Apple's decision as some kind of power grab is deeply misleading.

Let me know if I'm misunderstanding the substance of the Mullvad post.

> Honestly this seems entirely reasonable

I want to agree with your optimistic view of this, but I can't, because I don't think reason was used in making the decision.

I think the reality is probably closer to this:

Product: "so we can't let users block our own apps. it might break things in weird ways and also they implicitly trust us already because we make their OS".

Engineers on the application firewall team: "ok cool, we'll disable users from blocking Apple apps".

Any freedom you're enjoying with PF isn't there because Apple decided it was a good idea. It's there because Apple decided to build on BSD.

I'm actually surprised MacOS even has PF (apparently since 2015, enhanced from other BSD implementations). I did a minimal amount of searching and found this now-relevant gem: https://manjusri.ucsc.edu/2015/03/10/PF-on-Mac-OS-X/

> If two firewalls, Application Firewall & PF, are both running, you may wonder whose rules take precedence. Let’s find out.

> ...

> So one can conclude that PF rules are applied first, then the rules for Application Firewall.

> Any freedom you're enjoying with PF isn't there because Apple decided it was a good idea. It's there because Apple decided to build on BSD.

It’s there because Apple decided it was a good idea. If they didn’t think it was a good idea, they wouldn’t have included it. Your next sentence even implies this when it admits that Apple’s inclusion of PF is only a few years old.

> I'm actually surprised MacOS even has PF (apparently since 2015, enhanced from other BSD implementations).

It's not like PF was billed as a hot new feature of the OS. I believe it's a happy accident that we got PF, and I won't be shocked if it goes away in the future.

Especially now that it's been publicly documented that it can block Apple apps.

The fact that all of this still has had to be deduced ad hoc in some reverse engineering-type paradigm also should give anyone pause. The fact packet filtering works is better than if it didn't but that's almost besides the point. The problem is Apple deliberately obfuscating important security details from the user. It's literally asserting privilege of itself over the user/device owner in an essential way, if not entirely through filtering protocol than through informing about the protocol.

> a system-wide content blocking API (which Linux does not

Technically, isn't that what apparmor does?

> can anyone think of any real-world scenario where it's a genuine problem that Apple traffic isn't routed through the VPN?

A MacOS update with a bug that accidentally leaks user personal info in plaintext.

Use of a Mac in a public, open hotspot setting.

Two that come to mind.

A bug that accidentally disables the encryption on the encrypted protocols Apple is using? That seems rather unlikely.

And the second, “Use of a Mac in a public, open hotspot setting” is really the same thing as your first, because if all traffic is encrypted, then being on a public hotspot isn’t leaking your data.

>rather unlikely https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-a...

If you work for someone and had an apple computer to work from home, bypassing the VPN would merge your personal life (ip address, location, so on) with your job. All packets that go direct to apple are identified with your real home ip address.

There is a VPN concept called "split tunneling" where your employer can control what data goes through the VPN via work and what data can actually go directly to and fron a destination from your home network.

Employers very cautiously permit or deny this kind of thing - sometimes allowing videoconferencing to use this with specific domains or ip ranges.

Apple goes around all this. They can identify and correlate who works where, where they live and pierce the veil of privacy that should be afforded employees who have to work for someone else.

Also, if there is a vulerability in apple's stuff, some employers would be vulnerable to attacks through the VPN, even though they didn't permit split tunneling.

The fact that you use an Apple device is readily apparent from these traffic patterns - that alone seems worth hiding with a VPN.

What's your threat model for this concern? Local networks are still going to see the MAC address (randomization means they can't track you specifically across different WiFi networks, but they still know it's an Apple device). VPNs aren't perfect so an attacker is almost certainly going to see enough from DNS queries, HTTP user agents, TLS SNI headers, etc. to detect the OS in the times where the VPN isn't active. Traffic analysis is also likely to be leaky at this level, too — if you see a big download around the time that Mac/iOS updates come out that's pretty indicative even if you can't see the traffic.

Capital One used to offer different mortgage rates to IE users and Firefox users;

I’m sure there are places that would try to charge Mac users more (or make them more likely to be mugged or something) as they are more well-off statistically.

Verizon used to add http headers identifying their users to advertisers.

Everyone is out to tag you, and it’s because on average it makes them ever-so-slightly more profitable - at your expense, on average.

Orbitz used to charge higher fares for Mac users [2]

[2] https://www.cnet.com/news/mac-users-pay-more-than-pc-users-s...

> Capital One used to offer different mortgage rates to IE users and Firefox users

That's amusing, I didn't know about it before. Looks like the story broke 10 years ago:

https://hothardware.com/news/at-capital-one-different-browse...

https://consumerist.com/2010/11/01/capital-one-made-me-diffe...

None of those are a threat model and if you think about them for a minute you can understand why they aren't relevant.

> Capital One used to offer different mortgage rates to IE users and Firefox users;

This was driven by looking at the User-Agent header your browser sends on every request, not sniffing your local network connection.

Similarly, the Verizon super-cookie header wouldn't affect HTTPS traffic (this was one of the motivations behind HTTPS-everywhere campaigns since even many people who think the NSA can track them no matter what mind marketers doing it) and the point was tracking individual people across multiple devices, not simply gross device fingerprinting. Even if your VPN connection has 100% uptime they can do the traffic analysis I mentioned but since it's almost certain that there will be some non-VPN requests they would already know that you have at least one Apple device.

The underlying issue here is that the kinds of things you're worried about happen in the browser. Using a VPN adds reliability and performance issues but it doesn't prevent this kind of basic identification and very, very few people aren't going to leave some kind of far more identifying cross-site activity which would uniquely identify them rather than just narrowing it down to one of the most popular consumer brands.

They are a threat model for your wallet, which some people consider a threat model.

The older user-agent / supercookie tags don't work for intermediaries on https, indeed. Which is all the reason why your other metadata (such as contacting apple servers) helps tag you.

> The underlying issue here is that the kinds of things you're worried about happen in the browser.

The things I'm worried about are those I'm yet unaware of. Those things I am aware of (in the browser, for example), I mitigate with browser addons and other tools. But I"m not aware of everything.

I'm not paranoid, everyone IS trying to tag me (and you, and everyone else) for their profit. I am not familiar with ALL the ways they do it, therefore I worry about all information leaks.

> They are a threat model for your wallet, which some people consider a threat model.

That's not a threat model:

https://en.wikipedia.org/wiki/Threat_model

My point is that you need to think about what you're trying to protect against so you can avoid spending time on things which don't matter. For example, if you're concerned that your ISP is going to tell people your IP address and say you own a Mac, you might want to think about whether having a VPN installed would prevent them from doing so, which will not be the case unless you set it up at the router level, configure it to drop traffic if the VPN connection fails, spread your traffic across multiple providers to make things like download profiling harder, etc.

Trying to conceal such general signals from a network-level attacker is a very hard game but once you stop to think about why you care, it becomes clear that it's a waste of time. The two stories from a decade ago were about businesses presenting different rates based on the user-agent. If you're not masking that, you're giving away more detailed information to every site you visit. If you are masking that, you might say that the problem is your ISP selling your IP association to third-parties as part of a “can pay more” list and that clarifies that the real concern isn't what your ISP can see — they do, after, all have your address, billing information, logs from your access to their services, and probably a credit score — but whether they resell it.

Putting it all together, your threat is “third-parties can obtain information which they would not otherwise have about me from my ISP”. That tells you that you need to think about breaking ways they'd make that link: using a VPN for web browsing can make a difference there since it means that Shady Bank™ can't use an IP lookup (assuming your VPN provider wasn't the threat you really needed to worry about) but trying to force Apple system services through it is just wasting time to make things slower and less reliable, and you're much better off spending your time making sure that you use unique contact info, browser containers, etc. to limit the ability of third parties to link your data. In a world where most people use cell phones, Google, Facebook, etc. it's just not that valuable to have a signal which says “IP x uses products from one of the most popular consumer electronics companies”.

On my home network I used this [1] guide to set up a pihole with dns over https. Should stop snooping of some of those types by anyone but your chosen DNS target at least (middlemen, ISPs etc). Though I can't comment on other types of attacks.

[1] https://docs.pi-hole.net/guides/dns-over-https/

Since the application attestation service sends application hashes unencrypted, any third party observing the traffic can fingerprint you if you use exotic enough applications.

Do they even have to be exotic applications? I don't use Chrome very often but I think it is installed. That means I have a very current FF but some specific old version of Chrome. Ditto for a bunch of stuff installed by Macports, that all just updates at once but pretty infrequently. I don't recall the last time I updated Steam. Seems easy to fingerprint someone with just a handful of even normal apps.

Given that a large majority of users only ever run a single browser and maybe a messaging app, anything above would be considered exotic in my book :)

Good point. Do users uninstall stuff they use infrequently though?

Because Apple users allow Apple to manage so many aspects of the computers they sell, remotely, it seems to me getting access to Apple traffic or the data Apple collects and stores about its customers is nearly as informative as getting physical access to the customer's Apple computer.

"Privacy" in the case of the traffic relies on two things: (a) trust in Apple to not get hacked or intentionally share the data with anyone and (b) trust in TLS (not all VPNs use TLS). Apple customers have little control over how Apple operates nor the development/maintenance of TLS. Apple customers can control physical access to their computer but Apple gets a free pass to access/monitor these computers remotely.

What would be a hypothetical "real-world scenario" where it's a genuine problem that Apple traffic isn't routed through the VPN

There is an existing flaw in TLS and Apple does not learn about it immediately, or, some individual/organisation gets access to Apple's private key with or without Apple's consent, a fact which may or may not become public knowledge.

There are a variety of "Apple services" that require TLS-encrytped traffic sent to/from Apple that are initiatied by today's Apple computers, with or without user interaction. Some of the content sent to Apple computers as part of these "services" could come from "fourth party" servers that are part of CDNs who Apple has employed to serve content. To the extent any of this Apple traffic is routed based on geolocation, e.g., from the nearest CDN server, that could reveal something about the user's location.

https://www.richard-purves.com/2016/09/10/apple-services/

The content of this traffic could vary based on the service. Decrypting iTunes/AppStore traffic might reveal the user's AppStore searches and the apps she has installed that have updates available. A full analysis of all the possible data leaks across all the services would be no small amount of work. One more service that the blog post above seems to omit is Apple's NTP service at time.apple.com (Apple performs DNS-based routing). This NTP traffic could produce vast logs of Apple customer IP addresses over time. Some years ago it was said that Shodan.io was using NTP to gather IPv6 addresses to scan by participating in pool.ntp.org.

Decrypting Apple so-called "Push" connections might possibly be viewed with a jailbroken device. Data included in the protocol messages might include connection type, OS version, OS build, device model, etc.

https://github.com/mfrister/pushproxy

Thanks for the explanation.

However, I think worrying about the security of TLS is applicable to everything -- it's nothing special to Apple not utilizing the VPN.

It's just as likely that your VPN itself could suffer the exact same problem, or your browser.

And that the mitigation techniques would be the same: reasonably timely security updates.

So it doesn't really seem like there's any higher security risk here? Just the same risk we already accept with everything?