On Jan 7, 3:20 am, Nick Pelly <[email protected]> wrote: > On Tue, Jan 6, 2009 at 8:44 PM, Qwavel <[email protected]> wrote: > > > 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? > > That's exactly how our platform works. The user has to OK the > permissions an application requires at install time. Unpaired > communication would definitely be a strongly worded permission, as > suggested earlier on this thread. But even then, for better or worse, > a lot of users don't pay a lot of attention to these permissions. So > we _still_ need to think very carefully about the security > implications of the functionality we are going to expose. Getting the > balance of functionality vs security right is not simple, as Dianne > was explaining. > > > > > > 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. > > No other mobile phone operating system allows casual users to so > easily download and install untrusted, third party applications. And > the ones that come close prevent Bluetooth applications from > communicating with unpaired devices. This isn't helping your argument > one bit :)
Now I'm confused. My system provides browsing over bluetooth with the ability for phones to 'roam' across a mesh of bluetooth access points. Most European phones can do this. I have tested many phones from all the manufacturers. As for ease of installation, on most of these phones I can even distribute my software (or any "untrusted, third party applications") via bluetooth. This is very simple and requires no pairing. I have not tried this on Android, but I don't see how Android could make it simpler. Most phones require network access permission for the browsing but that is no problem. The only brands that are incapable of this are the blackberry's (because they require pairing) and the iPhone (which has very limited bluetooth capability). Tom. > In any case, 'the rest of the industry does it this way' is not the > right discussion, and isn't going to get you anywhere. We can do > better. > > > > > Tom. > > > On Jan 6, 10:26 pm, "Dianne Hackborn" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > 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 > > > [email protected] > > > > 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 [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 -~----------~----~----~----~------~----~------~--~---
