Skip to content

consider setting StorageKey on environment explicitly #142

Open
@wanderview

Description

@wanderview

Currently various attributes are stored on the environment and environment settings object and then a StorageKey is computed from those values. This works today when StorageKey only consists of origin. It also will be relatively easy to add the top-level site to StorageKey.

In chromium, though, we have a couple of additional values in StorageKey. We include the ancestor-chain-bit and a possible nonce for anonymous iframes. The current properties on environment don't allow us to compute these values.

So, we could add ACB and nonce to the environment so we can compute the StorageKey. That feels a bit awkward, though, for things like the nonce. Its literally "storage key nonce" and not a nonce for anything else.

Should we instead consider setting a StorageKey on environment when its created?

Sometimes this will be computed and sometimes it will be inherited from the context initiating the creation of the environment. This would seem a more natural way to propagate things like nonce to me.

Also, this approach would seem to more naturally make it easier to extend StorageKey in the future. There are less places to fix since we don't have to deconstruct the StorageKey to assign each thing as a separate property on environment just to reconstruct it again later.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions