I don't think there's anything wrong with expecting that a company -- especially Apple -- delivers on what it promises to deliver. After all, it is that ability to execute that sets apart some companies -- especially Apple -- from others.
In my case, I am more puzzled by the frenzy over what I think is large an eye-candy update, one that seems more like a nice-to-have than must-have. (New security and privacy features are always welcome, but those do not need a new OS designation to make happen).
As always, I'll wait a few weeks to download, say, wait for 11.1.
I'm in the same camp as you. I downloaded Big Sur on my barely-used MacBook Pro when all the complaints about outages were going on. Not only did the entire download/install process take under an hour, I've been using it all yesterday and today and frankly, I don't see what the big deal is. It seems to be more eye-candy than anything else. It's nice to know all my apps (including some very important Java apps) worked perfectly, it don't see much difference functionally.
My MBP primarily lives in a desk drawer. With the pandemic eliminating travel for me, it doesn't get used so I don't mind using it as a testing platform for updates like these. My two main Mac workstations though... they're not going to be updated for at least a month until the inevitable BigSur updates occur... my MBP works perfectly (so far) with Big Sur, but I'm not ready mentally to do it on my main workstations.
As reported by 9to5 Mac, the problem goes far beyond Big Sur slowdowns. It centers on MacOS constantly sending detailed app usage data back to Apple, which in turn can be access on demand by governments and is even readable by ISPs! Read that article.
Thankfully, that can be mitigated by Little Snitch in Catalina and earlier versions of MacOS, but as the article states, Big Sur doesn't allow Little Snitch to block the outflow of data to Apple's servers. While most of us probably don't mind Apple knowing what apps we use, when and where we use them, the fact that an ISP or a government can easily gain access that personal info is highly disturbing to say the least. This is truly one of the biggest security and privacy related stories to come out in a long time, especially when you consider how strongly Apple has been trying to protect our privacy and personal data.
You're misinterpreting a bit of what the researcher said and what 9to5 accurately relayed in its reporting yesterday.
What gets sent back to Apple is a hash of the app that's been launched, so yes, Apple knows what app you're using, and when you launch it. But, Gatekeeper doesn't send to Apple what you're doing, how long the app is open, how long the app is active, or when the app is closed. While the hash that is sent is not further encrypted (other than being a hash), you're making a big assumption that Apple is either sharing this data, or that the hash is readable by a MITM attack by the ISP or the government.
The ISP already has your location information, and depending on locality, basically provides that to anybody who asks, so I'm not sure why the researcher is baffled by an IP giving away your location. Plus, if you have an app that connects to the internet for any reason including license authentication, the data it sends, and the port it sends it on, tells anybody watching you with a MITM attack more about you than a single hash at launch will.
This behavior has existed since Gatekeeper's launch in 2012. AI talked about it then, and I talked about it in a different venue.
This all said, we have renewed our queries to Apple about what it keeps, what it knows, and what it does with the data.
Thank you Mike, for a sensible and informative reply to these people that are jumping up and down and saying Apple is spying on us...
You're misinterpreting a bit of what the researcher said and what 9to5 accurately relayed in its reporting yesterday.
What gets sent back to Apple is a hash of the app that's been launched, so yes, Apple knows what app you're using, and when you launch it. But, Gatekeeper doesn't send to Apple what you're doing, how long the app is open, how long the app is active, or when the app is closed. While the hash that is sent is not further encrypted (other than being a hash), you're making a big assumption that Apple is either sharing this data, or that the hash is readable by a MITM attack by the ISP or the government.
The ISP already has your location information, and depending on locality, basically provides that to anybody who asks, so I'm not sure why the researcher is baffled by an IP giving away your location. Plus, if you have an app that connects to the internet for any reason including license authentication, the data it sends, and the port it sends it on, tells anybody watching you with a MITM attack more about you than a single hash at launch will.
This behavior has existed since Gatekeeper's launch in 2012. AI talked about it then, and I talked about it in a different venue.
Thank you for sharing your thoughts. However, I don't believe I have misrepresented the article, nor have I made any assumptions, as per the fact the article itself talks about PRISM as a "spying program" not me. The article raised a concern in me, and since this AI article is somewhat related, I shared my concern. That is all.
Even if one contends Apple isn't told how long my apps are open or when the app is closed, I would prefer if information about my app usage was not sent to Apple at all. The article I referenced is talking about that point, so it is relevant for each Mac user to consider.
The researcher you mention in that article is not baffled by an ISP sharing your information. He seems concerned that the unencrypted personal information that passes through the ISP could easily be shared. In other words, if that level of information was never sent to Apple, it would not pass through the ISP! That's the point here.
Since you have apparently written about this back in 2012, what specific domain should I block with Little Snitch rules to prevent this data transfer? (Not that it will help Big Sur users, as per the reasons given in the article which say Little Snitch cannot help in that case.)
You're misinterpreting a bit of what the researcher said and what 9to5 accurately relayed in its reporting yesterday.
What gets sent back to Apple is a hash of the app that's been launched, so yes, Apple knows what app you're using, and when you launch it. But, Gatekeeper doesn't send to Apple what you're doing, how long the app is open, how long the app is active, or when the app is closed. While the hash that is sent is not further encrypted (other than being a hash), you're making a big assumption that Apple is either sharing this data, or that the hash is readable by a MITM attack by the ISP or the government.
The ISP already has your location information, and depending on locality, basically provides that to anybody who asks, so I'm not sure why the researcher is baffled by an IP giving away your location. Plus, if you have an app that connects to the internet for any reason including license authentication, the data it sends, and the port it sends it on, tells anybody watching you with a MITM attack more about you than a single hash at launch will.
This behavior has existed since Gatekeeper's launch in 2012. AI talked about it then, and I talked about it in a different venue.
Thank you for sharing your thoughts. However, I don't believe I have misrepresented the article, nor have I made any assumptions, as per the fact the article itself talks about PRISM as a "spying program" not me. The article raised a concern in me, and since this AI article is somewhat related, I shared my concern. That is all.
Even if one contends Apple isn't told how long my apps are open or when the app is closed, I would prefer if information about my app usage was not sent to Apple at all. The article I referenced is talking about that point, so it is relevant for each Mac user to consider.
The researcher you mention in that article is not baffled by an ISP sharing your information. He seems concerned that the unencrypted personal information that passes through the ISP could easily be shared. In other words, if that level of information was never sent to Apple, it would not pass through the ISP! That's the point here.
Since you have apparently written about this back in 2012, what specific domain should I block with Little Snitch rules to prevent this data transfer? (Not that it will help Big Sur users, as per the reasons given in the article which say Little Snitch cannot help in that case.)
You'll need two rules: block ocsp.apple.com TCP outgoing at the System and User level.
While you can't block this in macOS in Big Sur (and later Catalina versions), if you can set rules at your router to block outgoing to the domain, you're good to go regardless.
And, in regards to the researcher from the original article that 9to5 reported on, PRISM shut down in 2019 and its legal authority expired in the same year. And, if it was still running, it would have caught all of the apps that you hit the internet with, and not been able to do anything with the hash that Apple looks at for certificate validation, like I said in my post.
Thank you William for a very well articulated commentary on an obviously humiliating mistake by Apple. I think you pretty much said everything useful that needed to be said without any grandstanding or inflated sense of victimization. Yeah, Apple made a mistake. But what separates winners from losers isn't the fact that winners never make mistakes, they do, but the fact that winners admit their mistakes and take necessary measures to minimize the probability of ever making the same mistake again in the future. Ask Michael Jordon about how many potentially game winning shots he missed.
I think Apple has demonstrated that they can do beta testing on a scale that no other company can do. It's amazing. So now's the time that they apply some of those same scaling principles to figure out how to massively stress their release day rollout process so they can uncover whatever types of weaknesses the Big Sur rollout exposed. They have tremendous computing capacity and they should be able to synthesize the massive loads and demands that were to be expected as soon as they opened the floodgates on the upgrade process. This type of load testing needs to be done beforehand - and it must include scenarios where critical system faults and failures are injected into their system. Limiting testing to "happy path" scenarios alone is a recipe for disaster, but I'd bet you'd find that it's by far the most common technique employed, and especially when the last teams to touch the release before it goes out the door, i.e., system testers, are under a lot of pressure to move things along, or much worse, asked to recover the schedule delays introduced by the upstream activities like design, coding, and integration.
Since you have apparently written about this back in 2012, what specific domain should I block with Little Snitch rules to prevent this data transfer? (Not that it will help Big Sur users, as per the reasons given in the article which say Little Snitch cannot help in that case.)
You'll need two rules: block ocsp.apple.com TCP outgoing at the System and User level.
While you can't block this in macOS in Big Sur (and later Catalina versions), if you can set rules at your router to block outgoing to the domain, you're good to go regardless.
Mike, I have one last question for you.
Does blocking that domain cause any issues? If not, it seems only logical to conclude that Apple should not need a steady stream of that data in the first place.
Your 2012 article might help me better understand what’s going on, so could you please provide a link?
I downloaded the software update on my iMac -saw the notification to do so and did so without thinking anything more of it. Absolutely disastrous! I use my iMac for work and since big sur ( big sewer) was installed my printer won’t print text only images . This is a nightmare. Printing is vital for my business and since I downloaded on Friday evening I have to wait until at least mid next week to get it repaired. Not to mention expense of repair. Am absolutely raging with apple to launch this on unsuspecting users.
In other news I was researching the new Eero Pro 6 wifi system (offered by Apple) I came across this:
"STEP 2: Create an eero account
To begin setting up your new eero network, you will need an eero account first. You will need to enter your phone number and email address. "
Now why would I need to have an account to set up my own wifi system? So I phoned Eero and was told that an authentication code is needed to activate the hardware, but I was assured that the ONLY data collected (other than my name, email and phone) was bulk anonymous usage data (how many Gb went through). BUT when I asked to see the Privacy policy (Eero is owned by Amazon now) the rep and I found this:
Types of data we (Eero) collect
“Personal Data” means data that allows someone to identify or contact you, including, for example, your name, telephone number, e-mail address, as well as any other non-public information about you that is associated with or linked to any of the foregoing data, and may also include Device Data. “Device Data” means product and performance data that are automatically collected when you use eero Devices and Application(s) to the extent that such data is associated with or linked to data that allows someone to identify or contact you, for example:
performance statistics, including network speeds, network internet service provider (ISP), and other eero Device data (e.g., temperature, CPU, memory),
network bandwidth usage statistics (i.e. the volume of data transferred and the protocol of packets),
MAC addresses for eero Devices and connected devices, IP addresses and network SSID and password,
family profile names, device hostnames, firmware data, Application clickstream, Application crash data, WiFi channel usage information, types of connected devices, the association of devices with a specific family profile, and WiFi signals from other WiFi systems in the area.
OOPS - they can, and apparently do, hoover up everything, and because the Eero sits between your modem and your computer, none of Apple's privacy measures can stop this. Further down the Privacy document it details what all Amazon can (and will) do with all that data. See:
The only thing the rep and I decided could be done would be to use a VPN (or possibly another router that the user controlled that would sit between the modem and the Eero). Both have overhead and management concerns.
The future of privacy on Apple products is looking very bleak...
Why do you say that? You clearly stated that Aero is an Amazon product, and that is their privacy policy!
When I tried to upgrade to Big Sur on Thursday it failed immediately and wouldn’t even start the download. Turns out that was a good thing as was my decision to back off and wait. Two days later, I tried again, the massive download completed in 38 minutes, the installer popped up, I started the upgrade, and it completed about 30 minutes later. No problems at all. What a difference a couple of days made. Yeah, this is still a black eye for Apple but it appears that they’ve fixed the issue from where I’m standing. Now it’s time for them to figure out what happened, make sure it doesn’t happen again, and provide the appropriate relief to those who experienced any lasting damage from this incident.
This is the part where I say that I am embarrassed to be a part of modern society where people whine and complain that they can't get their computers updated or working for a few hours, and those that write articles claiming it to be a bigger deal than it really is. People NEVER say anything about the countless days, weeks, or years that something's been working well. It's only that ONE day, or hours that the twitterverse gets their undies in a wedgie. It's embarrassing really and those that think the world is falling need to take a step back and contemplate what's really important.
I guess it's me being born before modern technology took over. I know tech's not perfect and things go wrong, but damn... some people.
Disclaimer: After all the complaining yesterday, I decided to upgrade my 2017 MBP that I rarely use just to see how bad it was. I was fully prepared to experience the same problems as others complained about. My MBP downloaded BigSur and upgraded it all in under and hour. I was shocked. I expected to leave it on the entire day/night while I do my other work. On top of that, after a few hours of using it - so far - I've had zero issues with my apps, and was pleasantly surprised that my crucial apps (Java-based) worked perfectly.
Go figure.
The "opinion piece"? Whatever. People place way too high a value on these kind of articles. Most folks have the attention-span of a gnat. Today most will have forgotten about it. By the weekend... completely forgotten about and now looking forward to their next 15-minute fix.
Apple will take this event as something they need to work out. It never ends, and it will happen again. Nothing is perfect, but funny how some expect that from others knowing what they do could certainly be put under scrutiny as well. Get over it.
The complaint is not that people couldn't download Big Sur, though that was the case, but that Apple (if this analysis is correct) managed to nuke a lot of Macs when the launched it. My entire department's Mac's were essentially bricked for about an hour and a half and none of us were trying to download the update. Applications would either not launch or launched and worked so slowly as to be unusable. I have two MacBook Pro's and they both became unresponsive at the same instant.
I will say that neither AI's news article from yesterday nor the opinion piece issued today adequately explain what happened, what caused it, how many people were affected, and why people are upset. That is why the comments here are hard to interpret.
90 minutes? Wow. There's 525,600 minutes in a year. Glass half empty kind of person? Go make a cup of coffee.
disclaimer: I'm in IT and I understand outages in our enterprise as well. We calculated that each hour of downtime at our company costs about $80,000 of lost productivity. At the same time, I also understand that everyone complains when something doesn't work, but never complements the uptime and countless weeks when everything is running smoothly and without issue. Think about it.
Technology brings amazing benefits in speed and productivity. If 90 minutes really burns your backside, maybe you should consider unplugging everything and running your company on paper & pencil and see how efficient that is. That 90 minutes will suddenly feel like nothing.
People are just a bunch a entitled whiners that either have no idea how things were, or have very short attention spans.
I’m not sure why you are being a jerk, nothing in my post attacked you. Your post actually comes off as a rant that is made more senseless by the fact you try to defend something that should not be defended. You talk about the 90 minutes as if it was some sort of planned outage where we knew ahead of time that our computers would be unusable for a specified short period of time. This was an unexpected event that virtually unplugged thousands of Macs simultaneously without warning, explanation or apology. I’m not actually that upset by the episode but it can’t be brushed off like you have done otherwise we run the risk of it happening again. Apple touts its computers’ reliability, they need to ensure this.
Since you have apparently written about this back in 2012, what specific domain should I block with Little Snitch rules to prevent this data transfer? (Not that it will help Big Sur users, as per the reasons given in the article which say Little Snitch cannot help in that case.)
You'll need two rules: block ocsp.apple.com TCP outgoing at the System and User level.
While you can't block this in macOS in Big Sur (and later Catalina versions), if you can set rules at your router to block outgoing to the domain, you're good to go regardless.
Mike, I have one last question for you.
Does blocking that domain cause any issues? If not, it seems only logical to conclude that Apple should not need a steady stream of that data in the first place.
Your 2012 article might help me better understand what’s going on, so could you please provide a link?
Thank you!
I am AFK for the remainder of the weekend, into Monday. I know my first article on it is long gone, as the MacNN content has faded into history, having been closed for over four years.
Malcolm is working on a modern explainer as we speak, which will go up at some point today.
In other news I was researching the new Eero Pro 6 wifi system (offered by Apple) I came across this:
"STEP 2: Create an eero account
To begin setting up your new eero network, you will need an eero account first. You will need to enter your phone number and email address. "
Now why would I need to have an account to set up my own wifi system? So I phoned Eero and was told that an authentication code is needed to activate the hardware, but I was assured that the ONLY data collected (other than my name, email and phone) was bulk anonymous usage data (how many Gb went through). BUT when I asked to see the Privacy policy (Eero is owned by Amazon now) the rep and I found this:
Types of data we (Eero) collect
“Personal Data” means data that allows someone to identify or contact you, including, for example, your name, telephone number, e-mail address, as well as any other non-public information about you that is associated with or linked to any of the foregoing data, and may also include Device Data. “Device Data” means product and performance data that are automatically collected when you use eero Devices and Application(s) to the extent that such data is associated with or linked to data that allows someone to identify or contact you, for example:
performance statistics, including network speeds, network internet service provider (ISP), and other eero Device data (e.g., temperature, CPU, memory),
network bandwidth usage statistics (i.e. the volume of data transferred and the protocol of packets),
MAC addresses for eero Devices and connected devices, IP addresses and network SSID and password,
family profile names, device hostnames, firmware data, Application clickstream, Application crash data, WiFi channel usage information, types of connected devices, the association of devices with a specific family profile, and WiFi signals from other WiFi systems in the area.
OOPS - they can, and apparently do, hoover up everything, and because the Eero sits between your modem and your computer, none of Apple's privacy measures can stop this. Further down the Privacy document it details what all Amazon can (and will) do with all that data. See:
The only thing the rep and I decided could be done would be to use a VPN (or possibly another router that the user controlled that would sit between the modem and the Eero). Both have overhead and management concerns.
The future of privacy on Apple products is looking very bleak...
Why do you say that? You clearly stated that Aero is an Amazon product, and that is their privacy policy!
No! It’s Apple’s fault! They have us by the balls!
Comments
I'm in the same camp as you. I downloaded Big Sur on my barely-used MacBook Pro when all the complaints about outages were going on. Not only did the entire download/install process take under an hour, I've been using it all yesterday and today and frankly, I don't see what the big deal is. It seems to be more eye-candy than anything else. It's nice to know all my apps (including some very important Java apps) worked perfectly, it don't see much difference functionally.
Even if one contends Apple isn't told how long my apps are open or when the app is closed, I would prefer if information about my app usage was not sent to Apple at all. The article I referenced is talking about that point, so it is relevant for each Mac user to consider.
The researcher you mention in that article is not baffled by an ISP sharing your information. He seems concerned that the unencrypted personal information that passes through the ISP could easily be shared. In other words, if that level of information was never sent to Apple, it would not pass through the ISP! That's the point here.
Since you have apparently written about this back in 2012, what specific domain should I block with Little Snitch rules to prevent this data transfer? (Not that it will help Big Sur users, as per the reasons given in the article which say Little Snitch cannot help in that case.)
While you can't block this in macOS in Big Sur (and later Catalina versions), if you can set rules at your router to block outgoing to the domain, you're good to go regardless.
And, in regards to the researcher from the original article that 9to5 reported on, PRISM shut down in 2019 and its legal authority expired in the same year. And, if it was still running, it would have caught all of the apps that you hit the internet with, and not been able to do anything with the hash that Apple looks at for certificate validation, like I said in my post.
I think Apple has demonstrated that they can do beta testing on a scale that no other company can do. It's amazing. So now's the time that they apply some of those same scaling principles to figure out how to massively stress their release day rollout process so they can uncover whatever types of weaknesses the Big Sur rollout exposed. They have tremendous computing capacity and they should be able to synthesize the massive loads and demands that were to be expected as soon as they opened the floodgates on the upgrade process. This type of load testing needs to be done beforehand - and it must include scenarios where critical system faults and failures are injected into their system. Limiting testing to "happy path" scenarios alone is a recipe for disaster, but I'd bet you'd find that it's by far the most common technique employed, and especially when the last teams to touch the release before it goes out the door, i.e., system testers, are under a lot of pressure to move things along, or much worse, asked to recover the schedule delays introduced by the upstream activities like design, coding, and integration.
Does blocking that domain cause any issues? If not, it seems only logical to conclude that Apple should not need a steady stream of that data in the first place.
Thank you!
Malcolm is working on a modern explainer as we speak, which will go up at some point today.