5 ms·

Last Week on My Mac: Deceived by the Finder

55 points by miles 7y ago

kirstenbirgit 7y ago
Apple really needs to spend a whole release cycle just fixing existing bugs instead of making new features. Even simple things are faltering, like when logging in, macOS stops registering keypresses in the middle of entering my password. Switching screens around when docking my MacBook Pro. Important features like Time Machine silently corrupting your files. It's such a shame that macOS just keeps getting more buggy. I've read from multiple (ex) employees that there's no real incentive to fix bugs, since employees seem only to be rewarded when they're working on prestige projects. What good is investing so much R&D into new hardware like Mac Pro when the operating system is the limiting factor?
- mixmastamyk 7y ago
  I wish Apple could multitask, but they haven’t in years.
  - saagarjha 7y ago
    Their OSes have been able to since 2001, but evidently their engineering team is much less adept ;)
    - mixmastamyk 7y ago
      Or management team.
- passerby1 7y ago
  Organizational inertia cannot allow this switch to fixing issues. That just don't happen at once because now a lot of people work in an environment rewarding them to only new feature development. This can be changed by replacing the whole tech organization motivation culture. Better at once.
  - Wowfunhappy 7y ago
    Snow Leopard happened. High Sierra too, to a lesser extent.
- basejumping 7y ago
  I had so much frustration yesterday while renting a movie from Apple TV for my kids. I wanted to view it on my wife's laptop (also a Macbook), apparently she can't download the Apple TV app unless she subscribes. I had the app from when I had the TV trial. Overall such a poor and buggy user experience, not going into details, but I hear these devs are getting 400k/yr for not giving a shit about the overall user experience.
- wlll 7y ago
  > Apple really needs to spend a whole release cycle just fixing existing bugs instead of making new features. I would pay proper old-school Mac OS release prices for this upgrade.
saagarjha 7y ago
But Finder isn’t lying here: it shows the ability to read or write the file, but from Finder’s perspective. Just because you can do that doesn’t mean any old app on your machine can by default. This is literally the manifestation of Apple plugging holes in the UNIX permissions model. You can complain all you want about “protected” directories being stupid, but arguing that Finder should show you whether an arbitrary app can access a file is just inane.
- owl57 7y ago
  Finder isn't some third-party tool released before this kernel change. Why should it not know about those plugged holes?
  - saagarjha 7y ago
    How should it present this information?
    - dmitriid 7y ago
      How about: not from Finder's point of view? There is no such thing as Finder's point of view. It must show info from the currently logged in user's point of view.
      - saagarjha 7y ago
        The entire point is that the user permissions are not accurate for an arbitrary app because of sandboxing. This is like yelling at readelf for "deceiving you" because the binary is slid around by layout randomization to somewhere else.
        dmitriid 7y ago
        https://news.ycombinator.com/item?id=22518215 https://news.ycombinator.com/item?id=22518215
      - oefrha 7y ago
GiantSully 7y ago
The battery of my 2018 MBP can not last even for 18 months before its performance decreases drastically, which is disappointing.
- zapzupnz 7y ago
  What does that have to do with anything?
listsfrin 7y ago
This reminds me of the equivalent SELinux issues. Good ideas rushed out and not packaged properly.
- cowsandmilk 7y ago
  Ivan Krstić has been trying to push this system for over a decade now. Maybe it just isn’t a good idea because over a decade of iteration and it still isn’t intuitive or exposed to the user in an understandable manner.
sibartlett 7y ago
Third-party apps are sandboxed on macOS. You have to explicitly grant them access to the file system. Finder is not lying at all. The permissions it shows in “Get Info” are the user/group permissions; not app permissions. Maybe Apple could enhance the UX somehow to better what’s going on, but I wouldn’t go as far as to say Finder is lying.
- tinus_hn 7y ago
  This is exactly the same thing as happens on Windows, the real permissions are far too complex to convey in a simple dialog. It’s just more sour grapes about SIP. Tough luck, it’s there to stay, if you don’t like it, turn it off.
  - saagarjha 7y ago
    (This isn’t SIP, technically.)
  - ksaj 7y ago
    You can see this with Linux as well. For example, with ext# file systems, extended attributes allow you to make files append-only, copy-on-write, or give files project and version numbers. It also lets you decide which files are or are not compressed if the file system is set to be compressed. Other attributes determine what happens to a file when you delete it (nothing, zeroing the sectors, etc) The chattr/lsattr commands are used for accessing them. The only time I've seen these come up are for secure locations that set log files to append-only. But I'm sure there are people out there that swear by extended attributes.
