Comment by ruthmarx 2 days ago
It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.
> If you were writing a Java application, would you do your own DNS resolution,
Java isn't known to nanny the users of apps developed in it's language. It's never even tried IMO.
> If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.
Sure, but that isn't the threat model. I described the threat model above, which is closer to "I don't trust a company famous for trying to nanny not to try to nanny if using their preferred developer frameworks, while I kind of trust they won't for a legacy API they barely pay attention to".
> Java isn't known to nanny the users of apps developed in it's language. > It's never even tried IMO.
I think anyone who's run into java keystore / cert problems would beg to differ.
> Sure, but that isn't the threat model. I described the threat model above, > which is closer to "I don't trust a company famous for trying to nanny not to > try to nanny if using their preferred developer frameworks, while I kind of > trust they won't for a legacy API they barely pay attention to".
Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].
But we're talking about the same apple that implemented SIP which locks out even root (and by extension sudo) from being able to make changes to "system" directories like `/bin`, and necessitated things like homebrew having to migrate their entire deployment hierarchy from `/usr/local/` to `/opt/homebrew/`. The same Apple who replaced init scripts in BSD with their own proprietary `launchd`. The same Apple who swapped `bash` for `zsh` to avoid GPL3 licensing stuff. The same Apple that last OS update changed what signals were sent when doing illegal memory access, breaking a mess of java/docker things in the process. This is the Apple you think would impose hidden DNS interception and replacement at the swift library level but wouldn't bother to either change libc too or point getaddrinfo() at their own internal interceptor.
You are of course free to have whatever threat model you like, but surely you can see why other people find it a little inconsistent?
> Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].
I don't think this is a crazy position at all. Higher level frameworks often do things a particular way, often in a way that benefits the company pushing.
I'm pretty sure there are examples of Microsoft doing some slightly dodgy things via the .NET framework or similar but leaving the base win322 APIs untouched.
> but surely you can see why other people find it a little inconsistent?
Not really. I think people are dismissing it before really considering it because they think it's a moot point because the OS vendor could do anything, but I explained in other comments why I think that's flawed reasoning and not really relevant.
I appreciate your reply though, thank you.
I would feel far more concerned that an arbitrary application that decided to do its own DNS resolution would be doing so for nefarious reasons, or might mess up the process (such as not supporting encrypted DNS in this case).
If you genuinely cannot trust the OS vendor, you don't try to tinker around in user space but you stay off their platform. Personally, this is why I don't have any machines with a Microsoft OS, and why I don't have a Playstation.
> so it's a moot point and needless paranoia.
No it's not. You are misunderstanding my point.
I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely.
I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPhone with the justification being safety or 'for the children' or whatever.
That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way? As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.
(And further, assuming arguendo that there was DNS meddling happening but somehow getaddrinfo() was exempt - now the user has one app that behaves differently to all their others, which is worse in every practical sense.)
> Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way?
Nothing, I already acknowledge they have the power to do rootkity things if they wanted to, but I don't consider that likely.
I do consider it likely they might do that kind of a thing at a framework level and try to push most developers to use it.
> As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.
I responded to that as I'm responding here, by pointing out that isn't relevant to the threat model that I've described.
> now the user has one app that behaves differently to all their others, which is worse in every practical sense.
Not if that app actually gets the user to where they actually wanted to go.
If you were writing a Java application, would you do your own DNS resolution, or would you make a new socket address object and give it a hostname and let the api resolve the hostname for you? If you don’t hand roll your own dns protocol lookups, how do you know the OS, or Java or your socket library aren’t intercepting and modifying request out from under you? Heck, even if you use getaddrinfo directly how do you know your libc implementation isn’t intercepting and modifying the lookups on you? If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.