7 ms·

> For both applications, complying with Apple’s sandboxing and feature constraints to get them approved for sale would have required significant rewrites. As a

• axoltl 10y ago
  It's also a rather important security feature.
  • ams6110 10y ago
    When OSX and iOS merge, there won't be any options other than the App Store. Might as well bite the bullet and make the necessary revisions, or just decide to abandon the Apple market.
    • hgontijo 10y ago
      Is that really happening? Links or you just got information from inside Apple?
      • ams6110 10y ago
        I'm speculating. I just can't see the financial upside for Apple to continue with Mac OS X. The vast majority of their sales and profits are from phones, tablets, and music. Mac OS X and laptop and desktop hardware will become more and more of a distraction. We've seen them stagnating already. As a unix, Mac OS X is a rather elderly BSD. They may keep a laptop device in the mix, but it will be more like a chromebook and run iOS. Again, I'm speculating.
        • chrisballinger 10y ago
          Except you need to use macOS to develop iOS apps.
          • ams6110 10y ago
            Now, yes. No reason that couldn't change. It's just software.
    • LeoPanthera 10y ago
      > When OSX and iOS merge [Citation needed]
    • 1123581321 10y ago
      That's not happening, and wouldn't be worth worrying about until it's announced anyway. We know it's not happening because Tim Cook has explicitly said so. Additionally, it doesn't make financial or engineering or UX sense.
    • jacquesm 10y ago
      Not that Apple never spoke an un-truth, but they're on the record saying that will not happen: http://fortune.com/2015/10/13/apple-merge-ios-os-x/ http://fortune.com/2015/10/13/apple-merge-ios-os-x/ (They also said they would not launch a small tablet and so on...)
      • dingo_bat 10y ago
        No stylus also.
        • gurkendoktor 10y ago
          Which is still true, there's no stylus for the iPhone. You can buy one for the iPad Pro, which is a completely different product, just like you can buy a Wacom tablet for your Mac.
          • dingo_bat 10y ago
            I know. My point was that Steve Jobs was extremely critical of tablets that have a stylus and said ipad won't have one ever. But they went back on that, too, like the other examples.
            • gurkendoktor 10y ago
              Ah, I was only aware of Jobs' comments about styluses in 2007, which are often quoted but not really relevant (he was talking about phones). Turns out he also brought it up in the context of the iPad: https://www.wired.com/2015/09/steve-jobs-stylus/ https://www.wired.com/2015/09/steve-jobs-stylus/
    • kilon 10y ago
      Eeeeeeh ... you know .... iOS is just a mobile version of MacOS ... to be specific it's macOS code plus some code to make it mobile friend. Thus there is zero need for a merge.
  • ThomPete 10y ago
    That argument is not really useful as you can basically set up the Mac to make it really insecure. The real question is should those who really care about security and are fine with the limitations of an sandboxed app really be defining the OS X ecosystem.
• Dobbs 10y ago
  It entirely matters what the app is trying to do. One of his apps Jettison lets you control disconnecting external drives by adding keyboard shortcuts. That is not something you can reasonably do from a sandbox. You have to be able to query arbitrarily which drives exist and then interact with them. Otherwise you have to do the hack he was talking about where you download and install the helper from the internet and the controller is installed from the Mac App Store.
  • theWatcher37 10y ago
    Copied from my previous post: Wouldn't this work? -download from App Store; app runs normally -function in app hits boundary - OS: "app Example has request access to <files: all/this directory/this folder> this time/always/not now/never" Would solve this problem pretty quick right? I don't want handbrake to have access to my photos, I'd love Native fine-tuned permissions like this. Seems like you could adapt this to any functionality be it location/file access/ability to do certain things etc etc. you know... just like iOS does
    • SparkyMcUnicorn 10y ago
      Apple needs to decide, it's not up to us. Currently, they seem to be doing nothing.
    • gotow 10y ago
      The issue here is that the majority of Mac users are not as savvy as HN readers. Apple rightly avoids popping up these kinds of prompts because the typical user has no idea what the request means, much less the security implications of allowing it. If you're going to sandbox, what Apple's doing makes (some) sense - the issue is whether sandboxing needs more granularity, more capabilities and better support from Apple on the developer side. Then again, some things would still be impossible unless Apple granted special exceptions somehow. It's a tradeoff - Apple has to choose a line somewhere - they've chosen it where they have, knowing that it limits what developers can do and completely blocks certain classes of apps. When sandboxing was first introduced and I objected, I was told that Apple was willing to accept some "collateral damage" in return for what they perceived as better security.
