During our meeting today Gray proposed three possible approaches to implementing this: 1. Use the new pairwise remote settings list to generate temporary storage access permission (reusing the same permission we currently use) 2. Use the new pairwise remote settings list to generate a new type of storage access permission (NOT reusing the same permission we currently have) 3. Check the list directly at the same time we check the current storage access permissions. This is similar to what we do for the `url-classifier-skip-urls` remote settings collection. IMO which direction we go depends on whether we'd want these exceptions to be included in the UI as part of the work we're doing in Bug 1643191 Comment 6. If we want the exceptions in the UI then it seems like (1) is the right option. In the user's eyes, the exceptions granted by this mechanism are no different than those granted by the Storage Access API or a web compatibility heuristic. We wouldn't want users to have to manage them separately. There's a lot of complexity here though: * If a user attempts to delete any permission granted by the blocklist it would pop back up during the next session. A sort of "zombie" permission. * We can consider implementing an "Allow/Block" mechanism instead, and refuse to re-create a permission from the list when the user has manually toggled it to "Block" in the past. Perhaps the Storage Access API could still override this. * We'd like the mechanism to be specific to partitioning, but adding a storage access permission would exempt the third party from ETP's cookie blocking as well (maybe that's acceptable). * We don't have such a UI mechanism for `url-classifer-skip-urls` or the various skipUrl prefs. These ETP allowlist mechanisms would override whatever choices the user has made in the UI (e.g., if the user says to "Block" a certain third party from getting permission again in the future). If we don't want exemptions in the UI, then (3) seems preferable unless there are other implementation / performance concerns we didn't get to discuss during our meeting. The downside of (2) is that the permission would be sticky. We wouldn't be able to _remove_ it if the list changes and would have to wait for it to expire. It's not clear to me what the lifetime would be? If these are session-bound and could survive a session restore than this would be pretty bad. We could implement some kind of diffing method to mitigate this. Given the complexities above, I think it's better to not try to display these as part of the new UI. Like the ETP exemptions, we don't want these to stay around forever and should use them sparingly as we fix breakage.
Bug 1642051 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
During our meeting today Gray proposed three possible approaches to implementing this: 1. Use the new pairwise remote settings list to generate temporary storage access permission (reusing the same permission we currently use) 2. Use the new pairwise remote settings list to generate a new type of storage access permission (NOT reusing the same permission we currently have) 3. Check the list directly at the same time we check the current storage access permissions. This is similar to what we do for the `url-classifier-skip-urls` remote settings collection. IMO which direction we go depends on whether we'd want these exceptions to be included in the UI as part of the work we're doing in Bug 1643191 Comment 6. If we want the exceptions in the UI then it seems like (1) is the right option. In the user's eyes, the exceptions granted by this mechanism are no different than those granted by the Storage Access API or a web compatibility heuristic. We wouldn't want users to have to manage them separately. There's a lot of complexity here though: * If a user attempts to delete any permission granted by this allowlist it would pop back up during the next session. A sort of "zombie" permission. * We can consider implementing an "Allow/Block" mechanism instead, and refuse to re-create a permission from the list when the user has manually toggled it to "Block" in the past. Perhaps the Storage Access API could still override this. * We'd like the mechanism to be specific to partitioning, but adding a storage access permission would exempt the third party from ETP's cookie blocking as well (maybe that's acceptable). * We don't have such a UI mechanism for `url-classifer-skip-urls` or the various skipUrl prefs. These ETP allowlist mechanisms would override whatever choices the user has made in the UI (e.g., if the user says to "Block" a certain third party from getting permission again in the future). If we don't want exemptions in the UI, then (3) seems preferable unless there are other implementation / performance concerns we didn't get to discuss during our meeting. The downside of (2) is that the permission would be sticky. We wouldn't be able to _remove_ it if the list changes and would have to wait for it to expire. It's not clear to me what the lifetime would be? If these are session-bound and could survive a session restore than this would be pretty bad. We could implement some kind of diffing method to mitigate this. Given the complexities above, I think it's better to not try to display these as part of the new UI. Like the ETP exemptions, we don't want these to stay around forever and should use them sparingly as we fix breakage.