This makes me feel somewhat better, honestly. The fact that packet-level firewalls work is reassuring.
It hadn't been clear from previous reports that they all have to do with content-level filtering and VPN's. In that context, it seems to make more sense for Apple to exempt its own critical services (like malware detection and security updates). Kind of the same way applications can't overwrite system files either.
I am curious though: can anyone think of any real-world scenario where it's a genuine problem that Apple traffic isn't routed through the VPN?
When I think of normal uses for VPN's -- security for online work and communications, evading censorship, bypassing geo blocks -- these would all seem to be entirely unaffected.
Is there anything at all an ISP or attacker could snoop on outside your VPN that could ever be genuinely threatening or privacy-invading? Or is there a worry that we don't have a definitive answer to this because nobody's catalogued everything Apple sends and looked for privacy vulnerabilities?
> 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
I find it worrying that the side effects of leaving Mullvad enabled are that the keyboard takes longer to wake from sleep. What the hell is going on here?
I mentioned this issue regarding my laptop during the apple server downtime last week. Someone mentioned that the T2 chip connects to Apple during wake from sleep. I'm guessing the keyboard goes through the T2 chip and until the timeout is hit it won't let it through.
I assume this is related to the iCloud 'Find My Mac' feature: whenever a device wakes up one of the first few things it does is update its location on iCloud.
Yes, it is both a security leak and a useful feature: it is useful to find a lost/stolen device as the location will become visible whenever anyone powers it up with access to an internet connection.
I've wondered about the practicality of this for some time, but never came up with an answer. For a device with an always on connection like an iDevice with cell chips, the location can always be updated. However, a locked laptop with WiFi only would need to be unlocked to be told to join an available WiFi network. If I'm someone that is inclined to do something with an Apple laptop with a T2 chip that has found its way to me, I'm not going to allow it to join a WiFi.
As of macOS Catalina, it can piggyback off nearby devices. Even if the device is turned off, it still may be able to broadcast location if there are other devices nearby.
> If I'm someone that is inclined to do something with an Apple laptop with a T2 chip that has found its way to me, I'm not going to allow it to join a WiFi.
So that means you will never use that laptop on a network again?
Its more than that, You can't wipe it at all until you log in with the apple account it was connected to. Rendering a stolen laptop effectively bricked and only useful for parts.
Yes, from what I know the keyboard goes through that chip.
I also think to have heard that in some cases broken keyboards can cause your laptop to not work anymore at all because of this but I didn't remember where I heard this, does anyone happen to know the source/correctness of that?
This is also an issue on always-on VPNs, where the process of verifying keyboard firmware can result in the alarming "Please connect a keyboard via Bluetooth" dialog on even a laptop. It goes away as soon as the verification completes, but is not the fault of Mullvad per se.
I'm aware of this being a well-documented issue starting in Catalina [1], but I wasn't aware there was a definitive answer as to why. Do you have a source for the fact that it's firmware verification?
I wish I did. I just remember it being a huge annoyance.
It does both make sense and seem incredibly buggy. It'd have to be a fairly impressive attack vector that hits the keyboard firmware, but if you did, I suppose you'd have access to the raw key stream to exfiltrate... not curious to see if it applied on my Mac Pro (which just has a WASD keyboard - I don't use the Apple Magic Keyboard), or a MBP without touchbar (maybe this is the firmware, not the keyboard per se). I do know it is demonstrably the VPN at issue - I can disable our always-on device VPN and the problem goes away, but alas, no easily accessible source that says "verification of HID firmware" or similar.
This explains a lot, actually. I travel a lot, so I often deal with very bad internet connection quality. I also often have the problem that my keyboard takes a long time to start working again after sleep mode.
I've even gotten the "you don't have a keyboard plugged in" error message on my laptop (because the keyboard hasn't been detected after ~30 seconds).
Does this mean that MacOS packet filtering does work as expected, and can block any/all traffic, including traffic to Apple? That's good, and what I would hope, but then I'm a little confused about what nastiness Apple is doing in Big Sur related to firewalls.
macOS packet filtering in Big Sur is unchanged, offering src/dst host/port/proto filters, as is typically thought of to be a 'firewall'.
macOS content filtering in Big Sur is no longer able to intercept apps on the exclusion list shipped by Apple, and is akin to 'iptables --uid 501' or 'iptables --command firefox-bin' (actual syntax may vary).
The content filtering API can see which user/app originated the traffic, as it's running higher up in the stack; the packet filtering API cannot, as it's running lower down in the stack.
Apps such as Little Snitch allow you to filter network traffic per-application, which can't be done with PF; you need CF for that, and CF no longer extends to Apple core system processes in Big Sur.
Mullvad's blocks are done imprecisely with PF (presumably they deny 17.0.0.0/8), which is why their blocks break various functionality such as the Mac App Store or:
> For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online.
And while they note that it's possible to punch exceptions into the firewall, those exceptions can't be granted per-use, only per-IP.
I wonder if a Little Snitch type application could look at both data flows and correlate the two. Anything that packet filtering detects that isn't also detected by content filtering could itself be handled with custom rules.
It might be able to report that unfiltered traffic occurred, assuming it can detect unfiltered traffic using pcap, but it wouldn't be readily possible to prevent the initial packet from being sent prior to a rule specifically being created to prohibit it.
Operating a system in PF deny-all default would cure this, as long as LS carefully curated a list of PF allows.
It's possible there are external constraints preventing more widespread use of PF, like "Is this allowed on Mac App Store?".
I assume that Apple's reasoning is "Userspace malware shouldn't be able to trivially intercept anti-malware checksum updates".
Trivially is defined as 'click an OK button in a dialog' as the CF permissions process works in Big Sur today.
Malware could still block anti-malware checksum updates with PF, but that requires sudo/root which is 'less easy' than the one-click CF approval process, and PF blocks break so many things on the system that malware can't get away with it without triggering a call to technical support.
(I personally think that much of the issue here is 'macOS background updates can cause $$$$ cellular data drain over wifi-tethered cellular', and that the absence of Low Bandwidth mode in Control Center is one thing that drives users towards these third-party content filters, when they might otherwise not need a third-party product at all.)
Doesn't a VPN work over the internet (in order to access a local network). So I wouldn't say it provides internet connectivity (as you already need to be connected to the internet to connect to a VPN).
A VPN simply gives you access to a local network. A specific use of a VPN is masking your internet traffic as if it came from that local network, but there are many uses besides it.
The nastiness is based on misunderstanding of what Apple is doing, and of how their API’s work, coupled with a healthy distrust for large organizations.
The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.
That problem is different: whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)
>whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)
This sentence suggests that there's no way to filter/vpn whitelisted traffic, but this is clearly not the case, as evidenced by this article. Furthermore, it's still possible to block/filter traffic on a whole machine basis by using the Packet Tunnel Provider API.
There has been malware that pretends to be a HID driver and function as a keylogger and/or execute arbitrary code. While Apple may be being overly cautious here, it's not entirely unreasonable.
Presumably to check if the software that is about to run is in a blacklist. But this is nonsense because the blacklist could also be downloaded and checked locally.
When are they going to require an always-on camera to protect the user from potentially being held at gunpoint? Or is Apple confident they're the only party that gets to do that?
AFAIK it's nothing to do with mullvad specifically. Using the generic openvpn/wireguard client (or other VPN service's client that are based on those clients) should also be fine. The only thing that might be an issue would be VPN apps that implement split/per-app tunneling.
You can turn off the internet and freely use your Mac. The network dependent features are smart enough to know you are offline and not impede you.
Their problems come when you have bad connections or Apples servers are down/overwhelmed. They don’t fail gracefully then.
As a mobile developer I know there are always at least two or more failure modes with any network request, failures because of network/server failures, or failures because internet is off. My clients constantly think Airplane mode is the bad network test case,and I constantly remind them that no, it’s only one possible error cause.
While I'm very grateful for the research that Mullvad has done to reassure us that VPN's can still be effective and work as normal, it's still a serious enough issue for me not to "upgrade" to Big Sur. Especially after reading about the Little Snitch fiasco as well. Both tools are essential for a proper internet experience.
You can also use Mozilla VPN to support Firefox and use the same service (it's done through Mullvad). Downside to Mozilla though is no Mac or Linux client
> They are thirsty for your personal data and they need to know everything you do on their computer.
This is completely opposite of what Apple does, no? Out of all of the tech giants (Microsoft, Facebook, Google) it's my impression that Apple is the one that sends the least amount of data to their own servers.
It's contrarianly cool to interpret Apple's "pivot to services" to mean adopting the privacy-invading Google/Facebook business model but that's probably not happening in reality.
From the non-encrypted ICloud, the eavesdropping on Siri conversations, to the non-encrypted spying about opened apps going through 3rd party server and some zillion other cases of Apple screwing up privacy... I'm not sure Apple cares about privacy beside their marketing propaganda.
Why do we need to take side ? big tech are like choosing between the plague and cholera.
The message to spread is not "Apple/Google is better for privacy", it's " Google & Apple are both screwing up our privacy and have awful anticompetitive practices, so buy an Android or IPhone whatever cause we don't have choices right now, but if you want things to change support Purism/PinePhone/Protonmail/EFF/FSF/etc."
We need people to realize the harm both Apple & Google ( & Amazon & etc.) are doing to our privacy and society rather than having them thinking one is the bad guy and not the other.
Hard to really know where Apple stands in comparison to the other tech giants. It feels like forever ago, but they all sang the same tune when Snowden leaked those documents a few years back.
We first heard of the government’s “Prism” program when news organizations asked us about it on June 6.
Microsoft: We provide customer data only when we receive a legally binding order or subpoena to do so, and never on a voluntary basis. In addition we only ever comply with orders for requests about specific accounts or identifiers. If the government has a broader voluntary national security program to gather customer data we don't participate in it.
Facebook: We do not provide any government organization with direct access to Facebook servers. When Facebook is asked for data or information about specific individuals, we carefully scrutinize any such request for compliance with all applicable laws, and provide information only to the extent required by law.
Google: Google cares deeply about the security of our users' data. We disclose user data to government in accordance with the law, and we review all such requests carefully. From time to time, people allege that we have created a government 'back door' into our systems, but Google does not have a backdoor for the government to access private user data.
I have long wanted to believe Apple is fighting for its customers' privacy, but this new phone-home telemetry "feature" really stacks undeniable doubt against the likelihood that Apple is in my corner. I am starting to think that all the back-and-forth with the Justice Department and Bill Barr (https://www.nbcnews.com/think/opinion/bill-barr-wants-apple-...) was encryption theatre and the US government actually wants people to use Apple devices. Think about it...Apple is a US company with major access to China and other world markets, and it writes its own software. Seems like the ideal partner for a nosy surveillance agency.
I just want a blazing fast aluminum laptop that doesn't betray me at every turn. I guess that's too much to ask these days.
Are you saying that implementing shady bypassing of VPNs to transfer who knows what data out of "your" machine without your knowledge is okay because it is not as bad as Microsoft, Facebook or Google? Is it really what we have come to? I think this is worse than Microsoft, because in Windows I can actually disable that and it doesn't try to bypass my firewall or VPN.
Again, there is no evidence or even reason to believe they would store these IP addresses or any records of the OCSP requests (other than temporary logging for debugging purposes). It's not necessary to the feature, it goes against their privacy policies, it provides zero value for any Apple product, and storing them is a potentially serious PR or even legal risk.
Apple isn't Google, ad revenue is such a tiny part of overall revenues it's not even quantifiable, while their brand is a huge part of customer purchasing decisions. At Google almost all revenues are Ad revenues. Any little bit of data can help you target ads better, and they are competing against Facebook which knows all about their users.
Is there a difference between disallowing an action and denying it? I think so, and that word choice matters. I see this pattern everywhere. Do you disallow someone on FB, or do you block them? Does iptables use disallow as a keyword? I do see BLOCK and DROP though.
Normalized use of the passive voice is no different than being uncomfortable with making eye contact during a regular conversation. Perhaps the writer accounted for that considering the user base.
Apple making some of its components bypass application level firewall might need to occur given the reality that a modern os is a decentralized system -- but I really think the set of such code with this functionality should be minimized to the absolute smallest possible surface area -- and this behavior should be confined to a tiny set (or even a single) of system components ... "low latency clock coordinator component" or whatever the true architectural reason for the system to require unfettered network access is ...
It seems to me like ultimately the only use cases that should require bypassing network controls will relate to scenarios where there are architectural constraints imposed by the need to minimize latency - and minimizing latency needs to be possible ... so Whatever needs to happen at the architecture level to ensure minimal latency is going to need to happen -- but hopefully only those things ... -- and hopefully only in ways that are visible and decoupled from content-ful network transactions ...
It hadn't been clear from previous reports that they all have to do with content-level filtering and VPN's. In that context, it seems to make more sense for Apple to exempt its own critical services (like malware detection and security updates). Kind of the same way applications can't overwrite system files either.
I am curious though: can anyone think of any real-world scenario where it's a genuine problem that Apple traffic isn't routed through the VPN?
When I think of normal uses for VPN's -- security for online work and communications, evading censorship, bypassing geo blocks -- these would all seem to be entirely unaffected.
Is there anything at all an ISP or attacker could snoop on outside your VPN that could ever be genuinely threatening or privacy-invading? Or is there a worry that we don't have a definitive answer to this because nobody's catalogued everything Apple sends and looked for privacy vulnerabilities?