Live data from Hacker News

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

blogs.atlassian.com

81–90 of 157 posts

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

#81
post #13
post #3

Dev tools don't really have a place in managed environments IMO - they just need too low level of access to a system to be able to do their work. Now, say a game or web browser that runs potentially malicious content, sure, sandbox it. But other things like code interpreters, low level Unix tools, or inter process tools like AppleScript, they're still open to (mis)use by anyone. I'm going to guess that most malware f…

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 original XBOX had a problem with a 007 game and with the right game save you could turn it into a FTP server. Once that was loaded, you where in.

Dave

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

#82
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 dialog is a terrible way of requiring access to a file or folder.

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

#83
post #65

Earlier quoted context omitted.

That would actually be (GUI, it doesn't work like this actually, I think, but what I want would look the same) ideal: you don't get my ssh key. You get an ssh session arranged for by the keychain. Too bad it's probably too much work for something not enough people use (and those who use it are generally security-conscious enough to avoid malware on their own).

If you call `ssh` on the command line it will use Keychain to unlock your private SSH key. That part is done. The application shouldn't be asking for SSH keys, it is completed already. Just use `ssh` as you would before.

And if you type 'ssh-add' you'll only have to enter your passphrase once. I think this all got sorted out beginning with Leopard; before that, it may not have worked as expected (compared to other *NIX environments).

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

#84
When I think of all the articles that have passed through the HN front page about mobile developers' terrible experience with the app store, I can't imagine why a desktop software developer would voluntarily subject themselves to it.

Sure, iDevice developers have no choice. But for desktop software there's this handy thing called the Internet. Why kick up revenue to apple, subject myself to submission rules and arbitrary rejection, absurd technical limitations and switcheroos like the one described in this article, and all the rest?

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

#85

I like the idea of a sandbox. Apple promotes the sandbox as a security feature but shouldn't Apple try to improve much more important things (security wise) first which are much less invasive? Example: The Keychain application from Apple (used to store certificates, private keys and passwords) is using a encryption algorithm that is too weak for what it is used - namely: DES. You can break it with a reasonable amount…

> "The Keychain application ... using a encryption algorithm that is too weak for what it is used - namely: DES"

Source? This is relevant to my interests. Namely, I'm trying to figure out if using something like 1password or other services would be worth it. Thanks!

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

#86
post #79
post #62

Earlier quoted context omitted.

I think you missed my point. I have thousands of photos "in" iPhoto, and I have no idea of any of the file names or their location on the file system. I don't care what they are called or where they are, I just want to have my photos. Sure, there might be a filesystem under there, but I have no interest in interacting with it directly.

So... what about my scripts? Should I have to load some specific manager - iScript - in order to access my creations? Just because 'the filesystem is dying'? What about my store of .iso files? Do I need iIso?

I think people who need to manage files outside of a particular application will become the exception, not the rule. As long as you can access the underlying file system when you need to, I see no problem with most people not having to care about it.

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

#87
post #29

How could Apple handle sandboxing in Xcode? It doesn't seem possible. Right now they just distribute the installer via the app store, but I thought they were planning to put the whole app in there. I wonder if Apple might give some companies of just distributing the installer via the app store as well.

Apple fairly routinely lets themselves be exceptions to rules for their own platform. Lion is distributed via the Mac App Store, and I'd put money on them not allowing Ubuntu or Windows to be distributed via the Mac App Store in a similar fashion[1]. 1: future anti-trust cases or congressional testimonies nonwithstanding

Hypothetical rule: "Operating Systems may be distributed through the Mac App Store only if they are capable of running the Mac App Store"

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

#88
post #69

Earlier quoted context omitted.

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

Are you suggesting that every pro media application released before March 1, 2012 was not safely distributed? I guess I should step back a bit and make my argument more clear. I'm not opposed to the concept of sandboxing, I recognize the benefits of these policies as Apple's user base grows and malware becomes a greater concern. My contention is that the imposition this places on users and developers alike will most…

I'm suggesting that every single application prior sandboxing was not safely distributed. It's not like anyone had a choice, there was an age before airbags.

I also disagree that extensibility is in conflict with sandboxing. As for pro media software developers, I'm pretty sure it's just a matter of time and polishing of the platform. AutoCad LT is already in.

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

#89
post #79
post #62

Earlier quoted context omitted.

I think you missed my point. I have thousands of photos "in" iPhoto, and I have no idea of any of the file names or their location on the file system. I don't care what they are called or where they are, I just want to have my photos. Sure, there might be a filesystem under there, but I have no interest in interacting with it directly.

So... what about my scripts? Should I have to load some specific manager - iScript - in order to access my creations? Just because 'the filesystem is dying'? What about my store of .iso files? Do I need iIso?

Quit trying to get everyone off your lawn and accept that you are a (presumably) some kind of developer. Computers are not made just for your needs. The needs of the many outweigh the needs of the few or the one. In this case, you'll eventually have to be running some kind of developer tool to have this kind of access. This is probably appropriate. The average computer user (of any mainstream OS) has as much use for the ability to manage "scripts" and "ISOs" outside of a purpose-built application for using them, as he does for a C compiler.

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

#90
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…

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.)
Post reply on HN