Approvals for risky org-managed settings are now remembered per organization, so you get re-prompted far less.
What's wrong with this entry?
When your organization ships managed settings, consent to the dangerous ones can now be recorded against the org rather than only against the local payload you saw. Consent is stored in a new remote-settings-consent.json, capped at 20 organizations and rewritten at most once a day per org, and you are not re-prompted while the org record's hash of the dangerous settings still matches.
- Requests now carry the organization and account ids so the response can identify which org the consent belongs to.
- Without an org record, the previous behaviour applies: the locally consented payload is compared directly.
- Consent is not recorded if the signed-in identity changed part-way through the fetch.
- A login or logout during a fetch discards that fetch's result, reported as
reset_during_fetch.
Remote settings: Cache was reset (login/logout) during this fetch; discarding its result, remote-settings-consent.json
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.236
Managed-settings review prompt dropped from the main UI
Both mention managed
-
v2.1.242
Startup can wait on a remote managed-settings refresh, with a deadline
Both mention managed
-
v2.1.246
Remote managed settings can defer their consent prompt to the next interactive session
Both mention managed