- BETTERTOUCHTOOL PERMISSIONS FOR MAC
- BETTERTOUCHTOOL PERMISSIONS INSTALL
- BETTERTOUCHTOOL PERMISSIONS CODE
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. Regardless, though, if there were mechanisms for the user to control the sandboxing enforcement to a greater degree, I would be all for it. 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. 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. 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.
BETTERTOUCHTOOL PERMISSIONS INSTALL
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. 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.Īt the same time, though, in theory I do want sandboxing, at least by default. 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. But force Mac devs to castrate their apps even more, and there won't be anything left to protect.
BETTERTOUCHTOOL PERMISSIONS CODE
IMO Apple should drop the Mac app sandbox altogether (though continue to sandbox system services, which is totally sensible, and maybe retain something geared towards browsers.) The code signing requirements and dev cert revocation, which has been successfully used to remotely disable malware, will be sufficient security: the Mac community is good at sussing out bad actors. The price is far too high and the benefits too little. In return it offers security inferior to a web app, as this post illustrates.
BETTERTOUCHTOOL PERMISSIONS FOR MAC
For Mac apps to survive, they must capitalize on their strengths: superior performance, better system integration, better dev experience, more features, and higher general quality.īut the app sandbox strikes at all of those.
Cocoa-based Mac apps are rapidly being eaten by web apps and Electron psuedo-desktop apps.
IMO the app sandbox was a grievous strategic mistake for the Mac. Sometimes this cost is prohibitive (see Coda 2.5). We did our best but the fact is that sandboxed apps run more slowly, have fewer features, are more isolated, and take longer to develop. Think open and save panels, copy and paste, drag and drop, Services menu, Open Recents, etc.
Much of our effort that release (and in following releases) was dedicated to making Mac features work within sandboxed apps. I was an AppKit engineer when the Mac app sandbox was introduced in 10.7.
0 kommentar(er)
