We do clearStoragsForPrincipal based on the result from listOrigin, so it's fine
to not clear all stroages that match the prefix here. Also, since the passing
principals can contain origin attributes which is not allowed to be used with
aClearAll.
Differential Revision: https://phabricator.services.mozilla.com/D73417
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
The idea of this patch is to try to not use oberver mechanism as possible. To
achieve that, it introduces deleteByOriginAttributes() to cleaners. Different
from other methods, it would only be executed if it's implemented from a
cleaner.
It doesn't remove oberver mechanism entirely since some cleaners are still using
that for other deleteByXXX() functions. So, it only applies removing stuff to
PushService, QuotaManagerService, ServiceWorkerManager, nsPermissionManager,
nsApplicationCacheService, and nsCookieService.
Since the original issue is related to QuotaManagerService, it adds xpcshell
test under the dom/quota/test/unit/ to ensure the behavior won't be changed
accidentally in the future.
Differential Revision: https://phabricator.services.mozilla.com/D33758
--HG--
extra : moz-landing-system : lando
* storage-mozStorage was used by Fenenc but that is no longer built from m-c.
* Existing Android tests need to be disabled since they rely on being able to manipulate storage but this commit only stubs searching for logins.
* A later commit will actually filter the logins returned by a GV delegate.
Differential Revision: https://phabricator.services.mozilla.com/D54139
--HG--
rename : toolkit/components/passwordmgr/storage-json.js => toolkit/components/passwordmgr/storage-geckoview.js
extra : moz-landing-system : lando
This will change RemoveCookiesFromRootDomain to not remove cookies from all sub-domains but instead
only remove the single host that is passed. This is necessary to support removing all sub-domain
cookie data in ForgetAboutSite without compromising on the cookie permissions that are supported by
Sanitizer.jsm
As a side effect, this also fixes the issues described in https://bugzilla.mozilla.org/show_bug.cgi?id=1515913#c24
(which were caused by deleting sub-domains without checking their permission).
Sanitizer.jsm should retain its functionality even with this change, because it already collects
all the principals we have to delete individually and tries to delete them (so it would consider
mozilla.org and support.mozilla.org separately).
Differential Revision: https://phabricator.services.mozilla.com/D45012
--HG--
extra : moz-landing-system : lando
As originally implemented, nsISiteSecurityService.removeState allowed direct
access to remove HSTS state. It also provided the implementation for when the
browser encountered an HSTS header with "max-age=0". In bug 775370, it was
updated to store an entry that would override preloaded information when
processing such headers. However, this meant that the semantics of the direct
access API had changed. Preloaded information could be overridden if a user
invoked the "forget about this site" feature. This change fixes the public API
(and renames it to "resetState") so it actually behaves as its consumers expect.
Reviewers: jcj!, KevinJacobs!
Tags: #secure-revision
Bug #: 1564481
Differential Revision: https://phabricator.services.mozilla.com/D38108
--HG--
extra : rebase_source : 8dd5460d3fd3c0ce92746cc83fae220d6e2a83cf
extra : amend_source : 171ebb015e9f9ae775f0caa22e161d41970f3d51
Protocols, likes about:, moz-extension, ... etc, don't have a host. Thus, an
exception will be returned if they are accessed. To avoid from that, this patch
catches this bug a try-catch.
Differential Revision: https://phabricator.services.mozilla.com/D29821
--HG--
extra : moz-landing-system : lando