- amarshall 7y ago
  > Third-party apps are sandboxed on macOS. You have to explicitly grant them access to the file system. There’s missing nuance there. The “full disk access” and similar permissions apply even if an app is not using the traditional macOS Sandbox. Only software from the Mac App Store is required to use the traditional Sandbox, but the restrictions on disk access to certain directories apply to all processes not whitelisted (implicitly or explicitly), regardless of Sandboxing. This nuance is somewhat important because an app listed “Sandbox: No” in e.g. Activity Monitor is still subject to disk access restrictions.
blunte 7y ago
Finder is not really lying to you. It's just showing the truth from a standard viewpoint. The OS, however, creates another view from the application perspective - one which now imposes additional access rules.
IAmEveryone 7y ago
I’m failing to understand the implied outrage here? Permissions have become far more nuanced than traditional UNIX, and can no longer be understood with only chmod literacy. Apple doesn’t go out of its way to educate users about these changes because it’s supposed to be as transparent as, say, APFS’s file compression and encryption. HN has nothing but scorn usually for these “un-Professional” users that tend not to spend their time doing binary diffs on new point updates of MacOS housekeeping daemons. They do get a lot more actual work done, though. The article doesn’t even try to make any specific point how these changes hurt anybody. Indeed the author mentions that nobody would have noticed if not for people running ‘strings’ on new binaries. Millions of people have been running these changes, none of them even noticed, and all were presumably at least a bit safer than before. People at Apple must be feeling like tourists in bizzarroworld seeing people trying to scandalize this.
- zapzupnz 7y ago
  > I'm failing to understand the implied outrage here? Because it's entirely manufactured. The writer doesn't seem willing to differentiate file permissions from a sandboxed application's permissions to access the file. Once a sandboxed application is granted permission to access the file system, those file permissions still apply. For non-sandboxed applications, those permissions still apply. For non-GUI applications that run in the command line or as daemons, those permissions still apply. Nothing is inaccurate. There is no lie. File permissions and applications' permissions to escape the sandbox are separate concerns with their own user interfaces (Finder and the Security & Privacy preference pane in System Preferences, respectively). Therefore, the outrage is manufactured.

55 points by miles 7y ago

Apple really needs to spend a whole release cycle just fixing existing bugs instead of making new features. Even simple things are faltering, like when logging in, macOS stops registering keypresses in the middle of entering my password. Switching screens around when docking my MacBook Pro. Important features like Time Machine silently corrupting your files. It's such a shame that macOS just keeps getting more buggy. I've read from multiple (ex) employees that there's no real incentive to fix bugs, since employees seem only to be rewarded when they're working on prestige projects. What good is investing so much R&D into new hardware like Mac Pro when the operating system is the limiting factor?

mixmastamyk 7y ago
I wish Apple could multitask, but they haven’t in years.
- saagarjha 7y ago
  Their OSes have been able to since 2001, but evidently their engineering team is much less adept ;)
  - mixmastamyk 7y ago
    Or management team.
passerby1 7y ago
Organizational inertia cannot allow this switch to fixing issues. That just don't happen at once because now a lot of people work in an environment rewarding them to only new feature development. This can be changed by replacing the whole tech organization motivation culture. Better at once.
- Wowfunhappy 7y ago
  Snow Leopard happened. High Sierra too, to a lesser extent.
basejumping 7y ago
I had so much frustration yesterday while renting a movie from Apple TV for my kids. I wanted to view it on my wife's laptop (also a Macbook), apparently she can't download the Apple TV app unless she subscribes. I had the app from when I had the TV trial. Overall such a poor and buggy user experience, not going into details, but I hear these devs are getting 400k/yr for not giving a shit about the overall user experience.
wlll 7y ago
> Apple really needs to spend a whole release cycle just fixing existing bugs instead of making new features. I would pay proper old-school Mac OS release prices for this upgrade.

saagarjha 7y ago

But Finder isn’t lying here: it shows the ability to read or write the file, but from Finder’s perspective. Just because you can do that doesn’t mean any old app on your machine can by default. This is literally the manifestation of Apple plugging holes in the UNIX permissions model. You can complain all you want about “protected” directories being stupid, but arguing that Finder should show you whether an arbitrary app can access a file is just inane.

