Hmm, in my mind we sort of have a store implicitly defined in the spec. The key is the entire context of the JS call (including permission, origin, etc.). Setting a value corresponds to "new information about the user’s intent". This gives the UA a lot of freedom. I think we can define more constraints on this boundary if we have consensus (such as the origin one). WDYT? On Tue, 16 Aug 2016 at 18:03 Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Aug 16, 2016 at 5:18 AM, Raymes Khoury <raymes@google.com> wrote: > > This constraint turns out to be very difficult to describe in a model. > The > > UA needs flexibility to resolve permissions in whatever way it sees best > for > > the user. In Chrome, for example, we have enterprise policy which can > > specify a set of rules which impact how a permission is resolved. This > can > > be done more broadly than a per-origin basis. In the end the UA should > have > > flexibility to return whatever it wants to allow browsers to experiment > with > > permission systems that provide the best experience for the user. > > I think you're confusing UX at that point with the underlying model. > The model is basically working out what the key is. If you have > something layered on top that can set permissions for several origins > and such, or wildcarding, that's fine, but that doesn't really affect > the model. > > The model is something like Key + Permission -> State. Where Key > consists of one or more variables that are obtained in some manner and > which depend on the Permission. E.g., origin, maybe a session > identifier, a user-agent-defined bit, etc. Again, for storage that'd > just be origin. > > > > With that said, I think there is general consensus that changes to the > state > > of a permission which are triggered by a website (e.g. through request(), > > revoke(), getUserMedia(), etc.) should only impact the permission state > for > > the current origin and not more broadly. I think we can probably describe > > this constraint in the spec without needing to formulate a detailed > model. > > That is all the model needs to account for really since everything > else is UX and largely outside the scope of standards. Web standards > only deal in what is observable by the web. > > > -- > https://annevankesteren.nl/ >Received on Wednesday, 17 August 2016 01:56:17 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:21 UTC