• cortesoft 10y ago
  But what about apps that you are downloading that are SUPPOSED to do things to files outside of the 'sandbox'? I can think of a million use cases that require access to arbitrary files or system functions - a backup app, an app that compresses infrequently used files, a network analyzer, etc. The blog post talks about an app that needs access to things beyond the sandbox - the jettison app requires the ability to eject disks. Sure, there are a lot of apps that CAN work in a sandbox, but not all of them. There should be a way to grant apps permissions beyond the sandbox.
  • theWatcher37 10y ago
    An iOS-like approach seems natural. -download from App Store; app runs normally -function in app hits boundary - OS: "app Example has request access to <files: all/this directory/this folder> this time/always/not now/never" Would solve this problem pretty quick right? I don't want handbrake to have access to my photos, I'd love Native fine-tuned permissions like this.
    • gberger 10y ago
      The problem is that permissions only work for the most basic things.
      • function_seven 10y ago
        What complicated things would a permissions system not be able to handle?
        • AtheistOfFail 10y ago
          Basic Internet Access. How often will you read the dialog for Chrome before you just go "Screw it, set to Always"?
          • function_seven 10y ago
            Just once, the first time the application runs into a particular sandbox boundary. The application can decide for itself what granularity it wants to request, then I accept or decline. For example, the first time I use Chrome to visit a website, it would trigger a dialog requesting permission to “Connect to websites” (i.e. initiate outbound TCP connections toward ports 80 and 443). The first time I tried to use WebRTC, the dialog would appear for that.
• LeoPanthera 10y ago
  Can a non-AppStore app voluntarily sandbox itself?
  • ThomPete 10y ago
    Yes
    • LeoPanthera 10y ago
      Can a user easily tell when an app has done so? (Or not done so?)
      • ThomPete 10y ago
        depends on the app and what it is trying to do but no clear indication.
      • charlesdm 10y ago
        Not really
      • mrpippy 10y ago
        There's a "Sandbox" column that can be enabled in Activity Monitor. Probably the easiest way short of terminal commands
      • danieldk 10y ago
        Yes, using Activity Monitor, as a sibling mentioned. I have done this regularly over the years and my conclusion is that virtually no app distributed outside the App Store does this. Even when they have an App Store counterpart (example: 1Password). Hence, I have decided to always purchase the App Store version of an application when available and to think twice if there is no App Store version. I do not want to give a random developer full access to my filesystem.
        • oneeyedpigeon 10y ago
          > I do not want to give a random developer full access to my filesystem. Surely an app can only do that if it requests escalated privileges. By default, I would expect it to have the same filesystem permissions as the user that launches it.
• Lazare 10y ago
  I would agree if Apple's restrictions were at all reasonable or flexible.
• driverdan 10y ago
  Why? It has worked fine for that past 40+ years. I don't want my desktop OS to be targeted at the lowest common denominator.
  • dredmorbius 10y ago
    More like the past 15 years: OSX was released in 2002, and is a full ground-up replacement for the original MacOS. So there's that. There's the scale issue. Apple served perhaps low single-digit percentages of the PC market, which ranged from the tens to hundreds of millions overall, so millions to tens of millions of users, most affluent and educated. Computer usage is highly democratised now. Which gets to the third point: mobile OSes are targeting user populations in the billions, across the globe, and at all manner of educational and literacy levels. If you think there's any possible way that's not going to target the lowest possible skill level, or that that skill level isn't tremendously low (see a recent OECD computer skills survey across the G-20: about half of all users have either no or the very most basic computer skills), well, I'm sorry. There's a reason wide adoption leads to generally de-skilled products.
