Comment by veidr | Hacker News Reader

Comment by veidr | Hacker News Reader

Parent Full thread

I agree, it's terrible. As a user, I often go to pains to avoid getting the App Store version of an app, if an alternative exists, because those apps are crippled to such a degree that they aren't worth using.

If I'm using the App Store stuff, then my text editor can't edit all my files, my video player can't open videos when I double-click them, my Evernote can't print to PDF, my disk usage analyzer can't analyze my disk because it can't ask me for authorization to do so, and so on.

At the same time, though, in theory I do want sandboxing, at least by default. I do want to have to explicitly authorize some random app before it can install a printer system extension, or before it can scan my entire disk.

I feel like the problem is more political/cultural: Apple prioritizes their low-information, low-computer-literacy users (hi, Dad!) so dearly, that they aren't willing to expend resources to find any compromise for their technically proficient ones. And through the sandboxing requirements, they force their third-party developers to either tell their power users to fuck off, or to give up on the App Store.

Or, I don't know, perhaps they just don't have enough engineers left for the Mac after moving so many of them to their higher-volume Candy Crush console business.

Regardless, though, if there were mechanisms for the user to control the sandboxing enforcement to a greater degree, I would be all for it.

If we could tell our Macs "yes, dude, I hereby authorize DaisyDisk to see all the files" and "Computer, hey bud do me a favor, overrule this restriction that says CotEditor can't ask me to authorize modifying root-owned files", then I would actually not only be happy with, but even prefer, the App Store versions.

But we can't, and it's sad.

I feel completely the same.

The problem though, if you allow for user overrides, then the next TotallyNotShadyVideoPlayer will kindly ask you to add the manual override for "can't read the screen" and, if you agree, it'll steal your credentials. That is, regular users will be easy to selfpwn.

I don't think this can be solved on the software side. It's "security vs. usefulness, pick one" kind of situation. Maybe we need to tackle the human factor - make it easier to prosecute malicious code authors - but not sure if that's any more possible to implement than software that's both useful and secure.

Yep, that's what I meant: Apple's stance is, We can't let veidr override sandbox limitations, because then his dad might get pwned.

That's true, as far as it goes. My view is, maybe you make the dialog to do that scary enough; maybe you have to go enable some security setting to even make the dialog possible; maybe, even so, you have to accept that some users like my dad will get fooled and exploited.

OTOH, it's already a slippery slope; even more secure would be to completely prohibit all third-party software entirely.

I think they are drawing the lines wrong.

History shows that if the dialog shows up often enough people will simply hit accept/ok/whatever without reading what it is about.

> maybe you have to go enable some security setting to even make the dialog possible

This sounds like you're on the right track. Make it a shell command you have to execute with SIP disabled.

> If I'm using the App Store stuff, then my text editor can't edit all my files, my video player can't open videos when I double-click them, my Evernote can't print to PDF, my disk usage analyzer can't analyze my disk because it can't ask me for authorization to do so, and so on.

I fail to see how the macOS sandbox prevents this. Disk usage analyser can ask you for disk access, sandboxed video players can surely open files double clicked in Finder, sandboxed apps can print to PDF.

A few example: QuickTime Player is sandboxed, Pages is sandboxed.

> I fail to see how the macOS sandbox prevents this

I think you might be thinking of the reasonable sandbox we wish we had, not the one we have.

https://daisydiskapp.com/manual/4/en/Topics/Editions.html

(Apple's own apps do not have to follow the rules that third-party apps do.)

Ok, that's a limitation. What about the other ones you described? I wrote a bunch of sandboxed app, and it's good enough for a document based app (when working on a single document).

The sandbox allows apps to open files via three methods:

* Open dialogs

* A limited number of files that have been opened in the past via open dialogs (intended for e.g. recent files)

* Files that live in the app's sandboxed region of the filesystem.

That's it. So your text editor can't open ~/.bash_profile unless it pops up an open dialog and asks you to manually click it.

Which is a good thing for most users, just not the power users that would potentially want their editor to open ~/.bash_profile (although the downside is that if they were allowed to do so, they could do so silently as well... which is the problem Apple is trying to solve for).

How exactly is that a problem? You can open an open file dialog that is in the user's home directory and you can even select ".bash_profile" for them. All they have to do is click "OK" to start editing it. This gives them the security that your app can't just go and erase or overwrite or add malicious stuff to their .bash_profile without their consent, which seems like a really good idea!

I'm a bit confused - if I explicitly want my text editor to open ~/.bash_profile, then I need to tell it that, which I would do through the Open dialog for GUI apps (or as a command line parameter for command line apps); and if I don't explicitly want to do so, then it probably shouldn't be opening it behind my back.

This sandboxing would be a problem with editors that naturally work with multi-file projects (e.g. an IDE where you'd want to open a whole Java project of linked files), but in the text editor scenario this limitation seems to make sense.

Those examples don't make any sense. All of them are possible within sandbox except perhaps the disk usage analyser.

> Evernote can't print to PDF

Yes it can. The print dialog has a whole PDF menu.

Ugh, sorry, my bad; this one, I misstated. I meant that Evernote (App Store version) isn't allowed to have the "Save PDF to Evernote" feature.

That feature is very useful, though; it can save anything, from any app that can print, to Evernote.

That's not true either. You can definitely save PDF in Evernote on the Mac (btw, there's only the App Store version of Evernote if your discount the web version).

To save PDF into Evernote on the Mac:

- if it's a file- use the share option (right click>Share>Evernote) - if it's in a browser- in Safari click on share (top right hand corner of the browser) > Evernote. If it's in Chrome, AFAIK, you have to use Evernote Web Clipper (extension) which is also available for Safari. - Of course, you can also copy/paste or drag and drop PDF into Evernote

I am talking about the feature whereby any app that can print can print directly to Evernote, as a PDF. This feature is very useful, though web clipper and the Sharing extension offer workarounds for some applications.

Screenshot: https://www.dropbox.com/s/xt4xqcr4lp1tpvh/Screenshot%202018-...

I personally am happy with subscription based applications in the App Store. I feel more confident that Apple will manage my credit card information better than unknown application developer.

Reply on news.ycombinator.com