Backup the client ID in local storage

[dvoytenko]

It looks like we're using a client side cookie for a CID we create on the origin site. It appears that the client-side cookie is fragile and could be removed after 24 hours. Since the intention of client ID is to last longer than that, we could back it up by the local storage. Here's the related thread of cookie-vs-localstorage, which clarifies that the local storage is a more appropriate storage mechanism in some cases.

[zhouyx]

The 24 hours limit was introduced by ITP2.2

I'm not sure about switching to local storage though due to a few reasons

1. local storage doesn't have an expiration date which could be an issue when storing user id
2. Safari also put 7 days cap on local storage. The help here is limited
3. Analytics vendors may rely on the cookie value on the origin site, non AMP pages. Switching to local storage would require analytics vendors to change their tagging script as well.

[kushal]

Re (2) , the stated policy is 7 days without a visit, so for a site a user uses frequently it should be a big improvement?

[dvoytenko]

@zhouyx I was wondering if this worked not as an alternative, but just as a backup. E.g. getCookie() || localStorage.get(). In theory, we could always set the cookie back when backup is available. IMHO the distinction between a cookie and the local storage seems very arbitrary to me from the point of view of that spec.

[zhouyx]

AMP also update the cookie expiration time on user revisit if the value is created by AMP (with amp- prefix). But I agree the value is much more likely to persist with a 7 days window compared to 1 day.

I can see us using localStorage as an opt-in backup method on non proxy origin with individual analytics vendor opt-in.

[dvoytenko]

Wouldn't any analytics vendor want to have the right data?

[zhouyx]

: ) Not sure about that.
cc @avimehta @zikas @cory-work @joshschwartz for feedback. Thanks

[joshschwartz]

Thanks for looping me in. I agree that analytics would benefit from using localstorage as a backup, and we'd definitely change our code to accommodate it were the option available.

[cory-work]

I like this strategy

[dvoytenko]

@zhouyx Should we take this to the design review?

[zhouyx]

Looks like a well received feature : ) Definitely! Let me work on the design proposal. I think all we need is to provide the current CLIENT_ID API an additional opt-in param.

[avimehta]

an additional opt-in param works from gtag/googleanalytics perspective. Would need to go through a review before starting the use of localstorage.

[kushal]

Fwiw we're receiving a growing number of user complaints about getting logged out frequently. Please let us know if we can help accelerate a fix.

[zhouyx]

Here's the proposed design

CLIENT_ID(scope, opt_userNotificationId, opt_cookieName, opt_storageName).

When the opt_storageName is defined and when the AMP doc is served from origin, AMP will use the value from the local storage entry as back up, and also write the value from localStorage to opt_cookieName

AMP will write the client id value to provided storage entry name in the following cases

1. client id value from opt_cookieName is retrieved by the CLIENT_ID API and is an AMP created id starts with amp-
2. When AMP first creates the client id

Open question: Since localStorage value never expire, does AMP needs to clean up expired cid value.

[joshschwartz]

I think that AMP should ideally clean up expired values. When analytics companies (at least us) talk about cookie expiration policies, we generally think we're guaranteeing a user that we won't persist their ID for longer than N days. If the ID is persisting in local storage as a backup for longer, that violates the spirit of that policy, albeit not the letter of a cookie expiration policy.

[kushal]

Could AMP limit the use of localstorage to platforms known to limit the duration of LocalStorage?

…

On Thu, Aug 13, 2020 at 3:38 PM Josh Schwartz ***@***.***> wrote: I think that AMP should ideally clean up expired values. When analytics companies (at least us) talk about cookie expiration policies, we generally think we're guaranteeing a user that we won't persist their ID for longer than N days. If the ID is persisting in local storage as a backup for longer, that violates the spirit of that policy, albeit not the letter of a cookie expiration policy. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2XNH2Z4G4MZOIV2HMUCDSARTMTANCNFSM4PGG7FAA> .

[zhouyx]

I agree, AMP should clean up expired value in localStorage. I see the AMP created CID cookie has an expiration time of 1 year, wonder if we can put the same expiration time to CID backup in localStorage.
@lannka Could you confirm that 1 year expiration time is always the case?

[dvoytenko]

@zhouyx expiration aside, I'm still wondering why we want an API change. I see this more of a "preserving the existing" API feature.

[zhouyx]

I prefer opt-in for two reasons

1. To keep the behavior the same when navigating to a non AMP page vs an AMP page. When a vendor opt in to use localStorage they should have done the same to their non AMP solution.
2. To assign the storage name. So when the CID is not created by AMP, AMP still knows where to retrieve it. Vice versa.

[dvoytenko]

To assign the storage name. So when the CID is not created by AMP, AMP still knows where to retrieve it. Vice versa.

Can we at least default the name to the opt_cookieName?

To keep the behavior the same when navigating to a non AMP page vs an AMP page. When a vendor opt in to use localStorage they should have done the same to their non AMP solution.

I'm not sure this is a critical part, tbh, if we were to restore a cookie from the local storage's "backup" - things would be fairly transparent then.

[zhouyx]

Using opt_cookieName would work!

I'm not sure this is a critical part, tbh, if we were to restore a cookie from the local storage's "backup" - things would be fairly transparent then.

True. @avimehta @zikas @cory-work @joshschwartz What's your thought here? Is opt-in required or preferred? Or can AMP store/retrieve CID value from storage by default as an internal implementation detail? Thanks

[kushal]

Bump. FWIW, agree with @dvoytenko that if services want to match this behavior on the non-AMP side, that's easily done, no need for AMP to worry about it.

[dvoytenko]

Bump as well.

[zhouyx]

@micajuine-ho is working on the design. We'll bring the topic to the next design review.

Meanwhile, feedback I get is: Is fine for AMP to set the default behavior to opt-in or opt-out, but it is preferred to have a way to disable the feature.

[micajuine-ho]

Hi all, here is the design doc for this feature: https://docs.google.com/document/d/1INLsmzjgj_ehCXW2kadq_mU1WcWgydpxof9abXqsdik/edit?usp=sharing

I will be taking this to design review on Wednesday. Please feel free to join the conversation at that time, or here on this thread.