[Tfug] [offlist] Re: OT: Phones..... Argh!

[John Gruenenfelder]

On Fri, Mar 22, 2013 at 4:16 AM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi John,
>
> Remember, I don't use a cell phone so I have no idea what I am talking
> about...  <grin>

I resisted for a very long time until Android eventually came onto the
scene.  Since Palm had imploded their own company, I figured Android
would make a good replacement and would have a user base that was
actually growing.  Even now, though, my "phone" is used much more as a
portable computer I can fit in my pocket.  I'm actually on my sister's
account and she has tweaked what services my device has a number of
times since I use very few voice minutes and can count the number of
text messages I send each month on one hand.  Having access to the
wireless data network (3G on my device) is a nice bonus, but I connect
to WiFi whenever I can.

> I'm trying to sort out a realistic/practical way for users to control
> access to the data that my home automation system has available.
> It's a similar model to (my understanding of) smart phone apps...
> i.e., add/develop whatever apps you want and let them tie into the
> "system" however they need in order to do their jobs.
>
> In the HA system, everything resides in a database (sets of tables).
> So, every "fact" can be individually identified and located.  I.e.,
> the time that you wake up on Tuesday mornings (vs. Wednesday
> mornings); when you retire at night; how often you water your roses;
> what plants you have in the yard (and *where* they are located);
> etc.

(Quick note:  I'm mostly sure the below is correct, but I am still
rather new to Android development)

On Android, most all data is stored in a SQL database, normally
SQLite.  Each app has its own database and cannot access any data or
files belonging to another app.  System data and your personal data
can be accessed via the API, but not by default for most of it.  For
example, if your app needs *read* access to the user's contacts, write
access to the same, or network access, each of those has an associated
permission.  Unless your app's manifest indicates one or more of these
permissions are needed then the API won't give an app access to those
bits.

On the other hand, if your device is rooted, and you run a root-aware
app, it can do most anything it wants.  There is still one layer of
security, though, provided by the Superuser app.  When a root app
requests root access, the SU app will appear and request one-time or
permanent approval for the requesting app to have root access.

Overall, I think the Android permission/protection API is fairly nice
and far more complete and robust than the equivalent on iOS (though I
think Apple has made a number of changes to this semi-recently).  The
main thing I think it is missing is the ability to control/override
some permissions (not surprisingly, the way LBE Privacy Guard
allowed).  Currently, your choices are basically all or none.  You can
choose to install an app and give it access to whatever permissions it
requests, or you can choose to not install it.

If there was some middle ground, you could choose to install an app
and at the same time maybe uncheck some of of the listed permissions.
Of course, this would require apps to perform checks to see if they
really have access to the data they requested access to.  I suppose
Android doesn't support this because it would easily confuse users,
but it would be nice if it did.

> But, it's relatively easy to write an application (or, hide
> some code *in* an application) that *deduces* information
> based on *other* information that might be available to it.
> I.e., because the user thought the information was "harmless"
> (or, possibly "necessary" for the application to perform its
> task).
>
> For example, it is relatively easy for me to code something
> that determines how often you urinate, defecate, bathe, etc.!
> The system knows *where* you are so if you;re in the bathroom,
> you're *probably doing one of the above tasks.  So, an app
> that has access to your physical location already knows that
> much (even if you filter the reports that are given to the app
> so it never is told "he's in the bathroom"... the app can
> deduce this because you're position is reported as "unknown"
> or "blocked", etc.).
>
>...
>
> It's a silly example.  But, shows how easy it would be to
> make crude estimates as to what you are *likely* doing based
> on the flimsiest of data/observations.

Wow, this metaphor came from right field.  :)

> *And*, intentionally highlights some bit of information that
> you probably *wouldn't* want an app to be able to "report"
> about you!  ("Gee, this guy goes to the bathroom a lot!
> Maybe he's diabetic?  Reports from other households suggest
> the average male goes to the bathroom 5.8 times daily and
> this guy is going 8.3 times!!")
>
> While I can, theoretically, govern access to every individual datum
> (since every fact has an "address", of sorts, in the database
> tables), there's just no way I can imagine a casual user being
> able to rationally control *what* gets access to each bit of
> information!  I.e., your comment, above.
>
> Do I just give up and consider it an unmanageable task?  <frown>

It is certainly not an easy task, that's for sure.  Truth be told, you
could probably make do with something quite similar to the Android
data access/restrictions handled via its API.  In your case, you have
data stored in an actual database and if you handle it right you
shouldn't have too much difficulty who can even access the database to
begin with.  The easy way would be to use an actual database, like
MySQL, instead of something much simpler, like sqlite, but I'm sure
there are other ways to provide coarse access control to the DB.

Once you have DB access controlled, you can design your system such
that all code, or at least all 3rd party/user code, must access the
database via an API of your design.  At this point you can maybe add
permissions in the style of Android.  That is, a code module must
declare which permissions it requires so that it can access whatever
data in the database it needs to properly perform its tasks.  Like
Android, at install time the system should display all of these
permissions and then ask the user whether or not they really want to
continue with the install.

Of course, this doesn't mean much if the users are clueless as to the
purpose/meaning of these permissions.  Android makes an attempt to
address this problem by listing all of the requested permissions in
mostly plain English and if you tap on one it will present a slightly
longer explanation.  It's a good attempt at a solution, but I am still
curious as to how good a job it does when put up against users who a)
don't care, b) always click yes, or c) want the shiny new app X enough
to allow it permissions it shouldn't be asking for in the first place.

