Discussion:
Random deletion of apps under IOS5
(too old to reply)
Peter
2011-10-22 13:25:27 UTC
Permalink
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011

This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".

I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.

More here

http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
Alan Browne
2011-10-22 14:43:34 UTC
Permalink
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
I've known it was only a matter of time before an issue popped up wrt to
the iPad on the flight deck. iPad, iOS and these Apps do not go through
the eye of the needle cert than avionics usually go through.
Eliminating paper charts is a beautiful thing - but the iPad and
aviation Apps are getting a pass because they are not appliances
integrated into the aircraft proper.

The positive note is that in the crew, with 2 iPads, the other probably
(possibly) did not get the same hit - but it could happen.

"Aviation in itself is not inherently dangerous. But to an
even greater degree than the sea, it is terribly
unforgiving of any carelessness, incapacity or neglect."

— Captain A. G. Lamplugh,
--
gmail originated posts filtered due to spam.
salgud
2011-10-24 14:18:44 UTC
Permalink
Post by Alan Browne
"Aviation in itself is not inherently dangerous. But to an
even greater degree than the sea, it is terribly
unforgiving of any carelessness, incapacity or neglect."
— Captain A. G. Lamplugh,
With due respect to the Captain, I disagree. Being 30,000 ft above the
ground IS "inherently dangerous"!
Davoud
2011-10-22 15:08:27 UTC
Permalink
Post by Peter
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
That's called circular reporting. You cite a second source which has
nothing new, but only refers back to the first source. Yet you think
that you have two sources to confirm your bogus alarm.

Unless the FAA and NTSB have made some changes of which I am unaware,
"Flying" magazine is not an authorized issuer of NOTAMS or other
official alerts.

Furthermore, you hyped this non-news, non-safety-related item by
declaring it to be a "bombshell." Tempest in a tea cup.

Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!

There is one other recommended step, and that is to identify those
pilots who were operating with iPads with no additional storage space
and who were nonetheless downloading additional apps or other data
in-flight. They can keep their iPads, but their pilot's licenses need
to be permanently suspended, as we just can't afford to have idiots
flying airplanes.

Davoud
--
I agree with almost everything that you have said and almost everything that
you will say in your entire life.

usenet *at* davidillig dawt cawm
Peter
2011-10-22 15:10:20 UTC
Permalink
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Bollocks.
Post by Davoud
There is one other recommended step, and that is to identify those
pilots who were operating with iPads with no additional storage space
and who were nonetheless downloading additional apps or other data
in-flight. They can keep their iPads, but their pilot's licenses need
to be permanently suspended, as we just can't afford to have idiots
flying airplanes.
Idiot.
Jolly Roger
2011-10-22 18:51:04 UTC
Permalink
Post by Peter
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Bollocks.
Post by Davoud
There is one other recommended step, and that is to identify those
pilots who were operating with iPads with no additional storage space
and who were nonetheless downloading additional apps or other data
in-flight. They can keep their iPads, but their pilot's licenses need
to be permanently suspended, as we just can't afford to have idiots
flying airplanes.
Idiot.
Oh so you're some fool wanker from that island over there. That explains
everything about you anyone needs to know.
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR
Wes Groleau
2011-10-24 04:22:03 UTC
Permalink
Post by Jolly Roger
Post by Peter
Bollocks.
That fails to persuade me.
Post by Jolly Roger
Post by Peter
Idiot.
Equally unconvincing.
Post by Jolly Roger
Oh so you're some fool wanker from that island over there. That explains
everything about you anyone needs to know.
And again.
--
Wes Groleau

There are two types of people in the world …
http://Ideas.Lang-Learn.us/barrett?itemid=1157
J.J. O'Shea
2011-10-23 23:03:24 UTC
Permalink
Post by Peter
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Bollocks.
An amazingly comprehensive refutation of his position. Do carry on.
Post by Peter
Post by Davoud
There is one other recommended step, and that is to identify those
pilots who were operating with iPads with no additional storage space
and who were nonetheless downloading additional apps or other data
in-flight. They can keep their iPads, but their pilot's licenses need
to be permanently suspended, as we just can't afford to have idiots
flying airplanes.
Idiot.
I see that you did, indeed, carry on.

However, you might, just might, for the benefit of us totally neutral
bystanders, attempt to... expand... on your comments. Failure to do so may
result in a... negative... impression.

But do carry on.
--
email to oshea dot j dot j at gmail dot com.
Bert
2011-10-22 15:21:26 UTC
Permalink
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space.
How many real operating systems will "delete files at its discretion if
it were to run low on space?"
--
***@iphouse.com St. Paul, MN
Todd Allcock
2011-10-22 20:20:31 UTC
Permalink
Post by Bert
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space.
How many real operating systems will "delete files at its discretion if
it were to run low on space?"
In this case the "villain" isn't really the OS, but the dev guidelines.
Absent Apple's directives, how many programs would intentionally store
"permanent" documents in a "cache" or "temp" folder that the OS has carte
blanche to empty when necessary?

This is most likely a case of the right hand not knowing what the left is
doing (our already did.) Someone said "tell the devs to put their crap
in a cache so iCloud doesn't get overwhelmed" without realizing someone
else already said "if space gets tight, dump the cache folders
automatically!"
JF Mezei
2011-10-22 21:44:14 UTC
Permalink
Post by Todd Allcock
In this case the "villain" isn't really the OS, but the dev guidelines.
The vilain is Apple who decided early on that IOS did not have an
accessible file system, and instead of revoking this religious belief
and granting access to *a* file system, Apple went with a baby step that
wasn't enough (limited storage within an app's directory).

HOWEVER:

Not sure if "not smart" or "extremely stupid" applies, but at the end of
the day, those who decided to use an iPad for a mission critical app in
cockpits made a huge error.

Without a reliable file system, they should not have selected the iPad
for this. This is the same as stock exchange presidents deciding to
migrate their IT to Windows and finding out after having spent hundreds
of millions that Windows was not designed to handle such a job.


Apple clearly did not intend the iPad (or IOS) to be used for mission
critical apps needing their own storage. Folks in aviation decided to
use it anyways and are now stuck with a major problem.



The big question now is how will Apple react. There is the issue of
short term fix. This has the potential of a meg egg on face if the media
take a hold of this.


If Apple realises the potential of the iPad in commercial applications,
perhaps it will relent and open a real file system. If not, it risks
relegating its iToys to the toy department and be shunned from business.
Doug Anderson
2011-10-22 23:00:10 UTC
Permalink
Post by JF Mezei
Post by Todd Allcock
In this case the "villain" isn't really the OS, but the dev guidelines.
The vilain is Apple who decided early on that IOS did not have an
accessible file system, and instead of revoking this religious belief
and granting access to *a* file system, Apple went with a baby step that
wasn't enough (limited storage within an app's directory).
That's wrong on two counts.

a) it isn't what the problem is.

b) the storage within an app's directory isn't limited. (Well, it is
limited by the free space on the device, but that would be true
wherever the storage was.)
Post by JF Mezei
Not sure if "not smart" or "extremely stupid" applies, but at the end of
the day, those who decided to use an iPad for a mission critical app in
cockpits made a huge error.
Without a reliable file system, they should not have selected the iPad
for this.
I remain confused about why you keep going on about the iPad file
system. It is a standard unix type of file system. You may not have
software that allows you to browse that file system, but the iPad
wouldn't run without it.

It is also perfectly reliable.

What the problem really is (if there is one) is that OS updates can
apparently (deliberately) remove files. (The ability to delete files
is an important one on any file system, and the iPad has that
ability.)

I haven't read enough about this to understand it, but if OS updates
can delete user data then it is important for that to be well
documented in a specific enough way so that users can avoid losing
data they care about.
JF Mezei
2011-10-23 02:11:02 UTC
Permalink
Post by Doug Anderson
b) the storage within an app's directory isn't limited. (Well, it is
limited by the free space on the device, but that would be true
wherever the storage was.)
I am not privy to that information. But the information on thsoe web
sites indicated that the data files used by the airline application were
too big to fit in the application's directory. Consider also that many
different apps may be involved in accessing the data, and storing it
outside of a single application was required.

I wonder if the Apple vetting would have spotted this if those apps had
been submitted to the app store.
Post by Doug Anderson
I remain confused about why you keep going on about the iPad file
system. It is a standard unix type of file system.
As long as users and applications are not allowed to see *a* fiole
system, there is no file system. Hey, there is also a file system in
some candy bar telephone, but the user can't see it.

When you look at many phones, when you connect as USB, you do get a FAT
drive, but it contains only your data, you can't see the phone's software.

Apple should have done the same for IOS, providing one directory tree
that is visible to applications and perhaps even mountable as a drive on
computers. The real files that contain the OS would still be invisible.
Post by Doug Anderson
It is also perfectly reliable.
Not anymore when the OS chooses to delete your files without telling
you. Now, if those airline apps really do use a temporary directory,
then they really couldn't have expected that directory to be permanent.
Post by Doug Anderson
What the problem really is (if there is one) is that OS updates can
apparently (deliberately) remove files.
reread. Say you have a 2 gig map file. You have 1 gig left. You download
a 3 gig update of software. The system will delete your 2gig file to
make room for that 3 gig file you are donwloading (instead of telling
you there isn't enough room to download that file).

So when you want to apply the updates, your 3 gigs worth of updates may
be there, but the program that applies the updates to the data won't
file the 2 gig map data anymore.
Todd Allcock
2011-10-23 04:01:13 UTC
Permalink
Post by JF Mezei
Post by Doug Anderson
b) the storage within an app's directory isn't limited. (Well, it is
limited by the free space on the device, but that would be true
wherever the storage was.)
I am not privy to that information. But the information on thsoe web
sites indicated that the data files used by the airline application were
too big to fit in the application's directory. Consider also that many
different apps may be involved in accessing the data, and storing it
outside of a single application was required.
That's not really it. Storage is unlimited (limited by device capacity
of course) as long as the data is permitted by the dev guidelines, which
is that it's user-generated, rather than downloaded.
Post by JF Mezei
I wonder if the Apple vetting would have spotted this if those apps had
been submitted to the app store.
No, because the data isn't "too big", it's that it doesn't belong in the
app's Docs folder (which would be protected,) because it's not user
created, so it's placed in the cache instead.


My prediction? This will be fixed in a 5.0.x, update within a couple of
weeks.
JF Mezei
2011-10-23 04:45:32 UTC
Permalink
Post by Todd Allcock
My prediction? This will be fixed in a 5.0.x, update within a couple of
weeks.
The question is whether Apple will address this with a press release or
other type of statement on Monday morning. Because the operating system
deletes data files without warning, this is very serious to those who
make serious use of an iPad or iPhone.

Apple must send out a message to those customers that they must not
upgrade to IOS 5 until the fix is available.

They could add a preference to enable cleanup or disable it.
n***@nowhere.com
2011-10-23 06:16:25 UTC
Permalink
Post by JF Mezei
The question is whether Apple will address this with a press release or
other type of statement on Monday morning. Because the operating system
deletes data files without warning, this is very serious to those who
make serious use of an iPad or iPhone.
If this was Jobs, he would have called it one of the "edge cases" and
ignored it.
JF Mezei
2011-10-23 07:34:53 UTC
Permalink
Post by n***@nowhere.com
If this was Jobs, he would have called it one of the "edge cases" and
ignored it.
I don't think so. Because Apple has bragged about its iPads going into
major airline's cockpits, news of the "feature" breaking those
applications may become fairly serious and Apple may have to react very
quickly.


If Apple had not bragged about ipads in cockpits, then yeah, Apple might
have igored the isse as an "edge case".
Jolly Roger
2011-10-23 15:13:40 UTC
Permalink
Apple has bragged about its iPads going into major airline's cockpits
Citation please?
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR
JF Mezei
2011-10-23 21:12:09 UTC
Permalink
Post by Jolly Roger
Apple has bragged about its iPads going into major airline's cockpits
Citation please?
Tim Cook's keynote of a week or two ago btagged about it. And when these
deal with Alaska and United were announced, Apple made comments to the
reporters.
Doug Anderson
2011-10-23 06:28:46 UTC
Permalink
Post by JF Mezei
Post by Doug Anderson
b) the storage within an app's directory isn't limited. (Well, it is
limited by the free space on the device, but that would be true
wherever the storage was.)
I am not privy to that information. But the information on thsoe web
sites indicated that the data files used by the airline application were
too big to fit in the application's directory. Consider also that many
different apps may be involved in accessing the data, and storing it
outside of a single application was required.
I wonder if the Apple vetting would have spotted this if those apps had
been submitted to the app store.
Post by Doug Anderson
I remain confused about why you keep going on about the iPad file
system. It is a standard unix type of file system.
As long as users and applications are not allowed to see *a* fiole
system, there is no file system.
That statement is simply absurd. I can't see the CPU in my iPhone
either, but it's in there. Do you think your iPhone isn't electric
because you can't see the electrons moving?

Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.

App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
Post by JF Mezei
Hey, there is also a file system in
some candy bar telephone, but the user can't see it.
That's right. So it makes no sense to say there is no file system.
Post by JF Mezei
When you look at many phones, when you connect as USB, you do get a FAT
drive, but it contains only your data, you can't see the phone's software.
Apple should have done the same for IOS, providing one directory tree
that is visible to applications and perhaps even mountable as a drive on
computers. The real files that contain the OS would still be
invisible.
Well, I would have liked it if they did that. But I don't know why
that means they _should_ have. I doubt if it would have sold them
more phones, and I doubt it would have improved most users
experience.
Post by JF Mezei
Post by Doug Anderson
It is also perfectly reliable.
Not anymore when the OS chooses to delete your files without telling
you.
That isn't a file system problem. It may be a problem, but it isn't
because the file system is unreliable. If its a problem, it is
because Apple has made a combination of error in advising app writers
and poor choices in algorithms for finding unimportant files.
JF Mezei
2011-10-23 07:40:48 UTC
Permalink
Post by Doug Anderson
Well, I would have liked it if they did that. But I don't know why
that means they _should_ have. I doubt if it would have sold them
more phones, and I doubt it would have improved most users
experience.
Here is where the problem begins. Of you're Nokia and plan on making
candy bar phones, you don't need a fisible file system because it is
just a phone.

