https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.en.x6imtnZQlN0.es5.O/am=BgKoxP3g_xIeYTEbAiRyvw78Z8LBEtD_43zGPwAFBHCxkW5pvz-hkg5-QB5A7KyOg2JgHMCwNsPQYUkIfwHABAAAAAAAAAAAAAAAAAAAAC5Sfg/d=1/exm=a,b/ed=1/im=1/dg=0/br=1/wt=1/rs=AHGWq9BJG7CUXDiAeuuez_Z5TDs80Jwofg/cb=loaded_2/m=m,m_i,i20jfd,lKrWxc,hkjXJ,gYOl6d,HXLjIb,DL8jZe,xaQcye,J41knb,oRmHt,E1P0kd,pE92lb,v2eEBc

We have a .global tld that points back to our .com tld. In looking at the guidance for how to handle ccTLD's it states that the ccTLD should be referenced in the ccTLD subsection of the well-known-sites.json.

In looking at the list of supported ccTLD, .global is not listed, so we are unsure how this should work with a .global domain. Any guidance you can provide on handling .global TLD entries would be appreciated.

Example of how we think the JSON should be structured per our understanding:

{
"primary": "https://hc1.com/",
"serviceSites": [
"https://hc1cas.com/",
"https://hc1cas.global/"

  ],
"rationaleBySite": {
  "https://hc1cas.com/": "hc1 Insights Lab platform authentication service for US.",
  "https://hc1cas.global/": "hc1 Insights Lab platform authentication service for UK region"
},
  "ccTLDs": {
    "https://hc1.com/": [
      "https://hc1.global/"
    ]
  }
}

https://play.google.com/store/apps/details?id=com.DAA.appchoices

I'm seeing errors when running the check_sites script locally:

Are all of these expected?

#![IMG_20231027_183108](https://github.com/GoogleChrome/related-website-sets/assets/118791217/327ea199-26c5-4d6f-9827-935c674ddd2b)

          #87

Originally posted by @Leonelhdzm99 in #87 (comment)

https://developercertificate.org/

I'm repeatedly unable to sign the corresponding CLA. I've tried creating both a public and private group. On every initial submission it says that a server error occurred, and then every subsequent attempt shows that "a CLA has already been submitted for this group".

Please advise.

• - Not blocking - is bu

