For the record, from BlueZ folks:

Up to you, but we may as well just disallow that over D-Bus if we
don't have a reason to keep this policy, but then again this is a
reflection of stacks that don't manage notification themselves so
there is always a risk the application will not get these details
quite right breaking the notifications, if I were to enforce this I
would probably file an errata to the spec outlining the requirements
to support notification which may or may not end up allowing
unsolicited notifications/indications. Note that unsolicited
notifications may not be a bad idea since the implementation of CCC is
quite expensive given that it needs to be persisted, also for services
provided by application it may not be possible to restore the CCC
because the database may have changed.

From a system point of view, it could make sense to let BlueZ subscribe to notifications without CCC descriptors (there is precedent about not being able to subscribe to notifications from some LE keyboards immediately on system restart).

From the Web Bluetooth side though, I'd argue we should be consistent across platforms and provide same level of experience when we want to start characteristic notifications.

+1 for being consistent. If this is a change that can go into BlueZ instead of Chrome, I always like having less code in Chrome.

Either way Im fine, the CCC was checked initially so we can return to the old behavior, Im just worried that this will cause an outcry if there are existing solutions depending on this, but well it is probably a good way to stop this behavior.

For info, I've just sent a BlueZ patch for review at http://marc.info/?l=linux-bluetooth&m=147446747925407&w=2

(Francois, please hold off on landing this patch till we hear from the ARC++ folks about the implications this would have on what they're trying to implement.)

This may not be something we want to completely restrict in BlueZ. We want to, in fact, allow CCC handling completely outside of BlueZ, for ARC++.

Opal, Eric, what implications does this have for ARC++?

If that's the case, Web Bluetooth would have to check for CCC by itself and returns errors for startNotifications and stopNotifications. We want to make sure we provide a consistent experience across platforms regarding characteristic notifications.

ortuno@ pointed that Web Bluetooth now actually checks for the CCC on all platforms:  https://codereview.chromium.org/2051333004
Thank you Opera folks!

This means we don't need to land this patch to BlueZ.
All we need is to implement characteristic descriptor on macOS. See blocking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=624017

Fixed by jlebel's work