make cross-site information accessible

[fcurti]

I need to share informations on several domains.

I have to accomplish, for example, the following use case

A login web page (a.login) write a cookie with some informations. Some information needs to be retrieved on other properties ( a.myproperties, b.myproperties) where user navigates.

In login web page and other properties I can inject javascript (obviously).

I'm asking which is the best strategy to achieve this using the shared storage API.

[pythagoraskitty]

When you say:

Some information needs to be retrieved on other properties ( a.myproperties, b.myproperties) where user navigates.

Can you be a little more specific about what kind of information retrieval you will need?

Keep in mind that it's easy to write to shared storage, but there are intentional restrictions on reading from shared storage. Currently, there are two output gates: private aggregation reports and URL selection.

If I get a better sense of what kind of information you are planning to retrieve and/or how you are hoping to use it, I might be able to provide better suggestions of how to accomplish your task.

[fcurti]

@pythagoraskitty for example we need to retrieve the user PPID.

During user login on a.login the login service creates a cookie with ppid. We need to read this ppid on other properties, for example a.myproperties1, b.myproperties2 and so on.

In this time we are using a 3rd party request to save the ppid as a cookie on a single remote domain (shared.domain) As well we are using a 3rd party request on shared.domain to read the ppid and save the ppid in a cookie on domains where user navigates.

[b-hatley]

Hi @pythagoraskitty, our company (Flashtalking) is also seeing the same issue, causing a major bump in our road to integrating with PS APIs. Below is an overview of our challenge:

As a creative ad server, we need to serve creatives from a CDN (cdn.flashtalking.com). At the same time, we also need the ability to read data in Shared Storage we previously set on the browser to personalize the creative during the ad request.

Currently, we are unable to complete this because our ad server engine, which is responsible for writing to Shared Storage and decisioning on the data within, runs on a secondary sub-domain (servedby.flashtalking.com).

Example flow:

• User 123 visit Advertiser A’s site and looks at shoes.
• Flashtalking sets "shoes" segment in Shared Storage with servedby.flashtalking.com
• Flashtalking receives an ad request from Publisher XYZ for Advertiser A from User 123’s browser
• Our ad request is fired from cdn.flashtalking.com, which is where our tag+worklet Javascript resides.
• We are unable to read the segments in User 123’s Shared Storage, as they were written by servedby.flashtalking.com

We understand this limitation follows the web standard definition of same origin, but it is in direct contrast to how 3rd party cookies behave today, and thus breaks a critical path for tech vendors to gain access to Shared Storage data.

[jkarlin]

Thanks for the description @b-hatley . Is there any chance you can host your worklet script on servedby.flashtalking.com but leave the rest of the creative assets on cdn.flashtalking,com? That should solve your problem.

Meanwhile, we're discussing what it might look like for one shared storage origin to declare that it's okay for a worklet from a different origin to read its storage. It'd require opt-in from both origins.

[michaelgulak-ft]

Hi @jkarlin. Given how we will need to interface with the worklet and our established architecture, we are not able to host the worklet script on our ad server (servedby.flashtalking.com).

Would the opt-in be a one-time operation for each domain, similar to the attestations we've completed in the enrollment process?

[jkarlin]

How the opt-in might work is still TBD. One possibility is making it part of enrollment. Another is to store the data in a .well-known file on servedby.flashtalking.com that only gets fetched infrequently (e.g., when the browser doesn't have the response cached locally).