If you make a smartphone, you might not initially need a file systyem
because you only have games and a few built in apps.

But as the ecosystem grows, the need for a file system materialises.
This is where Apple failed to react.

And with the ipad, Apple treated it as a glorified ipod Touch, and
failed to provide the tooks such as a real file system to allow serious
commercial applications to be built (such as the electronic flight bag).

An for icloud, it would mean that the users owuld need to do like with
Time Machine and provide a list of things to be backed up and/or
excluded from backup, and probably the ability to a a full backup when
connected to a computer (inoring those bits that decide what to backup
and what to ignore when doing backups over wi-fi/3g).

So Apple failed to react quickly to the development of file based
applications and they are now pushing Apple to react instead of Apple
leading the market.

And consider that file based Apps started about a eyar ago with apps
like Pages, Numbers etc.
Doug Anderson
2011-10-23 16:35:11 UTC
Permalink
Post by JF Mezei
Post by Doug Anderson
Well, I would have liked it if they did that. But I don't know why
that means they _should_ have. I doubt if it would have sold them
more phones, and I doubt it would have improved most users
experience.
Here is where the problem begins. Of you're Nokia and plan on making
candy bar phones, you don't need a fisible file system because it is
just a phone.
I don't know the word fisible.
Post by JF Mezei
If you make a smartphone, you might not initially need a file systyem
because you only have games and a few built in apps.
All smart phone have file systems. I think you are wrong to think you
can make a smartphone without one.
Post by JF Mezei
But as the ecosystem grows, the need for a file system materialises.
This is where Apple failed to react.
No, the problem is you apparently don't know what a file system is.

The iPhone (and the iPad and ipod touch) all have full-featured and
robust file systems.

What you are complaining about is that Apple hasn't provided the tools
to allow you to interact with the file system in the way you want.
Peter
2011-10-23 19:19:45 UTC
Permalink
Post by Doug Anderson
All smart phone have file systems. I think you are wrong to think you
can make a smartphone without one.
However, you can connect a typical smartphone to a PC with a USB cable
and browse a lot of it using either windoze explorer, or some other
"explorer" type app which comes with the phone.

You can't do that with an Iphone/Ipad. Or at least not until the 3rd
party utils came out, and even they have very limited access, and they
rely on Apple DLLs which are currently broken (according to Iphone
Explorer).
Doug Anderson
2011-10-24 01:22:44 UTC
Permalink
Post by Peter
Post by Doug Anderson
All smart phone have file systems. I think you are wrong to think you
can make a smartphone without one.
However, you can connect a typical smartphone to a PC with a USB cable
and browse a lot of it using either windoze explorer, or some other
"explorer" type app which comes with the phone.
You can't do that with an Iphone/Ipad. Or at least not until the 3rd
party utils came out, and even they have very limited access, and they
rely on Apple DLLs which are currently broken (according to Iphone
Explorer).
That's right. They have file systems. These file systems work well.
But Apple doesn't want you messing around with them directly, so
they've tried to make that hard.

That has nothing to with whether the file systems exist, or with their
level of functionality.
Peter
2011-10-23 11:49:40 UTC
Permalink
Post by Doug Anderson
Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.
App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
One can see parts of the file system using programs like Iphone
Explorer. Even on a non-JB Ipad one can see quite a bit.

It is just Itunes which is written for complete idiots.
Doug Anderson
2011-10-23 16:37:13 UTC
Permalink
Post by Peter
Post by Doug Anderson
Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.
App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
One can see parts of the file system using programs like Iphone
Explorer. Even on a non-JB Ipad one can see quite a bit.
Yes, and there are other ways to get in there too.

The only question for me is did apple mislead developers into putting
big data files in cache directories thinking that was a good place to
keep permanent data. I don't know anything about this one way or the
other.
Jolly Roger
2011-10-23 16:40:44 UTC
Permalink
Post by Doug Anderson
Post by Peter
Post by Doug Anderson
Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.
App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
One can see parts of the file system using programs like Iphone
Explorer. Even on a non-JB Ipad one can see quite a bit.
Yes, and there are other ways to get in there too.
The only question for me is did apple mislead developers into putting
big data files in cache directories thinking that was a good place to
keep permanent data. I don't know anything about this one way or the
other.
Either way, it'll all be worked out in short order. No big concern for
me.
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR
Your Name
2011-10-23 21:58:56 UTC
Permalink
Post by Doug Anderson
Post by Peter
Post by Doug Anderson
Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.
App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
One can see parts of the file system using programs like Iphone
Explorer. Even on a non-JB Ipad one can see quite a bit.
Yes, and there are other ways to get in there too.
The only question for me is did apple mislead developers into putting
big data files in cache directories thinking that was a good place to
keep permanent data. I don't know anything about this one way or the
other.
Not being an iOS developer, I don't know either, but a "cache" by
definition is a temporary storage space, so if some developers are
permanently storing stuff there, then they've probably only got themselves
to blame.
J.J. O'Shea
2011-10-23 23:05:06 UTC
Permalink
Post by Your Name
Post by Doug Anderson
Post by Peter
Post by Doug Anderson
Much more to the point, the app writers have access to the file
system, and can put files in places that won't get deleted. It is
standard unix behavior to delete files in temp/cache directories when
there isn't enough space on the file system.
App writers shouldn't be putting things there that are meant to be
retained. If Apple isn't giving them any other choice, then that _is_
a mistake on Apple's part.
One can see parts of the file system using programs like Iphone
Explorer. Even on a non-JB Ipad one can see quite a bit.
Yes, and there are other ways to get in there too.
The only question for me is did apple mislead developers into putting
big data files in cache directories thinking that was a good place to
keep permanent data. I don't know anything about this one way or the
other.
Not being an iOS developer, I don't know either, but a "cache" by
definition is a temporary storage space, so if some developers are
permanently storing stuff there, then they've probably only got themselves
to blame.
That would be how I see things. However I'm a little short on actual data. I
really would like to have some real, actual, hard data on this.
--
email to oshea dot j dot j at gmail dot com.
JF Mezei
2011-10-24 00:31:39 UTC
Permalink
Post by J.J. O'Shea
That would be how I see things. However I'm a little short on actual data. I
really would like to have some real, actual, hard data on this.
If you have 2 gigs worth of maps in the "documents" folder, they get
backed up. With the move to backing up over wi-fi or 3g, this becomes
not only time consuming bout also expensive for 3g connection when this
is done every day to icloud.

So, Apple recommended you move those files to the cache directory so
they don't get backed up.

In VMS, there is a bit in files called "no backup". you set the bit, and
the backup utility does not backup the file's contents. This dates from
the days of slow tapes to greatly reduce backup times (it would skip
page/swap files for instance). But with backups over wi-fi and 3g, such
a bit would have been much better on IOS than telling app priters to put
their files in "cache".

Or perhaps they should have created a second documents directory which
is not backed up.

This is why Apple really needs to open up a proper file system for IOS.
It has now reached a point where people want to write file based apps
that need access to a proper file system.
J.J. O'Shea
2011-10-24 02:05:12 UTC
Permalink
Post by JF Mezei
Post by J.J. O'Shea
That would be how I see things. However I'm a little short on actual data. I
really would like to have some real, actual, hard data on this.
If you have 2 gigs worth of maps in the "documents" folder, they get
backed up.
I still don't see a problem.
Post by JF Mezei
With the move to backing up over wi-fi or 3g, this becomes
not only time consuming bout also expensive for 3g connection when this
is done every day to icloud.
Ah. Well, I fired Verizon and moved to Sprint when I got my brand-new iPhone
4S (the first iPhone I ever had) last week. I did that in part precisely
because Verizon (and AT&T) have 2 GB caps on their data services while Sprint
does not. Now, when I was with Verizon I rarely went over 500 MB and topped
1.5 GB exactly once, and I was there for four years. (which meant that I had
an unlimited data account which was grandfathered in, but Verizon did other
things which annoyed me, so I waited for the contract to expire and bailed.
I've held my nose and gone to AT&T except that Sprint got iPhones so I went
there instead.)

Question: I thought that the backup only occurred _when your device was
connected by WiFi and was running on mains power_. Indeed, the connect by
WiFi bit is specifically mentioned at
<http://www.apple.com/icloud/features/apps-books-backup.html>; the must be on
mains power is somewhere in the iPhone user guide, available from Apple as an
iBook. I'm up to page 78 of 532. This would mean that 3G limits would be
immaterial, as you'd be connected by a wireless network. Further, unless you
changed all 2 GB of data on a daily basis, backup would only bother with your
changes. I don't see the problem. I really don't.
Post by JF Mezei
So, Apple recommended you move those files to the cache directory so
they don't get backed up.
That would be... silly.
Post by JF Mezei
In VMS, there is a bit in files called "no backup". you set the bit, and
the backup utility does not backup the file's contents. This dates from
the days of slow tapes to greatly reduce backup times (it would skip
page/swap files for instance). But with backups over wi-fi and 3g, such
a bit would have been much better on IOS than telling app priters to put
their files in "cache".
Or perhaps they should have created a second documents directory which
is not backed up.
This is why Apple really needs to open up a proper file system for IOS.
It has now reached a point where people want to write file based apps
that need access to a proper file system.
Where did Apple make the statement about moving files to the cache directory?
--
email to oshea dot j dot j at gmail dot com.
Your Name
2011-10-24 02:55:01 UTC
Permalink
In article <***@news4.newsguy.com>, ***@just.go.net wrote:
<snip>
Post by J.J. O'Shea
Post by JF Mezei
This is why Apple really needs to open up a proper file system for IOS.
It has now reached a point where people want to write file based apps
that need access to a proper file system.
Where did Apple make the statement about moving files to the cache directory?
Don't waste your time. "JF Mezei" is just another know-nothing anti-Apple
troll who posts utter garbage, and doesn't want to know nor have the
ability to understand actual facts. :-\
Todd Allcock
2011-10-24 03:58:15 UTC
Permalink
Post by Your Name
<snip>
Post by J.J. O'Shea
Post by JF Mezei
This is why Apple really needs to open up a proper file system for IOS.
It has now reached a point where people want to write file based apps
that need access to a proper file system.
Where did Apple make the statement about moving files to the cache directory?
Don't waste your time. "JF Mezei" is just another know-nothing anti-
Apple
Post by Your Name
troll who posts utter garbage, and doesn't want to know nor have the
ability to understand actual facts. :-\
JF might have a few very minor details wrong in this case, but I've
quoted the requested "statement from Apple" in my previous post. Make
sure your newsreader is set to display text in any color other than red
so your rose-tinted glasses don't inadvertently filter it out.
Your Name
2011-10-24 04:42:53 UTC
Permalink
Post by Todd Allcock
Post by Your Name
<snip>
Post by J.J. O'Shea
Post by JF Mezei
This is why Apple really needs to open up a proper file system for
IOS. It has now reached a point where people want to write file
based apps that need access to a proper file system.
Where did Apple make the statement about moving files to the cache directory?
Don't waste your time. "JF Mezei" is just another know-nothing anti-
Apple troll who posts utter garbage, and doesn't want to know nor have
the ability to understand actual facts. :-\
JF might have a few very minor details wrong in this case, but I've
quoted the requested "statement from Apple" in my previous post. Make
sure your newsreader is set to display text in any color other than red
so your rose-tinted glasses don't inadvertently filter it out.
I meant the crap about iOS not having a proper file system, among numerous
other garbage posts.
JF Mezei
2011-10-24 06:09:51 UTC
Permalink
Post by Your Name
I meant the crap about iOS not having a proper file system, among numerous
other garbage posts.
That argument is very stale. I don't care that IOS is actually Unix with
HFS under the hood. I care that I, as the onwer of an unlocked iPhone,
cannot see any of *MY* files in there.

I care that applications such as Safari don't allow me to download stuff
from the net to my device, and especially won't allow me to upload data
from my device to the net.

Yes, you'll argue this is an "application issue", but those applications
are Apple apps and designed to enforce Apple's decision to hide the file
system from users and applications.

So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.

And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe files
backups regularly, or only during sync or never.
Doug Anderson
2011-10-24 14:36:34 UTC
Permalink
Post by JF Mezei
Post by Your Name
I meant the crap about iOS not having a proper file system, among numerous
other garbage posts.
That argument is very stale. I don't care that IOS is actually Unix with
HFS under the hood. I care that I, as the onwer of an unlocked iPhone,
cannot see any of *MY* files in there.
I care that applications such as Safari don't allow me to download stuff
from the net to my device, and especially won't allow me to upload data
from my device to the net.
Yes, you'll argue this is an "application issue",
That's right, it is.
Post by JF Mezei
but those applications
are Apple apps and designed to enforce Apple's decision to hide the file
system from users and applications.
Also right.
Post by JF Mezei
So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.
That part's wrong. App writers can store things in a way that they
will get backed up, or they can store them in a way that they won't
get backed up. They get to make that choice, and it is sensible to
let them make that choice.
Post by JF Mezei
And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe files
backups regularly, or only during sync or never.
I'm not sure if there is anything for Apple to fix, except to make
clearer the consequences of putting files in the "no backup" category
and the consequences of putting them in the "to be backuped" category.
Todd Allcock
2011-10-24 15:59:57 UTC
Permalink
Post by Doug Anderson
Post by JF Mezei
So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.
That part's wrong. App writers can store things in a way that they
will get backed up, or they can store them in a way that they won't
get backed up. They get to make that choice, and it is sensible to
let them make that choice.
Except in the cases where Apple's guidelines don't let them make that
choice, as the links posted in this thread several times point out.
Post by Doug Anderson
Post by JF Mezei
And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe files
backups regularly, or only during sync or never.
I'm not sure if there is anything for Apple to fix, except to make
clearer the consequences of putting files in the "no backup" category
and the consequences of putting them in the "to be backuped" category.
Certainly there's something for Apple to fix. There needs to be a way for
apps to store data files without having them deleted arbitrarily by the OS.


Right now for devs it is a Hobson's choice. The dev can use the "no
backup" category (cache) and risk having the OS wipe the app's data
without the app having any way to prevent it, or store it in the "to be
backedup" category (documents) and risk Apple pulling the app from the
store for not following guidelines which demand such data be placed in
cache.

