How do you prevent domain theft from being used to gain access to Related Website Data?

[dopry]

What happens when an organization loses control of a primary domain or related domain though domain hijacking? Given the stated 2 week update window, that is a long time for exposure of session data and would be a gold mine for hackers looking to exfiltrate data.

How should domain owners handles these scenarios?

[cfredric]

Hi @dopry, I think there may be a misunderstanding here about how Related Website Sets is designed.

Related Website Sets was designed to preserve existing security boundaries on the web, including the Same-Origin Policy. As a result, no site in a RWS has access to data owned by another site in the same RWS, unless the other site actively shares that data via window.postMessage or similar.

So if one site in a set is compromised in a domain-hijacking attack, the admin's next steps would be to update all the other sites in the set to stop willingly sharing data with the compromised domain, rotate any secrets that might have previously been shared between sites, then work on regaining control over the compromised site. However, this is no different from operating multiple sites that aren't in the same RWS: if one site is compromised, the others ought to be updated to take that compromise into account and stop cooperating with the hijacked site.

So, I don't think the 2 week update window comes into question at all, if I'm understanding your concern correctly. The consequences and remediation of a domain hijacking attack do not change when RWS is in use.

Feel free to clarify your concern if I've misunderstood anything.

[dopry]

By session data, I'm talking from my perspective as a developer where cookies are part of what I would call session data, which may contain various information about a user which I wish to share among the domains of my "Related Web Set". Given a scenario where I have an internationalized site with say example.com, example.co.uk, and ejemplo.com. If someone in organization fails to renew ejemplo.com or we lose control over it for some reason, How would I prevent the cookies that were shared across my Related Web Set from continuing to be shared with ejemplo.com? If I have to revert to using Same-Origin to isolate cookies from the ejemplo.com at this juncture for the two weeks it would take to update the RWS, what is the utility of RWS? Why would I use RWS at all instead of build around the assumption that I'll be using same-origin and doing cross domain data sharing through some other means?

[cfredric]

By session data, I'm talking from my perspective as a developer where cookies are part of what I would call session data, which may contain various information about a user which I wish to share among the domains of my "Related Web Set".

Thanks, that matches my understanding.

Given a scenario where I have an internationalized site with say example.com, example.co.uk, and ejemplo.com. If someone in organization fails to renew ejemplo.com or we lose control over it for some reason, How would I prevent the cookies that were shared across my Related Web Set from continuing to be shared with ejemplo.com?

You would update your other sites (example.com and example.co.uk) so that they no longer proactively send data to ejemplo.com. There's no need to remove anything from the Related Website Set you're using, because RWS does not give ejemplo.com direct access to data on example.com or example.co.uk. The only way ejemplo.com could still access data on example.com or example.co.uk is if those sites voluntarily shared that data with the compromised site, via window.postMessage or similar. So, just remove the window.postMessage code (for example).

In other words, RWS doesn't force the sites to share their data with each other; it just gives them the option to, if the sites choose to cooperate with each other.

Why would I use RWS at all instead of build around the assumption that I'll be using same-origin and doing cross domain data sharing through some other means?

RWS is designed for the future (in Chrome) where third-party cookies are blocked by default, client-side storage is partitioned by the top-level site, etc., such that sharing data in a way that enables pervasive cross-site tracking is impossible or infeasible.

In that future, RWS is useful in cases where some sites still want to share cross-site data, but only within a small set of related sites. (Because the set is small, this data sharing would not allow pervasive tracking.) Some example uses cases for RWS are described here.

So, the "cross domain data sharing by some other means" that you mention will be impossible or infeasible in Chrome, at some point in the future. That's why you might choose to use RWS - because it may allow your use case to continue to work with minimal site updates and no added security risk.

[dopry]

So what exactly does RWS do if it doesn't allow sharing cookie across the sites? Now I'm really confused and wondering what the feature even does.

[cfredric]

So what exactly does RWS do if it doesn't allow sharing cookie across the sites?

RWS does allow sharing cookie data across sites, if both sites choose to cooperate. It currently allows this by integrating with the Storage Access API such that the browser automatically allows a site to access its own cookies when in a cross-site context if the top-level site is in the same RWS as the requesting site. Please see the RWS explainer and the Storage Access API explainer for more detail.

However, as I said above, RWS does not force the sites to share their cookie data. The sites have to explicitly opt in by 1) joining the RWS, 2) calling document.requestStorageAccess(), and 3) sending the cookie data to another site (e.g. with window.postMessage). As you can probably see, the explicit opt-ins are necessary as a security protection. RWS must not allow one site to unilaterally access cookies belonging to another site.

---

The key detail that you may be missing is that in the future, Chrome will block third-party cookies by default. So, the Storage Access API may be the only mechanism (or one of a few) by which a site can gain access to its own cookies in a cross-site context, for privacy reasons.

