Copied issue chromium:601523 from  issue chromium:562592 

Split  issue 562592  into
 issue 562592 : Enterprise policy switch
issue 601523: Content Settings switch  <<< this issue.

Fixed the empty status.

+jyasskin@ IIRC we started with the Bluetooth permission as non-persistent. Can we make it a persistent content setting now?

msramek, we do plan on doing so. We have not yet as we have focused on the minimum set of useful functionality to ship.

Because Web Bluetooth is already disabled by default and requires a user to select a device to enable it I believe we should not add a content setting to keep content settings simpler.

This is the decision we came to with the Fullscreen redesign about a year ago. That feature is enabled by default, and does have security considerations, mitigated with the transient exit message. Web Bluetooth is in a stronger position requiring opt-in.

To make the device grant persistent, we do need a content-settings surface for people to revoke permission. I guess it's plausible to avoid the global deny and the ability to block a site that asks repeatedly. What do the privacy and security-ui teams think?

If the grant is persistent, then it indeed needs to have a UI surface to audit/change/remove. One reason is that users should be able to manage their permissions, another reason is that the set of sites with a granted permission is a subset of browsing history, which in itself needs to be auditable and deletable.

I don't understand your second sentence though - by "avoid" you mean that you don't want the content setting to have a BLOCK state? That would be... unusual.

Re: #9 "don't want ... BLOCK state?": Fullscreen and pointer lock removed all content settings, even global deny. I think #8 was referring to that.

I think that Bluetooth should follow USB. There is no global setting. There is ability to manage for all origins the devices that were connected (became ALLOW). But, you can't block globally all USB, nor can you do so for all devices on one origin, and certainly not one origin and a specific device.

See screen shots:
https://goo.gl/photos/RcTBhdQmJCPabpwN6

Fullscreen has what I would call "shoot first, ask questions later" semantics. This is fine, because it's not sensitive; nothing horrible will happen if a website fullscreens one element, you can just press Esc and you're back. It doesn't need BLOCK semantics.

Bluetooth, however, is sensitive, so this is not applicable; we cannot give a website access to Bluetooth hoping that the user will stop it if they disagree.

Therefore, we need a real permission prompt. And then the policy is - if the permission sticks, we must have a UI surface for it. So either we ask every time, or we have a content setting (both is fine with me).

If the content setting is mapping a website to a *device*, then I agree that it makes sense to follow the example of the USB setting. In other words, if we don't have per-website ALLOW/ASK/BLOCK permissions, then I agree it's plausible not to have them on a global level either. Although I can imagine that enterprise admins, and users bothered by having to constantly decline permissions, would want a global BLOCK setting.

#11 has some clarification needed.

Bluetooth access is from 1 site to 1 or more specific devices. There is no bluetooth access until a device is selected by a user. 

Permission is currently not persisted, and won't be until permissions UI for site info and content settings are updated. This is tracked here in the issue's blocking relationships up to issue 577953.

We already have a 'real permission prompt' as well. It is a chooser dialog informing the user that the site would like access to a device. Suitable devices are listed, and a user may either select one and then confirm, or dismiss the dialog.

An enterprise policy already exists to block sites from requesting devices. I believe the enterprise policy is warranted, but have argued in recent comments that we should not complicate content settings by having a global pre-emptive block that disallows sites to make the request.

The Fullscreen comparison isn't quite right. Fullscreen does present a real threat for phishing, and that action takes effect immediately. This is more severe than Bluetooth, which only enables sites to show a chooser dialog but have no access. The design consideration for Fullscreen to move ahead even with this risk was based on existing data from Flash's widely deployed permission model and the impact it has, and users' understanding of using ESC.

I agree with #12.

To illustrate the fullscreen risk, check out http://feross.org/html5-fullscreen-api-attack/.

What I was trying to say is that for javascript or microphone, it doesn't make sense to show a toast saying "Press Esc to stop", because at that time the code has already been executed, and some sound has already been recorded. In your case, a Bluetooth device already accessed. I admit that you could argue that in the fullscreen case the user has already been phished, but that doesn't happen immediately and automatically like in the other cases. (and of course, hopefully the toast is effective at preventing that). That's why I see fullscreen as having different semantics than other permissions, and I don't think it's the right precedent to look at.

Anyways! If you have a permission prompt, it means that you have the usual ALLOW/ASK/BLOCK semantics.

The only thing I want to enforce from privacy side is that what is saved can be audited and deleted; in other words, if the permission is sticky, the user can view and revoke it in the content settings UI.

I think it's fine to model that Bluetooth settings after the USB devices section and not provide the global BLOCK option (especially because a global ALLOW option would not make much sense either). From privacy perspective, ASK as a global default is safe.

And if the feature is disabled by a policy, we should also add a short explanation to the settings UI, so users don't get confused why the "Manage..." button is disabled and Bluetooth doesn't work.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I recently implemented this for WebUSB in  issue 771703 .