make cross-site information accessible #127
Comments
|
When you say:
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. |
|
@pythagoraskitty During user login on a.login the login service creates a cookie with ppid. In this time we are using a 3rd party request to save the ppid as a cookie on a single remote domain (shared.domain) |
|
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:
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. |
|
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. |
|
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? |
|
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). |
…orklet` Currently, `addModule` only allows same-origin script. This was for convenience of the initial implementation, however, and is no longer necessary. The [worklet standard](https://html.spec.whatwg.org/multipage/worklets.html#dom-worklet-addmodule) does not contain this restriction. In fact, we have received [feedback](#127) from developers stating they would like to be able to host and run their worklet script on a separate origin---say a CDN---from the origin that owns and writes their shared storage data. So we update the explainer to remove the same-origin restriction for `addModule`. We also note that, when the worklet script is cross-origin to the invoking context, the invoking context's origin is used as the partition origin for accessing shared storage. Since `createWorklet` already allows cross-origin scripts, but currently uses the worklet script's origin as the data partition origin, updating `addModule` as described above without also making a change to `createWorklet` is liable to cause developer confusion in the long term. We have therefore decided to align `createWorklet`'s default data partition origin with `addModule`'s. `createWorklet` will use the invoking context's origin by default. This is a breaking change, but current usage of `createWorklet` is low as it was just introduced in M125. To preserve the ability to create a worklet whose script is cross-origin to the invoking context and then run operations on the worklet script origin's shared storage data, we introduce a new `dataOrigin` option for `createWorklet`. Passing `dataOrigin` with "script-origin" as its value will designate the worklet script origin as the partition origin for shared storage. For now, "script-origin" and "context-origin" will be the only allowed values for `dataOrigin`, when used. We’re considering adding support for separate data and script origins for `createWorklet` in the future. A corresponding specification update will follow.
|
An update on this. We've decided on the .well-known address approach and it's described now in the explainer here. We're currently targeting M133 but nothing is definite. |
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.
The text was updated successfully, but these errors were encountered: