“Trial for Disable Third-party Storage Partitioning” not working for our solutions

[CarlosAccedemeTrials]

Our project consists of adding a plugin/widget, that adds accessibility options, to any web page. We want to ensure continuity of user experience transmitting the visitor's accessibility selections from one site/web page to another where our widget is also located. We achieve this by injecting an iframe with a common domain (https://iframe.access-me.software). We store the visitor's selections in the browser's Local Storage in this common domain. Due to the new storage partitioning policy we can no longer access that data among different web pages and therefore we have stopped providing the service we want. None of the stored data is sensitive, it is not personal data, it is only technical data to achieve a navigation as the visitor has chosen.

We are working on updating our system with the new way with the upcoming solutions. In the meanwhile we want our customers to work as we used to do, without partitioned local storage. To achieve this, we first tried disabling the flag “Third-party Storage Partitioning” in Chrome browser.

With this flag disabled the behaviour is the expected, because when we load a web page that includes our widget, the local storage of the widget’s domain doesn’t appear as a third-party, and all the adjustments are shared through all the pages with our widget loaded.

Due to this success, we registered to the “Trial for DisableThirdPartyStoragePartitioning” for the origin “https://iframe.access-me.software”, checked the “Third-party matching. The token will be injected by script on other origins” check box, got a Token and provide it via external JavaScript file to our production environment.

Once the token is decoded using the tool provided in https://ot-decode.glitch.me/, the information inside the token is:

// Expiry date: Wed Sep 04 2024 01:59:59 GMT+0200 (Central European Summer Time) { "payload": { "origin": "https://iframe.access-me.software:443", "feature": "DisableThirdPartyStoragePartitioning", "expiry": 1725407999, "isThirdParty": true }, "version": 3, "length": 139, "signature": { "0": 190, "1": 148, "2": 65, "3": 7, "4": 181, "5": 147, "6": 64, "7": 141, "8": 247, "9": 159, "10": 173, "11": 180, "12": 63, "13": 252, "14": 121, "15": 136, "16": 166, "17": 158, "18": 9, "19": 146, "20": 93, "21": 200, "22.........

In production environment, with the flag “Third-party Storage Partitioning” in “Default” position in Chrome we went to several pages that load our widget and checked that the Token was loaded in the “meta” tag in the head of the iframe DOM and enabled in the “Aplication” tab in the developer console.

But even though the Token is enabled and recognized by the browser, the local storage of our widget’s domain appears as third-party, and therefore the information in the local storage is not shared among different web pages that load our widget, e.g. our domain https://accedeme.com/ and other domains, such as https://gedesprin.com https://impresionesmai.com or https://rotuleros.com/

This is not working, probably we are doing something wrong but we don't see where is our error. Or it could be an issue.

We want to know what we should do to have the same behaviour as it was before the third-party storage partitioning.

We have tried all the instructions provided in the documentation, as we show above, but it has not worked.

Please advise us how to go ahead with this feature.

Thanks.

[miketaylr]

Thanks for the issue. One thing to be aware of - the deprecation trial is expiring in short order. It will be valid for users on Chrome 111 to 126, and then stop working entirely on September 3rd (or before that, as users upgrade to 127). As of right now, 127 is scheduled to be released on July 23rd.

One question: I see you have https://iframe.access-me.software/accss_me/test_trial.js to inject the token (I'm looking at https://gedesprin.com/). Does that happen before your iframe is created?

[CarlosAccedemeTrials]

Hi Mike,

Thanks for your quick reply.

We are aware about scheduled expiring events, but need, in the meantime, to have our tool working as usual.

In the hosting webpage, in this case https://gedesprin.com, we load a js ( ..../accssmetool.js) and once finished his task we delete it, this js creates the iframe who has as source https://iframe.access-me.software/....html. This HTML loads a js which imports this test_trial.js. This final js is the one who injects the meta with the token INSIDE the iframe source DOM.

Once said this, I really don't understand your question because I can't load a js inside an iframe before loading this iframe, isn't it?

But as a consequence of your question I think what you are trying to say is we have to load the meta tag with the token in the hosting web page, in this case https://gedesprin.com, but we have also done this as explained in the issue text and didn't worked.

So, we are ready for more questions.

El vie, 10 may 2024 a las 22:56, Mike Taylor @.***>) escribió:

Thanks for the issue. One thing to be aware of - the deprecation trial is expiring in short order. It will be valid for users on Chrome 111 to 126, and then stop working entirely on September 3rd (or before that, as users upgrade to 127). As of right now, 127 is scheduled to be released on July 23rd.

One question: I see you have https://iframe.access-me.software/accss_me/test_trial.js to inject the token (I'm looking at https://gedesprin.com/). Does that happen before your iframe is created?

