Live data from Hacker News

Between a rock and a hard place – our decision to abandon the Mac App Store

blogs.atlassian.com

141–150 of 157 posts

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#141
post #130
post #90

Earlier quoted context omitted.

Thanks for the suggestion, this is very helpful. Do you know if this also bypasses issues of file ownership, or is this only relevant to the sandbox? (Editing of non-owned files using an admin password is a gorram nightmare on modern OS X.)

I'm pretty sure it should stay that way... no?

It should be non-trivial for both user and developer, but it shouldn't require interprocess communication and reading fifty-ish pages of docs. It's a little insane, and I gave up on trying. (It was a simple GUI for editing a particular system file, similar to what Cocktail does; like sudo vi, but more convenient.)

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#142
post #18
post #13

Earlier quoted context omitted.

Good point. Every interpreter - and program that loads anything - will have to be foolproof. There was a case some time ago where an Xbox (or was it ps3?) game did not correctly check the saved games before loading them. IIRC people where able to exploit this and get the game to run code on their behalf. In theory, all the games and apps have to sign/encrypt/check everything they load. But I can't believe they will a…

The sandbox lessens the risk of said overflows. Instead of exploiting a flaw in an interpreter or file handling function and getting control of the entire machine, you'd only get control of the sandbox's context. The only way to parlay that into control of the system would be to break the sandbox. And then, because OS X default security is fairly sane, the only way to do real lasting damage is to use a further exploi…

True, but that would be true without signed apps as well.

Also, I guess it depends on what the app does and what you mean by "real lasting damage".

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#143
post #27

Wouldn't security-scoped bookmarks solve some of the problems he describes? From the sandbox design guide: -------------------------------- Starting in Mac OS X v10.6, the NSURL class and the CFURLRef opaque type each provide a facility for creating and using bookmark objects. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current…

Bookmarks are a working solution, the problem is getting the user to locate those urls in the first place. I'm having many of the same problems that the OP mentions and explaining to the user how to locate folders and files correctly is a usability nightmare. "Click the button below, locate file xyz and 'Open' it to proceed" I would be perfectly ok with a system "Grant permission to xyz" dialog, but the open file dia…

Imagine if there were "just pass a path" APIs. Apps could then just pass a path, users wouldn't care where the path points to even if it's shown to them. "Yeah whatever." Clearly defies the idea of the sandbox.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#144
I hope Apple relaxes it's policy in regards to the sandbox. I do think it's great to have a sandbox provided by the OS, but IMO the default rule should be: "no access", then the developer could tick all legitimate uses for the application, if this happens to be unrestricted access, so be it. I think this is especially true with the new upcoming code signing feature in Mountain Lion.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#145
I'm grateful for the iTunes App Store, but I have a bad feeling about the Mac App Store.

I think now might be the time for a rival App Store to set up shop before Apple locks developers into only releasing through their approval process.

Maybe I'm over reacting, but an ounce of prevention is worth a pound of cure.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#146
post #119

Earlier quoted context omitted.

Actually, the sandbox seems like a requirement for safely distributing apps that allow plug-ins.

Can you explain how this works? My understanding is that plugins — defined for clarity's sake as "loadable code that interacts with the original application but was not included in it" — are not allowed in the sandbox. Has this been fixed? Or did you mean something else?

I mean that plugins are very unsafe if there's no sandbox. I don't mean they got actually allowed.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#147

Earlier quoted context omitted.

@recoiledsnake: (for whatever reason, I'm not allowed to reply directly to you) You're comparing Apple's ecosystem to Earth's. Apple is a private company that makes products that are sold on the commercial markets. The Earth is something entirely different. If Apple made planets, then yes – they could decide how to manage the atmosphere. That's how business works.

(for whatever reason, I'm not allowed to reply directly to you) It's a cool-off period.

To keep me from advocating an unpopular, but entirely rational, position – all while other people freely misrepresent the First Amendment in response to my comments.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#148

Earlier quoted context omitted.

@recoiledsnake: (for whatever reason, I'm not allowed to reply directly to you) You're comparing Apple's ecosystem to Earth's. Apple is a private company that makes products that are sold on the commercial markets. The Earth is something entirely different. If Apple made planets, then yes – they could decide how to manage the atmosphere. That's how business works.

(for whatever reason, I'm not allowed to reply directly to you) It's a cool-off period.

To keep me from advocating an unpopular, but entirely rational, position – all while other people freely misrepresent the First Amendment in response to my comments.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#149
post #132

Earlier quoted context omitted.

If the app store can truly compete with an open marketplace, why won't apple let me install arbitrary software on my iDevice?

It's common courtesy to announce when one's surrendering an argument and starting a new one. "If the app store can truly compete with an open marketplace" As it turns out there is an open market for iOS apps and an open alternative to iOS and Apple's walled garden is competitive with both. "why won't apple let me install arbitrary software on my iDevice?" Aren't the reasons obvious? Simplicity, profit, security? You…

Since you've asked, Steko, I'll continue as if you're actually interested in exploring this topic with me. I promise I was trying to contribute to my argument and not change the subject. Please calm your fury.

First, what is this open market for iOS apps you mentioned? I haven't heard of it.

Of course Apple locks down the app store on their iDevices for profit. I think we're in agreement on that. If they didn't limit software delivery in that way, their app store would have to compete with other software delivery channels including the open web.

What I'm trying to express is my surprise that developers in the desktop world would opt in to a market like this. I had assumed that iDevice developers only used the app store because they had no choice.

Re: Between a rock and a hard place – our decision to abandon the Mac App Store

#150
post #60

Earlier quoted context omitted.

MAS applications are not disallowed from supporting plugins.

You're technically correct. They're just disallowed from supporting plugins in the manner that they have been on every platform for 20 or 30 years.

Providing deep platform-specific support in a cross-platform codebase is a pain; believe me I get that. But platforms evolve, and frankly the ways they've been evolving recently is likely much tougher to keep up with than "loading plugins from a new location, or with a new security context", especially for a time-based media application.

Wholesale changes in OS or environment runtime? Changes in underlying processor architecture? Forced update to full 64-bit support? Customers wanting to operate on files that are an order of magnitude larger?

If these apps have any claim to being worth hundreds or thousands of dollars per seat, and charging hundreds of dollars for basic compatibility updates, their developers should Pro-up and deal with this change like they've dealt with others.

And given the motivation for the change, I think they should skip the complaining step and lean into the work.

Post reply on HN