This is now necessary because of https://chromium.googlesource.com/chromium/src/+/10e8933627cf2753881d6106ec9f480454f0d72d

vudentz commented on BlueZ IRC with:

fbeaufort, it is less optimal since bluetoothd will read the name, appearance, etc so the application can display this to the user early on and then come the application and read it again. Also allowing writing in a context of multiple applications sounds like a bad idea, also the reconnection_address will be exposing the device address which afaik was something not recommended.

For info, org.bluetooth.characteristic.gap.reconnection_address is already blacklisted: https://github.com/WebBluetoothCG/registries/blob/7b46fd5d58ea98fa098372a774fd7b981f0bdb0d/gatt_blacklist.txt#L30

Btw, if you look at the point of profiles GAP and GATT are two very different profiles, GAP Service seems to have been created because of the limitation on advertising data, which is part of GAP, so a bigger name could be used. That said I wouldn't be surprised if this service changes a lot over time since it informing parameters of a layer bellow which is the reason it is specified in core:

BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C]
page 390

A lot of it been have been changed since 4.0, reconnection_address is no longer in GAP, but we get the connection parameter there which is another reason for the stack to automatically read it. With all these there is a very good chance that other security sensitive information is shared over this service, so we will need to keep checking in every new release.

This is getting very tricky with the way we maintain a blacklist of attributes in web bluetooth vs whitelist of services in BlueZ, perhaps we should align the mechanism and maybe even fetch the list from a common place.

For info, BlueZ folks have started a conversation at http://marc.info/?t=146375513700002&r=1&w=2

And the official sample now lives at https://googlechrome.github.io/samples/web-bluetooth/gap-characteristics.html 

For info, I can also reproduce this issue with a Developer Chromium build on macOS which supports getCharacteristics().

Chromium	53.0.2767.0 (Developer Build) (64-bit)
Revision	da7f0338171febd1298f841f1fbad6d084503f5a
OS	Mac OS X 

Deleted: 1 (1).png 131 KB

	1 (1).png 131 KB View Download

It looks like "CoreBluetooth does not expose the GAP service directly to CoreBluetooth clients" according to http://lists.apple.com/archives/bluetooth-dev/2016/Feb/msg00018.html
I'm not sure what we can do about this now...

For info, I've just sent a message to Apple Mailing List "bluetooth-dev" at http://lists.apple.com/archives/bluetooth-dev/2016/Jun/msg00007.html

And filed a feature request at https://bugreport.apple.com (Fingers crossed)

Any update on that feature request?

Here's the last thread: http://marc.info/?l=linux-bluetooth&m=148436877000675&w=2

I meant the apple feature request, not bluez.

Oops. Sorry for misreading your last comment.
I didn't see any update from Apple.

Issues not modified in last 50 days aren't on track to ship in next release.