Re: Fw: [android-developers] Re: Android and bluetooth

2009-01-07 Thread Qwavel

On Jan 7, 3:20 am, Nick Pelly npe...@google.com wrote:
 On Tue, Jan 6, 2009 at 8:44 PM, Qwavel qwa...@gmail.com 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 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

Re: Fw: [android-developers] Re: Android and bluetooth

2009-01-06 Thread Qwavel

Is there any update on this?

Specifically, have decisions been made about whether to limit
bluetooth comm to paired devices - as discussed below?

Thanks,
Tom.

On Dec 22 2008, 1:01 am, Qwavel qwa...@gmail.com wrote:
 Nick,

 Thanks for participating in this open conversation about thebluetooth
 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,Bluetoothdata 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 
 limitsbluetoothis 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 thatbluetoothcommunication 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 preventBluetoothdata 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Fw: [android-developers] Re: Android and bluetooth

2009-01-06 Thread Qwavel



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

Re: Fw: [android-developers] Re: Android and bluetooth

2009-01-06 Thread Qwavel

Nick,

I'm sorry to hear this, but I understand the need to add some sort of
bluetooth API to Android as quickly as possible.

I look forward to v1.1.

Thanks,
Tom.

On Jan 6, 11:07 pm, Nick Pelly npe...@google.com wrote:
 On Tue, Jan 6, 2009 at 7:10 PM, Qwavel qwa...@gmail.com wrote:

  Is there any update on this?

  Specifically, have decisions been made about whether to limit
  bluetooth comm to paired devices - as discussed below?

 We are unlikely to have this in the first Bluetooth API release. I don't
 think developers would be very excited about us holding up a first release
 while we debate and then implement this.

 That doesn't mean we can not add it later. Android moves pretty quick.

  Thanks,
  Tom.

  On Dec 22 2008, 1:01 am, Qwavel qwa...@gmail.com wrote:
   Nick,

   Thanks for participating in this open conversation about thebluetooth
   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,Bluetoothdata 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
  limitsbluetoothis 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 thatbluetoothcommunication 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 preventBluetoothdata 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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: Fw: [android-developers] Re: Android and bluetooth

2009-01-06 Thread Qwavel

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

Re: Fw: [android-developers] Re: Android and bluetooth

2008-12-21 Thread Qwavel

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
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



[android-developers] Re: New SDK available - 0.9 SDK beta

2008-08-26 Thread Qwavel

Thanks for bringing up an important and related point.

We are upset that the bluetooth API has been pulled, but I guess it
wouldn't have been much good if it didn't work well or was not
'comprehensive'.

Java developers are used to JSR82.  J2ME bluetooth apps are currently
written to JSR82.  If Android is not going to support JSR82 it would
be better if their API could at least support the basic things that
can be done with JSR82.

One example is L2CAP sockets.  I see in this new blog entry:
http://android-developers.blogspot.com/2008/08/some-information-on-apis-removed-in.html
that L2CAP socket support from Java is being considered but is not
certain, whereas this is supported in JSR82.

If the Android Bluetooth API is not only different then JSR82 but also
quite inferior in functionality then it will be hard to port JSR82
apps to Android and it will simply make the Android SDK look bad.

Please add the bluetooth API in Android 1.1 and please make it
possible for us to port our existing JSR82 apps to Android.

Thanks,
Tom.

On Aug 19, 3:15 am, Peli [EMAIL PROTECTED] wrote:
 Thank you very much for this long awaited public SDK! This is really a
 great step forward!

 On a detail level, I would also like to know more about the planned
 Bluetooth API.

 a comprehensive Bluetooth API will not be possible...

 Does it mean, there could be a limited Bluetooth API available for
 1.0? Will there be a way to send custom commands to an external
 device?

 Peli

 On 19 Aug., 02:20, Qwavel [EMAIL PROTECTED] wrote:

  Due to significant API changes in the upstream open-source project
  and due to the timeline of getting certain Bluetooth profile
  implementations certified, a comprehensive Bluetooth API will not be
  possible or present in Android 1.0.

  YIKES, this is a major loss.  What does this mean?  The text above
  implies that bluetooth API support is still intended for Android, and
  that it will come soon after 1.0.  If this is not true then please be
  clear - developers need to plan.

  Tom.

  On Aug 18, 3:01 pm, David McLaughlin (Android Advocate)

  [EMAIL PROTECTED] wrote:
   Fellow Android developers,

   We're pleased to announce the release of the Android 0.9 SDK beta!

   For full information, please see Dan Morrill's blog post:

  http://android-developers.blogspot.com/2008/08/announcing-beta-releas...

   Enjoy,
   David- Zitierten Text ausblenden -

  - Zitierten Text anzeigen -
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
Announcing the new Android 0.9 SDK beta!
http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---