

Android and Security - bond
http://googlemobile.blogspot.com/2012/02/android-and-security.html

======
casca
Google have decided that the app maker is best equipped to decide what access
the app should be allowed. This makes perfect sense if you assume that your
average user will not install the app if it requests too much privilege. The
reality is that most people don't check and install it anyway because they're
given a binary choice.

Would a better model be to allow the user to choose the allowed permissions?
In some cases this would cause an app to fail, but as someone who firewalls
outgoing IOS requests, this is unlikely.

However, it still becomes a user interface issue. Any security system that
requires the user to make knowledgeable security decisions in unfair and
usually just a way to offer plausible deniability.

------
Macha
I am a bit worried about the amount of false positives from these type of
scans over the years (see antivirus scans) , and google`s lack of support or
accountability in disputes. "We have found you to be guilty. We will not say
what of. Goodbye" type attitudes from Google have shown up in a number of blog
posts. I hope this system doesn't lead to more incorrect bans.

------
mindslight
If they want to improve security, they should switch from the current offer-
you-can't-refuse approach to a capability/interface system. An application
should always be able to successfully "list my contacts". Whether it gets the
complete list, an empty list, or a less-sensitive subset should be up to me
(and unknown to the app).

~~~
wmf
This would probably destroy many ad-supported apps, since users would just
choose to not allow them to access the network.

~~~
mindslight
So then Google doesn't have to make that an option on stock android (although
droidwall currently takes care of that quite nicely). The restrictive option
for internet access could be a low quota for people concerned with data usage.

The open source android distributions would hopefully go further and empower
their users with control over their devices.

~~~
Maxious
CyanogenMod lets you change permissions of apps:
<http://review.cyanogenmod.com/#change,4055>

They drew the line at letting you spoof unique IDs for privacy purposes though
<http://review.cyanogenmod.com/#change,5677>

~~~
mindslight
Except (AFAIK) the API calls _fail_ when a permission has been revoked. A non-
defensively coded application will most likely crash when it tries to use a
revoked permission. A developer has little motivation to support a user taking
app permissions into their own hands. What really needs to happen is for the
call to return a sensible value for what the application is allowed to access.
It would even be handy to return a subset of the contacts list, say if a user
is willing to take a risk of spamming friends but not professional contacts. A
user would set the base permission for all newly installed apps, and would
_increase_ an app's permission after they used it long enough to trust it. The
only thing the current system does is fake consent for misbehaving apps.

I am aware of that rejected patch, and I can only hope that the CM people will
overcome their fear in the future (or maybe a security-conscious friendly
fork).

------
chaostheory
I'm actually a little surprised that this wasn't in place from the start.

~~~
jsight
I believe that they have been running (and refining) this process since at
least early 2011. It is surprising that they didn't do it from earlier than
that, though.

~~~
shareme
not early 2011, was summer GSOC project 2011 though

------
keeperofdakeys
The only truly revocable permission for applications is internet access. Each
application runs as its own user (although some from the same publisher do use
the same user), and this can be combined with the linux kernel's firewall to
prevent internet connections to specific applications. To do this you need
root access, and an application like DroidWall. By default, DroidWall only
allows applications you select to have internet access. Since DroidWall is
using the kernel's firewall, it doesn't need to do anything in the background,
so doesn't impact battery life.

------
barista
This moment is akin to Microsoft creating a free antivirus (security
essentials or something) for Windows users. An acknowledgement that a real
problem exists. But good that google took a step before this was blown out of
proportions.

~~~
r00fus
Well, aside from the fact that a) Antivirus was already a thriving market and
b) No one but Google could create "bouncer" for Google's Android Market.

It is a further admission that Google needs to apply some more order and
curation to their marketplace.

------
Steko
"The service has been looking for malicious apps in Market for a while now,
and between the first and second halves of 2011, we saw a 40% decrease in the
number of potentially-malicious downloads from Android Market."

I'm not sure how to read this. They detect an App is malware and leave it in
the market? Or they didn't detect it until after it had been downloaded many
times? The former is unfathomable while the latter indicates a gaping hole in
the system.

"This drop occurred at the same time that companies who market and sell anti-
malware and security software have been reporting that malicious applications
are on the rise."

Don't believe all the charts showing a malware explosion on Android, they have
a conflict of interest. We at the Official Google Android Blog continue our
100% neutrality however.

"While it’s not possible to prevent bad people from building malware, the most
important measurement is whether those bad applications are being installed
from Android Market"

Not if you're going to advertise side-loading as a feature the competition
lacks.