This wasn't an issue until iOS5 introduced the "cleaning" feature which
empties sandboxed cache folders when storage space gets low. Presumably
this was an unintended consequence (I'd hope, anyway!) and will be fixed
in the next update.
Doug Anderson
2011-10-24 17:29:41 UTC
Permalink
Post by Todd Allcock
Post by Doug Anderson
Post by JF Mezei
So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.
That part's wrong. App writers can store things in a way that they
will get backed up, or they can store them in a way that they won't
get backed up. They get to make that choice, and it is sensible to
let them make that choice.
Except in the cases where Apple's guidelines don't let them make that
choice, as the links posted in this thread several times point out.
Well, not exactly. They can still make the choice to put stuff in
Documents, and that seems to be the right thing to do until Apple
provides other options.
Post by Todd Allcock
Post by Doug Anderson
Post by JF Mezei
And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe
files
Post by Doug Anderson
Post by JF Mezei
backups regularly, or only during sync or never.
I'm not sure if there is anything for Apple to fix, except to make
clearer the consequences of putting files in the "no backup" category
and the consequences of putting them in the "to be backuped" category.
Certainly there's something for Apple to fix. There needs to be a way for
apps to store data files without having them deleted arbitrarily by the OS.
Yes, and apparently that is the Documents folder.
Post by Todd Allcock
Right now for devs it is a Hobson's choice. The dev can use the "no
backup" category (cache) and risk having the OS wipe the app's data
without the app having any way to prevent it, or store it in the "to be
backedup" category (documents) and risk Apple pulling the app from the
store for not following guidelines which demand such data be placed in
cache.
This wasn't an issue until iOS5 introduced the "cleaning" feature which
empties sandboxed cache folders when storage space gets low. Presumably
this was an unintended consequence (I'd hope, anyway!) and will be fixed
in the next update.
Presumably, yes.

It seems like Apple needs to figure out a third option, or change the
behavior of the "cleaner."
Todd Allcock
2011-10-24 18:40:35 UTC
Permalink
Post by Doug Anderson
Post by Todd Allcock
Post by Doug Anderson
App writers can store things in a way that they
will get backed up, or they can store them in a way that they won't
get backed up. They get to make that choice, and it is sensible to
let them make that choice.
Except in the cases where Apple's guidelines don't let them make that
choice, as the links posted in this thread several times point out.
Well, not exactly. They can still make the choice to put stuff in
Documents, and that seems to be the right thing to do until Apple
provides other options.
Again, no, they really can't. Apple's guidelines only allow non-
replicable data to be stored in a Documents folder. If you make an
encyclopedia app, your entries must go in cache, since they can be re-
retrieved from the original source. Your ebook reader must put the ebooks
in cache, since they can be re-downloaded. Your offline GPS must put the
maps in cache, etc. Apple
(understandably) seems to want to keep the iCloud servers' load as light
as possible.

Don't follow the rules and you accept Apple's consequences, which
presumably include having your app removed from the store. Not exactly a
"choice" for the dev, is it?
Post by Doug Anderson
Post by Todd Allcock
Post by Doug Anderson
I'm not sure if there is anything for Apple to fix, except to make
clearer the consequences of putting files in the "no backup"
category and the consequences of putting them in the "to be
backuped" category.
Certainly there's something for Apple to fix. There needs to be a way
for apps to store data files without having them deleted arbitrarily
by the OS.
Yes, and apparently that is the Documents folder.
Again, only if your data fits the narrow category of allowed "document"
content, mostly user-created documents.
Post by Doug Anderson
Post by Todd Allcock
Right now for devs it is a Hobson's choice. The dev can use the "no
backup" category (cache) and risk having the OS wipe the app's data
without the app having any way to prevent it, or store it in the "to
be backedup" category (documents) and risk Apple pulling the app from
the store for not following guidelines which demand such data be
placed in cache.
This wasn't an issue until iOS5 introduced the "cleaning" feature
which empties sandboxed cache folders when storage space gets low.
Presumably this was an unintended consequence (I'd hope, anyway!) and
will be fixed in the next update.
Presumably, yes.
It seems like Apple needs to figure out a third option, or change the
behavior of the "cleaner."
Exactly, which is why this IS something for them to "fix".
Wes Groleau
2011-10-26 01:33:28 UTC
Permalink
Post by Doug Anderson
Well, not exactly. They can still make the choice to put stuff in
Documents, and that seems to be the right thing to do until Apple
provides other options.
If I save a document from Pages, or a Photo from the camera,
I ought to be able to browse to it and upload it when I click
the button on a web page designed for that purpose.

Grandma says, "Why does this work on the computer and not here?"
--
Wes Groleau

There are two types of people in the world …
http://Ideas.Lang-Learn.us/barrett?itemid=1157
Michael Eyd
2011-10-26 11:45:58 UTC
Permalink
Post by Wes Groleau
Well, not exactly. They can still make the choice to put stuff in
Documents, and that seems to be the right thing to do until Apple
provides other options.
If I save a document from Pages, or a Photo from the camera,
I ought to be able to browse to it and upload it when I click
the button on a web page designed for that purpose.
Grandma says, "Why does this work on the computer and not here?"
For security reasons. No application is allowed to access data from
another application (with only a few exceptions like the camera roll or
published APIs (like to access calendar or contact data)). And a browser
is a different application than Pages, isn't it?

Like it or not, but exactly this behavior is part of the (much) higher
security of the iOS platform compared with Android (where this is
possible AFAIK).

Best regards,

Michael
Wes Groleau
2011-10-26 23:25:39 UTC
Permalink
Post by Michael Eyd
Post by Wes Groleau
Grandma says, "Why does this work on the computer and not here?"
For security reasons. No application is allowed to access data from
I wasn't expecting an answer, especially not one that's already been
said several times in this thread. I was just emphasizing the point
of the thread that "security reasons" do NOT prohibit what we've been
asking for.
--
Wes Groleau

There are two types of people in the world …
http://Ideas.Lang-Learn.us/barrett?itemid=1157
nospam
2011-10-24 14:44:10 UTC
Permalink
Post by JF Mezei
That argument is very stale. I don't care that IOS is actually Unix with
HFS under the hood. I care that I, as the onwer of an unlocked iPhone,
cannot see any of *MY* files in there.
nonsense. of course you can. tap on the relevant app or sync with
itunes.
Post by JF Mezei
I care that applications such as Safari don't allow me to download stuff
from the net to my device, and especially won't allow me to upload data
from my device to the net.
other browsers do.
Post by JF Mezei
Yes, you'll argue this is an "application issue", but those applications
are Apple apps and designed to enforce Apple's decision to hide the file
system from users and applications.
see above.
Post by JF Mezei
So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.
that's a different issue. you don't need file system access to share
data.
Post by JF Mezei
And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe files
backups regularly, or only during sync or never.
yet another issue unrelated to file system access.
Your Name
2011-10-24 20:24:38 UTC
Permalink
Post by JF Mezei
Post by Your Name
I meant the crap about iOS not having a proper file system, among numerous
other garbage posts.
That argument is very stale. I don't care that IOS is actually Unix with
HFS under the hood. I care that I, as the onwer of an unlocked iPhone,
cannot see any of *MY* files in there.
I care that applications such as Safari don't allow me to download stuff
from the net to my device, and especially won't allow me to upload data
from my device to the net.
Yes, you'll argue this is an "application issue", but those applications
are Apple apps and designed to enforce Apple's decision to hide the file
system from users and applications.
So this whole busimess about not allowing access to a file system has
resulted in a very stupid way to store private app data which makes
backup issues serious, and prevents 2 cooperating apps from sharing data.
And if Apple really wanted to fix this, it would add a "no backup" bit
to files to allow applicatiosn/users to specify if they want thsoe files
backups regularly, or only during sync or never.
More of the same know-nothing Anti-Apple garbage. :-\
JF Mezei
2011-10-24 04:14:31 UTC
Permalink
Post by J.J. O'Shea
Post by JF Mezei
If you have 2 gigs worth of maps in the "documents" folder, they get
backed up.
I still don't see a problem.
See how long it takes to back that up every day. Consider a case where
such a file is a database and a few records get changed every day. Do
you really want to backup the whole file (since its "last modified date"
would be changed).
Post by J.J. O'Shea
Where did Apple make the statement about moving files to the cache directory?
This was posted earlier in this thread by someone else.

http://www.marco.org/2011/10/13/ios5-caches-cleaning

Suggest you read it. It isn't from me, so perhaps you'll believe it.
J.J. O'Shea
2011-10-24 12:22:25 UTC
Permalink
Post by JF Mezei
Post by J.J. O'Shea
Post by JF Mezei
If you have 2 gigs worth of maps in the "documents" folder, they get
backed up.
I still don't see a problem.
See how long it takes to back that up every day.
I back up more than 2 GB every day on my desktop system. I don't see a
problem.
Post by JF Mezei
Consider a case where
such a file is a database and a few records get changed every day. Do
you really want to backup the whole file (since its "last modified date"
would be changed).
And that's why I back up more than 2 GB on my desktop system. Actually I back
up considerably more than 2 GB; the newsreader I'm using, for instance, uses
a database per newsgroup to track posts, which means that every time I update
any newsgroup or post something myself at least one database gets updated.
The database for the collection of groups which includes this one is about
200 MB, but I have quite a few groups that I keep track of, so the overall
total is more than 4 GB. Not all of that gets updated every day, of course,
but a fair proportion does. And this particular app is by no means the only
one which creates databases, some of them quite large, which get backed up on
a daily basis... or more often, depending on where they are and how I set
Time Machine.

I really am having a hard time seeing the problem.
Post by JF Mezei
Post by J.J. O'Shea
Where did Apple make the statement about moving files to the cache directory?
This was posted earlier in this thread by someone else.
http://www.marco.org/2011/10/13/ios5-caches-cleaning
Suggest you read it. It isn't from me, so perhaps you'll believe it.
I was merely asking for information.
--
email to oshea dot j dot j at gmail dot com.
Peter
2011-10-24 13:52:04 UTC
Permalink
Post by J.J. O'Shea
I back up more than 2 GB every day on my desktop system. I don't see a
problem.
Over 3G?
J.J. O'Shea
2011-10-24 14:02:48 UTC
Permalink
Post by Peter
Post by J.J. O'Shea
I back up more than 2 GB every day on my desktop system. I don't see a
problem.
Over 3G?
Except that the backup doesn't work over 3G, as I've stated in Message-ID:
<***@news4.newsguy.com>. Please see
<http://www.apple.com/icloud/features/apps-books-backup.html> and do try to
keep up.

I don't see a problem. I really don't.
--
email to oshea dot j dot j at gmail dot com.
Todd Allcock
2011-10-24 03:52:52 UTC
Permalink
Post by J.J. O'Shea
Post by JF Mezei
So, Apple recommended you move those files to the cache directory so
they don't get backed up.
That would be... silly.
Not if the OS didn't flush the cache without the app's permission.

Keep in mind, with iOS sandboxing, we're talking about a specific cache
(and/or temp) folder for each app, not a general purpose cache or temp
folder for the entire device/OS, (which would be silly, and probably
impossible, for apps to use for storage.)

The policy seems perfectly reasonable, and was, until iOS5 added a device
storage "cleaning" feature, which empties the various cache and temp
folders of individual apps when storage gets low.
Post by J.J. O'Shea
Where did Apple make the statement about moving files to the cache directory?
It's in the developer documentation, which, since I'm not an iOS dev, I'm
not privy to, but this guy, the developer of Instapaper, is:

http://www.marco.org/2011/10/13/ios5-caches-cleaning

He quotes the dev documentation:

"1. Only documents and other data that is user-generated, or that cannot
otherwise be recreated by your application, should be stored in the < A p
p l i c a t i o n _ H o m e > / D o c u m e n t s directory and will be
automatically backed up by iCloud.

"2. Data that can be downloaded again or regenerated should be stored in
the < A p p l i c a t i o n _ H o m e > / L i b r a r y / C a c h e s
directory. Examples of files you should put in the Caches directory
include database cache files and downloadable content, such as that used
by magazine, newspaper, and map applications."


If a dev's apps don't follow the rule, they get this letter from Apple:

"In recent testing it appears that [your app] stores a fair amount of
data in its Documents folder.

"Since iCloud backups are performed daily over Wi-Fi for each user’s iOS
device, it’s important to ensure the best possible user experience by
minimizing the amount of data being stored by your app.

"In addition to purchased music, apps, books, Camera roll, and device
settings, everything in your app’s home directory, including its
Documents folder, is backed up to iCloud.

"Data stored in the application bundle itself, the caches directory, and
the temp directory is not backed up to iCloud. Your app should store data
in these locations according to the iCloud Data Storage Guidelines on
<http://developer.apple.com/icloud/documentation/data-storage/>.

"Please review these guidelines, make any required changes to your app,
and submit an update to the App Store..."
J.J. O'Shea
2011-10-24 12:25:19 UTC
Permalink
Post by Todd Allcock
Post by J.J. O'Shea
Post by JF Mezei
So, Apple recommended you move those files to the cache directory so
they don't get backed up.
That would be... silly.
Not if the OS didn't flush the cache without the app's permission.
Well, yeah.
Post by Todd Allcock
Keep in mind, with iOS sandboxing, we're talking about a specific cache
(and/or temp) folder for each app, not a general purpose cache or temp
folder for the entire device/OS, (which would be silly, and probably
impossible, for apps to use for storage.)
I was wondering how they did it.
Post by Todd Allcock
The policy seems perfectly reasonable, and was, until iOS5 added a device
storage "cleaning" feature, which empties the various cache and temp
folders of individual apps when storage gets low.
I see.
Post by Todd Allcock
Post by J.J. O'Shea
Where did Apple make the statement about moving files to the cache directory?
It's in the developer documentation, which, since I'm not an iOS dev, I'm
http://www.marco.org/2011/10/13/ios5-caches-cleaning
Thanks.
--
email to oshea dot j dot j at gmail dot com.
Todd Allcock
2011-10-24 03:52:52 UTC
Permalink
Post by J.J. O'Shea
Post by JF Mezei
So, Apple recommended you move those files to the cache directory so
they don't get backed up.
That would be... silly.
Not if the OS didn't flush the cache without the app's permission.

Keep in mind, with iOS sandboxing, we're talking about a specific cache
(and/or temp) folder for each app, not a general purpose cache or temp
folder for the entire device/OS, (which would be silly, and probably
impossible, for apps to use for storage.)

The policy seems perfectly reasonable, and was, until iOS5 added a device
storage "cleaning" feature, which empties the various cache and temp
folders of individual apps when storage gets low.
Post by J.J. O'Shea
Where did Apple make the statement about moving files to the cache directory?
It's in the developer documentation, which, since I'm not an iOS dev, I'm
not privy to, but this guy, the developer of Instapaper, is:

http://www.marco.org/2011/10/13/ios5-caches-cleaning

He quotes the dev documentation:

"1. Only documents and other data that is user-generated, or that cannot
otherwise be recreated by your application, should be stored in the < A p
p l i c a t i o n _ H o m e > / D o c u m e n t s directory and will be
automatically backed up by iCloud.

"2. Data that can be downloaded again or regenerated should be stored in
the < A p p l i c a t i o n _ H o m e > / L i b r a r y / C a c h e s
directory. Examples of files you should put in the Caches directory
include database cache files and downloadable content, such as that used
by magazine, newspaper, and map applications."


If a dev's apps don't follow the rule, they get this letter from Apple:

"In recent testing it appears that [your app] stores a fair amount of
data in its Documents folder.

"Since iCloud backups are performed daily over Wi-Fi for each user’s iOS
device, it’s important to ensure the best possible user experience by
minimizing the amount of data being stored by your app.

"In addition to purchased music, apps, books, Camera roll, and device
settings, everything in your app’s home directory, including its
Documents folder, is backed up to iCloud.

"Data stored in the application bundle itself, the caches directory, and
the temp directory is not backed up to iCloud. Your app should store data
in these locations according to the iCloud Data Storage Guidelines on
<http://developer.apple.com/icloud/documentation/data-storage/>.

"Please review these guidelines, make any required changes to your app,
and submit an update to the App Store..."
Todd Allcock
2011-10-24 04:13:09 UTC
Permalink
Post by JF Mezei
Or perhaps they should have created a second documents directory which
is not backed up.
There's nothing wrong with using a cache folder to store data, so long as
the app has exclusive control if it (which, until iOS5, it did.)
Post by JF Mezei
This is why Apple really needs to open up a proper file system for IOS.
It has now reached a point where people want to write file based apps
that need access to a proper file system.
*Sigh* Apps have access to a "proper file system." You and I as end-
users don't. Those are two completely different things.
The sandbox concept certainly is limiting in many ways, but it isn't the
villain here. Turning the "cleaning" feature loose on sandboxed data
space without first giving devs a safe location that isn't synced yet
immune from "cleaning" is the problem.

Take a deep breath and relax, since this issue doesn't affect you anyway,
and give Apple a few days to sort out what was obviously an unintended
consequence of a new feature.

The sky isn't falling, and neither are any planes! Despite the issue, no
one here knows with any certainty if the industry specific (and
proprietary) apps the airlines are using are even subject to this issue.
(Without the need for App store approval, none of us know if these
airline chart apps follow the cache guidelines or simply "illegally"
store their data in the protected document folders.)
Todd Allcock
2011-10-23 03:43:59 UTC
Permalink
Post by Doug Anderson
I haven't read enough about this to understand it, but if OS updates
can delete user data then it is important for that to be well
documented in a specific enough way so that users can avoid losing
data they care about.
The update doesn't delete the data per se, it's that iOS5 now has the
ability to flush the cache folders created by individual apps.

My understanding of this comes from the blog of the dev who created the
Instapaper app.

http://www.marco.org/2011/10/13/ios5-caches-cleaning



"There’s no longer anywhere to store files that don’t need to be backed
up (or can’t be, by the new policy) but shouldn’t be randomly deleted.
This is problematic for lots of apps, including this quick list off the
top of my head:

"Instapaper and anything that saves web articles for offline reading

"Ebook and comic-book apps (including iBooks, if the rules apply to it)

"Podcast clients (the rules don’t apply to synced podcasts from iTunes)

"Offline Wikipedia apps

"Offline mapping programs..."
Michael Eyd
2011-10-24 08:33:18 UTC
Permalink
Post by JF Mezei
Post by Todd Allcock
In this case the "villain" isn't really the OS, but the dev
guidelines.
The vilain is Apple who decided early on that IOS did not have an
accessible file system, and instead of revoking this religious
belief and granting access to *a* file system, Apple went with a baby
step that wasn't enough (limited storage within an app's directory).
Great! Let's open up a standard file system like e.g. under DOS/Windows,
where every application can actually write everywhere (at least pre-Win
Vista).

You know that this generally 'open' design of the PC file systems was
one of the fundamental preconditions for many of the PC malware? You
really want to get that on iOS just as well? Me not... And actually,
since Windows Vista Microsoft has seriously limited this openness,
applications these days are only allowed to write into certain areas of
the file system, others require admin approval (UAC), others are
off-limits to all third-party applications, full-stop. Doesn't that make
you wonder why MS went exactly the opposite way than what you're
requesting? And why they were getting big cheers from security
specialists from all over the world for this (not so much from users for
their first implementation, I admit... ;-) )?
Post by JF Mezei
Not sure if "not smart" or "extremely stupid" applies, but at the end
of the day, those who decided to use an iPad for a mission critical
app in cockpits made a huge error.
Without a reliable file system,
The file system in iOS is (AFAIK, please provide provide proof for other
findings) reliable. I've yet to hear from data loss due to an unreliable
file system.

That the OS (i.e. the downloader) is allowed to free up space in
'directories' (AFAIK) clearly documented as 'non-permanent' - that's
certainly not the fault of the file system itself. And, by the way,
Windows (and most probably MacOS X just as well) does the same, if space
runs low, the $TEMP$ directory might be cleared just as well. And nobody
may complain about this, this directory was just not meant for permanent
data.
Post by JF Mezei
they should not have selected the iPad for this. This is the same as
stock exchange presidents deciding to migrate their IT to Windows and
finding out after having spent hundreds of millions that Windows was
not designed to handle such a job.
Apple clearly did not intend the iPad (or IOS) to be used for
mission critical apps needing their own storage. Folks in aviation
decided to use it anyways and are now stuck with a major problem.
Please enlighten me: How do standard (on-board) navigation apps for
street navigation suffer from this? Not at all? Then why didn't the
programmers of the aviation software didn't use the very same data
storage strategy? They are? Why didn't anybody brag about this so far?
Post by JF Mezei
The big question now is how will Apple react. There is the issue of
short term fix. This has the potential of a meg egg on face if the
media take a hold of this.
If Apple realises the potential of the iPad in commercial
applications, perhaps it will relent and open a real file system.
I'm very sure that they will not go there. And, as stated above, for
*very* good reasons! Which doesn't mean that they might not change their
policies for app data storage - but I see no reason whatsoever for
allowing apps to access any part of the (present) file system.
Post by JF Mezei
If not, it risks relegating its iToys to the toy department and be
shunned from business.
Due to a 'missing' file system? Keep on dreaming, that's not gonna
happen. :-)