So if a site wants to access its cookies in a cross-site context, and it can prove to the browser that those cookies won't be used to do pervasive tracking (by restricting the cookie access to within a small set of cross-site contexts, i.e. by forming a RWS), then the browser may choose to automatically allow that cross-site cookie access. This is the choice that Chrome has made.

If the cross-site context is not restricted to within a RWS, then the browser may need to ask for the user's consent via a permission prompt, since the browser cannot prove that the cross-site cookie access won't be used for pervasive tracking. This is a more disruptive user experience, so sites most likely want to avoid showing a permission prompt unless it's absolutely necessary.

[dopry]

I am aware that chrome will block 3rd party cookies by default. I am mostly confused about how the cookie sharing works.

Related Website Sets (RWS) is a web platform mechanism, proposed within the context of browser efforts to phase out support for third-party cookies, through which site authors of multi-domain sites may declare relationships between domains such that the browser may understand the relationships and handle cookie access accordingly.

This part implies to me as the developer that if domains are in an RWS then the browser will automagically share the cookies between the sites, given consent.

To facilitate the browser's ability to handle each subset differently, we are proposing leveraging the Storage Access API (SAA) to enable cookie access within a RWS.

Is ambiguous about whether that cross domain cookie request will be handled by the RWS implementation or if as I developer I will need to explicitly try to fetch that cookie from storage.

Where is the workflow you describe with the RWS Opt-in, document.requestStorageAccess, and window.postMessage documented?

When you say

You would update your other sites (example.com and example.co.uk) so that they no longer proactively send data to ejemplo.com.

It is unclear to me what you mean by proactively send data. I can't find anything in the readme or draft spec.

As far as I can tell the only mechanism I have as a web develop working in the browser is to switch to same-site, which would break sharing and UX with non-compromised domains.

[cfredric]

This part implies to me as the developer that if domains are in an RWS then the browser will automagically share the cookies between the sites, given consent.

You're not alone in that interpretation; we've had a few people think that this feature makes cookies from one site implicitly visible to another site, which isn't our intention. If you have suggestions for how we can reword things to avoid implying that, we'd be happy to hear them.

To facilitate the browser's ability to handle each subset differently, we are proposing leveraging the Storage Access API (SAA) to enable cookie access within a RWS.

Is ambiguous about whether that cross domain cookie request will be handled by the RWS implementation or if as I developer I will need to explicitly try to fetch that cookie from storage.

The precise technical description of how RWS integrates with the Storage Access API is in the specification, specifically this section. Please refer to the Storage Access API explainer, specification, or MDN documentation to learn more about that API and how to use it.

Where is the workflow you describe with the RWS Opt-in, document.requestStorageAccess, and window.postMessage documented?

• Instructions for setting up a Related Website Set are here;
• Documentation on the Storage Access API is here.

Regarding using postMessage/etc. to send data from one site to another:

• If your application relies on sharing data between sites, then this communication is something your application is already doing.
• Otherwise, if your application doesn't need to share data (it just needs access to its own unpartitioned data), then postMessage/etc. is not needed.

So, we didn't write documentation/examples illustrating what to do with your site's cookies once you get access to them again; that's beyond the scope of the Storage Access API and this explainer. This explainer (and Storage Access API) are solely about restoring access.

However, there is documentation on the web that could help your sites communicate; I searched for "cross-site communication" and found this article, which discusses postMessage as an option.

It is unclear to me what you mean by proactively send data. I can't find anything in the readme or draft spec.

By "proactively send data", I'm referring to the use of postMessage to establish communication and data-sharing between your sites. Your questions implied that your sites need to communicate and share cookie data in order to function normally, so this explicit communication is what ought to cease if one of the sites were compromised.

[dopry]

I understand how postMessage functions. I'm have also read every resource you linked. It would be really good to spell out the use case and a sample end to end implementation. While portions of that sample are going to be beyond the scope of your proposal and well covered with the Storage Access API in general. It is critical context for understanding the RWS proposal. It's knowledge that you probably take for granted since you and the other specifiers have likely been inundating yourselves with the subject for a while. The Storage Access API is relatively new, so it doesn't hurt to re-iterate some of those details.

I think my revised understanding is that this is a proposal to modify the behavior the Storage Access API to give it context to that would allow calls to requestStorageAccess without necessarily prompting the user, assuming the sites are 'Related' per RWS and the UA developer wants to allow that. RWS is the proposed implementation for providing that context. To me, in this scenario, RWS is secondary to the Objective not nagging users with a million allow access prompts.

Given the complexity of the implementation, (pushing data from one site to another via iframe post message), I'm more likely to push my projects to use canonical domains. I've done enough debugging of silent renew and 3rd party payment providers to want to subject myself to that without necessity.

Thanks for taking the time to help me understand RWS.