Re: [w3c/permissions] Consider removing Permissions.revoke(). (#46)

I do see valid point from the concern raised by @martinthomson and @jan-ivar.  User permissions are typically managed by users directly through the user agent UI and also very often kept in sync with the corresponding OS settings.  The revoke() method can potentially make the user permission management more convoluted.

Meanwhile, we should keep in mind that user permissions could be given and stored as either "granted" or "denied".  I don't think the revoke() process has been clearly defined for all the scenarios.  
- When a user set a persistent "denied" to a particular permission, the user agent won't prompt any ask for the same permission again unless the existing permission entry is deleted by the user.  It'd be a common sense that the website has no right to revoke that user decision, and it is not appropriate for the user agent to pop up a UI to ask again.
- When a user set a "granted" to the permission, it is not clear either what should be expected based on the spec.  For instance, does "revoke" mean to delete the permission entry, or turn it to a persistent "denied"?  As another question, let's assume the user agent pop up a UI to ask for revocation, can the user dismiss the ask and keep the permission as a persistent "granted"?  Would that limit the goal for the website to reliably turn off the permission using the revoke() method?

I just started looking into the spec, so hope experts in the WG can help point out if I have missed anything.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/46#issuecomment-242935655