Best regards,

Michael
Todd Allcock
2011-10-24 12:24:18 UTC
Permalink
Post by Michael Eyd
Post by JF Mezei
Post by Todd Allcock
In this case the "villain" isn't really the OS, but the dev
guidelines.
The vilain is Apple who decided early on that IOS did not have an
accessible file system, and instead of revoking this religious
belief and granting access to *a* file system, Apple went with a baby
step that wasn't enough (limited storage within an app's directory).
Great! Let's open up a standard file system like e.g. under DOS/Windows,
where every application can actually write everywhere (at least pre-Win
Vista).
You know that this generally 'open' design of the PC file systems was
one of the fundamental preconditions for many of the PC malware? You
really want to get that on iOS just as well? Me not... And actually,
since Windows Vista Microsoft has seriously limited this openness,
applications these days are only allowed to write into certain areas of
the file system, others require admin approval (UAC), others are
off-limits to all third-party applications, full-stop. Doesn't that make
you wonder why MS went exactly the opposite way than what you're
requesting? And why they were getting big cheers from security
specialists from all over the world for this (not so much from users for
their first implementation, I admit... ;-) )?
Post by JF Mezei
Not sure if "not smart" or "extremely stupid" applies, but at the end
of the day, those who decided to use an iPad for a mission critical
app in cockpits made a huge error.
Without a reliable file system,
The file system in iOS is (AFAIK, please provide provide proof for other
findings) reliable. I've yet to hear from data loss due to an unreliable
file system.
That the OS (i.e. the downloader) is allowed to free up space in
'directories' (AFAIK) clearly documented as 'non-permanent' - that's
certainly not the fault of the file system itself. And, by the way,
Windows (and most probably MacOS X just as well) does the same, if space
runs low, the $TEMP$ directory might be cleared just as well. And nobody
may complain about this, this directory was just not meant for permanent
data.
Post by JF Mezei
they should not have selected the iPad for this. This is the same as
stock exchange presidents deciding to migrate their IT to Windows and
finding out after having spent hundreds of millions that Windows was
not designed to handle such a job.
Apple clearly did not intend the iPad (or IOS) to be used for
mission critical apps needing their own storage. Folks in aviation
decided to use it anyways and are now stuck with a major problem.
Please enlighten me: How do standard (on-board) navigation apps for
street navigation suffer from this? Not at all? Then why didn't the
programmers of the aviation software didn't use the very same data
storage strategy? They are? Why didn't anybody brag about this so far?
Post by JF Mezei
The big question now is how will Apple react. There is the issue of
short term fix. This has the potential of a meg egg on face if the
media take a hold of this.
If Apple realises the potential of the iPad in commercial
applications, perhaps it will relent and open a real file system.
I'm very sure that they will not go there. And, as stated above, for
*very* good reasons! Which doesn't mean that they might not change their
policies for app data storage - but I see no reason whatsoever for
allowing apps to access any part of the (present) file system.
Post by JF Mezei
If not, it risks relegating its iToys to the toy department and be
shunned from business.
Due to a 'missing' file system? Keep on dreaming, that's not gonna
happen. :-)
I agree that a completely open file system would be silly, but a shared
document space all third party apps could read/write to would make sense,
along with an ability to specify a default app to open a particular file
type. (E.g. ePub books open in iBooks by default, etc.)

The current system, and the "send to" method of redundantly copying files
between apps' sandboxes file areas, is a little tedious.
Michael Eyd
2011-10-24 15:37:12 UTC
Permalink
Post by Todd Allcock
I agree that a completely open file system would be silly, but a shared
document space all third party apps could read/write to would make sense,
along with an ability to specify a default app to open a particular file
type. (E.g. ePub books open in iBooks by default, etc.)
Which would in turn open again the chance for app A to supply app B with
data, that is de facto malware (or allows malware to take over the
system). All this without any chance for a user to stop this.

Security was (as much as I can tell from looking at the result) one of
the very basic design principles when starting the development of iOS,
even user experience (otherwise probably the most important design
driver) had to step back against security, I feel.
Post by Todd Allcock
The current system, and the "send to" method of redundantly copying files
between apps' sandboxes file areas, is a little tedious.
Yes, but certainly less insecure. ;-) Like always, there're pros and
cons for each design decision...

Best regards,

Michael
Todd Allcock
2011-10-24 17:31:34 UTC
Permalink
Post by Michael Eyd
Post by Todd Allcock
I agree that a completely open file system would be silly, but a shared
document space all third party apps could read/write to would make sense,
along with an ability to specify a default app to open a particular file
type. (E.g. ePub books open in iBooks by default, etc.)
Which would in turn open again the chance for app A to supply app B
with data, that is de facto malware (or allows malware to take over the
system). All this without any chance for a user to stop this.
How so? I'm not saying to break the sandbox, just to create a shared
folder that all apps can choose to use instead of, or in addition to,
their own protected folders.

How would this be any different from a security standpoint than the
current awkward "send to" technique, where my Dropbox app can send a file
to my PDF reader by making an unnecessary duplicate for the reader to
place in its own file space?

Same PDF, same potential "trojan horse" malware; the only difference is
that with a shared folder, the user could willingly open the file in "app
B" without the cumbersome need to open "app A" and send it first. Apps
would still be vetted by Apple like they are currently, how does your
hypothetical "malicious app A" get on the device in the first place?
Post by Michael Eyd
Security was (as much as I can tell from looking at the result) one of
the very basic design principles when starting the development of iOS,
even user experience (otherwise probably the most important design
driver) had to step back against security, I feel.
I disagree. I think the "app store" was a lucky accident, and the "web
app" model was the original intent and that only changed when devs balked
at the limitations of web apps, along with the looming threat of more
robust native apps on other platforms. The original security model was
simple: secure Safari, and make it the only access for applications.

To launch a third-party apps ecosystem quickly, Apple had two choices: one,
they could use a sandbox/VM model and throw a minimal set of APIs
together quickly, or two, allowing Palm OS/Windows Mobile-style
unfettered access to the innards of the device by opening it up to
unmanaged code, and let devs use the same tools Apple used internally to
build the native apps.

For a variety of security, stability, revenue-generation, and user
experience reasons, sandboxing was an obvious choice, but I still don't
see any real downside in letting devs opt to use a shared documents folder.
They already have one now: the camera roll, but it's limited, obviously,
to pictures. Why not one dedicated to documents? How is that less
secure than the shared camera roll (which, IIRC was surreptitiously used
to share data between apps by the same developer until Apple discovered
the practice and kiboshed it.)
Post by Michael Eyd
Post by Todd Allcock
The current system, and the "send to" method of redundantly copying files
between apps' sandboxes file areas, is a little tedious.
Yes, but certainly less insecure. ;-)
How, exactly, is it less secure to let apps share the same file than
sending copies of the exact same files between apps?

And how would your hypothetical malware attack the system from within a
sandboxed app, even if that app could access a folder shared by other
sandboxed apps? Other, than perhaps erase the contents of that folder
intentionally or unintentionally? The device's system files and data
(contacts, calendar, etc.) would be no more accessible than they are now.
(Which, AFAIK, are already accessible via "legal" APIs and therefore
already at risk from malicious apps that could sneak by the approval
process.)