• 1_2__3 10y ago
  Bear in mind that no it cannot write arbitrary files. It's a unix system, it has unix permissions, and required privilege escalation to write to locations the user is not allowed to.
  • danieldk 10y ago
    It's a unix system, it has unix permissions, and required privilege escalation to write to locations the user is not allowed to. Although strictly true, Unix DAC is a security model that stems from the 60/70ies. When a malicious actor gets read (or write) access to your home directory, it is pretty much game over (think cryptolocker, identity theft, loss of sensitive files, etc.). With vulnerabilities in internet-facing software being a fact of life, you want compromises to be restricted to their own little sandbox, not all the files in your home directory.
    • oneeyedpigeon 10y ago
      Wouldn't an application-specific user account (mostly) solve that problem without having to resort to a more complicated access control model?
      • danieldk 10y ago
        Then you have to fiddle when you want the application to read/write a file in your home directory. So, then either the application has blanket access again or the user has to manager per-file groups or ACLs.
        • oneeyedpigeon 10y ago
          So a text editor gets the user's permissions, a game that writes a local save file has its own permissions ... what's an example app that wouldn't be able to work this way?
• jakobegger 10y ago
  In principle you are right. It would be nice if every app was sandboxed, even apps distributed outside the Mac App Store. But in practice the Sandbox has a few issues that make it unusable for many use cases: - There is no way to provide automatic software updates for sandboxed apps. For Mac App Store apps, that doesn't matter (MAS takes car of updates), but for apps distributed outside the MAS, this is pretty much a deal breaker. - Many technologies are not available for sandboxed apps, eg. shared memory. This makes it hard hard to distribute some popular software on the Mac App Store (eg. PostgreSQL) - Unix Socket Connections outside the sandbox are not possible. This makes connecting with a lot of services (eg. SSH Agent) impossible. - the whole sandbox mechanism is buggy, poorly documented, poorly supported, and error logging in insufficient. I currently distribute a sandboxed app outside the Mac App Store, and I'm considering to remove the sandbox for the above reasons.
  • nicky0 10y ago
    For updates, you can use the latest Sparkle implementation, or something like it. It works with Sandboxed apps.
    • jakobegger 10y ago
      It doesn't yet. From the website: "Support for sandboxing is currently under development." Allowing automatic software updates requires leaving a big fat hole in your Sandbox... (And what's the point of restricting your app to a sandbox, when it can replace itself with a non-sandboxed app?)
      • deleted 10y ago
        [deleted]
      • nicky0 10y ago
        There is a working branch which fully supports Sandboxing with a secure approach: https://github.com/zorgiepoo/Sparkle https://github.com/zorgiepoo/Sparkle This is set to be Sparkle 2.0. You raise an interesting point about security. It's about what you trust. Do you trust the app, or do you trust the developer of the app and their update infrastructure too. To have auto updates you need to do the latter.
• Razengan 10y ago
  Exactly. As a user, these are the reasons I prefer the [Mac/iOS] App Store, more or less in order of importance: • On every new computer/device, I don't want to visit multiple sites and separately download every app that I use/prefer to keep available. • Likewise for updates. • I don't like obnoxious developers being "too smart"; There are things that I do not want apps to be able to do by default, on any of my devices, and I don't want you to attempt them unless I unambiguously allow each specific action. • I prefer to look in one place for new apps and games. • I prefer to link my payment and personal info to as few places as possibles. However, I definitely agree that both the Mac and iOS App Stores suck at discoverability, the MAS especially so. It's baffling that such high profile storefronts are missing many basic filters in 2017.