Historically our permissions database has used host names as part of the
permission entry, which means that if we stored a permission for
, it would also apply to https://example.com
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
* 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
, 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
(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.