Allow install to SD card

[mitchellsundt]

Migrated to getodk/collect#67 by spacetelescope/github-issues-import

Originally reported on Google Code with ID 569

It doesn't seem like a problem to allow the application to be installed to a SD card,
please allow by adding installLocation to the manifest:

http://developer.android.com/guide/topics/manifest/manifest-element.html#install

Reported by mdekker78 on 2012-05-03 09:26:50

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Why would allowing this be helpful? We already store our data on the SD card.

Reported by wbrunette on 2012-05-08 06:47:34

• Labels added: Type-Enhancement, Collect
• Labels removed: Type-Defect

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

This sounds like a bad idea.  Installing it on the SD Card makes moving the SD cards
across phones in such a configuration more difficult, as the app will need to be reinstalled
(because of the phone-specific keys established when installing the app to the SD Card).
 Having the app stay on the phone enables moving the SD Cards freely among the phones.
 All data is on the SD card, so you gain nothing by doing this.

What use case are you trying to support?

Reported by mitchellsundt on 2012-05-08 16:08:54

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

The one thing that we should consider is moving the application preferences onto the
SD card so that you can configure one SD card, replicate it, then install them across
all phones, and all phones will then be similarly configured.  Perhaps this is what
you're seeking?

Reported by mitchellsundt on 2012-05-08 16:10:51

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

On devices with little internal memory like my own HTC Desire, it can be a problem to
install all applications to the internal memory. Everything that can be installed to
SD helps keeping this internal memory available to the things that really need it.

I figured if the sd card is required anyway to store responses, why not use it to free
some internal memory. Ofcourse one always has the choice to install to the preferred
location manually. I think default for auto is internal, but allow to move to external
and install to external when internal is full.

Reported by mdekker78 on 2012-05-09 07:31:42

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

My concern is security, we have made assumptions when thinking through are security
model that Collect is not on the SD card. We will have to think about it some more
so don't expect this change anytime soon.

In regards to your HTC desire the while the Storage has 512 MB flash with only 150
MB is user accessible (according to the web, could be wrong). However collect is 1
MB so this seems like having a program that takes up >1% of your storage is not really
the cause of the issue.

Since this is open source you can always create your own apk that installs anywhere.
I am not sure that is the best for everyone though because of security and logistical
concerns. We will need to discuss it with the rest of the core team. 

Reported by wbrunette on 2012-05-09 16:07:30

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Oops it takes up less than 1% of your memory, used the wrong character in previous comment:
'<1%' is correct.

Reported by wbrunette on 2012-05-09 16:08:32

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Collect is a little bigger for me (2.7mb), but just the size of collect is not the issue.
It is all other programs together.

I never heard of issues regarding security and sd install, but I am no android expert.
It is not really a big problem for me, but I figured it was just a switch that was
not added because at one point in development nobody thought about it. If you have
reasons not to do it, that is perfectly fine with me.

Reported by mdekker78 on 2012-05-10 08:37:49

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

There is a difference between the two memories. As stated here:
http://developer.android.com/guide/topics/data/data-storage.html

Internal Storage
    Store private data on the device memory.
External Storage
    Store public data on the shared external storage.

Collect 1.2 has some basic encryption in it to protect transmission and long term storage.
In the future we plan to improve that even more. Keeping Collect in the private data
area has advantages.

More Info
http://source.android.com/tech/security/index.html#filesystem-permissions

Reported by wbrunette on 2012-05-10 17:09:20

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Well the choice is all yours, I only think that security is not a valid reason. The
sensitive data is the data collected in the forms, and that is stored readable on the
sd card accessible via usb or to any other program with sd access. Internal memory
is private to the app, so when security really is the issue, I would say move all data
to internal storage. But ofcourse swapping sd cards to 'export' the data is no longer
possible then.

Reported by mdekker78 on 2012-05-10 22:07:05

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

As an FYI we are moving towards having it secure. Currently only the finalized versions
of the submissions/instances can be encrypted with 256-bit encryption so the data is
no longer readable on the SD card. Because of internal memory size constraints we can't
put all the data into internal memory.

How Collect will deal with intermediate state so it can still read and modify the data
before the submission is finalized is still being worked out so it's not secure yet
(you will notice we make that clear on the website). 

http://opendatakit.org/help/encrypted-forms/

You have to explicitly turn encrypting submissions on, but there will be a single code
base that offers security. We are working with security experts to determine the best
course of action as some projects really care about this.

We have no problems with people doing a custom build with that flag turned on, but
the default Collect install is targeted at a wide variety of users with many different
use cases. We try to accommodate everyone and it takes trade offs.

We will take this suggestion under advisement as we think through the final security
design with security experts. The security design is not complete yet, only a small
portion of things have been implemented and released. However, I want to point you
to the fact that if you enable encryption that a finalized version is not stored in
a readable format on the SD card. Also that there are many different use cases we are
trying to support. After we finalize a secure version we may decide an install on the
SD card is a good thing, but in the meantime the initial security design had the application
in a protected area taking advantage of Android security.

Reported by wbrunette on 2012-05-10 22:26:45

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Reading back I might seem a little agressive about adding the option, that was by no
means my intention. So I apologize for that.

I am very much interested in future changes, as we sometimes deal with sensitive information.
If you can point me to a general bug/feature id to track progress that would be very
welcome. Will also keep an eye on the opendatakit.org website. Thanks for the great
product!

Reported by mdekker78 on 2012-05-14 08:55:18

[mitchellsundt]

Migrated to opendatakit/collect#67 (comment) by spacetelescope/github-issues-import

Reported by wbrunette on 2012-06-08 19:28:18

• Labels added: Future