You can't win them all, right?

Anyway, it's not a bad attempt at a solution.  There are shortcomings,
to be sure, and it doesn't do anything to address a code module or
nefarious user from inferring data it does not have access to from
data it does have access to... but is there even a software solution
to this issue to be had?

> Others have (naively) suggested let the user *code* whatever
> sorts of rules he wants.  Yeah, sure.  I can just see Grandma
> writing a filter to protect particular bits of *her* data from
> prying apps!!  :-/
>
> As I have said, I don't *use* cell phones so deciding what to
> "protect" is a no-brainer, for me:  *nothing* is accessible!  :>
> I'm afraid I'm only going to make a society already rapidly
> losing its privacy even *more* "transparent"  :<

I used to have a simple cell "flip-phone" while I was attending UMass.
 My family insisted I take it with, but I kept it turned off and in my
book bag almost all the time.  Even if it had been on, though, there
really wasn't any concern about protecting "personal data" since there
really wasn't any on the device.  For actual phone service, I made do
with Asterisk running on my closet server which connected to a company
called Teliax (a recommendation I got here from TFUG).  I like this
because it was amazingly cheap.  It was $5/month to have service and
my own phone number, and then I paid per-minute for all calls, in and
out.  I don't believe I ever spent over $10 total in any given month.

Now, of course, with "smart" phones there is far more personal data on
the device which brings the need and desire to protect it.  I try to
make a good effort at protecting it myself, when I can.  This was the
big reason I liked the LBE Privacy Guard app so much since it allowed
me to disable many app permissions that *I* did not deem necessary.  I
used it to control stock apps, good apps, and apps I wouldn't have
used otherwise.  For stock (included in the ROM) apps and good apps,
even though I was reasonably confident that they were operating
properly and not doing anything bad, since I *had* the control I
figured I might as well exercise it.

For example, does app X *really* need access to my contacts or access
to the network?  Maybe, maybe not, but I can use LBE do disable it and
if it doesn't work or misbehaves I can always re-enable it.  LBE also
had a middle ground for many permissions where it would prompt you.
That way an app might require the permission to access your contacts,
but not until it actually did so would LBE ask you.

For apps I was less sure about, LBE was even more useful.  I could
then download an app which seemed like it might be useful, but which,
in my opinion, either requested too many permissions or had yet to
earn my trust.  Since I had the ability to disable some of these
seemingly "extra" permissions I felt the risk was well managed.  Some
of these apps came from the Google Play/market store, but most of the
questionable ones seemed to come from the Amazon app store.  It may
have just appeared that way to me and might not have been anything
real or supported by facts/stats.  The generally poor quality of the
comments on Amazon's apps didn't help, I'm sure.  Play requires that
you have at least installed an app before you can rate it or comment
on it, whereas the Amazon store allows (or used to, anyway) anybody to
comment on app.  For an app which receives a lot of attention, such as
the "Free App of the Day", this can make the S/N ratio go into free
fall.

That was then, though... I uninstalled LBE as a performance test and
it immediately caused the phone to behave/perform much better.  I
wasn't expecting this (for reasons detailed in another response).
And, LBE doesn't work with Android 4+, which I now have installed on
my phone.  So, either way, I won't be using LBE anymore and no longer
have many of those permission control abilities, which is unfortunate
since it offered a nice safety net and gave me, the user, more control
over the device and its programs.  I need to dig around on the Net
some more to see if there is a functional alternative to LBE for newer
versions of Android.  If there isn't, I'll just need to be more picky
about what I install, and I suppose that won't really be hard to do as
I can easily do without all of those apps which I found
"questionable".

Protecting your personal data is always a challenge, even more so
today with devices that store much more of that data.  I know that I,
and most people here on TFUG, can handle this task without trouble.
My biggest worry is that there are so many people out there who just
don't give a damn that giving away personal data will become the new
normal.  If that occurs, then it seems to follow that it will become
harder in the future on those of us who *do* wish to protect our
personal data since this will become an "extra" step that most people
will ignore and so it will receive less implementation and less
testing in tomorrow's applications, apps, and websites.

Here's to the future!  :)


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for Palm OS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max