Live data from Hacker News

Apple removes first-party firewall exemption in macOS 11.2 beta 2

twitter.com

281–290 of 354 posts

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#281
post #255

Earlier quoted context omitted.

When Apple launched iOS 6, it was the first operating system to include per-app privacy controls around access to things like microphone, camera, photos, etc. Controls we consider fundamental today. It did not mention it a single time in any of its PR or marketing at all. The first reference you find to it will be from Apple blogs who were surprised to stumble upon it in the iOS 6 beta. It took Android two more years…

The first except for Blackberry. Before IOS or Android even existed Blackberry had granular per app permissions. I don't disagree with your argument though, of the modern mobile OSs Apple moved to towards the per-app model before everyone else. I just find it interesting when Apple or Android gets coverage/credit for a feature that has long existed but was forgotten or ignored.

The problem is BB wasn't around by the time smartphones became more than a niche product.

The list of prior work that influenced Apple, or any tech company, is usually far too long to list.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#282

Earlier quoted context omitted.

IMO that's a big problem. They are completely different risk categories. My FDE password is absurdly long and complicated, since I never want someone who gains physical access to get all my data, but my Linux user account password isn't as long since it's main purpose is to stop someone from getting passed my lock screen if I was to leave my system unattended.

Both are 'physical access'. If one does not power down your system, your FDE is unlocked. So they only need your Linux user account password to get access to the data on your disk. FDE only protects your data when it's locked. Normally this is when your system is shut down.

The main difference is in the attack surface. Attacking the FDE can happen offline with infinite attempts with a large-scale operation dedicating lots of compute power. Breaking my user password has to happen on site at that exact moment and my lock screen can detect N number of failed logins and shutdown.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#283
post #255

Earlier quoted context omitted.

When Apple launched iOS 6, it was the first operating system to include per-app privacy controls around access to things like microphone, camera, photos, etc. Controls we consider fundamental today. It did not mention it a single time in any of its PR or marketing at all. The first reference you find to it will be from Apple blogs who were surprised to stumble upon it in the iOS 6 beta. It took Android two more years…

The first except for Blackberry. Before IOS or Android even existed Blackberry had granular per app permissions. I don't disagree with your argument though, of the modern mobile OSs Apple moved to towards the per-app model before everyone else. I just find it interesting when Apple or Android gets coverage/credit for a feature that has long existed but was forgotten or ignored.

Actually, BB10 had an even better feature, you could provide dummy data to wrapped Android applications. So you could fill the Android contact data with an empty contact list and the app would be none-the-wiser. This feature was never advertised.

But noone bought the phones so who cares?

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#284
post #219

Earlier quoted context omitted.

XWayland is essentially a translation layer consisting of Xserver and Wayland client [0]. Therefore it has all the same problems a normal Xserver has, which they do acknowledge: > A Wayland compositor usually spawns only one Xwayland instance. This is because many X11 applications assume they can communicate with other X11 applications through the X server, and this requires a shared X server instance. This also mean…

That does not sound different from what Windows does. By default all programs running under the same user can access all windows of other applications (except UAC elevated ones). It's a relic from when OLE and Clipboard in Windows 3 just was (very simplified) a pointer to RAM.

The only reason it is worse with X11 is that it is an inherently networked protocol, so the same statements also apply to any remote connections you might allow to your X server. It also makes it somewhat easier to capture Xkb / Xinput events purely through API, without need for any elevation or excessive polling of the devices ("it just works").

That includes any systems you might have SSHed into with X forwarding enabled, as it automatically extends the trust there. Yes, your ssh client might try to enable X SECURITY extension (which clamps acesss to just the current window), but it is disabled by default or bypassed anyway by the users as that extension is known to crash quite a few programs.

Both are a product of their time when the prevailing approach was to trust the programs you run.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#285

Earlier quoted context omitted.

