T

mkarolin 34e8d0f2f7 Content Settings updated to Utilize Time/Scope Restrictions.

Chromium change:

https://chromium.googlesource.com/chromium/src/+/f62a1294a4b54626abf1275e47057e5564a7bb3a

commit f62a1294a4b54626abf1275e47057e5564a7bb3a
Author: Brandon Maslen <brandm@microsoft.com>
Date:   Wed Apr 29 07:37:10 2020 +0000

    Update Content Settings to Utilize Time/Scope Restrictions to Get/Set Settings.

    Currently all content/website settings are not bounded or scoped aside
    from possibly being ephemeral and held in memory only. In order to
    support scenarios for the Storage Access API and future permission
    time-boxing efforts the concept of scoping settings is needed.

    This change introduces the notion of a ContentSettingConstraints struct
    that can be optionally provided when setting a content or website
    setting. The constraint consists of an optional base::Time to
    specify the expiration that a setting should use,as well as a
    SessionModel to specify the lifetime model of the setting.

    The following initial SessionModel have been specified; however, future
    options such as TabOnly may be added to accommodate permissions scoping:
    Durable:     Settings persist forever and are bounded only by an expiry
                 date, if set. Will be persisted to disk to survive session
                 restarts.
    UserSession: Settings will persist no longer than a user session
                 regardless of expiry date, if set.

    All types of scopes may be constrained by an upper bound duration. This
    allows settings to expire after a set period of time has passed.

    The majority of this new behaviour is contained within the
    HostContentSettingsMap and associated Providers and supporting classes.
    New constraint parameters have been added as optional to setters and
    unless opted in by new callers will behave as they did prior to this
    change. The getters have been updated so that a direct retrieval of
    a setting will only return a value if a currently un-expired setting
    exists. If an array of values is retrieved for future use like with
    GetSettingsForOneType the expiry date and convenience method
    IsExpired() have been added to ensure consumers can accurately
    determine if a setting is relevant.

    In order to cleanup expired Durable entries we will validate the
    expiration time on entries, if set, when we read our settings from
    prefs. If present any expired entries will be cleaned up at this time.

    New test cases have been added to validate the HCSM behaviour changes
    as well as the PrefProvider and supporting classes.

    In addition to this the first consumer of these changes has been added
    in the Storage Access API permissions context code. This ensures that
    the API can both set either a UserSession or Durable grant with an
    associated duration as well as determine the number of existing grants
    that are UserSession only as required.

    Bug: 989663

2020-07-01 18:12:02 -04:00