Comment by ruthmarx

Comment by ruthmarx 2 days ago

2 replies

> 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".

tpmoney 2 days ago

> 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?

  • ruthmarx a day ago

    > 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.