The current file management in iOS is broken- it's ridiculous that users
have to check umpteen different apps to figure out which one has the
particular file they're looking for.
Post by Michael Eyd
Like always, there're pros and cons for each design decision...
I'm not seeing any cons to a shared folder that apps could opt-in to using.
And non-specific "security" concerns aren't particularly convincing.
Michael Eyd
2011-10-25 07:08:59 UTC
Permalink
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
I agree that a completely open file system would be silly, but a
shared document space all third party apps could read/write to
would make sense, along with an ability to specify a default app
to open a particular file type. (E.g. ePub books open in iBooks
by default, etc.)
Which would in turn open again the chance for app A to supply app
B with data, that is de facto malware (or allows malware to take
over the system). All this without any chance for a user to stop
this.
How so? I'm not saying to break the sandbox, just to create a
shared folder that all apps can choose to use instead of, or in
addition to, their own protected folders.
I see several possibilities:

a) App A can store a (suitably prepared) document to be opened by some
other app B, that will then make B behave in some unexpected and
unwanted way.

b) App A could manipulate already present files in this shared folder,
i.e. files which it was never expected to manipulate. It could alter its
content (like the very first viruses under DOS did), it could altogether
replace the file, it could even delete the whole content of this directory.
Post by Todd Allcock
How would this be any different from a security standpoint than the
current awkward "send to" technique, where my Dropbox app can send a
file to my PDF reader by making an unnecessary duplicate for the
reader to place in its own file space?
In this case it's still the user who needs to push a button - though I
agree that this is only a very limited security barrier.
Post by Todd Allcock
Same PDF, same potential "trojan horse" malware; the only difference
is that with a shared folder, the user could willingly open the file
in "app B" without the cumbersome need to open "app A" and send it
first. Apps would still be vetted by Apple like they are currently,
how does your hypothetical "malicious app A" get on the device in the
first place?
a) There are other sources than the official Apple AppStore (at least
for jailbroken devices).
b) Some sufficiently advanced programming tricks might do the trick as
well... ;-)
Post by Todd Allcock
Post by Michael Eyd
Security was (as much as I can tell from looking at the result) one
of the very basic design principles when starting the development
of iOS, even user experience (otherwise probably the most important
design driver) had to step back against security, I feel.
I disagree. I think the "app store" was a lucky accident, and the
"web app" model was the original intent and that only changed when
devs balked at the limitations of web apps, along with the looming
threat of more robust native apps on other platforms. The original
security model was simple: secure Safari, and make it the only access
for applications.
Which is by no means contradicting my statement.
Post by Todd Allcock
To launch a third-party apps ecosystem quickly, Apple had two
choices: one, they could use a sandbox/VM model and throw a minimal
set of APIs together quickly, or two, allowing Palm OS/Windows
Mobile-style unfettered access to the innards of the device by
opening it up to unmanaged code, and let devs use the same tools
Apple used internally to build the native apps.
For a variety of security, stability, revenue-generation, and user
experience reasons, sandboxing was an obvious choice, but I still
don't see any real downside in letting devs opt to use a shared
documents folder.
I do. Now, where does this lead us? ;-)
Post by Todd Allcock
They already have one now: the camera roll, but it's limited,
obviously, to pictures. Why not one dedicated to documents? How is
that less secure than the shared camera roll (which, IIRC was
surreptitiously used to share data between apps by the same developer
until Apple discovered the practice and kiboshed it.)
I agree that the shared camera roll is a step back from the 'security
first' principle, but that does not mean that Apple needs to take the
next (and even bigger) step of a general shared 'Documents' folder just
as well. For the camera roll one (i.e. Apple) has much better ways to
control the content than in a general 'Documents' folder.
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
The current system, and the "send to" method of redundantly
copying files between apps' sandboxes file areas, is a little
tedious.
Yes, but certainly less insecure. ;-)
How, exactly, is it less secure to let apps share the same file than
sending copies of the exact same files between apps?
See above.
Post by Todd Allcock
And how would your hypothetical malware attack the system from within
a sandboxed app, even if that app could access a folder shared by
other sandboxed apps? Other, than perhaps erase the contents of that
folder intentionally or unintentionally? The device's system files
and data (contacts, calendar, etc.) would be no more accessible than
they are now.
No, but it would be much easier for some app to hand over another app
data which will make this behave maliciously.
Post by Todd Allcock
(Which, AFAIK, are already accessible via "legal" APIs and therefore
already at risk from malicious apps that could sneak by the approval
process.)
Access via an API can be much better controlled (e.g. by filtering the
data for formal correctness, ...).
Post by Todd Allcock
The current file management in iOS is broken- it's ridiculous that
users have to check umpteen different apps to figure out which one
has the particular file they're looking for.
You don't work in software development, do you? The file management is
by no means (as far as I can tell from the outside) broken, it is
strictly following its design. You might not like this design, and it
certainly has its drawbacks, but still I don't see any reason whatsoever
to call this design (or the implementation) 'broken'.
Post by Todd Allcock
Post by Michael Eyd
Like always, there're pros and cons for each design decision...
I'm not seeing any cons to a shared folder that apps could opt-in to
using. And non-specific "security" concerns aren't particularly
convincing.
I've tried to be more specific above. If you find these reasons more
convincing - fine. :-) If not, fine with me just as well, I'm not
Apple's evangelist.

Unless you bring new (and convincing) arguments, I'd suggest to end this
discussion here - neither of us will be able to convince the other, I feel.

Best regards,

Michael
Peter
2011-10-25 09:29:41 UTC
Permalink
Post by Michael Eyd
I agree that the shared camera roll is a step back from the 'security
first' principle, but that does not mean that Apple needs to take the
next (and even bigger) step of a general shared 'Documents' folder just
as well. For the camera roll one (i.e. Apple) has much better ways to
control the content than in a general 'Documents' folder.
The Camera Roll is not the only avenue for inter-app data sharing. I
see more and more apps having an option called something like "open
with". For example, an incoming PDF can be opened with the native app,
with Goodreader, or with other PDF readers.

Camera Roll is a big enough vulnerability, because you can have a
malformed Jpeg which causes execution of code of the attacker's
choice. All you need is an app which can read Jpegs (or PNGs, etc) and
which has the vulnerability. Same for a PDF.

To me, every indication is that Apple have gone first and foremost for
SIMPLICITY, even if this arrives at a great cost in productivity.
Those who don't like it need to only look at Apple's share price since
2004 ;) ;)

The "proper computer" paradigm where you have a filing system, and a
given file can be opened in any one of a number of apps easily,
delivers huge productivity and flexibility of working, but causes a
lot of confusion among "dumb" computer users. And productivity is
hardly something associated with an Ipad, which is principally a media
player / web appliance. Very little original content is created on it.
Todd Allcock
2011-10-25 17:53:26 UTC
Permalink
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
I agree that a completely open file system would be silly, but a
shared document space all third party apps could read/write to
would make sense, along with an ability to specify a default app
to open a particular file type. (E.g. ePub books open in iBooks
by default, etc.)
Which would in turn open again the chance for app A to supply app
B with data, that is de facto malware (or allows malware to take
over the system). All this without any chance for a user to stop
this.
How so? I'm not saying to break the sandbox, just to create a
shared folder that all apps can choose to use instead of, or in
addition to, their own protected folders.
a) App A can store a (suitably prepared) document to be opened by some
other app B, that will then make B behave in some unexpected and
unwanted way.
I think you're imagining a scenario that doesn't really apply here, by
applying a typical DOS/Windows malware situation. The rigged payload
only works when the app opening it has unfettered access to the system.
No app in iOS has that. What "unwanted" behavior could you induce in app
B that represents a security risk? Maybe you could get it to crash, but
again, like app A, app B is also sandboxed.
Post by Michael Eyd
b) App A could manipulate already present files in this shared folder,
i.e. files which it was never expected to manipulate. It could alter its
content (like the very first viruses under DOS did), it could altogether
replace the file, it could even delete the whole content of this directory.
Fair enough, I already mentioned that risk, although I feel Apple's
vetting process would be sufficient to prevent this. in either case,
it's a risk/reward thing.

I always find it humorous that we attach a different set of
safety/security expectations to mobile computers when they reach a
certain size. No one would see this file handling advantageous (or at
least worth the usability tradeoff) on their desktop or laptop, but
suddenly it's mission-critical on a tablet or phone? Apparently a shared
documents folder is de rigeur on my desktop, which contains thousands of
documents, but an unacceptable risk on my mobile which contains a few
dozen.

iOS remind me of 1980's era computing, which was app-centric. If you
wanted to open a word processing document you opened your word processor,
then selected the desired document from the file handler in the app.
Crazy me, I thought the file-based handling the GUI introduced was
supposed to be an improvement! ;)
Post by Michael Eyd
Post by Todd Allcock
How would this be any different from a security standpoint than the
current awkward "send to" technique, where my Dropbox app can send a
file to my PDF reader by making an unnecessary duplicate for the
reader to place in its own file space?
In this case it's still the user who needs to push a button - though I
agree that this is only a very limited security barrier.
So then the issue becomes if this awkward layer is only a "limited
barrier", is the usability trade off worth it?
Post by Michael Eyd
Post by Todd Allcock
Same PDF, same potential "trojan horse" malware; the only difference
is that with a shared folder, the user could willingly open the file
in "app B" without the cumbersome need to open "app A" and send it
first. Apps would still be vetted by Apple like they are currently,
how does your hypothetical "malicious app A" get on the device in the
first place?
a) There are other sources than the official Apple AppStore (at least
for jailbroken devices).
True, but those devices already have eschewed any security the sandbox
file system offers since they have no longer have such limitations.
Post by Michael Eyd
b) Some sufficiently advanced programming tricks might do the trick as
well... ;-)
Perhaps, but again, if we're relying on the sandboxed apps to be the
final protection of the device, then the payload that dastardly app A set
up for app B should only really affect app B. (And pragmatically, why
bother? Both app A and app B are subject to the same limitations imposed
by sandboxing and available APIs. Why rig a file to get app B to do
something nasty when app A could just do it itself? App B has no magical
abilities to wreak havoc that app A doesn't have. Your hypothetical
strikes me as a little Rube Goldberg-esque. Not impossible, but rarely
worth the effort! ;)
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Security was (as much as I can tell from looking at the result) one
of the very basic design principles when starting the development
of iOS, even user experience (otherwise probably the most important
design driver) had to step back against security, I feel.
I disagree. I think the "app store" was a lucky accident, and the
"web app" model was the original intent and that only changed when
devs balked at the limitations of web apps, along with the looming
threat of more robust native apps on other platforms. The original
security model was simple: secure Safari, and make it the only access
for applications.
Which is by no means contradicting my statement.
Not directly, just that the security model in my theory took a back seat
to expediency. Sandboxing was easier than securing the OS to a Mac OS
level. The lack of a shared document folder wasn't part of a master
plan, there was just no need for one on a device that didn't have apps,
and therefore no documents, in the first place.
Post by Michael Eyd
Post by Todd Allcock
To launch a third-party apps ecosystem quickly, Apple had two
choices: one, they could use a sandbox/VM model and throw a minimal
set of APIs together quickly, or two, allowing Palm OS/Windows
Mobile-style unfettered access to the innards of the device by
opening it up to unmanaged code, and let devs use the same tools
Apple used internally to build the native apps.
For a variety of security, stability, revenue-generation, and user
experience reasons, sandboxing was an obvious choice, but I still
don't see any real downside in letting devs opt to use a shared
documents folder.
I do. Now, where does this lead us? ;-)
We agree to disagree, I guess.
Post by Michael Eyd
Post by Todd Allcock
They already have one now: the camera roll, but it's limited,
obviously, to pictures. Why not one dedicated to documents? How is
that less secure than the shared camera roll (which, IIRC was
surreptitiously used to share data between apps by the same developer
until Apple discovered the practice and kiboshed it.)
I agree that the shared camera roll is a step back from the 'security
first' principle, but that does not mean that Apple needs to take the
next (and even bigger) step of a general shared 'Documents' folder just
as well. For the camera roll one (i.e. Apple) has much better ways to
control the content than in a general 'Documents' folder.
I don't follow. Both would have insulation from the OS at large, and
both are equally subject to malicious files masquerading as legitimate
data. My malicious .jpeg could be just as dastardly as your malicious
spreadsheet, and my malicious photo editing app could wipe the device's
camera roll just like your malicious document viewer could wipe the
document folder. The only difference is the type of files we destroy.
I'd argue the camera roll us actually a bigger risk. Rarely do users
actually create original documents on their device. We receive them as
email attachments, sync themfrom our computers, download them from the web,
etc. Virtually any document stored on the device is probably recoverable
from somewhere. The biggest risk from deletion might be edits made to a
document before we send it off by email or sync it with iTunes.

