> > > The data roaming thing is fixed in Cupcake.
> > Fixed? It's not broken as far as I can tell. It's a System setting.
> > Seriously, why on earth would you change it? I'm sure that no
> > developer has requested this as a change, so why is it changing?
>
> Yes, fixed as far as applications can no longer modify it without the user
> being involved. This wasn't done for application developers, it was done
> for users.
But why was this done? Why this change? As I pointed out before, you
can destroy all of a user's content (which is as important and often
FAR more important to the user than whether their phone is
misconfigured for data access.) Even, as you mention below, you want
to add a permission for manipulating the SDCARD, I think that's a
great idea; however, why does adding a permission in that case make it
'secure enough' for Android but using an already existing permissions
'WRITE_SETTINGS' isn't secure enough to allow a user to designate that
an application can manage their phone settings?
Wouldn't the answer be far less draconian than simply pulling the
ability out and instead proffering a finer level of granularity to
permissions so that when a user installs an application they're made
aware it can affect synchronization or something similar?
It seems illogical for the framework to lose the ability, in all
cases, to programatically change a setting; especially given that no
one knows how to launch an intent to bring up the settings in question
(android.settings.SYNC_SETTINGS doesn't work.) Now, I KNOW that you
and the other Android framework engineers are anything but illogical,
so I can only guess that there's some other reason that you're not
telling us about (I don't mean that to sound Machiavellian, LOL, I
just mean that you can't always talk about the things you'd like for
all kinds of good reasons.)
> > > If you are doing this for a vendor, you can have your app signed with the
> > > platform certificate for the vendor, and do many of these things. What
> > you
> > > are asking is not within the scope of the third party SDK, and is most
> > > likely something we don't want to have within it.
> > Apologies, but I don't understand how having my 'app signed' for a
> > vendor will suddenly make new features of the SDK available. Does
> > doing this get me a different Android Jar that suddenly makes the Sync
> > Manager available?
>
> It won't make any new kind of SDK available, but you can do this if you are
> being bundled in the system image of a particular device (as you seemed to
> imply by saying you are writing something for a vendor), in which case you
> can be signed by them to use system permissions and use their internal
> APIs. This would never be something you could put up on Market (nor would
> such a thing really work).
I'm sorry, but this vendor (who is very large, and in the US, hint,
hint) explicitly wants to push this through the market. It is a
subsection of a larger system management application. They have zero
interest in having to update their system images simply to accomodate
changes and additions to the myriad of applications they wish to offer
their customers (including this one.)
> > Why wouldn't you want to be let applications control the functionality
> > of the phone? Protecting the user? That can't be it because you can
> > stomp all over the SDCARD, you can run background services that run at
> > boot, you can upload data from the phone to pretty much any website
> > you wish.
>
> The main reasons are either because it is considered to be too insecure
> (such as installing applications without going through the installer UI), or
> because it is an API that an engineer doesn't want to commit to supporting
> forever (such as telephony stuff, which is especially fragile with CDMA
> support going in).
It is too insecure to allow them to turn on/off auto-sync but you can
erase their content? I'm sorry, but I find that both of them are
equally secure/insecure, given the permissions model, and in the case
of abuse I think any objective person would think the latter would be
far more damaging.
> I am hoping that in an upcoming release we will close the issue with the
> SDCARD not requiring a permission.
How does that make it more 'secure'? You just stipulated that it is
too insecure to allow a user to enable/disable auto-sync, even though
it already requires a permission, but adding a permission will make
SDCARD access acceptably secure?
I have no problem with the permissions model, I don't, however, like
losing the ability to do things each release of the SDK when the
framework is basically 2 years old already. It's not like Android is
in 'beta'. This is a framework upon which large/medium/small
corporations and thousands of individuals are expecting to be stable,
backwards compatible, and reliable in the sense that telling people to
manage the auto-sync settings by using Google's own activity (which on
1.1 r1 doesn't appear to handle the intent defined) to change it means
that Google can change your user's experience with your application at
any time by moving a setting you expected to be there to some other
UI.
> i don't really see what the security
> issue is with starting background services.
Really? You consider an application that obtains permission from the
user to enable/disable phone settings such as auto-sync insecure, but
a service that once installed by the user may be forgotten about and
be running, years later, on their phone and they don't remember it at
all, and it can basically do anything the user first gave it
permission to do?
Again, it seems like your saying "Danger! Danger! You shouldn't be
able to do X" when you also argue that doing Y, Z, and the rest, are
totally acceptable. I don't understand how taking away the ability to
turn data roaming on/off from our own UIs and Activities makes the
phone any more secure unless you plan to make everything impossible
for applications to do without going through a Google Android
activity.
> I would also like to close any
> holes for applications to send data over the network without explicitly
> requesting it, but am not sure what or when we might do that.
That would certainly make things more secure, and I can think of cases
where you could apply that, but in general, you'd be ruining the
phone. The most attractive thing about Android is that you expect it
to be flexible. BSD is a relatively secure computing environment and
they don't restrict developers from changing settings. Seriously, you
need to leave most of these things open to users to decide, ignoring
the well established premise that users do crazy and dangerous things.
> Our goal should very much be to close holes as we find them, which you
> already see happening in Cupcake, not just give up and let applications do
> whatever they want.
The problem is that you (and others) see holes where I (and others) do
not. I certainly don't consider it a hole for applications, who use
the settings write permission, to change settings. The problem is
exacerbated by the fact that Vendors do not want to be tied to their
system image updates as a deployment mechanism for new and/or updated
applications.
> Where is this mysterious group who decides what's dangerous and what
>
> > isn't, when it's all technically dangerous to begin with...?
>
> If you are coming at the position that security isn't useful because
> everything an application can do is dangerous, then I'm not sure what kind
> of useful discussion we can have. :}
I don't have a problem with fixing things that need fixing, I'm just
having a very hard time understanding how there are these terrifically
dangerous areas such as the SDCARD that you seem to think are fine (as
evidenced by your posts, barring a new permission set) but it's a
security hole to allow users to allow applications to manage their
phone settings.
> Anyway, the security engineers, core
> technical team, and engineers responsible for their area of the system makes
> these kinds of decisions.
Is there a forum (in the classical sense) where requests and
suggestions can be directed explicitly to this group?
Thanks,
Hans :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
