Thanks for the piece about StoragePrincipal. I think that motivates this well for me. Changing principal is not something we can do trivially (or not something we should even contemplate ideally).
I do want to pick out one comment you made, which is probably off-topic for the thread, but I think important in this context. I'm happy to discuss more separately if you think I'm taking this too far afield. On Fri, Jan 25, 2019 at 12:23 AM Andrea Marchesini <amarches...@mozilla.com> wrote: > We should not treat the cookie policy as a normal permission setting. > I want to challenge this, because I think that our posture toward storage might set a pattern for how we deal with other things as well. The question here is what sort of special treatment we give to storage/cookie access. There are two aspects I think that you are concerned with: hiding what we are doing from pages, and the whole discussion we're having on this thread. 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. 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