Photos, however, are a different story. They are the most common form of
content creation on a mobile device. Between syncs or iCloud uploads,
photos and videos only exist on the device, and by their very nature are
difficult or impossible to recapture. They are also completely at risk,
since any app can access them, edit them or delete them. You're at a far
bigger risk from a malicious app that surrepeticiously adds mustaches to
the people in your photos than anything you've imagined in this thread.
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
The current system, and the "send to" method of redundantly
copying files between apps' sandboxes file areas, is a little
tedious.
Yes, but certainly less insecure. ;-)
How, exactly, is it less secure to let apps share the same file than
sending copies of the exact same files between apps?
See above.
Post by Todd Allcock
And how would your hypothetical malware attack the system from within
a sandboxed app, even if that app could access a folder shared by
other sandboxed apps? Other, than perhaps erase the contents of that
folder intentionally or unintentionally? The device's system files
and data (contacts, calendar, etc.) would be no more accessible than
they are now.
No, but it would be much easier for some app to hand over another app
data which will make this behave maliciously.
Again, in the sandboxed app model, no one app has greater access to the
system than another, so that doesn't really answer my question: what is
the malicious data created by app A going to get app B to do that app A
couldn't do itself directly?
Post by Michael Eyd
Post by Todd Allcock
(Which, AFAIK, are already accessible via "legal" APIs and therefore
already at risk from malicious apps that could sneak by the approval
process.)
Access via an API can be much better controlled (e.g. by filtering the
data for formal correctness, ...).
Right, so the buck already stopped there. app B has no access to
different APIs than app A already has. If I wanted to shoot you, it's
far easier for me to just shoot you myself than to disguise my gun as
your toaster and hope you'll do yourself in tomorrow at breakfast.
There's nothing your app can trick another app to do that your app can't
do itself.
Post by Michael Eyd
Post by Todd Allcock
The current file management in iOS is broken- it's ridiculous that
users have to check umpteen different apps to figure out which one
has the particular file they're looking for.
You don't work in software development, do you? The file management is
by no means (as far as I can tell from the outside) broken, it is
strictly following its design. You might not like this design, and it
certainly has its drawbacks, but still I don't see any reason whatsoever
to call this design (or the implementation) 'broken'.
Broken from a user experience standpoint. eBooks can live in a myriad of
different apps, and there's no central directory to choose from. In a
shared folder model, I could tap on Huckleberry Finn and key the device
figure out if it was an iBook, Kindle book, Nook book, or a Guttenburg
book I loaded into Stanza.
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Like always, there're pros and cons for each design decision...
I'm not seeing any cons to a shared folder that apps could opt-in to
using. And non-specific "security" concerns aren't particularly
convincing.
I've tried to be more specific above. If you find these reasons more
convincing - fine. :-) If not, fine with me just as well, I'm not
Apple's evangelist.
Understood.
Post by Michael Eyd
Unless you bring new (and convincing) arguments, I'd suggest to end this
discussion here - neither of us will be able to convince the other, I feel.
Fair enough. One of us either has too much faith or too little faith in
the sandboxing model employed in iOS, and I expect, as the saying goes,
the truth is somewhere in-between. ;)


Take care!
Michael Eyd
2011-10-26 12:10:29 UTC
Permalink
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
I agree that a completely open file system would be silly, but a
shared document space all third party apps could read/write to
would make sense, along with an ability to specify a default app
to open a particular file type. (E.g. ePub books open in iBooks
by default, etc.)
Which would in turn open again the chance for app A to supply app
B with data, that is de facto malware (or allows malware to take
over the system). All this without any chance for a user to stop
this.
How so? I'm not saying to break the sandbox, just to create a
shared folder that all apps can choose to use instead of, or in
addition to, their own protected folders.
a) App A can store a (suitably prepared) document to be opened by some
other app B, that will then make B behave in some unexpected and
unwanted way.
I think you're imagining a scenario that doesn't really apply here, by
applying a typical DOS/Windows malware situation. The rigged payload
only works when the app opening it has unfettered access to the system.
It's by no means only about attacking the system itself. How about a
banking app you're running and that one could (by means of manipulated
files) get to transfer money (or change a money transfer currently going
on)? Actually, such attacks were already shown for Android devices:
Malware could access the messages app to get a transaction number (a
one-time key needed at least here in Germany for authorizing online
transactions) and could then use this to create its own money transfer -
using (general) authentication from the currently running money transfer
and leaving this one to fail. This is a real scenario, proven (AFAIK) in
real software!
Post by Todd Allcock
No app in iOS has that. What "unwanted" behavior could you induce in app
B that represents a security risk? Maybe you could get it to crash, but
again, like app A, app B is also sandboxed.
Perhaps it's the data of app B itself that's of interest to me/the attacker?
Post by Todd Allcock
Post by Michael Eyd
b) App A could manipulate already present files in this shared folder,
i.e. files which it was never expected to manipulate. It could alter its
content (like the very first viruses under DOS did), it could altogether
replace the file, it could even delete the whole content of this
directory.
Fair enough, I already mentioned that risk, although I feel Apple's
vetting process would be sufficient to prevent this. in either case,
it's a risk/reward thing.
Like with each and every malware. And if I just look in my inbox, all
this spam seems to bring enough reward to make the efforts worthwhile.
Post by Todd Allcock
I always find it humorous that we attach a different set of
safety/security expectations to mobile computers when they reach a
certain size. No one would see this file handling advantageous (or at
least worth the usability tradeoff) on their desktop or laptop, but
suddenly it's mission-critical on a tablet or phone?
a) 'Normal' computers have a different usage concept
b) 'Normal' computers have a different historical background, which the
OS producers can hardly ignore. It was tried several times, but hardly
ever accepted by the users.
Post by Todd Allcock
Apparently a shared
documents folder is de rigeur on my desktop, which contains thousands of
documents, but an unacceptable risk on my mobile which contains a few
dozen.
Well, on your desktop there's (hopefully) anti-virus software. Do you
have this (and do you want this) on your mobile just as well? Me not.
Post by Todd Allcock
iOS remind me of 1980's era computing, which was app-centric. If you
wanted to open a word processing document you opened your word processor,
then selected the desired document from the file handler in the app.
Crazy me, I thought the file-based handling the GUI introduced was
supposed to be an improvement! ;)
Sorry, but you're wrong here! The file-based handling was already
replaced a long time ago by a document-centric paradigm - though no
(major) OS is really implementing it. MS had it (according to rumors) on
its list for Vista, but pulled back...
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
How would this be any different from a security standpoint than the
current awkward "send to" technique, where my Dropbox app can send a
file to my PDF reader by making an unnecessary duplicate for the
reader to place in its own file space?
In this case it's still the user who needs to push a button - though I
agree that this is only a very limited security barrier.
So then the issue becomes if this awkward layer is only a "limited
barrier", is the usability trade off worth it?
Apple seems to have decided in favor... :-)
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
Same PDF, same potential "trojan horse" malware; the only difference
is that with a shared folder, the user could willingly open the file
in "app B" without the cumbersome need to open "app A" and send it
first. Apps would still be vetted by Apple like they are currently,
how does your hypothetical "malicious app A" get on the device in the
first place?
a) There are other sources than the official Apple AppStore (at least
for jailbroken devices).
True, but those devices already have eschewed any security the sandbox
file system offers since they have no longer have such limitations.
Post by Michael Eyd
b) Some sufficiently advanced programming tricks might do the trick as
well... ;-)
Perhaps, but again, if we're relying on the sandboxed apps to be the
final protection of the device, then the payload that dastardly app A set
up for app B should only really affect app B. (And pragmatically, why
bother? Both app A and app B are subject to the same limitations imposed
by sandboxing and available APIs. Why rig a file to get app B to do
something nasty when app A could just do it itself? App B has no magical
abilities to wreak havoc that app A doesn't have. Your hypothetical
strikes me as a little Rube Goldberg-esque. Not impossible, but rarely
worth the effort! ;)
See above, app B might have information (data) a user would not give app
A, but which app A would like to (covertly) use... ;-)
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Security was (as much as I can tell from looking at the result) one
of the very basic design principles when starting the development
of iOS, even user experience (otherwise probably the most important
design driver) had to step back against security, I feel.
I disagree. I think the "app store" was a lucky accident, and the
"web app" model was the original intent and that only changed when
devs balked at the limitations of web apps, along with the looming
threat of more robust native apps on other platforms. The original
security model was simple: secure Safari, and make it the only access
for applications.
Which is by no means contradicting my statement.
Not directly, just that the security model in my theory took a back seat
to expediency. Sandboxing was easier than securing the OS to a Mac OS
level. The lack of a shared document folder wasn't part of a master
plan, there was just no need for one on a device that didn't have apps,
and therefore no documents, in the first place.
Well, as long as we don't get access to resources who were involved in
this design phase, we'll never know for sure... ;-)
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
To launch a third-party apps ecosystem quickly, Apple had two
choices: one, they could use a sandbox/VM model and throw a minimal
set of APIs together quickly, or two, allowing Palm OS/Windows
Mobile-style unfettered access to the innards of the device by
opening it up to unmanaged code, and let devs use the same tools
Apple used internally to build the native apps.
For a variety of security, stability, revenue-generation, and user
experience reasons, sandboxing was an obvious choice, but I still
don't see any real downside in letting devs opt to use a shared
documents folder.
I do. Now, where does this lead us? ;-)
We agree to disagree, I guess.
I agree. :-)
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
They already have one now: the camera roll, but it's limited,
obviously, to pictures. Why not one dedicated to documents? How is
that less secure than the shared camera roll (which, IIRC was
surreptitiously used to share data between apps by the same developer
until Apple discovered the practice and kiboshed it.)
I agree that the shared camera roll is a step back from the 'security
first' principle, but that does not mean that Apple needs to take the
next (and even bigger) step of a general shared 'Documents' folder just
as well. For the camera roll one (i.e. Apple) has much better ways to
control the content than in a general 'Documents' folder.
I don't follow. Both would have insulation from the OS at large, and
both are equally subject to malicious files masquerading as legitimate
data. My malicious .jpeg could be just as dastardly as your malicious
spreadsheet, and my malicious photo editing app could wipe the device's
camera roll just like your malicious document viewer could wipe the
document folder. The only difference is the type of files we destroy.
I'd argue the camera roll us actually a bigger risk. Rarely do users
actually create original documents on their device. We receive them as
email attachments, sync themfrom our computers, download them from the web,
etc. Virtually any document stored on the device is probably recoverable
from somewhere. The biggest risk from deletion might be edits made to a
document before we send it off by email or sync it with iTunes.
Which in its own right might already be 'dangerous' enough. But actually
I disagree with you that no content is being created on mobile devices.
You might not do so, I hardly do so myself, but I know of others who do.
Take e.g. all those people who use their mobile device to access company
software systems (e.g. to post working times, create and approve/reject
workflows), ... All this could be targets for attackers.
Post by Todd Allcock
Photos, however, are a different story. They are the most common form of
content creation on a mobile device. Between syncs or iCloud uploads,
photos and videos only exist on the device, and by their very nature are
difficult or impossible to recapture. They are also completely at risk,
since any app can access them, edit them or delete them. You're at a far
bigger risk from a malicious app that surrepeticiously adds mustaches to
the people in your photos than anything you've imagined in this thread.
Oh, what about my imagination in this post? ;-)
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
The current system, and the "send to" method of redundantly
copying files between apps' sandboxes file areas, is a little
tedious.
Yes, but certainly less insecure. ;-)
How, exactly, is it less secure to let apps share the same file than
sending copies of the exact same files between apps?
See above.
Post by Todd Allcock
And how would your hypothetical malware attack the system from within
a sandboxed app, even if that app could access a folder shared by
other sandboxed apps? Other, than perhaps erase the contents of that
folder intentionally or unintentionally? The device's system files
and data (contacts, calendar, etc.) would be no more accessible than
they are now.
No, but it would be much easier for some app to hand over another app
data which will make this behave maliciously.
Again, in the sandboxed app model, no one app has greater access to the
system than another, so that doesn't really answer my question: what is
the malicious data created by app A going to get app B to do that app A
couldn't do itself directly?
See above. In short: A lot.
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
(Which, AFAIK, are already accessible via "legal" APIs and therefore
already at risk from malicious apps that could sneak by the approval
process.)
Access via an API can be much better controlled (e.g. by filtering the
data for formal correctness, ...).
Right, so the buck already stopped there. app B has no access to
different APIs than app A already has. If I wanted to shoot you, it's
far easier for me to just shoot you myself than to disguise my gun as
your toaster and hope you'll do yourself in tomorrow at breakfast.
There's nothing your app can trick another app to do that your app can't
do itself.
What about a possibility for app A to make app B (the homebanking app)
change the target of the next outgoing money transfer your (secret)
account, while at the same time increasing the amount to be transfered?
Post by Todd Allcock
Post by Michael Eyd
Post by Todd Allcock
The current file management in iOS is broken- it's ridiculous that
users have to check umpteen different apps to figure out which one
has the particular file they're looking for.
You don't work in software development, do you? The file management is
by no means (as far as I can tell from the outside) broken, it is
strictly following its design. You might not like this design, and it
certainly has its drawbacks, but still I don't see any reason whatsoever
to call this design (or the implementation) 'broken'.
Broken from a user experience standpoint. eBooks can live in a myriad of
different apps, and there's no central directory to choose from. In a
shared folder model, I could tap on Huckleberry Finn and key the device
figure out if it was an iBook, Kindle book, Nook book, or a Guttenburg
book I loaded into Stanza.
Post by Michael Eyd
Post by Todd Allcock
Post by Michael Eyd
Like always, there're pros and cons for each design decision...
I'm not seeing any cons to a shared folder that apps could opt-in to
using. And non-specific "security" concerns aren't particularly
convincing.
I've tried to be more specific above. If you find these reasons more
convincing - fine. :-) If not, fine with me just as well, I'm not
Apple's evangelist.
Understood.
Post by Michael Eyd
Unless you bring new (and convincing) arguments, I'd suggest to end this
discussion here - neither of us will be able to convince the other, I
feel.
Fair enough. One of us either has too much faith or too little faith in
the sandboxing model employed in iOS, and I expect, as the saying goes,
the truth is somewhere in-between. ;)
Take care!
Same to you! :-)

Best regards,

Michael
Peter
2011-10-26 14:09:42 UTC
Permalink
There is a more basic thing involved here.

The Ipad processor does not provide hardware memory address range
protection.

That means that any app can potentially access all the data on the
machine.

IOW, if an attacker can execute code of their choice, there is NO
security. Same under windoze, OSX, etc. Running a PC app under
non-admin privileges hardly helps because there are various ways in
which a rogue process can elevate itself to admin privileges.

So restricting user-visible functionality, as Apple have done, is
largely a marketing exercise.

The fact that this is true is evident from the constant stream of
jailbreaks, which all involve executing code of the jailbreaker's
choice, usually by opening a media file which has some malformed data
fields that result in the execution of *data* (probably placed on the
local stack inside some function) as *code*. All the time people write
in high level languages which hide the details of buffer management,
the vulnerability to this form of attack is not going to go away.

One day somebody is going to develop an attack for Iphones and Ipads,
and it is going to hit the user community very very hard, because they
all think they are protected via their membership of the Church of
Jobs :)