— Reply to this email directly, view it on GitHub https://github.com/miketaylr/partitioned-storage-deprecation-trial-feedback/issues/15#issuecomment-2105260884, or unsubscribe https://github.com/notifications/unsubscribe-auth/BIMXHAMTDOKHZW7DSDL76GDZBUYABAVCNFSM6AAAAABHQ5NPMOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGI3DAOBYGQ . You are receiving this because you authored the thread.Message ID: <miketaylr/partitioned-storage-deprecation-trial-feedback/issues/15/2105260884 @github.com>

--

[miketaylr]

I think you're misunderstanding my question - sorry if it was confusing.

Once said this, I really don't understand your question because I can't load a js inside an iframe before loading this iframe, isn't it?

From the blog post:

The DisableThirdPartyStoragePartitioning deprecation trial does support the third-party origin trials feature, but the third-party script injecting the token must be evaluated in the top-level frame before the third-party iframe that won't have partitioning applied is loaded.

gedesprin.com will need to load a script from https://iframe.access-me.software that injects the Origin Trial meta tag in the top-level gedesprin.com site before the iframe pointing to https://iframe.access-me.software/whatever.html is created.

Something like so, which would be at https://iframe.access-me.software/ot.js loaded by gedesprin.com:

//step 1, add the OT token to the top-level site
const meta = document.createElement("meta");
meta.content = "<valid origin trial token here>";
document.head.append(meta);

// step 2, add your cool cross-site iframe to the DOM
const iframe = document.createElement("iframe");
const coolPage = "https://iframe.access-me.software/whatever.html";
iframe.src = coolPage;
document.body.appendChild(iframe);

[CarlosAccedemeTrials]

Hi Mike,

I'm so glad!!!! It's working. Thanks Mike.

You are right, I find the Blog Spot confusing, it doesn't says what you pointed out. So without your explanation it would be impossible to solve this issue.

What I did is to add the origin-trial token in the top-level site loading a JavaScript placed on the top-level site (in my case https://gedesprin.com) pointing to a js in the iframe domain (in my case in https://iframe.access-me.software/thetokenscript.js) injecting the origin-trial meta tag with the token,

Inside the iframe, I also loaded the same token as in the top-level. In my case I used the same script (thetokenscript.js) for obvious reasons.

And started to work.

I have a case where my customer's site already has other origin-trial tokens, I imagine for other trials.... In this site it doesn't works our system.

You can test this changing a Accessibility Adjustment (like Readable font) in https://gedesprin.com, seeing that it works because when you load another domain with our Accessibility Widget (like https://impresionesmai.com or https://rotuleros.com) in another tab the font changes to what is in Gedesprin, even if it is in another Chrome window. But in https://sonrisalud.es not. If you check the DOM you will see other origin-trials.

Is this the expected behaviour?

[miketaylr]

Different origin trials shouldn't affect the outcome of this one, so I'm not sure it's expected behavior. Can you verify that the token you're injecting is correct?

[CarlosAccedemeTrials]

The answer is yes, in fact it's the same as all other. All load in the same way the same js's. And of course all other behaves as expected. You can check this easily.

This was my initial thought but after a minimal investigation I can see in gedesprin.com Local storage like before Third-party Storage Partitioning but in sonrisalud.es shows "origin is outside of the top level site". The token is the same, so I'm guessing the reason is another token, but this is just imagination....:-)

[miketaylr]

Just to confirm, the DT is working for all sites except sonrisalud.es?

[CarlosAccedemeTrials]

NO, All is always too big :-)

In general is working fine, but I found, in a deeper investigation, some other sites where the DT (I guess this means Trial for Disable Third-party Storage Partitioning) doesn't works.

Here you have a list with some of them:

• https://fideshome.com
• https://luisveraoposiciones.com
• https://psicoabaco.es

and guess what?. All of them have another origin-trial meta tag. I can't guess for what are these tokens, hope you can.

[miketaylr]

What you can do: take the origin trial token and run it through https://glitch.com/~ot-decode to find out what it is, then report back here.

[CarlosAccedemeTrials]

In sonrisalud.es and luisveraoposiciones.es the other origin trial token is for "google.com:443". But psicoabaco.es has changed and in this moment doesn't has another token.

I really don't know why our token is not working in these websites.

[arichiv]

Unfortunately I have a repro here: https://sp-dt-demo.glitch.me/

I'll look into a patch, might be able to get it into M126 which just had a branch cut

[colts227]

why dont you stop problem at the core ? i mean i am glad it was way to hell just saying

[miketaylr]

In sonrisalud.es and luisveraoposiciones.es the other origin trial token is for "google.com:443". But psicoabaco.es has changed and in this moment doesn't has another token.

I really don't know why our token is not working in these websites.

Thanks for the report - it is indeed a bug. You can follow along at https://issues.chromium.org/u/1/issues/340594921 for the fix - there's a chance it can be shipped in Chrome 126.

But otherwise, I think we can close out this thread since the OT is working for your other sites (except where it's not... 😢).