* Re: GATT service blacklist @ 2017-01-14 4:38 Vincent Scheib 2017-01-16 13:46 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Vincent Scheib @ 2017-01-14 4:38 UTC (permalink / raw) To: linux-bluetooth I just ran into this issue again (being blocked from accessing a standard GATT service) when using bluez. I had an application accessing GATT objects, and also the generic_access service. It's very odd that GATT operations to any service would be blocked unless there was a security reason to prevent them. Reading and writing the device name should just work. It doesn't make sense to write different code with a different API when the GATT API is already designed to provide access to this service. Is there a reason bluez can't allow access? Re: http://marc.info/?l=3Dlinux-bluetooth&m=3D146433282020607 > We now have a new Web Bluetooth sample which shows how to read all GAP > characteristics from a nearby Bluetooth device. > https://plus.google.com/+FrancoisBeaufort/posts/7pLosPyHd41 > > Hopefully, we'll get BlueZ to work. > > On Wed, May 25, 2016 at 2:51 PM, Fran=C3=A7ois Beaufort > <beaufort.francois@gmail.com> wrote: >> For info, the Web Bluetooth team is tracking this issue at >> https://bugs.chromium.org/p/chromium/issues/detail?id=3D611678 >> >> We would really appreciate some consistency between Android, Mac OS >> and Linux platforms to query GAP service characteristics. >> >> Thanks in advance for considering this, >> Francois. >> >> On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz >> <luiz.dentz@gmail.com> wrote: >>> Hi, >>> >>> In Web Bluetooth there is a list of blacklisted attributes that may >>> leak some important information: >>> >>> https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt >>> >>> Currently we don't support claiming attribute, which is what in the >>> end prevent a service to be exposed, so I would like to know the >>> opinion about having such a feature noting that this may lead to >>> conflicts such as plugins and application accessing the same >>> attributes which may or may not interfere. >>> >>> One of the service that web guys would like to access is GAP service ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-14 4:38 GATT service blacklist Vincent Scheib @ 2017-01-16 13:46 ` Luiz Augusto von Dentz 2017-01-19 19:52 ` Vincent Scheib 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2017-01-16 13:46 UTC (permalink / raw) To: Vincent Scheib; +Cc: linux-bluetooth Hi Vincent, On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: > I just ran into this issue again (being blocked from accessing a standard > GATT service) when using bluez. I had an application accessing GATT > objects, and also the generic_access service. It's very odd that GATT > operations to any service would be blocked unless there was a security > reason to prevent them. Reading and writing the device name should just > work. It doesn't make sense to write different code with a different API > when the GATT API is already designed to provide access to this service. > > Is there a reason bluez can't allow access? Well the general idea was to block access if there is a plugin already handling a certain service. Now you seem to be claiming this shouldn't be the case and any service can be accessed simultaneously by a plugin running in daemon process and an application, but I don't think this is always true and in some cases they may conflict, or just generate duplicated traffic. Perhaps for GAP service itself it is fine to allow applications to access it, the problem is if we allow the application to set the name like you want does it notifies that do the daemon as well? If it doesn't then the daemon might only be able to detect the name has changed once it connect again and attempt to read the name. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-16 13:46 ` Luiz Augusto von Dentz @ 2017-01-19 19:52 ` Vincent Scheib 2017-01-19 20:17 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Vincent Scheib @ 2017-01-19 19:52 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: >> I just ran into this issue again (being blocked from accessing a standard >> GATT service) when using bluez. I had an application accessing GATT >> objects, and also the generic_access service. ... > > Well the general idea was to block access if there is a plugin already > handling a certain service. Now you seem to be claiming this shouldn't > be the case and any service can be accessed simultaneously by a plugin > running in daemon process and an application, but I don't think this > is always true and in some cases they may conflict, or just generate > duplicated traffic. Correct. Bluetooth devices are all required to have a generic_access service, and I believe applications should be able to use the GATT protocol to interact with that service. I think that the current approach bluez has taken of trying to abstract this is a mistake. There doesn't seem to be value added by doing so, but there is harm in creating additional ways to interact, harming portability and requiring more attention and custom code by application developers. > Perhaps for GAP service itself it is fine to allow applications to > access it, the problem is if we allow the application to set the name > like you want does it notifies that do the daemon as well? Yes. The same way multiple applications should be able to receive notifications for one device. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-19 19:52 ` Vincent Scheib @ 2017-01-19 20:17 ` Luiz Augusto von Dentz 2017-01-19 21:11 ` Emil Lenngren 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2017-01-19 20:17 UTC (permalink / raw) To: Vincent Scheib; +Cc: linux-bluetooth Hi Vincent, On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@google.com> wrote: > On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: >>> I just ran into this issue again (being blocked from accessing a standard >>> GATT service) when using bluez. I had an application accessing GATT >>> objects, and also the generic_access service. ... >> >> Well the general idea was to block access if there is a plugin already >> handling a certain service. Now you seem to be claiming this shouldn't >> be the case and any service can be accessed simultaneously by a plugin >> running in daemon process and an application, but I don't think this >> is always true and in some cases they may conflict, or just generate >> duplicated traffic. > > Correct. Bluetooth devices are all required to have a generic_access > service, and I believe applications should be able to use the GATT > protocol to interact with that service. I think that the current > approach bluez has taken of trying to abstract this is a mistake. > There doesn't seem to be value added by doing so, but there is harm in > creating additional ways to interact, harming portability and > requiring more attention and custom code by application developers. Well you seem to forget that there are various ways to get the name, not only GATT. In fact the GAP Service over GATT is just the tip of the iceberg, since GAP define the connection procedures which has very little to do with this service, and when it comes to GAP procedures we do need to know the Name of the devices to display to the user and that may come from advertisements, inquiry results or from Read Name command so we can cache the name so we can display it even when not connected. So if you arguing that the stack should not deal with this service I would have to disagree. >> Perhaps for GAP service itself it is fine to allow applications to >> access it, the problem is if we allow the application to set the name >> like you want does it notifies that do the daemon as well? > > Yes. The same way multiple applications should be able to receive > notifications for one device. Except that org.bluetooth.characteristic.gap.device_name excludes notification support: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-19 20:17 ` Luiz Augusto von Dentz @ 2017-01-19 21:11 ` Emil Lenngren 2017-01-23 9:41 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 10+ messages in thread From: Emil Lenngren @ 2017-01-19 21:11 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Vincent Scheib, linux-bluetooth Hi, 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>: > Hi Vincent, > > On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@google.com> wrote: >> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz >> <luiz.dentz@gmail.com> wrote: >>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: >>>> I just ran into this issue again (being blocked from accessing a standard >>>> GATT service) when using bluez. I had an application accessing GATT >>>> objects, and also the generic_access service. ... >>> >>> Well the general idea was to block access if there is a plugin already >>> handling a certain service. Now you seem to be claiming this shouldn't >>> be the case and any service can be accessed simultaneously by a plugin >>> running in daemon process and an application, but I don't think this >>> is always true and in some cases they may conflict, or just generate >>> duplicated traffic. >> >> Correct. Bluetooth devices are all required to have a generic_access >> service, and I believe applications should be able to use the GATT >> protocol to interact with that service. I think that the current >> approach bluez has taken of trying to abstract this is a mistake. >> There doesn't seem to be value added by doing so, but there is harm in >> creating additional ways to interact, harming portability and >> requiring more attention and custom code by application developers. > > Well you seem to forget that there are various ways to get the name, > not only GATT. In fact the GAP Service over GATT is just the tip of > the iceberg, since GAP define the connection procedures which has very > little to do with this service, and when it comes to GAP procedures we > do need to know the Name of the devices to display to the user and > that may come from advertisements, inquiry results or from Read Name > command so we can cache the name so we can display it even when not > connected. So if you arguing that the stack should not deal with this > service I would have to disagree. > In my opinion, it's nice that the system tries to maintain a cache using various methods to be able to show the name to the user even when the device is disconnected. However that should not imply that it shouldn't be possible to read the name characteristic directly from an application. There are many reasons why one thinks the name is old and needs to be refreshed; for example if you use a smartphone as GATT server where you easily can change both GATT server and name, or if you do a firmware update and reboot the device the name may change as well. If there is no way to force the system to reload the name then it should definitely be possible to read it directly. This is how Android's implementation works and I guess no one has complained about it. Also when you want to build a Bluetooth library on top on another Bluetooth library it's never fun when each platform has its own restrictions that probably was intended to simplify for the users but in practice often misses special cases leading to incompatibility problems. >>> Perhaps for GAP service itself it is fine to allow applications to >>> access it, the problem is if we allow the application to set the name >>> like you want does it notifies that do the daemon as well? >> >> Yes. The same way multiple applications should be able to receive >> notifications for one device. > > Except that org.bluetooth.characteristic.gap.device_name excludes > notification support: > > https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml I would guess the spec writers didn't really think about what should happen when the name gets updated. iOS actually "takes up/waste" one round trip in each start of connection to read the name characteristic in order to always try to have the latest. Emil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-19 21:11 ` Emil Lenngren @ 2017-01-23 9:41 ` Luiz Augusto von Dentz 2017-02-05 21:16 ` Giovanni Ortuño 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2017-01-23 9:41 UTC (permalink / raw) To: Emil Lenngren; +Cc: Vincent Scheib, linux-bluetooth Hi Emil, On Thu, Jan 19, 2017 at 11:11 PM, Emil Lenngren <emil.lenngren@gmail.com> wrote: > Hi, > > 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>: >> Hi Vincent, >> >> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@google.com> wrote: >>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz >>> <luiz.dentz@gmail.com> wrote: >>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: >>>>> I just ran into this issue again (being blocked from accessing a standard >>>>> GATT service) when using bluez. I had an application accessing GATT >>>>> objects, and also the generic_access service. ... >>>> >>>> Well the general idea was to block access if there is a plugin already >>>> handling a certain service. Now you seem to be claiming this shouldn't >>>> be the case and any service can be accessed simultaneously by a plugin >>>> running in daemon process and an application, but I don't think this >>>> is always true and in some cases they may conflict, or just generate >>>> duplicated traffic. >>> >>> Correct. Bluetooth devices are all required to have a generic_access >>> service, and I believe applications should be able to use the GATT >>> protocol to interact with that service. I think that the current >>> approach bluez has taken of trying to abstract this is a mistake. >>> There doesn't seem to be value added by doing so, but there is harm in >>> creating additional ways to interact, harming portability and >>> requiring more attention and custom code by application developers. >> >> Well you seem to forget that there are various ways to get the name, >> not only GATT. In fact the GAP Service over GATT is just the tip of >> the iceberg, since GAP define the connection procedures which has very >> little to do with this service, and when it comes to GAP procedures we >> do need to know the Name of the devices to display to the user and >> that may come from advertisements, inquiry results or from Read Name >> command so we can cache the name so we can display it even when not >> connected. So if you arguing that the stack should not deal with this >> service I would have to disagree. >> > > In my opinion, it's nice that the system tries to maintain a cache > using various methods to be able to show the name to the user even > when the device is disconnected. However that should not imply that it > shouldn't be possible to read the name characteristic directly from an > application. There are many reasons why one thinks the name is old and > needs to be refreshed; for example if you use a smartphone as GATT > server where you easily can change both GATT server and name, or if > you do a firmware update and reboot the device the name may change as > well. If there is no way to force the system to reload the name then > it should definitely be possible to read it directly. This is how > Android's implementation works and I guess no one has complained about > it. Reading is alright, writing is the one Im more concerned since we might not be able to detect the change until it gets reconnected. Also there is no mention on how this affects the name in the advertisement, if that gets truncated, etc. Flashing a new firmware is actually no problem, we do read the name every time it gets connected. Im not sure I follow regarding the GATT server and name, do you want applications to register a GAP service as a server? How would we handle different applications trying to register themselves as GAP service since I don't think we can have multiple instances of that service, if Android allow to do that its probably not even complaint. > Also when you want to build a Bluetooth library on top on another > Bluetooth library it's never fun when each platform has its own > restrictions that probably was intended to simplify for the users but > in practice often misses special cases leading to incompatibility > problems. Well the same can be said if the Bluetooth stack allow doing things forbidden by the spec. > >>>> Perhaps for GAP service itself it is fine to allow applications to >>>> access it, the problem is if we allow the application to set the name >>>> like you want does it notifies that do the daemon as well? >>> >>> Yes. The same way multiple applications should be able to receive >>> notifications for one device. >> >> Except that org.bluetooth.characteristic.gap.device_name excludes >> notification support: >> >> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml > > I would guess the spec writers didn't really think about what should > happen when the name gets updated. iOS actually "takes up/waste" one > round trip in each start of connection to read the name characteristic > in order to always try to have the latest. BlueZ does the same and we do emit a signal if we the detect the name has changed. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2017-01-23 9:41 ` Luiz Augusto von Dentz @ 2017-02-05 21:16 ` Giovanni Ortuño 0 siblings, 0 replies; 10+ messages in thread From: Giovanni Ortuño @ 2017-02-05 21:16 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Emil Lenngren, Vincent Scheib, linux-bluetooth [Sending again in plain text mode] I don't think it makes sense to block this functionality. This will only cause developers to introduce non-standard characteristics to achieve what they want. For example Playbulb already does this: Characteristic with UUID 0xffff[1] can be used to change the device's name. I can imagine the number of peripherals that do this will only grow as this is clearly a desired feature. [1] https://github.com/Phhere/Playbulb/blob/master/protocols/characteristics.md On Mon, Jan 23, 2017 at 8:41 PM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi Emil, > > On Thu, Jan 19, 2017 at 11:11 PM, Emil Lenngren <emil.lenngren@gmail.com> wrote: >> Hi, >> >> 2017-01-19 21:17 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>: >>> Hi Vincent, >>> >>> On Thu, Jan 19, 2017 at 9:52 PM, Vincent Scheib <scheib@google.com> wrote: >>>> On Mon, Jan 16, 2017 at 5:46 AM, Luiz Augusto von Dentz >>>> <luiz.dentz@gmail.com> wrote: >>>>> On Sat, Jan 14, 2017 at 6:38 AM, Vincent Scheib <scheib@google.com> wrote: >>>>>> I just ran into this issue again (being blocked from accessing a standard >>>>>> GATT service) when using bluez. I had an application accessing GATT >>>>>> objects, and also the generic_access service. ... >>>>> >>>>> Well the general idea was to block access if there is a plugin already >>>>> handling a certain service. Now you seem to be claiming this shouldn't >>>>> be the case and any service can be accessed simultaneously by a plugin >>>>> running in daemon process and an application, but I don't think this >>>>> is always true and in some cases they may conflict, or just generate >>>>> duplicated traffic. >>>> >>>> Correct. Bluetooth devices are all required to have a generic_access >>>> service, and I believe applications should be able to use the GATT >>>> protocol to interact with that service. I think that the current >>>> approach bluez has taken of trying to abstract this is a mistake. >>>> There doesn't seem to be value added by doing so, but there is harm in >>>> creating additional ways to interact, harming portability and >>>> requiring more attention and custom code by application developers. >>> >>> Well you seem to forget that there are various ways to get the name, >>> not only GATT. In fact the GAP Service over GATT is just the tip of >>> the iceberg, since GAP define the connection procedures which has very >>> little to do with this service, and when it comes to GAP procedures we >>> do need to know the Name of the devices to display to the user and >>> that may come from advertisements, inquiry results or from Read Name >>> command so we can cache the name so we can display it even when not >>> connected. So if you arguing that the stack should not deal with this >>> service I would have to disagree. >>> >> >> In my opinion, it's nice that the system tries to maintain a cache >> using various methods to be able to show the name to the user even >> when the device is disconnected. However that should not imply that it >> shouldn't be possible to read the name characteristic directly from an >> application. There are many reasons why one thinks the name is old and >> needs to be refreshed; for example if you use a smartphone as GATT >> server where you easily can change both GATT server and name, or if >> you do a firmware update and reboot the device the name may change as >> well. If there is no way to force the system to reload the name then >> it should definitely be possible to read it directly. This is how >> Android's implementation works and I guess no one has complained about >> it. > > Reading is alright, writing is the one Im more concerned since we > might not be able to detect the change until it gets reconnected. Also > there is no mention on how this affects the name in the advertisement, > if that gets truncated, etc. Flashing a new firmware is actually no > problem, we do read the name every time it gets connected. Im not sure > I follow regarding the GATT server and name, do you want applications > to register a GAP service as a server? How would we handle different > applications trying to register themselves as GAP service since I > don't think we can have multiple instances of that service, if Android > allow to do that its probably not even complaint. > >> Also when you want to build a Bluetooth library on top on another >> Bluetooth library it's never fun when each platform has its own >> restrictions that probably was intended to simplify for the users but >> in practice often misses special cases leading to incompatibility >> problems. > > Well the same can be said if the Bluetooth stack allow doing things > forbidden by the spec. > >> >>>>> Perhaps for GAP service itself it is fine to allow applications to >>>>> access it, the problem is if we allow the application to set the name >>>>> like you want does it notifies that do the daemon as well? >>>> >>>> Yes. The same way multiple applications should be able to receive >>>> notifications for one device. >>> >>> Except that org.bluetooth.characteristic.gap.device_name excludes >>> notification support: >>> >>> https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml >> >> I would guess the spec writers didn't really think about what should >> happen when the name gets updated. iOS actually "takes up/waste" one >> round trip in each start of connection to read the name characteristic >> in order to always try to have the latest. > > BlueZ does the same and we do emit a signal if we the detect the name > has changed. > > -- > Luiz Augusto von Dentz > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* GATT service blacklist @ 2016-05-20 14:36 Luiz Augusto von Dentz 2016-05-25 12:51 ` François Beaufort 0 siblings, 1 reply; 10+ messages in thread From: Luiz Augusto von Dentz @ 2016-05-20 14:36 UTC (permalink / raw) To: linux-bluetooth Hi, In Web Bluetooth there is a list of blacklisted attributes that may leak some important information: https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt Currently we don't support claiming attribute, which is what in the end prevent a service to be exposed, so I would like to know the opinion about having such a feature noting that this may lead to conflicts such as plugins and application accessing the same attributes which may or may not interfere. One of the service that web guys would like to access is GAP service which is something BlueZ don't actually let them do since there is a plugin accessing it, and given its name we can probably except changes on every new Bluetooth release making me wary about exposing its attributes over D-Bus. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2016-05-20 14:36 Luiz Augusto von Dentz @ 2016-05-25 12:51 ` François Beaufort 2016-05-27 7:06 ` François Beaufort 0 siblings, 1 reply; 10+ messages in thread From: François Beaufort @ 2016-05-25 12:51 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth For info, the Web Bluetooth team is tracking this issue at https://bugs.chromium.org/p/chromium/issues/detail?id=611678 We would really appreciate some consistency between Android, Mac OS and Linux platforms to query GAP service characteristics. Thanks in advance for considering this, Francois. On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi, > > In Web Bluetooth there is a list of blacklisted attributes that may > leak some important information: > > https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt > > Currently we don't support claiming attribute, which is what in the > end prevent a service to be exposed, so I would like to know the > opinion about having such a feature noting that this may lead to > conflicts such as plugins and application accessing the same > attributes which may or may not interfere. > > One of the service that web guys would like to access is GAP service > which is something BlueZ don't actually let them do since there is a > plugin accessing it, and given its name we can probably except changes > on every new Bluetooth release making me wary about exposing its > attributes over D-Bus. > > > -- > Luiz Augusto von Dentz > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GATT service blacklist 2016-05-25 12:51 ` François Beaufort @ 2016-05-27 7:06 ` François Beaufort 0 siblings, 0 replies; 10+ messages in thread From: François Beaufort @ 2016-05-27 7:06 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth We now have a new Web Bluetooth sample which shows how to read all GAP characteristics from a nearby Bluetooth device. https://plus.google.com/+FrancoisBeaufort/posts/7pLosPyHd41 Hopefully, we'll get BlueZ to work. On Wed, May 25, 2016 at 2:51 PM, François Beaufort <beaufort.francois@gmail.com> wrote: > For info, the Web Bluetooth team is tracking this issue at > https://bugs.chromium.org/p/chromium/issues/detail?id=611678 > > We would really appreciate some consistency between Android, Mac OS > and Linux platforms to query GAP service characteristics. > > Thanks in advance for considering this, > Francois. > > On Fri, May 20, 2016 at 4:36 PM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> Hi, >> >> In Web Bluetooth there is a list of blacklisted attributes that may >> leak some important information: >> >> https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt >> >> Currently we don't support claiming attribute, which is what in the >> end prevent a service to be exposed, so I would like to know the >> opinion about having such a feature noting that this may lead to >> conflicts such as plugins and application accessing the same >> attributes which may or may not interfere. >> >> One of the service that web guys would like to access is GAP service >> which is something BlueZ don't actually let them do since there is a >> plugin accessing it, and given its name we can probably except changes >> on every new Bluetooth release making me wary about exposing its >> attributes over D-Bus. >> >> >> -- >> Luiz Augusto von Dentz >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-02-05 21:16 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-14 4:38 GATT service blacklist Vincent Scheib 2017-01-16 13:46 ` Luiz Augusto von Dentz 2017-01-19 19:52 ` Vincent Scheib 2017-01-19 20:17 ` Luiz Augusto von Dentz 2017-01-19 21:11 ` Emil Lenngren 2017-01-23 9:41 ` Luiz Augusto von Dentz 2017-02-05 21:16 ` Giovanni Ortuño -- strict thread matches above, loose matches on Subject: below -- 2016-05-20 14:36 Luiz Augusto von Dentz 2016-05-25 12:51 ` François Beaufort 2016-05-27 7:06 ` François Beaufort
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.