If such an attack is done via an app sneaked into the Apple shop, it
will obviously get pulled as soon as it is found out, so nobody is
going to do this unless the reward is really big - like a few million
online banking login details, collected silently over a very long
period of time. Nobody is going to bother writing some merely
irritating virus because Apple will block it pretty quick.
Jolly Roger
2011-10-26 20:19:08 UTC
Permalink
Post by Peter
One day somebody is going to develop an attack for Iphones and Ipads,
and it is going to hit the user community very very hard, because they
all think they are protected via their membership of the Church of
Jobs :)
They've been saying that exact same thing about Mac OS X since it was
introduced in 1999, twelve years ago. iOS is based on Mac OS X - they
share much of the same code base. Good luck with your predictions.
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR
Your Name
2011-10-27 05:38:11 UTC
Permalink
Post by Jolly Roger
Post by Peter
One day somebody is going to develop an attack for Iphones and Ipads,
and it is going to hit the user community very very hard, because they
all think they are protected via their membership of the Church of
Jobs :)
They've been saying that exact same thing about Mac OS X since it was
introduced in 1999, twelve years ago. iOS is based on Mac OS X - they
share much of the same code base. Good luck with your predictions.
Not only that, but iOS apps are approved by Apple before the public even
see them (unless you jailbreak the device), so there's even less chance of
malware getting through than there is for Mac OS X.
Todd Allcock
2011-10-26 16:53:04 UTC
Permalink
Note: I snipped some passages for brevity and readability; if I clipped
anything relevent to the points below, it was unintentional and I
apologize in advance.
Post by Michael Eyd
Post by Todd Allcock
I think you're imagining a scenario that doesn't really apply here, by
applying a typical DOS/Windows malware situation. The rigged payload
only works when the app opening it has unfettered access to the system.
It's by no means only about attacking the system itself. How about a
banking app you're running and that one could (by means of manipulated
files) get to transfer money (or change a money transfer currently
going on)?
To be fair, what documents would I be opening on a banking app? Every
banking app I've ever used interacts exclusively with the bank's website,
and perhaps the device camera to deposit checks via image capture.

The app can't fall prey to malformed data files if it doesn't open any.
Post by Michael Eyd
Actually, such attacks were already shown for Android
devices: Malware could access the messages app to get a transaction
number (a one-time key needed at least here in Germany for authorizing
online transactions) and could then use this to create its own money
transfer - using (general) authentication from the currently running
money transfer and leaving this one to fail. This is a real scenario,
proven (AFAIK) in real software!
Yes, but that's entirely different- in this case the malware worked
entirely via the messaging app, probably through legitimate APIs, and did
the work itself, not by exploiting security holes in another app. A
similar app could also do this on the iPhone if you could get it in the
app store and trick users into
running it.
Post by Michael Eyd
Post by Todd Allcock
No app in iOS has that. What "unwanted" behavior could you induce in app
B that represents a security risk? Maybe you could get it to crash, but
again, like app A, app B is also sandboxed.
Perhaps it's the data of app B itself that's of interest to me/the attacker?
Perhaps, but your examples are seemingly pretty farfetched. I've already
said that my proposal was a shared document folder *in addition to* the
sandboxed folders, that app devs could use *if they wished*. An app that
used proprietary file formats or secure data would have no reason to use
a shared data store. Apps that view/edit common document formats (Office
files, PDFs, eBooks, etc.) and have a reason to share files with other
apps (Dropbox sync, email, browser upload/download) would be the user of
a shared folder. "Independent" apps that only interact with the user and
a website (which is probably 90% of non-game mobile apps!) don't need to
share files with any other apps.
Post by Michael Eyd
Post by Todd Allcock
iOS remind me of 1980's era computing, which was app-centric. If you
wanted to open a word processing document you opened your word
processor, then selected the desired document from the file handler
in the app. Crazy me, I thought the file-based handling the GUI
introduced was supposed to be an improvement! ;)
Sorry, but you're wrong here! The file-based handling was already
replaced a long time ago by a document-centric paradigm - though no
(major) OS is really implementing it. MS had it (according to rumors)
on its list for Vista, but pulled back...
Ok, so instead of being one paradigm behind, iOS is two paradigms behind!
;)
Post by Michael Eyd
Post by Todd Allcock
Rarely do users
actually create original documents on their device. We receive them as
email attachments, sync them from our computers, download them from
the web,
Post by Michael Eyd
Post by Todd Allcock
etc. Virtually any document stored on the device is probably recoverable
from somewhere. The biggest risk from deletion might be edits made to a
document before we send it off by email or sync it with iTunes.
Which in its own right might already be 'dangerous' enough. But
actually I disagree with you that no content is being created on mobile
devices. You might not do so, I hardly do so myself, but I know of
others who do.
I said "rarely", not "none." I actually do a fair but of creation on my
device, which I sync to my PC via Dropbox.
Post by Michael Eyd
Take e.g. all those people who use their mobile device
to access company software systems (e.g. to post working times, create
and approve/reject workflows), ... All this could be targets for
attackers.
Seems unlikely, at least in your example, because again, like with the
banking apps, they are interacting with the company software system, and
their device is essentially acting as a browser/terminal.
Post by Michael Eyd
Post by Todd Allcock
Photos, however, are a different story. They are the most common
form of content creation on a mobile device. Between syncs or iCloud
uploads, photos and videos only exist on the device, and by their
very nature are difficult or impossible to recapture. They are also
completely at risk, since any app can access them, edit them or
delete them. You're at a far bigger risk from a malicious app that
surrepeticiously adds mustaches to the people in your photos than
anything you've imagined in this thread.
Oh, what about my imagination in this post? ;-)
It's excellent, but I think you're imposing "generic" security concerns
on a particular situation. None if the doomsday scenarios you describe
seem to be easily facilitated by the shared document folder I'm describing.
Are they possible? Perhaps, but the risk seems low enough to be
infinitesimal. The irony of security on mobile devices is that the
entire concept of device security is a diminishing rate of return. The
greatest danger to your data is physical: that you will lose the device
or have it stolen. That's the 99% security risk. We're really just
splitting the haus of the other 1%! ;)
Post by Michael Eyd
Post by Todd Allcock
Right, so the buck already stopped there. app B has no access to
different APIs than app A already has. If I wanted to shoot you, it's
far easier for me to just shoot you myself than to disguise my gun as
your toaster and hope you'll do yourself in tomorrow at breakfast.
There's nothing your app can trick another app to do that your app can't
do itself.
What about a possibility for app A to make app B (the homebanking app)
change the target of the next outgoing money transfer your (secret)
account, while at the same time increasing the amount to be transfered?
What possible file is my banking app going to open to be corrupted this
way? If you mean some config file, that wouldn't be in the shared folder
anyway, unless the dev was incompetent. Again, banking apps are really
just wrappers for bank websites.

I'm happy to debate hypotheticals, but some of these seem implausible.
Yes, other OSes have had malware attacks, but I'm not aware of any that
have exploited existing 3rd-party apps via malformed payloadd. Just the
effort to reverse engineer a particular app to design the payload seems a
herculean effort, vs. the far easier methods of social engineering we see
today on PCs. Hacking people is now easier than hacking systems.

Thanks, though, the discussion has been fascinating.
Wes Groleau
2011-10-26 23:29:36 UTC
Permalink
Post by Michael Eyd
Take e.g. all those people who use their mobile device to access company
software systems (e.g. to post working times, create and approve/reject
workflows), ... All this could be targets for attackers.
I am one of those people. And that is not creating content on the
device. Everything that changes is on the company servers. The only
thing on my iPhone is the IMAP or Web access to work with it--none of
which has been requested to be available to other apps.
--
Wes Groleau

There are two types of people in the world …
http://Ideas.Lang-Learn.us/barrett?itemid=1157
JF Mezei
2011-10-24 17:12:36 UTC
Permalink
Post by Michael Eyd
Great! Let's open up a standard file system like e.g. under DOS/Windows,
where every application can actually write everywhere (at least pre-Win
Vista).
Nobody is advocating that at all.

There are ways to create a rooted file system whyere you only see a
directory tree and cannot see/touch/access the devices's complete file
system.
Bert
2011-10-24 17:23:21 UTC
Permalink
Post by Michael Eyd
Great! Let's open up a standard file system like e.g. under
DOS/Windows, where every application can actually write everywhere (at
least pre-Win Vista).
Why would anybody want to do that?
--
***@iphouse.com St. Paul, MN
Your Name
2011-10-24 20:29:04 UTC
Permalink
Post by Bert
Post by Michael Eyd
Great! Let's open up a standard file system like e.g. under
DOS/Windows, where every application can actually write everywhere (at
least pre-Win Vista).
Why would anybody want to do that?
So they can then charge you even more for the anti-malware software, the
clean up services, etc. ;-)
Michael Eyd
2011-10-25 07:12:01 UTC
Permalink
Post by Bert
Post by Michael Eyd
Great! Let's open up a standard file system like e.g. under
DOS/Windows, where every application can actually write everywhere (at
least pre-Win Vista).
Why would anybody want to do that?
I don't know, ask Todd, this would have been a (possible) consequence of
his request.. And I'm definitively not in favor of that idea, just in
case you misunderstood my intention above...

Best regards,

Michael
Todd Allcock
2011-10-25 16:49:12 UTC
Permalink
Post by Michael Eyd
Post by Bert
Post by Michael Eyd
Great! Let's open up a standard file system like e.g. under
DOS/Windows, where every application can actually write everywhere (at
least pre-Win Vista).
Why would anybody want to do that?
I don't know, ask Todd, this would have been a (possible) consequence
of his request.. And I'm definitively not in favor of that idea, just
in case you misunderstood my intention above...
That's not what Todd is in favor of! Todd would prefer a shared document
folder all apps could read/write to in order too avoid the kludgey "send
to" function, not carte blanche access to the device's file system.

Todd needs to stop referring to himself in third-person as well... ;)
Alan Browne
2011-10-22 15:40:45 UTC
Permalink
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Aviation safety is not based on hoary advice.
--
gmail originated posts filtered due to spam.
Your Name
2011-10-22 22:13:21 UTC
Permalink
Post by Alan Browne
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Aviation safety is not based on hoary advice.
Just hoary science ... they don't even understand how bumblebees can fly. ;-)
Todd Allcock
2011-10-22 16:23:49 UTC
Permalink
Post by Davoud
Unless the FAA and NTSB have made some changes of which I am unaware,
"Flying" magazine is not an authorized issuer of NOTAMS or other
official alerts.
Furthermore, you hyped this non-news, non-safety-related item by
declaring it to be a "bombshell." Tempest in a tea cup.
To a point. If your usage scenario for your iPad only involves keeping
up with the latest episode of Modern Family or reading your Kindle library.


This will be fixed, but it's a potential problem for any "professional"
apps if the device is often used without connectivity (losing the ability
to reacquire lost documents.) It's certainly a non-issue if you have
ubiquitous connectivity.
Post by Davoud
Don't fill your iPad (or any other data storage device) to the point
where there is little or no free space. There! Another major flying
safety hazard eliminated!
Blame the user! Of course, everyone should willingly leave storage space
they paid for unused just in case the OS wants to randomly delete files.
Here's a crazy idea-instead, why doesn't the OS stop downloading new
stuff and tell the user the device is full? (Oh that's right- it'd
require one of those "Windows-like" dialog boxes Apple hates so much,
because it requires the user to actually make a choice, ruining the
illusion the device is intelligent enough to do it for them.)

Here's a question: can you define "little or no space"? How much
headroom does a user need to protect their downloaded docs? Is a few
hundred MB enough? A GB? Where's the Apple tech bulletin with the
"official" amount? And how does one determine this in the field without
that helpful colored graph in iTunes on their computer?
Post by Davoud
There is one other recommended step, and that is to identify those
pilots who were operating with iPads with no additional storage space
and who were nonetheless downloading additional apps or other data
in-flight. They can keep their iPads, but their pilot's licenses need
to be permanently suspended, as we just can't afford to have idiots
flying airplanes.
That's certainly one option. Because anyone who trusts their computing
device to actually store their files *after* an OS upgradethe same way it
did *before* the upgrade must be some kind of idiot. I'm no computer
genius, but I don't recall any device I've ever owned using the FIFO
method to deal with full storage except my DVR, and even it lets me
protect files.

Again, Apple will fix this. This is more iCloud teething troubles (the
issue stems from Apple's guidelines to store in-app downloaded content in
cache folders to prevent upload to iCloud. Unfortunately those cache
folders are cleared in low-storage garbage collections.) Apple will
likely create a new class of storage folder in the next .dot update that
doesn't sync to iCloud, and doesn't get cleared like the cache does.
This will require apps to be updated to use the new folder-type but the
problem will go away.

I guess Apple was right to hide file management from end-users. It's
apparently so complicated even the device can't manage it properly! ;)
Jumbo Jack
2011-10-22 16:44:34 UTC
Permalink
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
Is the iPad approved for aviation use by the aviation authority?
Alan Browne
2011-10-22 17:55:18 UTC
Permalink
Post by Jumbo Jack
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
Is the iPad approved for aviation use by the aviation authority?
Yes. Basically the FAA delegates approval to the airline training,
engineering and aircrew certification departments. The FAA monitor,
provide input but likely only object if they see a major discrepancy.

How pilots "administer" flight (procedure, technique) is the
responsibility of the airline, not the FAA. FAA is responsible for
standards, licensing, regulations and so on. Operations and training is
the resp. of the airline. As long as the airline meets the standards,
the FAA is a monitor, not an actor.

Because the iPads are not integrated into the aircraft, they face the
very lightest of requirements wrt certification (basically none).

I bet most aircraft will be carrying at least one paper copy of the
charts, procedures, checklists, manuals and so on for quite a while yet.
--
gmail originated posts filtered due to spam.
n***@nowhere.com
2011-10-22 18:22:16 UTC
Permalink
Post by Alan Browne
Post by Jumbo Jack
Is the iPad approved for aviation use by the aviation authority?
Yes. Basically the FAA delegates approval to the airline training,
engineering and aircrew certification departments. The FAA monitor,
provide input but likely only object if they see a major discrepancy.
How pilots "administer" flight (procedure, technique) is the
responsibility of the airline, not the FAA. FAA is responsible for
standards, licensing, regulations and so on. Operations and training is
the resp. of the airline. As long as the airline meets the standards,
the FAA is a monitor, not an actor.
Because the iPads are not integrated into the aircraft, they face the
very lightest of requirements wrt certification (basically none).
I bet most aircraft will be carrying at least one paper copy of the
I am a pilot (FAA and JAA Commercial/Instrument) and I suspect that
the recent flurry of announcements from airlines is really just
storing *aircraft documents/manuals* on an Ipad.

