[HN Gopher] Big no on Big Sur: Mullvad disallows Apple apps to b...
       ___________________________________________________________________
        
       Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall
        
       Author : Semaphor
       Score  : 59 points
       Date   : 2020-11-16 18:55 UTC (2 hours ago)
        
 (HTM) web link (mullvad.net)
 (TXT) w3m dump (mullvad.net)
        
       | varispeed wrote:
       | It is a matter of time Apple will block it. They are thirsty for
       | your personal data and they need to know everything you do on
       | their computer. They also need to control what you can or cannot
       | open. You are just not smart enough in Apple eyes to use a
       | computer on your own. On a side note, if I was an Apple customer
       | I'd start making GDPR complaints. Surely just because a OS is not
       | a web app it doesn't mean it can violate privacy in such brazen
       | way.
        
         | judofyr wrote:
         | > 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.
        
       | pwinnski wrote:
       | 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.
       | 
       | Time to dig in, I guess.
        
         | pram wrote:
         | 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)
        
           | gruez wrote:
           | >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.
           | 
           | https://news.ycombinator.com/item?id=25113039
        
             | pram wrote:
             | You have poor reading comprehension if you think thats what
             | I said.
        
         | floatingatoll wrote:
         | macOS _packet_ filtering continues to work in Big Sur, as it
         | did in previous releases of macOS.
         | 
         | macOS _content_ filtering changes in Big Sur as per any of the
         | articles posted each day for the past week or so.
         | 
         | 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.
        
         | whazor wrote:
         | A VPN provides internet connectivity, therefore it is more like
         | a partially broken internet connection instead of a firewall.
        
       | Semaphor wrote:
       | While I never used anything Apple, I'm a Mullvad user. This just
       | popped up in my RSS feed and I thought it would be relevant.
        
       | beervirus wrote:
       | This is just an ad.
        
       | gruez wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2020-11-16 21:01 UTC)