When Apple launched iOS 6, it was the first operating system to include per-app privacy controls around access to things like microphone, camera, photos, etc. Controls we consider fundamental today. It did not mention it a single time in any of its PR or marketing at all. The first reference you find to it will be from Apple blogs who were surprised to stumble upon it in the iOS 6 beta. It took Android two more years…

If you’re curious about more of the history (now, almost a decade ago), this was the scandal that likely motivated the above: https://www.theverge.com/2012/2/7/2782947/path-ios-app-user-... Congresspeople sent letters to app developers as a result (not even Apple, ha). iOS 6 was then seeded to the public four months after that article. But! It actually goes earlier than this. Apple started phasing out access to devic…

If it was seeded 4 months after the article, it had absolutely nothing to do with the article.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#286

I am glad that the public backlash forced them to fix a deliberate BACKDOOR that they had introduced (by design) in the Network Extension Framework that macOS Big Sur now forces all the firewalls to use. (At least, they claim to have removed it). But it is hard to trust them again, and I would prefer to use a firewall that uses its own kernel extension to manage the network than using Apple's API again. (Obviously th…

> I am glad that the public backlash

Due in no small part to HN. If it weren't for this community, the word would not have spread as far as it did to pressure them to make this change.

Thanks to all of you and everyone at HN who works hard to keep this place as awesome as it is.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#287
post #158

This firewall issue isn't the only privacy feature strip from Big Sur release. Unfortunately no big media care about other huge problem Apple introduced. My only hope they will also fix full disk encryption in this update. Since Big Sur broken installation of macOS on passphrase-encrypted disk partitions. I bought into M1 hype and now it's end up that you no longer able to have separate password for the disk encrypti…

Is it no longer possible to set a separate password by reformatting the disk in Recovery to one of the "Encrypted" options before (re-)installing to that volume?

That's how I set up multiple passwords for FDE on a recent hackintosh build, but I don't have an M1 and this wasn't Big Sur, so maybe I'm missing something obvious that has changed lately and I'm way off-base.

It had to manually be done in that order though, otherwise it defaulted to the user account password for FDE.

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#288
post #249

I am glad that the public backlash forced them to fix a deliberate BACKDOOR that they had introduced (by design) in the Network Extension Framework that macOS Big Sur now forces all the firewalls to use. (At least, they claim to have removed it). But it is hard to trust them again, and I would prefer to use a firewall that uses its own kernel extension to manage the network than using Apple's API again. (Obviously th…

It’s inaccurate to say “Apple selling user data to US government”. That’s not what the article claims (the word “sell” doesn’t even appear in the text), and there are in fact many consumer data brokers who really do sell data to law enforcement.

I don't think it's inaccurate; the IC pays the data providers (presumably for implementation/overhead) for receiving the FAA702 (PRISM/FISA) data.

Which data is picked by the US government, and no warrant is required. Apple provided data on 30,000+ users to the US government without a warrant in 2019, per their own transparency report.

If they received money for the program, they are indeed "selling user data to [the] US government".

Re: Apple removes first-party firewall exemption in macOS 11.2 beta 2

#290
In Case You Didn't Know:

Big Sur on M1 (and possibly on Intel) maintains a persistent, hardware-serial-number linked TLS connection to Apple (for APNS, just like on iOS) at all times when you are logged in, even if you don't use iCloud, App Store, iMessage, or FaceTime, and have all analytics turned off.

There's no UI to disable this.

This means that Apple has the coarse location track log (due to GeoIP of the client IP) for every M1 serial number. When you open the App Store app, that serial number is also sent, and associated with your Apple ID (email/phone) if you log in.

Apple knows when you leave home, or arrive at the office, or travel to a different city, all with no Apple ID, no iCloud, and no location services.

This has always been the case on all devices using iOS, too.

This change is essential for blocking such traffic, and I'm glad for it, but there is a long way to go when it comes to pressuring the pro-privacy forces inside of Apple to do more.

Post reply on HN