Re: Mountain Lion changes
Re: Mountain Lion changes
- Subject: Re: Mountain Lion changes
- From: "John C. Welch" <email@hidden>
- Date: Wed, 25 Jul 2012 13:18:59 -0400
- Thread-topic: Mountain Lion changes
On 7/25/12 11:51 AM, "Zav - public" <email@hidden> wrote:
>OK. I'm reserving my natural feelings on this topic for the sake of
>decorum since I am a genteel and refined gentleman.
>
>Sandboxing sucks, and it's the mark of people who do not know how to do
>security.
and this is based on what data other than personal feelings?
>
>Now, I do not know the correct way to do this, but I do know that this is
>not it and it places unfortunate burdens on the developers.
ALL security places burdens on the devs. All of it. If you dislike that, I
recommend a different career/hobby.
>
>If I am writing code that is not for release to the app store, I want
>nothing to do with sandboxing, yet Apple's docs all point you to a
>sandboxing model of writing files to the OS.
you can completely ignore sandboxing for your application if you are not
targeting the MAS. Other applications will use it, so you'll still have to
deal with it, but you are not yet REQUIRED to sandbox anything if you are
not targeting the MAS. If you're going to complain about something, base
it in reality.
>
>As it is on iOS, directly because of sandboxing, we are forced to co-opt
>other directories to SIMPLY STORE APP PREFERENCES OUTSIDE OF THE APP.
iOS is not the Mac OS. It operates under a different set of rules. I fail
to see how this is a great problem for anything but "I don't like it.".
>
>When our app gets updated, BECAUSE OF SANDBOXING, we had to rebuild the
>app and redistribute on each device just so we could have a certain
>unique ID for each app. This simply blows.
>
>Why? Because our app in question is serialized with a unique ID. When a
>new build gets installed, the previously saved ID is wiped, because the
>preference pList is IN the app, not saved where they are expected to be,
>in a prefs folder outside the app, just like Jesus intended.
There are no user directories in iOS, so it would make no sense to do
that.
>
>Why couldn't Apple sandbox each preference to be app specific, with a non
>mutate-able name in a preference folder that is OUTSIDE THE APP?
What great advantage would this provide other than making you happy.
>
>They could have. Files and folders are just items and containers with
>relations to each other. Apple's sandboxing could have extended support
>for preferences outside the app, even scratch files that exist in a
>non-mutable container that is tied to the name of the app.
They could have done many things, but "can" and "are going to" are two
different things. You could react like having to save prefs in the
application in iOS, thereby ensuring that a user never has to worry about
you forgetting to clean up after yourself when they delete your
application isn't akin to being stabbed in the face by Zombie Steve Jobs.
Yet, here we are.
>
>Developers are expensive. This is a massive waste of time and money and
>inconvenience to developers who are not using the App Store and are
>developing private applications or applications that are internal to
>their enterprise/company.
Nonsense. Developers are cheap. I can go to any high school or college,
kick a tree and 20 fall out.
As well, if you are developing for internal use only, you can ignore all
the rules.
>
>Also, it is against corporate policy of many companies to store ANY
>corporate info outside the corporate net, so storing data in iCloud is
>not acceptable. Also, if you look at the sandboxing premise, using
>iCloud for storage is also a sandboxing violation.
Nonsense. There's nothing about enterprise dev that requires iCloud, nor
is there anything about internal only dev that requires you to comply with
EITHER application store's policies. Internal Apps are only subject to App
Store review if distributed through the App stores.
>
>Apple's change means that we looked into storing unique app info in
>address books entries, in image files in the supported directories, even
>in MP3 file metadata. Remember, I'm reading and writing dicts, that end
>up as pLists, which are simply XML files, which is simply an ASCII string
>stream.
You forgot about binary plists.
>
>It's inane. Also restricting the coders from writing anywhere on the
>disk aside from the user's Documents, Music and Photos folders? OK.
>I'll give you one dictionary pList file. Every developer, write all your
>data to that.
and again, you don¹t' have to do that. You're not using the MAS.
Therefore, it's specific policies don't apply to you.
>
>This approach simply shows that Apple's people do not properly know how
>to apply security and offer a development system that is not overly
>restrictive for developers.
>
>Forcing devs to use a subset of folders will cost them more time and will
>end up with people co-opting what is there to handle simple tasks as
>reading and writing shareable data to the drives.
>
>It's simply bad and ill thought out.
No, you just want perfect security without having to do any of the work
yourself. That's a fantasy, but it's one you're clearly deeply invested in.
>
>And that's my reserved opinion. Now back to dealing with the stupidity
>of Xcode which added all the launch screens into the icon section of the
>app bundle.
Your opinion appears to rely on things that aren't correct.
>
>
>
>On Jul 25, 2012, at 11:11 AM, John C. Welch <email@hidden> wrote:
>
>> On 7/25/12 11:04 AM, "Zav - public" <email@hidden> wrote:
>>
>>> What I'm really worried about are the implications of sandboxing and
>>>the
>>> idiotic "every app is an island" approach. Often, I'll want to save a
>>> preference outside the app, or use AppleScript to write a file to my
>>> desktop that tracks the iTunes song I am playing in case I mistakenly
>>> quit and it forgets the song.
>>
>> Actually, sandboxing is a pretty intelligent security issue, and only a
>> requirement for the MAS. Also, you might want to read up on the docs on
>> sandboxing in ML. It's a bit better than lion. Much actually. And a lot
>>of
>> application sandboxing doesn't really apply to scripts. User-written
>> scripts are treated as you'd expect.
>>
>>>
>>> The sandboxing API only allows a few supported folders to write to file
>>> saving outside of the app and these places (preferences too) all
>>>require
>>> user interaction to confirm the action.
>>
>> you really, REALLY want to look at the changes to sandboxing in 10.8
>>
>>>
>>> I've also got some patent pending material written in AppleScript and
>>> Xcode that I'm sure will end up breaking, yet, I really hope not.
>>
>> --
>> --
>> Politics:
>>
>> A strife of interests masquerading as a contest of principles. The
>>conduct
>> of public affairs for private advantage.
>>
>> Ambrose Bierce
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> applescriptobjc-dev mailing list
>>(email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>ac.com
>>
>> This email sent to email@hidden
>
>
--
If someone passes out on the couch and you want to put them in a
figure-four leglock, ensure that the hold is correctly applied before they
wake and break your damned knee.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
applescriptobjc-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden