On Thu, Jan 24, 2019 at 5:34 PM Martin Thomson <m...@mozilla.com> wrote:
> There are two reasons I can see why we might consider access to storage to > require "hiding" of some sort. > > The first is that we want to make sure that pages that were built with an > expectation of access to persistent storage, continue to work more or less > as they did before. We don't want them to be able to track people, but we > don't want them to suddenly catch fire. In that light, we're not really > hiding the fact that we are compartmentalizing persisted data, we're just > ensuring that those pages aren't surprised by errors. > > The second possibility is that we might want to be able to present a fake > environment to trackers that mimics a real one, but is limited. That is, > they might think that they are operating in an unconstrained iframe, but > they really aren't. > > I think that the fact that you can query with document.hasStorageAccess > puts us firmly in the first bucket. While we might present a somewhat > functional API, we're only doing that to avoid bustage for old documents, > and we're not trying to hide the fact that we're blocking their ability to > track. From that perspective, having this modelled as a permission (and > even allowing permission.query() to work) is probably OK. > Note that hasStorageAccess() doesn't reveal whether you have "storage" access, rather it reveals whether you have "storage access". The difference is very subtle, but here "storage access" means the thing that you gain if you'd called requestStorageAccess() before, or if the browser determines that you're eligible to receive the kind of access that function is capable of granting you. That is effectively a subversion of our soon-to-be-default cookie policy for third-party trackers for web compatibility, not "storage" access in the sense you're referring to here. But anyways, there is navigator.cookieEnabled which reveals the kind of storage access I think you're alluding to here, so the rest of your point is still valid. :-) > So this is really about the dynamism aspects of this. Clearly, building a > system where you can switch out the fake storage with the real one > dynamically is hard. The surface area is surprisingly big and the changes > are pervasive. That's infeasible. But I think that rather than saying > that permissions are a poor fit, I think that it would pay to think more > about how maybe we might fix this in permissions. Because I think that > this is something that works with permissions in many other respects - it's > something that we might want to bake into feature policy for instance. > > When we talked about permissions recently, we concluded that there were > some aspects of the .query() API that didn't properly reflect the range of > policies that might apply. For instance, permission for some actions is > conditional on an engagement gesture (a click or key press). Here I think > that we might have a new condition: the permission is conditional on the > page being refreshed. Now, I concede that perhaps this is too ambitious > and in the absence of other cases that share this constraint this might be > overgeneralizing, but I think that this fits reasonably well. > I think the reason why Andrea said permissions are a poor fit here is the dynamism aspect. For example, web pages aren't typically written with the expectation that localStorage/indexedDB methods will throw until a permission is granted out of band, or they start throwing when a permission is revoked. Our current behaviour which is exactly that will cause pages to break when the user does something to change permissions while there are live documents around. I don't think the problem is really about whether Permissions.query() is a good fit to query this type of permission. -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