~~`ping Kotlin and the compiler require from accompanist? Just wondering if the transitive Kotlin bump here is worth it (or if that bump would be transitive anyway from base - [ ] - Compose)@andreban @

Originally posted by @alexvanyo in google/accompanist#1715 (comment)

Problem statement

After requestStorageAccessFor a domain is made and permission is received we've to make a network request to the same domain where the browser will send the cookies in the headers and then either the server can provide set-cookie in the response header or it can provide it's response body.

This entire process is way too cumbersome.

Solution

If the requestStorageAccessFor promise can directly return us to the cross-site cookies list, it would simplify our lives.

GSA/idmanagement.gov#438

Currently, the service domains of each FPS are checked to see if they have an "X-Robots-Tag" with a "noindex" value in their headers. As pointed out by @renebaudisch in their PR, this check is done in a case-sensitive manner; however, HTTPS header names are case-insensitive, so this check will miss valid header names that do not explicitly match the string "X-Robots-Tag" therefore failing when they ought to have passed. This check should be altered to look for the header in a case-insensitive way, allowing more sites to pass the workflow and be merged into the FPS list.

https://code.visualstudio.com/sha/download?build=stable&os=linux-deb-x64

I am curious to understand the rationale behind this repository. It is very much against the decentralized nature of the web to maintain the list of related domains to a website in a centralized repository.

I am fine with maintaining a /.well-known/related-website-set.json on my websites, but it is a big hassle to provide this information in a static form here.

The reason is that I am using serverless backends, that give me endpoint domains like https://<random string>.execute-api.eu-west-1.amazonaws.com/. So I would need to go through the extra effort to put these endpoints behind a static domain name in order to keep the information in this repo up to date.

Why can't chrome just fetch the /.well-known/related-website-set.json file on first visiting the website and discover related websites from there? You could even cache this file (while honoring it's caching headers) and serve it to other users.

Do you really want to have feat(manager/composer): Use bitbucket-tags for vcs repos if it has bitbucket.org URL (#24065) as the PR title?

I assume the (#24065) part is a typo?

Originally posted by @HonkingGoose in renovatebot/renovate#24096 (comment)

We have an approved and merged PR

#151

We would like to understand the process for when that will be released.

We have an approved PR that was merged last Tuesday (12 Dec 2023). When will it be available in the general chrome release?

Closing, as this issue has been resolved and the relevant RWS submission has been merged.

Originally posted by @sjledoux in #131 (comment)

https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.en.x6imtnZQlN0.es5.O/am=BgKoxP3g_xIeYTEbAiRyvw78Z8LBEtD_43zGPwAFBHCxkW5pvz-hkg5-QB5A7KyOg2JgHMCwNsPQYUkIfwHABAAAAAAAAAAAAAAAAAAAAC5Sfg/d=1/im=1/dg=0/br=1/wt=1/rs=AHGWq9BJG7CUXDiAeuuez_Z5TDs80Jwofg/cb=loaded_0/m=b

Hi everyone. I'm testing the requestStorageAccess using this document as a reference and I thought that by defining associatedSites we don't need users interactions to access the cookies. Still, I'm receiving prompt instead of.

Am I doing something wrong or is this correct, do we need the user's interaction?

Not blocking - is bumping Kotlin and the compiler require from accompanist? Just wondering if the transitive Kotlin bump here is worth it (or if that bump would be transitive anyway from base Compose)

Originally posted by @oasissoman in google/accompanist#1715 (comment)

Let's take an actual example of our live environment to explain the problem statement and solution.

https://vwo.com and https://wingify.com are part of the same RWS while https://dev.visualwebsiteoptimizer.com is a third-party script loaded on these 2 websites that can create third-party cookies as CHIPS.

We would like to have the ability to add comma-separated values as the partition keys if these domains are part of RWS so that these CHIPS-based cookies can be shared across different domains if they're part of the same RWS.

We look forward to your response!

Problem Statement

With Google Chrome's impending restriction on third-party cookies, the cross-domain cookie access between websites like a.com and b.com, both relying on third-party scripts from c.com, becomes a challenge. These scripts create cookies on a.com that need to be accessible on b.com.

Proposed Solution

To address this issue, we propose implementing the following steps:

1. Generate RWS JSON: a.com and b.com website owners need to visit https://rws-json-generator.ue.r.appspot.com to generate the necessary RWS JSON.

2. Add .well-known Folder: If not already present, a.com and b.com should add a ".well-known" folder in their respective web root directories.

3. Add JSON File: Within the ".well-known" folder, a.com and b.com should add a JSON file named "related-website-set.json" containing the generated RWS JSON.

4. Host Cross-Site Cookie URL: Both a.com and b.com need to host a URL that provides the cross-site cookie in the response, following the guidelines specified in the official documentation.

5. Implement c.com Changes: The javascript files hosted on c.com need to implement requestStorageAccessFor, and upon the end user's consent, a network request is made to the related websites for cookie fetching in its response.

Desired Outcome

Our goal is to establish a solution that minimizes the effort required by a.com and b.com to achieve the desired cross-domain cookie access. This approach is particularly beneficial in scenarios where there are numerous domains involved in the related website set (RWS).

Seeking Input

We are seeking input on the best possible way to implement this solution effectively while ensuring minimal disruption to the existing workflows of a.com and b.com. Any insights or alternative approaches are welcome to optimize this process further.

          <!-- add-pr-comment:add-pr-comment -->

Looks like you've passed all of the checks!

Originally posted by @github-actions[bot] in #59 (comment)

https://www.ietf.org/archive/id/draft-shaw-openpgp-hkp-00.txt

https://raw.githubusercontent.com/jay0lee/GAM/master/src/gam-install.sh

We have updated our well-know sites JSON to align with the guidance provided but we are running into a redirection problem that we are unsure how to resolve.

We have this defined (currently what we see showing up when looking at chrome://system/ under the Related Website Sets):

{
"AssociatedSites": [ "https://hc1.global" ],
"PrimarySites": [ "https://hc1.com" ],
"ServiceSites": [ "https://hc1cas.com", "https://hc1cas.global" ]
}

But we have the following situation (example):

Launch https://labtastic.hc1.com/
Inside of that, there is an iFramed page that references https://labtastic.bi.hc1.com/MIPreDashboard.i4 this url redirects to https://www.hc1cas.com/ for authentication.

When we launch this in the iFrame, we are not being redirected from the https://labtastic.bi.hc1.com/ url BUT if we launch https://labtastic.bi.hc1.com/ from another browser, it will redirect.

Is there something further we need to define for this to work properly in an iFramed context?

Context
The Related-Website-Set (RWS) comprises a network of websites belonging to the same organization. While ensuring stringent data privacy protocols, there is a need to provide organizations with more detailed insights about users within the limited ecosystem that FPS has restricted to.

The Case for Scroll as a User Gesture-

• Problem with Current Tracking: Currently FPS does not allow to capture navigation user activities, like reading an article or browsing through a page.
• Solution: Implementing scroll tracking can bridge this gap. It would allow us to understand how users interact with our content beyond just clicks and page views.

Proposed Implementation Strategy

Event-Driven Tracking: Implement scroll depth tracking to capture user engagement at various thresholds (25%, 50%, 75%, 100%).

https://workspace.google.com/discover

👍

Originally posted by @hau99 in univelop/yust#261 (review)

This issue seems to apply to both the GoogleChrome/first-party-sets repo as well as the WICG/first-party-sets repo, since it seems to hit both on the implementation of the FPS check under the first and the discussion of FPS under the second.

While the FPS check that is performed during a PR to submit an FPS does check for intersections among FPS (e.g. multiple primary domains including one or more of the same associatedSites domains), there does not appear to be a mechanism to resolve these conflicting FPS. The current behavior would indicate that the first FPS submission takes precedence even if it was a false FPS declaration (e.g., a malicious actor attempting to claim ownership of domains that it does not in fact own) and the true owner would have to somehow prove (to whom, Google Chrome?) that it is in fact the true owner of the associatedSites and not the malicious actor.

This could be resolved with the requirement that the same first_party_sets.json file is present under /.well-known on the primary domain, as well as all of the associatedSites domains. The FPS check could then validate that the all of the first_party_sets.json files match and thus prevent a malicious actor from claiming them, since they would not have the ability to place a fraudulent first_party_sets.json on the associatedSites domains.

In one of the recent version of Chrome new feature was added storage partitioning, that don't allow cross-domian communication on not related domains (it only works for subdomains).

Found this repo in Storage Access API article on MDN. Link from a new article Saying goodbye to third-party cookies in 2024

Will this API allow sending Cross Domain messages (with localStorage storage event or Broadcast channel)?

Also, it's not clear how to submit the set. Should I create a PR for this repo and add a JSON file? If yes then it's not clear where to add those JSON files.

I need this for my Open Source project that stopped working in Chrome for not related domains jcubic/sysend.js#54

The Top-down approach mentioned on the page wasn't working as expected. Getting an error on the https://rws-member-glitch.me/request-storage-access.html page for Permissed denied. STEPS FOLLOWED:

1. Opened Google Chrome with local related sets:
   /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --use-related-website-set="{"primary": "https://related-website-sets.glitch.me/\", "associatedSites": ["https://rws-member-1.glitch.me/"]}"
   https://related-website-sets.glitch.me/ --incognito
2. Selected Top-down approach and got redirected to https://rws-member-1.glitch.me/request-storage-access-for.html
3. Clicked on the Click for Cookies button, and got the error requestStorageAccessFor: Permission denied.

We tried the same with an actual RWS of https://wingify.com and https://vwo.com are RWS as seen in the screenshot below.

We're trying to access first-party cookies of https://vwo.com in https://wingify.com by using await document.requestStorageAccessFor('https://vwo.com') which throws "Permission denied" and the same can be observed below in the below screenshot.

Could we please help us in getting this work?

          Hi @emerson-paiva,

Chrome still does require the user's gesture if that's the first time requestStorageAccess() has been called, even within a RWS. Once the permission is "granted", Chrome won't require the user gesture anymore, though.

You should be able to click the "Click for cookies" button and get storage access granted without a prompt (assuming you used the right --use-related-website-set= or --use-first-party-set= command line switch). Then if you refresh the page, you should see the permission is "granted".

For a full description of Chrome's requestStorageAccess() implementation, please see https://github.com/cfredric/chrome-storage-access-api, specifically this section.

Originally posted by @cfredric in #153 (comment)

Hi everyone 👋🏼

I'm preparing to submit changes to the related_website_sets.JSON, but I have a doubt if I set the object like this:

{
      "contact": "[email protected]",
      "primary": "https://primary.com",
      "associatedSites": [
        "https://secondarysite.com",
        "https://anothersite.com"
      ],
      "rationaleBySite": {
        ...
      }
 }

We have an associatedSite: secondarysite.com that sends cookies as a third-party cookie to another site associatedSite anothersite.com, If the pull request is merged, the communication between the associatedSites is gonna work? Or do I need to set the secondarysite.com as primary?