They are not likely to be storing the approach plates for the flight,
and the briefing pack, on an Ipad, because if the Ipad packed up, you
would be stuffed.

The real saving in weight of paper (some huge figures have been quoted
in the press) is going to come from not carrying the big manuals. The
pack for the flight is very small.

This new Ipad problem is very serious because it means you have to
have a way of verifying database integrity, which is not going to be
possible for any ad hoc data which you just transferred to it (PDFs
etc). So you can never be sure that something important has not been
lost.

Apple have been incredibly stupid in this case.
Alan Browne
2011-10-22 18:30:49 UTC
Permalink
Post by n***@nowhere.com
Post by Alan Browne
Post by Jumbo Jack
Is the iPad approved for aviation use by the aviation authority?
Yes. Basically the FAA delegates approval to the airline training,
engineering and aircrew certification departments. The FAA monitor,
provide input but likely only object if they see a major discrepancy.
How pilots "administer" flight (procedure, technique) is the
responsibility of the airline, not the FAA. FAA is responsible for
standards, licensing, regulations and so on. Operations and training is
the resp. of the airline. As long as the airline meets the standards,
the FAA is a monitor, not an actor.
Because the iPads are not integrated into the aircraft, they face the
very lightest of requirements wrt certification (basically none).
I bet most aircraft will be carrying at least one paper copy of the
I am a pilot (FAA and JAA Commercial/Instrument) and I suspect that
Me too. Not as well certified. Instructor, most of my instrument, not
multi. Haven't flown PIC in 10 years+ though.
Post by n***@nowhere.com
the recent flurry of announcements from airlines is really just
storing *aircraft documents/manuals* on an Ipad.
They have enroute, plates, SIDS/STARS, etc. ad nauseum. And use them.
Source is Jepp, etc. Really, if both iPads went, a single set of paper
plates would get you on the ground. Absent a complete comm failure you
could even get your vectors and freqs from terminal to start an ILS
approach. (When's the last time anyone completed an IFR flight to
minimums with a complete comms failure? The 70's maybe?).
Post by n***@nowhere.com
They are not likely to be storing the approach plates for the flight,
and the briefing pack, on an Ipad, because if the Ipad packed up, you
would be stuffed.
Which is why they still have the bag and it's full.
Post by n***@nowhere.com
The real saving in weight of paper (some huge figures have been quoted
in the press) is going to come from not carrying the big manuals. The
pack for the flight is very small.
This new Ipad problem is very serious because it means you have to
have a way of verifying database integrity, which is not going to be
possible for any ad hoc data which you just transferred to it (PDFs
etc). So you can never be sure that something important has not been
lost.
Apple have been incredibly stupid in this case.
Has nothing to do with Apple (unless you mean the arbitrary file cuts -
which is stupid). The use of iPads in flight is airline/pilot driven.
--
gmail originated posts filtered due to spam.
Steve Hix
2011-10-22 21:20:58 UTC
Permalink
Post by n***@nowhere.com
Post by Alan Browne
Because the iPads are not integrated into the aircraft, they face the
very lightest of requirements wrt certification (basically none).
I bet most aircraft will be carrying at least one paper copy of the
I am a pilot (FAA and JAA Commercial/Instrument)
Me, too, if only FAA and PP-SEL currently.
Post by n***@nowhere.com
and I suspect that
the recent flurry of announcements from airlines is really just
storing *aircraft documents/manuals* on an Ipad.
Well, that too. But that's not all. United/Continental are the first to go for a
paperless flight deck, others are planning to do the same. For United, that
means issuing 11,000 iPads.
Post by n***@nowhere.com
They are not likely to be storing the approach plates for the flight,
According to United/Continental (and a couple of pilots I know at Southwest),
they are using iPads for approach plates and other erstwhile paper documentation.

They have other backups, and backups for the backups, of course.
Post by n***@nowhere.com
and the briefing pack, on an Ipad, because if the Ipad packed up, you
would be stuffed.
Which is why they don't carry just one. And they'll likely have at least one set
of paper charts in the usual bag in case all else fails.
n***@nowhere.com
2011-10-22 21:52:56 UTC
Permalink
Post by Steve Hix
And they'll likely have at least one set
of paper charts in the usual bag in case all else fails.
I can completely understand that (and I print off stuff I need for a
given flight, and use an Ipad for the unexpected stuff) but in that
case I wonder where the huge paper saving will come from. Jepps just
for Europe are something like 10-20kg of ring binders, and I guess it
will be at least as much for the USA, which has roughly as many
airports as the rest of the world put together. OK, an airline doesn't
have to carry plates for every small place, but it is still a lot of
stuff to carry and it has to be updated because there is no point in
carrying a paper backup if it isn't current.

I was very suprised that the airlines got operational approvals for
using an Ipad because it is hardly a bug-free product, and a bug is
likely to affect both pilots. Some of the bugs are obvious e.g.
Goodreader (which is what I use for Jepp PDFs) sometimes gets stuck on
a page and you cannot get back up the hierarchy by tapping the screen.
They seem to have fixed that particular one on the last update.

The certified EFB products are very different and much more stripped
down functionally.

What apps are United running?
Steve Hix
2011-10-23 05:49:58 UTC
Permalink
Post by n***@nowhere.com
Post by Steve Hix
And they'll likely have at least one set
of paper charts in the usual bag in case all else fails.
I can completely understand that (and I print off stuff I need for a
given flight, and use an Ipad for the unexpected stuff) but in that
case I wonder where the huge paper saving will come from.
One set of paper (if they even require it), rather than one for each flight
officer on board the flight.
Post by n***@nowhere.com
Jepps just
for Europe are something like 10-20kg of ring binders, and I guess it
will be at least as much for the USA, which has roughly as many
airports as the rest of the world put together. OK, an airline doesn't
have to carry plates for every small place, but it is still a lot of
stuff to carry and it has to be updated because there is no point in
carrying a paper backup if it isn't current.
I always thought the continuous updating was the worst part.
Post by n***@nowhere.com
I was very suprised that the airlines got operational approvals for
using an Ipad because it is hardly a bug-free product, and a bug is
likely to affect both pilots. Some of the bugs are obvious e.g.
Goodreader (which is what I use for Jepp PDFs) sometimes gets stuck on
a page and you cannot get back up the hierarchy by tapping the screen.
They seem to have fixed that particular one on the last update.
The certified EFB products are very different and much more stripped
down functionally.
What apps are United running?
So far I haven't been able to find out, but it may well be custom applications,
since they were supposed to prove to the FAA's satisfaction that iPad use would
be reliable and safe. Belt and suspenders must apply there somewhere.
n***@nowhere.com
2011-10-23 06:14:25 UTC
Permalink
Post by Steve Hix
I always thought the continuous updating was the worst part.
That is a horrible job. A friend of mine (an airline pilot) married a
girl in Ops whose whole day was spent updating the ring binders, and
that was for only about 100 pilots :)

The biggest savings must come not from reduced weight but from the job
savings on the Jepp binder stuffing :)
Steve Hix
2011-10-23 15:41:41 UTC
Permalink
Post by n***@nowhere.com
Post by Steve Hix
I always thought the continuous updating was the worst part.
That is a horrible job. A friend of mine (an airline pilot) married a
girl in Ops whose whole day was spent updating the ring binders, and
that was for only about 100 pilots :)
The biggest savings must come not from reduced weight but from the job
savings on the Jepp binder stuffing :)
I spent a couple decades writing technical manual at Sun Microsystems.

At the beginning, the operating system shipped with, literally, a nearly four
foot shelf of books; manuals in three-ring binders. With periodic updates for
users to collate and swap in. (We used to joke that big server customers should
get a free fork lift to manage documentation.)

By the time I left a couple years ago, documentation was all on line; we'd even
given up on shipping them on CDs, except as a special order item. You'd just
need to check periodically to make sure you had the latest updates.
JF Mezei
2011-10-22 18:25:58 UTC
Permalink
Post by Alan Browne
Because the iPads are not integrated into the aircraft, they face the
very lightest of requirements wrt certification (basically none).
They may not be "aircaft" equipment that are certified along with the
aircraft, but as they replace an FAA mandated flight bag (set of books
detailing aircraft ops, specs, maps of airport etc), the airline must
show to the FAA that its iPad version of the flightbook works , is
reliable , available/usable even in emergencies etc.

And because it was not tested by the aircraft manufacturer at the time
the aircraft was certificated, the onus is on the airline to make
necessary tests to show the FAA that the introduction of an iPad in the
cockpit does not interfere with any of the aircraft's electronics or
radio equipment.


Soe of the newer aircrafts such as the A380 newer 777s and the 787 have
embedded electronic flight bags. Those were tested as part of aircraft
certification.

It will be interesting to see if an airlines such as United choosed to
deploy iPads even on those aircraft (since pilots would be familiar with
the iPad already from having flown smaller/older aircraft) or whether
they will use the Boeing provided one.
Steve Hix
2011-10-22 21:22:35 UTC
Permalink
Post by JF Mezei
Soe of the newer aircrafts such as the A380 newer 777s and the 787 have
embedded electronic flight bags. Those were tested as part of aircraft
certification.
It will be interesting to see if an airlines such as United choosed to
deploy iPads even on those aircraft (since pilots would be familiar with
the iPad already from having flown smaller/older aircraft) or whether
they will use the Boeing provided one.
As they've announced that they'll be deploying 11,000 iPads fleet wide, it does
seem so.
Steve Hix
2011-10-22 21:09:23 UTC
Permalink
Post by Jumbo Jack
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-a
lert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
Is the iPad approved for aviation use by the aviation authority?
Yes. Currently, definitely for use by several major carriers, modulo a number of
possible backups, either electronic or paper. Individual use is also permitted
for non-commercial operations.
n***@nowhere.com
2011-10-22 21:45:53 UTC
Permalink
Post by Steve Hix
Individual use is also permitted
for non-commercial operations.
Non commercial ops were never regulated as to portable equipment,
anyway.
Steve Hix
2011-10-23 05:46:17 UTC
Permalink
Post by n***@nowhere.com
Post by Steve Hix
Individual use is also permitted
for non-commercial operations.
Non commercial ops were never regulated as to portable equipment,
anyway.
Sure, but non-pilots probably wouldn't know that.

I certainly wouldn't mind using an iPad for things like airport diagrams such as
the AOPA airport directory pages, enroute checklists and so on.
JF Mezei
2011-10-22 20:09:51 UTC
Permalink
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I agree. I suspect airlines will NOT upgrade to IOS5, and will insist
that Apple give them a way to install 4.something on any new iPads they
receive.

While an airline can manage those ipads to prevent download of movies,
music etc, the fact remains that some glitch in the device might cause
some log file to grow to fill up space with the OS then deleting files.


Apple,s logic is probably related to "cloud" since it thinks those
deleted files could be accessed transparently via the cloud. The problem
is that pilots might be right in the clouds but not have access to
iCloud. And I suspect a lot of corporate uses for the iPad would be
similar.

Perhaps Apple as decided that the iCloud is to be the primary storage
device and that storage on IOS is meany to be more of a "cache".

I suspect Apple will have to quickly issue a patch which adds some
system preference to disable such deletion.
Steve Hix
2011-10-22 21:24:57 UTC
Permalink
Post by JF Mezei
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-a
lert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I agree. I suspect airlines will NOT upgrade to IOS5, and will insist
that Apple give them a way to install 4.something on any new iPads they
receive.
Certainly they'll be slow to upgrade to iOS 5, which is just normal due
diligence for enterprise use of any software. When they do, though, there's no
reason that they should configure them for iCloud use, and they'll likely not
permit it.

They're not personal gadgets after all, they're part of the company's operating
equipment.
Doug Anderson
2011-10-22 22:44:33 UTC
Permalink
Post by Steve Hix
Post by JF Mezei
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-a
lert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I agree. I suspect airlines will NOT upgrade to IOS5, and will insist
that Apple give them a way to install 4.something on any new iPads they
receive.
Certainly they'll be slow to upgrade to iOS 5, which is just normal due
diligence for enterprise use of any software. When they do, though, there's no
reason that they should configure them for iCloud use, and they'll likely not
permit it.
Yes, and they'll problem have IT staff do the upgrades with a protocol
for being certain that the device is carrying the needed data after
the update.

At least that's what I would expect would happen in such an
environment.
Steve Hix
2011-10-23 05:53:15 UTC
Permalink
Post by Doug Anderson
Post by Steve Hix
Post by JF Mezei
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safe
ty-a
lert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I agree. I suspect airlines will NOT upgrade to IOS5, and will insist
that Apple give them a way to install 4.something on any new iPads they
receive.
Certainly they'll be slow to upgrade to iOS 5, which is just normal due
diligence for enterprise use of any software. When they do, though, there's no
reason that they should configure them for iCloud use, and they'll likely not
permit it.
Yes, and they'll problem have IT staff do the upgrades with a protocol
for being certain that the device is carrying the needed data after
the update.
IIRC, Apple has provided a means for corporations to set up their own private
app store function, including updates. This would be a likely customer for that
service.
Post by Doug Anderson
At least that's what I would expect would happen in such an
environment.
The last time I worked on that side of the commercial stuff, for the company
that used to provide ab initio flight training for JAL, it sounds about right,
at least for a minimum requirement.
Michael Eyd
2011-11-03 12:28:11 UTC
Permalink
Post by Peter
http://www.flyingmag.com/avionics-gear/portablehandhelds/ipad-pilot-safety-alert?cmpid=enews102011
This is a bombshell for anybody trying to use the Ipad or Iphone for
something "serious".
I wonder if documents placed in Goodreader's Documents directory) PDFs
mostly) are immune from this undocumented deletion.
More here
http://forums.flyer.co.uk/viewtopic.php?f=1&t=73183
Apple is working on iOS 5.0.1 (developers already have access to a
beta), that is said to contain some kind of solution to this issue.

<http://www.macrumors.com/2011/11/02/apple-posts-ios-5-0-1-beta-for-developers/>

So let's wait for the final release of 5.0.1... :-)

Best regards,

Michael

Loading...