Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nice to see that Apple isn't so big that it doesn't think it has to listen to reasonable/rational public feedback that it is making poor decisions.

Now, if they could empower lower levels to make these decisions before the issues blow up in the wider world context, all the better.



Having worked at Apple and other big companies it's almost always Engineers and PMs making these decisions. It's not like Tim Cook or Craig Federighi is running around demanding people add Apple apps to a firewall exclusion list. They have much bigger things to worry about.

It's just that as an engineer you are often in a bubble and can't foresee every implication of your decision. That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback. And on this occasion just like on many other they will take action if necessary.


> That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback. And on this occasion just like on many other they will take action if necessary.

Except that Apple did not take action. Firewall developers such as Little Snitch did become aware of the issue during the beta releases and gave feedback to Apple, which Apple ignored and shipped it anyway to the public. https://blog.obdev.at/a-hole-in-the-wall/


> Except that Apple did not take action.

Look, I don't mean to criticise. But how do you know that Apple didn't start working on a fix when they were told about it?

Apple doesn't exactly say when they start working on a fix for something, or else we would have known earlier.


It's not up to customers to assume the good intentions of a large organization. Apple has internal decisions and processes that result in them not communicating in a timely manner. Whatever fallout from that is on them.


There was a ContentFilterExclusionList key in the /System/Library/Frameworks/NetworkExtension.framework/Versions/Current/Resources/Info.plist file. macOS 11.2 beta 2 removed the ContentFilterExclusionList. Does that take 6 months?


Noticing the issue, discussing it, setting meetings to agree to revert, and handling all other higher priority stuff before an eminent GM release and the most pressing x.1 update release, can take more than 6 months.

Not to mention that "removing the ContentFilterExclusionList" is a hacky fix suggestion. Doesn't mean it's the actual hollistic fix, and there weren't other under the hood changes for this issue.


> Not to mention that "removing the ContentFilterExclusionList" is a hacky fix suggestion.

You've got in backwards. The ContentFilterExclusionList was itself a hack. It never should have existed.

Some people are handwaving about a mysterious vague problem that calls for a ContentFilterExclusionList, but Little Snitch has existed for many many years on the Mac and has been able to block everything, including Apple services. There was no problem with that until Apple decided to exempt itself from getting blocked.


>You've got in backwards. The ContentFilterExclusionList was itself a hack. It never should have existed.

It might or might not be a hack, but that's orthogonal to the functionality or whether it uses a ContentFilterExclusionList.

The fact that it wasn't there before, or that it is a misguided feature idea, doesn't mean it was done as a quick and dirty implementation or that it's hastily made feature done via cutting corners.

If you accept the need for your own apps to bypass user application filtering (eg. because you consider your traffic/apps integral to the OS operation) then that's the kind of thing you'd implement -- and you could do it with a team of 100, working for months with fine specs, to deliver the same thing.

There's nothing inherently hacky about it.

>There was no problem with that until Apple decided to exempt itself from getting blocked.

That's neither here nor there though, as to whether it was done as a hack - or, to get back to the point, as to whether they could just rip it off trivially.

People forget this is not just a single feature, but part of a change to how network filtering is done (not through a third party kernel extension anymore), accompanied with new APIs.


> doesn't mean it was done as a quick and dirty implementation or that it's hastily made feature done via cutting corners.

I wasn't implying that. The ContentFilterExclusionList was already present in the first WWDC beta and could have been there internally for many months prior, who knows. I was using "hack" more in the sense of bypassing a security system. I said "It never should have existed", which is not a comment on the quality of the design of the thing that did exist.

> People forget this is not just a single feature, but part of a change to how network filtering is done (not through a third party kernel extension anymore), accompanied with new APIs.

I'm not "people". I'm well aware and haven't forgotten. I've been a professional Mac developer for 15 years. I've used the Network Extension API myself. You may remember me from such news stories as the Mac OCSP appocalypse. https://techcrunch.com/2020/11/15/apple-responds-to-gatekeep... It's incredibly tiresome when HN commenters try to "Macsplain" to me.


>It's incredibly tiresome when HN commenters try to "Macsplain" to me.

