Hi Dianne, Thanks for your response. I'd like to address some of your points.
> users should not worry about the apps they install doing unexpected harmful > things I believe that limiting the functionality of the phone/API enough to achieve complete safety for any application would be very difficult. If it is even possible, then I think it would result in a neutered platform. So why not require digital signatures or user approval for risky application behaviors instead of removing the functionality in question? > the security side is just as critical but a lot more subtle ... > just saying that platform X does it so it is okay to do it on Android as well > is not enough. I don't deny the importance and subtly of the security issue. That is why I thought it was important to note what the rest of the industry has done. Companies like Nokia share the concerns of Google about developing a healthy application ecosystem but they have gone much further then I am suggesting and made this bluetooth functionality wide open - I think this observation is very relevant. There is a huge amount of empirical data for you to draw upon now: hundreds of millions of phones, from all brands except RIM and Apple, that allow applications the functionality in question. Tom. On Jan 6, 10:26 pm, "Dianne Hackborn" <hack...@android.com> wrote: > I think you are being overly dismissive of the security repercussions. One > of our goals with Android is to create an open and thriving third party > application market. Two cornerstones of doing this is that it should be > dead easy for a user to find and install an application, and users should > not worry about the apps they install doing unexpected harmful things. The > former is a fairly clear goal, but the security side is just as critical but > a lot more subtle -- each little piece you take out of the security picture > is a growing, long-term detriment to the user's trust. > > From the very start, our approach with Android security has been as > conservative as possible: if there is an application feature that seems > dangerous, we'll try to either take the time needed to think about and > address of its repercussions, or wait on making it available. The same > approach needs to be taken here, everything thought through before making it > available. This sounds like it requires enough thought that it probably > doesn't make sense to have in a 1.0 API (though Nick would know better than > I). > > At any rate, just saying that platform X does it so it is okay to do it on > Android as well is not enough. PalmOS lets apps patch the core OS to insert > their tendrils into everything it does; should that also be allowed on > Android? I wouldn't think so. That isn't to say a feature shouldn't be > there, but it should be done with thought and consideration to all of the > repercussions it has. > > > > On Sun, Dec 21, 2008 at 10:01 PM, Qwavel <qwa...@gmail.com> wrote: > > > Nick, > > > Thanks for participating in this open conversation about the bluetooth > > API - this is the first time that I'm aware of that outside developers > > have had the opportunity to express themselves at this stage in the > > development of a phone OS/API. > > > As I'm sure you are aware, Bluetooth data connection between apps are > > supported by JSR82. To the best of my knowledge, the only platform on > > which pairing is required for these connections is the Blackberry. As > > far as I can tell, this was done for the pretense of security since > > the platform was originally only targeted at the enterprise market. > > On the Blackberry dev forums I regularly see confusion and surprise > > about this restriction. > > > The only other platform (beside the Blackberry) which really limits > > bluetooth is the iPhone, but this is expected of Apple. > > > I am being dismissive about the security advantages of the blackberry > > approach for these reasons: > > > - The majority of phones available now (in Europe but not in the US) > > allow full access to JSR82, without requiring pairing, and without > > even requiring that the midlet be signed. > > > - More importantly, I've not encountered any regret about this, or any > > sense that it is a mistake. Instead, easy access to JSR82 is > > spreading: now, even LG and Samsung are starting to provide this. > > > - Security concerns like this should not be addressed by limiting the > > functionality of the system, when they can be addressed at the > > application security level. I can't comment on the difficulty of > > implementing this, but certainly it would be better to produce an OS > > that is not limited in the way that the BB and iPhone are. > > > If you really believe that bluetooth communication without pairing is > > a security hole - and I believe that Nokia and SE have shown that it > > isn't - then I think it would be better handled by the application > > level security mechanisms. > > > Thanks, > > Tom. > > > On Dec 3, 12:22 pm, Nick Pelly <npe...@google.com> wrote: > > > We are likely to prevent Bluetooth data connections (RFCOMM) from apps > > > unless the two phones have been paired. It's really hard to make > > > security work any other way. > > > > Nick > > > Android Systems Engineer > > > > On Wed, Dec 3, 2008 at 1:37 AM, whitemice <markbr...@zedray.co.uk> > > wrote: > > > > > Hi Nick > > > > While we are on the subject, I am looking for Android *Ad-hoc* > > > >Bluetoothsupport. > > > > > Example: Alice and Bob both have my client running on their phones, > > > > and walk withinBluetoothrange of each other in a social setting. I > > > > want the application to: > > > > (a) Be able to detect the otherBluetoothphone in the room > > > > (b) Detect that the same application is running on the other phone > > > > (c) Create a data connection between the two phones without asking for > > > > the user's permission (permission is granted beforehand). > > > > > Is this considered a security problem, or will this kind of thing be > > > > allowed in the new API? > > > > > Some more info on what I am doing…. > > > >http://blog.zedray.com/snowball/ > > > > > Regards > > > > Mark > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
