Hello Dianne, Thanks for the active participation in the discussion -- it's always good to have the knowledgeble parties engaged.
>If so, we simply do not do that. Android is an open platform, and we do not >require that applications be signed by some authority to use standard >features of the platform. I do understand the philosophy behind not wanting to put everything behind a closed padlock that no one can get to -- that has hampered growth in lots of application spaces. However, the various scenarios that have been laid out that could very easily be exploited for malicious intent due to this inadequate "trust me, I'm a good guy" security model should raise serious questions. There must be some way in which a middle position can be reached. I don't imagine that it's the intent of OHA or Google to create a platform rife with the same kind of exploitable scenarios that wreaks havoc on corporate networks running exploitable desktop operating systems that don't already have a clear way of establishing and revoking trust. Other non-locked mobile platforms (BlackBerry, Windows Mobile) have come up with workable trust systems that make it easy for developers to build and commercialize apps while protecting both users on their devices and the networks on which their devices operate. I'm sure the massive brains behind Android can conceptualize a model that works for all parties. The possible impacts of misbehaving applications on customer privacy and network operations in this scenario are very significant. I know that security/privacy has often been used as a bugaboo by carriers to prevent evolution of applications in the mobile space for years, but there is a correlation between that and the low number of trojans and viruses on mobile devices on wireless data networks to date. Android, unlike Linux on PDAs 10 years ago, is not meant to be a hacker-only platform. It's meant for consumers, the vast majority of which do not WANT to have to grasp complexities such as shared UIDs, self-signed certs and what those mean, etc. -jfr On Apr 1, 1:02 pm, Dianne Hackborn <[email protected]> wrote: > I am not sure what exactly you are looking for, but from your original > message it sounds like you want to have a certificate that most applications > must be signed with in addition to their own to be able to get most existing > application permissions. > > If so, we simply do not do that. Android is an open platform, and we do not > require that applications be signed by some authority to use standard > features of the platform. > > I could certainly imagine one extending the system to add a new permission > type where you specify the certificates that can have it, but we won't use > this in the base platform, because that is not how we do security. > > On Wed, Apr 1, 2009 at 7:06 AM, guillaume leterrier (Teleca Germany) < > > > > > > [email protected]> wrote: > > > Well, I do not agree. Indeed, as it was mentioned in an other thread > > (copied below), the multiple signature scheme is not supported. > > In my opinion, this is a huge limitation for the platform. > > > Basically, this means that an application can declare a permission > > ( protected by the signature scheme ), but this permission can only be > > used by an other application with the same signature. So, one can not > > create a permission ( protected by the signature scheme ) and have 2 > > different applications (signed with 2 different signatures, coming > > from 2 different developers ) using this permission. Only a dangerous > > or normal protection allows to do that ! > > > > 1)I know jar signer support multiple signatures in one jar file. If an > > > APK file has two valid signatures, does that mean this APK can access > > > signature level permission provided by both signers? > > > In theory, something is done with multiple signatures, but nobody has > > ever > > used this so it probably doesn't work. This also has the side-effect > > (if it > > does work) of aliasing the two signatures to the same thing since > > they > > presumably come from the same owner, which is likely not what you > > want. > > > So basically, please don't do this. :) > > > On Mar 27, 11:14 pm, "[email protected]" <[email protected]> wrote: > > > Android permissions guard activities between applications. From > > > Security perspective, android frame work is as same as an application. > > > To use signature level or permission defined by framework, your > > > application has to be signed using same key. > > > > You can define signature level permission in your application as well. > > > And you can use multiple signing keys to sign your application. Other > > > app would need to be signed using one of signing keys you used so they > > > can use permission enforced by your application. > > > > Do you agree with me? > > > > For T-Mobile G1, HTC generated 4 keys to sign different groups of > > > APKs. These 4 keys are corresponding to 4 keys in open source: > > > testkey, media, platform and shared. You can search .bks files under > > > build directory. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them.