Isn't it also tiresome when people on HN assume we know who they are from their handle, or that we are somehow obliged to have followed them outside HN, and remember/know who they are?

I might recognize pg, or patio11, or tptacek, and a few more, but not everybody. And most handles, I just glaze over, they are not the important part in the discussion. I'm pretty sure most of us on HN have dozens of HN handles that we don't otherwise know who they are, or even keep tabs on from one HN thread to another.

I wouldn't try to "Macpslain" if your comment didn't seem to me to imply that this is just some an isolated thing with ContentFilterExclusionList, that can just be reversed like that, or if it mentioned that this is part of an extensive change to how network filters / kernel extensions work (or rather, don't work anymore) in Big Sur.


> Isn't it also tiresome when people on HN assume we know who they are from their handle

No, I don't expect people to know who I am. However, I do expect people to avoid assuming that I'm ignorant of the subject at hand. This ought to be the default approach you have toward anyone.

In this same thread, I was referred to as "My sweet summer child", as if I didn't understand software development at all. This shouldn't happen, regardless of whether you know me or not. https://news.ycombinator.com/item?id=25771925


> Does that take 6 months?

If this one change is in a pool with tens of thousands of other possible changes, and it also has to go through one or more QA cycles? Sure, why not 6 months?


In some industries 6 months from initial report to consumer deployment would sound almost irresponsibly fast.


> Sure, why not 6 months?

Because the first WWDC preview version of Big Sur was released to developers on June 22, 2020, and Big Sur was released to the public on November 12, 2020, so Apple needs to be able to fix issues identified during the beta period much quicker than in 6 months.


Apple doesn't have to "fix issues identified during the beta period" much quicker than the release date.

No OS does, including FOSS distros / OSes.

Apple just has to fix "the most important issues" with the most bang for the buck identified during the beta period before release.

Which they do.

The ones they consider less important are put in a backlog.

You can find "issues identified during beta releases" still open and unfixed for all OSes, some even going 10 years back, long after the release was out...


> The ones they consider less important are put in a backlog.

True, but this just proves my point. It still doesn't take 6 months to fix this issue... if they wanted to fix it. Deprioritizing it was a deliberate choice by Apple. The reason the exclusion list shipped to the public in Big Sur wasn't technical, the reason is that Apple's priorities are messed up.

From my perspective, the explanation is simple: ContentFilterExclusionList wasn't a "bug", it was a deliberate "feature". So from Apple's perspective, there was nothing to "fix". At least one developer was told it "behaves as intended": https://twitter.com/david_ddw/status/1329017113709842437

Only the public backlash caused Apple to remove it.


>True, but this just proves my point. It still doesn't take 6 months to fix this issue... if they wanted to fix it.

Just because it was reported as an issue doesn't mean it was thought as a bug (or an issue to fix) by Apple. That's what they wanted to do. People coded it explicitly.

>Deprioritizing it was a deliberate choice by Apple.

Of course. Why wouldn't it be?

>From my perspective, the explanation is simple: ContentFilterExclusionList wasn't a "bug", it was a deliberate "feature".

Again, of course. Some people complained this was a bug, Apple thought it wasn't, the issue remained on the back burner, until some time it was given more consideration and was decided to fix.

What I'm saying is "why this took 6 months" doesn't make much sense as a question. Why wouldn't it? Unless something is a show stopper or high impact bug, it would take time. Even to be accepted as an issue to fix in the first place will take time. Plus all the internal red tape.


> What I'm saying is "why this took 6 months" doesn't make much sense as a question. Why wouldn't it?

For the 2nd or 3rd time in this thread, I have to remind that I was replying to a comment saying this: "That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback. And on this occasion just like on many other they will take action if necessary." So, maybe you should argue with that comment instead of with me?

My point was that developers filed feedback about this issue during the betas, yet Apple did not address that feedback, and thus "That's why Apple has the Developer and Public Beta releases for iOS/OSX" is not a valid point in this context.


>My point was that developers filed feedback about this issue during the betas, yet Apple did not address that feedback, and thus "That's why Apple has the Developer and Public Beta releases for iOS/OSX" is not a valid point in this context.

Well, to that I agree.


> Does that take 6 months?

You're assuming that changing that list is the only thing they needed to do. Have you thought about why they felt they needed that list to begin with? Maybe because they wanted to quality control that all their core services could graceful handle being blocked by a firewall first? That is, the job wasn't changing the list. The job was probably quality control of everything potentially blocked by that list.

Or they just didn't think it was such an important issue. Most MacOS users by far probably don't care.


> You're assuming that changing that list is the only thing they needed to do.

No, you're assuming that I'm making that assumption. Why would you assume that?

> Most MacOS users by far probably don't care.

It's frustrating that people keep ignoring the fact that I was directly replying to this comment: "That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback."

If feedback during the betas does not make Apple take action, then the comment I was replying to was wrong.

Your response seems a bit ironic, though, because public backlash is exactly what caused Apple to backtrack.


It’s possible they were working on other changes so firewalls didn’t break the whitelisted components.

They shouldn’t have been broken in the first place, but hey.


My sweet summer child I hope you never have to develop or schedule software releases at a level of complexity where 6 months sounds anything less than luxurious.


I've been a professional Mac software engineer for 15 years.

I've also lived my entire life in the North (which for some reason is called the Midwest).


See other comment re: realizing who I was responding to. Also I spent last winter up there (Saint Paul).


Why do you think Apple should've solved this issue immediately? I'm sure you (and the other people in this thread) care a lot about the firewall exception, but from the perspective of Apple this must've been a non-critical issue at best. I don't understand why you assume Apple should've dropped everything and fixed this as soon as it was reported. And clearly, as opposed to what you say, they did take action - otherwise they'd never have removed it.


> from the perspective of Apple this must've been a non-critical issue at best.

From the perspective of Apple, this wasn't even an issue at all. It "behaves as intended". https://twitter.com/david_ddw/status/1329017113709842437 So that's why Apple didn't fix it. You don't fix something that you don't think is broken.


To be “fair”, it’s a fairly well known secret that official feedback channels for all Apple software are basically a trash chute.


It's reasonable not to take action based on the feedback from a developer who sells an app-level firewall - it's neither a broad nor disinterested constituency. Big Sur's been out for less than two months - for a bigass company, it's decent turnaround.


Who else would Apple take feedback from during the betas? Who else would even notice that there was a hole in the firewalls except the firewall developers?


The gigantic majority of users who are not firewall developers as well as the gigantic majority who never touches the betas both seem like sensible and important sources of feedback.


> the gigantic majority who never touches the betas

I was replying to a comment that literally said, "That's why Apple has the Developer and Public Beta releases for iOS/OSX", so maybe you should argue with that comment instead of with me.


> Having worked at Apple and other big companies it's almost always Engineers and PMs making these decisions.

I wonder what the backstory to the original decision was.

Pure speculation: a "bug" was reported in which something was broken, and it turned out to be because a third party firewall was blocking access to some Apple-hosted service, and someone started working on "how to fix the bug", and the "bugfix" was to make sure third party software can't do that.


This sounds like a credible situation an engineer may come up with and implement without thinking through the reality of what they're doing.


> Having worked at Apple and other big companies it's almost always Engineers and PMs making these decisions. It's not like Tim Cook or Craig Federighi is running around demanding people add Apple apps to a firewall exclusion list. They have much bigger things to worry about.

This more or less confirms my hunch. Thanks for inside perspective on it. That’s how literally every other org works but I know Apple got this reputation for having a very executive-micromanaged culture under both Jobs eras, it’s good to have a reminder that at the end of the day it’s not the borg.


> it’s good to have a reminder that at the end of the day it’s not the borg.

The impression I always got was more like a mid-to-late USSR than the Borg (in structure rather than efficacy, the USSR didn't work, apple does). Everyone in the Borg is (supposed to be) identical, whereas Apple seems like a structure of lots of groups of often brilliant people working in seperate-but-equal subtrees, working under a (especially under Jobs) ideologically-inspired dictator from the top down. The way Apple are fairly reticent to document what they make partly informs the comparison.


I think their reticence to document is more a function of how long they’ve been able to get away with not doing it. Almost every engineering culture that finds that balance unfortunately embraces it.


IMO Apple move too fast and try do too much. They're always shipping half baked features and making bad decisions like this.


This happened so quickly I suspect there was never a decision for or against. Pretty likely a boneheaded engineer did what us boneheaded engineers do and cut corners, likely with all of the fun boneheaded management and deadlines that come along for the ride.

Why, you might ask, would this be a matter of cutting corners? Well, fault tolerance is hard. What happens when the OS can’t reach external services it depends on for security features? Well, Apple found out recently in quite an embarrassing way. Given the almost immutable yearly release cycle, I would be astonished if they didn’t just duct tape some whitelist in because a more resilient solution wasn’t ready.


The imagined timeline of this comment doesn't seem to align with reality. The exclusion list was already present in the first WWDC builds in summer 2020, as the Little Snitch developers noticed: https://blog.obdev.at/a-hole-in-the-wall/

The Mac "OSCP appocalypse" occurred in November on the day that Big Sur was released to the public, with the exclusion list still present, and a number of firewall developers were already aware of the exclusion list and had reported bugs to Apple.


I don't think the comment you're replying to made specific claims about this timeline.


You’re right, I didn’t. Thank you for saying so with much more clarity than I probably would have.


> This happened so quickly

This was your claim. What is the justification for the claim? The comment seemed to imply that it was the OCSP problem. Otherwise, no other explanation was offered by the comment.


It happened quickly on the heels of the public release. The problem I cited was about how embarrassing a half assed solution could be, not about prompting a different response.

Good engineers who boneheadedly cut corners are already tracking their omissions and FIXMEs. The fact that they shipped and quickly turned around a better solution reads to me like engineers doing their dang job.

Edit: I just realized who I responded to and even if we don’t see it the same way I just want to say I appreciate your work and even your particular cynicism.


Given how they have been always marketing on the privacy aspect, and this exception they made for themselves has been found out and shown to be bad for privacy, I'm not surprised.


Curious why you phrased Apple listening to their customers in such a negative way. Maybe from pessimism bias?

I observe a lot of HN commenters don't vibe with how Apple controls & develops their ecosystem. Yet, instead of go elsewhere, complaining and acting like being oh so very special enough to know how things should be done is preferred; while expecting a major company to just cater to their personal whims.

I'm unsure if it's entitlement I'm witnessing or just people that feel like they have no faith in Apple's competition at making anything better than Apple currently has.


To be honest I think having a pessimism bias towards large corporations is healthy. Sure, they might in the end do a good thing (or a less harmful thing than they could have), but they have a huge amount of power and very little oversight.

I like Apple products, but I try to avoid any illusion that they’re good guys on a corporate scale. They’ve proven they’re not in a lot of ways (see many recent articles about their labor practices). That doesn’t mean every thing they do should be equally scrutinized with a pessimistic predisposition. But I really don’t fault anyone for assuming a large for profit organization will prioritize their own priorities over everything else.

The thing I try to moderate that with is understanding their actual priorities and not just falling into blind cynicism.


Well, I've had a Mac continuously since the original 128k Mac, so I'm pretty well situated as an observer of all things Apple and more knowledgeable about their history and their machines/software then the vast majority of their employees, some of whom are close friends.

I want them to listen, since the decisions they make affect the ecosystem I've adopted for my extended family (for whom I'm the main technical point of contact,) and poor ones will affect me and them disproportionately.

So to me, it doesn't feel at all like entitlement, rather, the wishes of a longtime, loyal customer hoping they continue down the path of listening to those of us who have promoted their products and helped make them successful.


>have no faith in Apple's competition at making anything better than Apple currently has.

110% this.

Other laptops are awful hardware. Including the Dell XPS line and the new thinkpads.


There is no call to invent reasons of entitlement or faithlessness in engineering prowess when the desire is simply to control your own device.


I think your second point is next to impossible, businesses make mistakes no matter how much they try to stop them and what makes them who they are is how they respond.

In this case Apple responded well and that's great. We don't know how many of these decisions are already being squashed each day through appropriate governance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: