Hmmm, I wonder what ports and protocols are used? That information might make it possible for me to configure my hardware firewall for proper permissions. As far as I am concerned, apple only needs to know if any of their system apps crash.
-Eric > On Nov 13, 2020, at 6:25 PM, Brad Snyder <wb...@swbell.net> wrote: > > Deeper look at Apple’s recent server outage reveals potential Mac privacy > concerns > Michael Potuck <https://9to5mac.com/author/michaelpotuck/> > > As Apple launched its new macOS operating system to the public yesterday, > serious server outages occurred that saw widespread Big Sur download/install > failures, iMessage and Apple Pay go down but more than that, even performance > issues for users running macOS Catalina and earlier. We learned why that > happened at a high-level yesterday, now a security researcher has shared a > deep-dive along with his privacy and security concerns for Macs, especially > Apple Silicon ones. > > > Not long after macOS Big Sur officially launched for all users, we started > seeing reports of extremely slow download times, download failures > <https://9to5mac.com/2020/11/12/apple-widespread-outages-big-sur-downloads-catalina-imessage/>, > and in the cases that the download did go through, an error at the end that > prevented installation > <https://9to5mac.com/2020/11/12/apple-widespread-outages-big-sur-downloads-catalina-imessage/>. > > At the same time, we saw Apple’s Developer website go down, followed by > outages for iMessage, Apple Maps, Apple Pay, Apple Card, and some Developer > services. Then the reports flooded in about third-party apps on Macs running > Catalina and earlier not launching or hanging and other sluggish performance. > > Here are the latest details on Apple outages affecting Mac apps, Big Sur > updates, iMessage, and more > <https://9to5mac.com/2020/11/12/apple-widespread-outages-big-sur-downloads-catalina-imessage/> > Developer Jeff Johnson was one of the first to point out > <https://twitter.com/lapcatsoftware/status/1326990296412991489> what was > going on: an issue with Macs connecting to an Apple server: OCSP. Then > developer Panic elaborated that it had to do with Apple’s Gatekeeper feature > checking for app validity > <https://twitter.com/panic/status/1326991320519335936>. > > Now security researcher and hacker Jeffry Paul > <https://sneak.berlin/20201112/your-computer-isnt-yours/> has published an > in-depth look at what he saw happen and his related privacy and security > concerns in his post “Your Computer Isn’t Yours.” > <https://sneak.berlin/20201112/your-computer-isnt-yours/> > On modern versions of macOS, you simply can’t power on your computer, launch > a text editor or eBook reader, and write or read, without a log of your > activity being transmitted and stored. > > It turns out that in the current version of the macOS, the OS sends to Apple > a hash (unique identifier) of each and every program you run, when you run > it. Lots of people didn’t realize this, because it’s silent and invisible and > it fails instantly and gracefully when you’re offline, but today the server > got really slow and it didn’t hit the fail-fast code path, and everyone’s > apps failed to open if they were connected to the internet. > > He goes on to explain what Apple sees from the process: > > Because it does this using the internet, the server sees your IP, of course, > and knows what time the request came in. An IP address allows for coarse, > city-level and ISP-level geolocation, and allows for a table that has the > following headings: > > Date, Time, Computer, ISP, City, State, Application Hash > > This means that Apple knows when you’re at home. When you’re at work. What > apps you open there, and how often. They know when you open Premiere over at > a friend’s house on their Wi-Fi, and they know when you open Tor Browser in a > hotel on a trip to another city. > > Paul continues by posing the argument many readers might be thinking: “Who > cares?” He answers that by explaining that OCSP requests are unencrypted and > it’s not just Apple who has access to the data: > > 1. These OCSP requests are transmitted unencrypted. Everyone who can see the > network can see these, including your ISP and anyone who has tapped their > cables <https://en.wikipedia.org/wiki/Room_641A>. > > 2. These requests go to a third-party CDN run by another company, Akamai. > > 3. Since October of 2012, Apple is a partner in the US military intelligence > community’s PRISM spying program > <https://en.wikipedia.org/wiki/PRISM_(surveillance_program)>, which grants > the US federal police and military unfettered access to this data without a > warrant, any time they ask for it. In the first half of 2019 they did this > over 18,000 times, and another 17,500+ times in the second half of 2019. > <https://www.apple.com/legal/transparency/> > This data amounts to a tremendous trove of data about your life and habits, > and allows someone possessing all of it to identify your movement and > activity patterns. For some people, this can even pose a physical danger to > them. > > Paul mentions some workarounds to prevent this tracking but highlights that > those may be gone with macOS Big Sur. > > Now, it’s been possible up until today to block this sort of stuff on your > Mac using a program called Little Snitch > <https://www.obdev.at/products/littlesnitch/index.html> (really, the only > thing keeping me using macOS at this point). In the default configuration, it > blanket allows all of this computer-to-Apple communication, but you can > disable those default rules and go on to approve or deny each of these > connections, and your computer will continue to work fine without snitching > on you to Apple. > > The version of macOS that was released today, 11.0, also known as Big Sur, > has new APIs that prevent Little Snitch from working the same way. The new > APIs don’t permit Little Snitch to inspect or block any OS level processes. > Additionally, the new rules in macOS 11 even hobble VPNs so that Apple apps > will simply bypass them > <https://appleterm.com/2020/10/20/macos-big-sur-firewalls-and-vpns/>. > > @patrickwardle lets us know > <https://twitter.com/patrickwardle/status/1327034191523975168> that trustd, > the daemon responsible for these requests, is in the new > ContentFilterExclusionList in macOS 11, which means it can’t be blocked by > any user-controlled firewall or VPN. In his screenshot, it also shows that > CommCenter (used for making phone calls from your Mac) and Maps will also > leak past your firewall/VPN, potentially compromising your voice traffic and > future/planned location information. > > Paul highlights that Apple’s new M1-powered Macs won’t run anything earlier > than macOS Big Sur and says it’s a choice: > > you can have a fast and efficient machine, or you can have a private one. > (Apple mobile devices have already been this way for several years.) Short of > using an external network filtering device like a travel/vpn router that you > can totally control, there will be no way to boot any OS on the new Apple > Silicon macs that won’t phone home, and you can’t modify the OS to prevent > this (or they won’t boot at all, due to hardware-based cryptographic > protections). > > He updated the post to share that there may be a workaround via the bputil > <https://keith.github.io/xcode-man-pages/bputil.1.html> tool but that he’ll > need to test it to confirm that. > > In closing, Paul says “your computer now serves a remote master, who has > decided that they are entitled to spy on you. > > With Apple holding privacy and security as two of its core beliefs, time will > tell if we see Apple make changes around the issues brought to light during > the launch of Big Sur. > > You can find the full article by Jeffry Paul here > <https://sneak.berlin/20201112/your-computer-isnt-yours/>. > > Check out 9to5Mac on YouTube for more Apple news: > <https://www.youtube.com/c/9to5mac?sub_confirmation=1> > > > > > > -- > The following information is important for all members of the Mac Visionaries > list. > > If you have any questions or concerns about the running of this list, or if > you feel that a member's post is inappropriate, please contact the owners or > moderators directly rather than posting on the list itself. > > Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: > mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at > caraqu...@caraquinn.com > > The archives for this list can be searched at: > http://www.mail-archive.com/macvisionaries@googlegroups.com/ > <http://www.mail-archive.com/macvisionaries@googlegroups.com/> > --- > You received this message because you are subscribed to the Google Groups > "MacVisionaries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to macvisionaries+unsubscr...@googlegroups.com > <mailto:macvisionaries+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/macvisionaries/C894F0FF-DEE1-4924-BBB2-B4B67D49CB58%40swbell.net > > <https://groups.google.com/d/msgid/macvisionaries/C894F0FF-DEE1-4924-BBB2-B4B67D49CB58%40swbell.net?utm_medium=email&utm_source=footer>. -- The following information is important for all members of the Mac Visionaries list. If you have any questions or concerns about the running of this list, or if you feel that a member's post is inappropriate, please contact the owners or moderators directly rather than posting on the list itself. Your Mac Visionaries list moderator is Mark Taylor. You can reach mark at: mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at caraqu...@caraquinn.com The archives for this list can be searched at: http://www.mail-archive.com/macvisionaries@googlegroups.com/ --- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/macvisionaries/AA16B4CE-D7E4-4F9E-ADD2-992D82887135%40gmail.com.