owl57 7y ago
Finder isn't some third-party tool released before this kernel change. Why should it not know about those plugged holes?
- saagarjha 7y ago
  How should it present this information?
  - dmitriid 7y ago
    How about: not from Finder's point of view? There is no such thing as Finder's point of view. It must show info from the currently logged in user's point of view.
    - saagarjha 7y ago
      The entire point is that the user permissions are not accurate for an arbitrary app because of sandboxing. This is like yelling at readelf for "deceiving you" because the binary is slid around by layout randomization to somewhere else.
      - dmitriid 7y ago
        https://news.ycombinator.com/item?id=22518215 https://news.ycombinator.com/item?id=22518215
    - oefrha 7y ago

GiantSully 7y ago

The battery of my 2018 MBP can not last even for 18 months before its performance decreases drastically, which is disappointing.

zapzupnz 7y ago
What does that have to do with anything?

listsfrin 7y ago

This reminds me of the equivalent SELinux issues. Good ideas rushed out and not packaged properly.

cowsandmilk 7y ago
Ivan Krstić has been trying to push this system for over a decade now. Maybe it just isn’t a good idea because over a decade of iteration and it still isn’t intuitive or exposed to the user in an understandable manner.

sibartlett 7y ago

Third-party apps are sandboxed on macOS. You have to explicitly grant them access to the file system. Finder is not lying at all. The permissions it shows in “Get Info” are the user/group permissions; not app permissions. Maybe Apple could enhance the UX somehow to better what’s going on, but I wouldn’t go as far as to say Finder is lying.

tinus_hn 7y ago
This is exactly the same thing as happens on Windows, the real permissions are far too complex to convey in a simple dialog. It’s just more sour grapes about SIP. Tough luck, it’s there to stay, if you don’t like it, turn it off.
- saagarjha 7y ago
  (This isn’t SIP, technically.)
- ksaj 7y ago
  You can see this with Linux as well. For example, with ext# file systems, extended attributes allow you to make files append-only, copy-on-write, or give files project and version numbers. It also lets you decide which files are or are not compressed if the file system is set to be compressed. Other attributes determine what happens to a file when you delete it (nothing, zeroing the sectors, etc) The chattr/lsattr commands are used for accessing them. The only time I've seen these come up are for secure locations that set log files to append-only. But I'm sure there are people out there that swear by extended attributes.
amarshall 7y ago
> Third-party apps are sandboxed on macOS. You have to explicitly grant them access to the file system. There’s missing nuance there. The “full disk access” and similar permissions apply even if an app is not using the traditional macOS Sandbox. Only software from the Mac App Store is required to use the traditional Sandbox, but the restrictions on disk access to certain directories apply to all processes not whitelisted (implicitly or explicitly), regardless of Sandboxing. This nuance is somewhat important because an app listed “Sandbox: No” in e.g. Activity Monitor is still subject to disk access restrictions.

blunte 7y ago

Finder is not really lying to you. It's just showing the truth from a standard viewpoint. The OS, however, creates another view from the application perspective - one which now imposes additional access rules.

IAmEveryone 7y ago

I’m failing to understand the implied outrage here? Permissions have become far more nuanced than traditional UNIX, and can no longer be understood with only chmod literacy. Apple doesn’t go out of its way to educate users about these changes because it’s supposed to be as transparent as, say, APFS’s file compression and encryption. HN has nothing but scorn usually for these “un-Professional” users that tend not to spend their time doing binary diffs on new point updates of MacOS housekeeping daemons. They do get a lot more actual work done, though. The article doesn’t even try to make any specific point how these changes hurt anybody. Indeed the author mentions that nobody would have noticed if not for people running ‘strings’ on new binaries. Millions of people have been running these changes, none of them even noticed, and all were presumably at least a bit safer than before. People at Apple must be feeling like tourists in bizzarroworld seeing people trying to scandalize this.

zapzupnz 7y ago
> I'm failing to understand the implied outrage here? Because it's entirely manufactured. The writer doesn't seem willing to differentiate file permissions from a sandboxed application's permissions to access the file. Once a sandboxed application is granted permission to access the file system, those file permissions still apply. For non-sandboxed applications, those permissions still apply. For non-GUI applications that run in the command line or as daemons, those permissions still apply. Nothing is inaccurate. There is no lie. File permissions and applications' permissions to escape the sandbox are separate concerns with their own user interfaces (Finder and the Security & Privacy preference pane in System Preferences, respectively). Therefore, the outrage is manufactured.