I wonder, has the subject of double-keying been raised in this context? It comes up frequently in this context. And when I say double-keying, I mean forming a key from the tuple of the requesting principal and the top level browsing context principal (though origin may suffice).
If there are disruptive changes afoot, then segregating based on what is shown to the user might be sensible. On Tue, Jun 30, 2015 at 3:04 PM, Jonas Sicking <jo...@sicking.cc> wrote: > There are actually one downside with this change. > > It means that if a user denies access to https://website.com to use > cookies, then http://website.com will still have full ability to use > cookies since it's a different origin. > > For a DENY policy it often makes more sense to deny a whole domain > name, since more often than not the http and https website are run by > the same people. > > Whereas for an ACCEPT policy, it very often makes more sense to only > allow a given origin. > > The problem stems from that the permission manager doesn't store > policies, but rather stores unformatted data that is then up to the > *reader* to interpret as a policy. > > I.e. right now you just call > pm.add(<https://website.com>, "camera", ALLOW); > > It is then up to the reader to interpret this as either "camera is > available only for https://website.com"; or "camera is available for > https://website.com and any subdomain". This is decided by either > calling testPermission or testExactPermission. > > Most developers do not know about this difference and so I have > uncountably many times had to tell people to use testExactPermission > to get desired behavior. Obviously this is extra bad because > testPermission is the function people jump most immediately to due to > its simpler name. > > What I think the permission manager really needs to do is to have an API like: > > pm.addOriginRule(<https://website.com>, "camera", PROMPT); > pm.addDomainRule("domain.com", "cookies", DENY, INCLUDE_SUBDOMAINS | > OVERRIDE_EXISTING); > pm.testPermission(myprincipal, "geolocation"); > > / Jonas > > > On Tue, Jun 30, 2015 at 11:58 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: >> Historically our permissions database has used host names as part of the >> permission entry, which means that if we stored a permission for >> http://example.com, it would also apply to https://example.com (and >> http://example.com:8080 for that matter). This is undesirable specially >> once you note that this potentially makes us store permissions for MITMed >> connections and later on use them even for secure origins. >> >> Michael has been working on fixing this over in bug 1165263. We expect to >> land this change within the Firefox 42 timeframe. Here is the details of >> the changes we are planning to make: >> >> 1. Instead of storing a host name, appId and isInBrowserElement flag for >> each entry, we will store the full origin (including the origin attributes.) >> 2. Fix up the places where the permission manager APIs expose the notion of >> host/appId/isInBrowserElement to the consumers. >> 3. Drop the "<file>" hack from the permissions manager (bug 817007.) >> >> We're going to use the following algorithm for migrating the existing >> permission entries: >> >> * If the entry takes the form of a valid URI (such as entries for file:// >> URIs), then just insert it directly >> * For each host name foo, check to see whether the Places database >> includes a visit to that domain or any subdomain. >> * For each found entry in the Places database, we inject a permission for >> the visited origin, with the appId and isInBrowserElement origin attributes >> from the original permission. >> * If there are no existing visited entries, inject one permission for >> http://foo, and one for https://foo. >> >> The interesting part of how the migration step works is that we have no >> good way to know what origins need the permission after the upgrade by just >> looking at the host name, so we try to find something in the Places >> database that would help answer this question, and at the lack of that, we >> assume that the two common origins that can be constructed from the host >> name (namely the http and https origins with the default ports) can have >> the permission, which is our best guess. This means that in some edge >> cases such as the user having a foo.com permission that belongs to an >> origin such as http://foo.com:8080 but not having visited foo.com recently >> (by default in the last 180 days) we will lose the stored permission. We >> hope that these edge cases will happen very rarely in practice. >> >> Please let me know if you have any questions or concerns. >> >> Cheers, >> -- >> Ehsan >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
