Merge branch 'main' into Add-associated-warning

RWS-Submission_Guidelines.md

@@ -1,53 +1,51 @@
 # Related Website Sets Submission Guidelines 
-# Important Notice regarding Set Submissions 
-As Chrome prepares to [ship Related Website Sets](https://groups.google.com/a/chromium.org/g/blink-dev/c/7_6JDIfE1as) to General Availability (targeting a phased roll-out beginning Chrome 113),  we will shift from “testing” to “live” for Related Website Sets submissions. Please note key dates below as they relate to when your submissions will be applied to Stable behavior in Chrome:
-<ul>
-	<li><b>Monday, April 24, 2023</b>: The related_website_sets.JSON file will be cleared.</li>
-<li><b>Tuesday, April 25, 2023</b>: Submissions will be considered “live” submissions (no longer “test” submissions). The related_website_sets.JSON file will begin to be consumed by Chrome to be applied to Chrome 113+ releases.</li>
-</ul>
 
-# Overview
 Related Website Sets ("RWS") provides a framework for developers to declare relationships among sites, to enable limited cross-site cookie access for specific, user-facing purposes. This framework may help user agents, such as the Chrome browser ("Chrome"), to decide when to allow or deny a site access to their cookies when in a third-party context.
 RWS is a [Privacy Sandbox](https://privacysandbox.com/) proposal being incubated in the W3C's [WICG](https://www.w3.org/community/wicg/). For a full overview, consult the [explainer](https://github.com/privacycg/first-party-sets). The Related Website Sets Submission Guidelines ("Guidelines") are put forth by Chrome to define requirements and expectations for sets submitted by developers. Chrome remains committed to pursuing [standardization](https://www.w3.org/standards/) of RWS through engaging with developers, other browser vendors, and other interested parties.
- # Definitions 
-A <b>Related Website Set</b>, or <b>set</b>, is a collection of domains that is subject to the <a href="#set-formation-requirements">formation requirements</a>, has passed the <a href="#set-validation-requirements">validation requirements</a>, and has been successfully submitted to the canonical RWS list. 
 
-A <b>subset</b> is a defined use case within a set. Set members, or domains, will always be part of a subset. 
+## Definitions
+
+A **Related Website Set**, or **set**, is a collection of domains that is subject to the <a href="#set-formation-requirements">formation requirements</a>, has passed the <a href="#set-validation-requirements">validation requirements</a>, and has been successfully submitted to the canonical RWS list. 
+
+A **subset** is a defined use case within a set. Set members, or domains, will always be part of a subset. 
+
+A **set primary** is the domain a set submitter has identified as the representative of its set. Other domains within the set have a defined relationship with the primary. 
 
-A <b>set primary</b> is the domain a set submitter has identified as the representative of its set. Other domains within the set have a defined relationship with the primary. 
+A **set member** is a domain that is part of a set that is not the primary. A set member will always be part of a subset within the set.
 
-A <b>set member</b> is a domain that is part of a set that is not the primary. A set member will always be part of a subset within the set.
+The **canonical RWS list** is a publicly viewable list in a JSON file format housed in the <a href="https://github.com/googlechrome/first-party-sets">RWS GitHub repository</a> that is the source-of-truth for all sets that are subject to the formation requirements and have passed the validation requirements. Browsers, such as Chrome, can consume this file to apply to their behavior.
 
-The <b>canonical RWS list</b> is a publicly viewable list in a JSON file format housed in the <a href="https://github.com/googlechrome/first-party-sets">RWS GitHub repository</a> that is the source-of-truth for all sets that are subject to the formation requirements and have passed the validation requirements. Browsers, such as Chrome, can consume this file to apply to their behavior.
+A **pull request (PR)**, is the method of requesting a change on GitHub (like adding or modifying a set to the canonical RWS list). 
 
-A <b>pull request (PR)</b>, is the method of requesting a change on GitHub (like adding or modifying a set to the canonical RWS list). 
+A **submission** is an addition or modification to the canonical RWS list submitted by the submitter that is subject to the formation and the validation requirements.
 
-A <b>submission</b> is an addition or modification to the canonical RWS list submitted by the submitter that is subject to the formation and the validation requirements.
+A **submitter** is the individual or, if an individual is acting on behalf of their organization, the organization that has submitted a pull request against the canonical RWS list to create or modify a set for validation.
 
-A <b>submitter</b> is the individual or, if an individual is acting on behalf of their organization, the organization that has submitted a pull request against the canonical RWS list to create or modify a set for validation.
+An **equivalent domain** is the primary, service, or associated domain in a set for which there is a ccTLD variant in the same set. The equivalent domain has the same effective second-level domain (eSLD, or eTLD+1 minus eTLD) as a ccTLD variant in the same set.
 
-An <b>equivalent domain</b> is the primary, service, or associated domain in a set for which there is a ccTLD variant in the same set. The equivalent domain has the same effective second-level domain (eSLD, or eTLD+1 minus eTLD) as a ccTLD variant in the same set.
-# Set Formation Requirements 
-The table below describes the types of subsets that RWS currently supports, including requirements to help prevent misuse of the subset. 
+## Set Formation Requirements
 
-All submissions are subject to the formation requirements detailed in this section as well as the <a href="#set-validation-requirements">technical validation requirements</a> in the next section. 
+The table below describes the types of subsets that RWS currently supports, including requirements to help prevent misuse of the subset.
+
+All submissions are subject to the formation requirements detailed in this section as well as the <a href="#set-validation-requirements">technical validation requirements</a> in the next section.
 
 | Subset Type | Subset Definition |
 | ----------- | ----------------- |
 |   Service   | <ul><li>Domains that serve another set member to support functionality or security needs.</li><li>Service domains should not be the entry point to a user's journey on a site, but may be surfaced to a user as part of their journey.</li><li>Service domains must share a common owner with the set primary.</li><li>Submitters must provide an explanation of how each domain in this subset supports functionality or security needs.</li><li>Service domains must have a registered DNS entry</li>|
 |  Associated | <ul><li>Domains whose affiliation with the set primary is clearly presented to users.</li><li>Submitters must provide an explanation of how they clearly present the affiliation across domains to users and why users would expect their domains to be affiliated (e.g., an About page, header or footer, shared branding or logo, etc).</li>|
-	
+
 ccTLD (country code top-level domain) variants for the subsets above are also supported. The requirements for these domains are as follows:
-	
+
 | ccTLD | <ul><li>Domains that represent variations for a particular country or a geographical area. </li><li>ccTLD variants must share an identical eSLD with its equivalent domain.</li><li>The TLD of each ccTLD variant must be on <a href="https://icannwiki.org/Country_code_top-level_domain#Current_ccTLDs">ICANN's list of country codes</a>.</li><li>ccTLD variants must share a common owner with its equivalent domain.</li>|
 | ----------- | :------------ |
 
-## Set submissions ##
+### Set submissions
 
 New submissions to the canonical RWS list must be filed as <a href="https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request">pull requests (PRs)</a> on GitHub. Submitters should ensure that submissions follow the schema template provided below. Anyone with a <a href="https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts">GitHub account</a> may make a submission.
 
 Modifications to existing sets, including deletions, must also be submitted as new PRs against the canonical RWS list.
 The canonical RWS list will be validated against this schema whenever a user files their PR:
+
 ```json
 {
   "type": "object",
@@ -97,7 +95,9 @@ The canonical RWS list will be validated against this schema whenever a user fil
   }
 }
 ```
+
 A hypothetical example of the RWS canonical list is provided below for reference. A submission should follow the structure below, with new submissions being added as items to the "sets" list.
+
 ```json
 {
   "sets": [
@@ -125,10 +125,12 @@ A hypothetical example of the RWS canonical list is provided below for reference
   ]
 }
 ```
-# Set Validation Requirements 
+
+## Set Validation Requirements
 
 It is important that users' interests are protected from invalid submissions, and that web browsers use objective methods to validate submissions. As such, Chrome will rely on several technical methods to validate submissions. These technical checks, comprising both set-level checks and subset-level checks, will be conducted on GitHub, where results will be accessible and viewable by the public. 
-## Set-level technical validation ##
+
+### Set-level technical validation
 
 Upon submission of a PR, a series of technical checks will run on GitHub to verify the following: 
 <ul>
@@ -204,13 +206,17 @@ The `/.well-known/related-website-set.json` file for the set primary must follow
   }
 }
 ```
+
 Example for associate1.com/.well-known/related-website-set.json:
+
 ```json
 {
   "primary":"https://primary.com"
 }
 ```
+
 The /.well-known/related-website-set.json file for set members must follow the schema specified below:
+
 ```json
 {
   "type": "object",
@@ -220,7 +226,8 @@ The /.well-known/related-website-set.json file for set members must follow the s
   "required": ["primary"]
 }
 ```
-## Subset-level technical validation ##
+
+### Subset-level technical validation
 
 Additionally, more granular technical checks will also run on GitHub for service domains and ccTLD variants in the submissions. 
 
@@ -239,11 +246,11 @@ ccTLD variants must satisfy the following conditions:
 <li>Must share a common eSLD with the primary domain, 'service' domain, or 'associated' domain in the same set.</li>
 	</ul>
 
-<b>Validation success</b>
+#### Validation success
 
 If a set submission passes all technical checks successfully, the submitter will be notified that their PR was successful on GitHub. At this time, approved PRs will be manually merged in batches to the canonical RWS list once per week (Tuesdays at 12pm Eastern Time (ET)), excluding during holidays. 
 
-<b>Validation failure</b>
+#### Validation failure
 
 A submission may fail for the following reasons:
 <ul>
@@ -253,7 +260,9 @@ A submission may fail for the following reasons:
 In the case of submission failure, the submitter will be notified through a PR failure on GitHub. The PR failure notification may also provide additional information on why the submission may have failed. All technical checks governing set submissions are conducted on GitHub, and consequently all submission failures resulting from technical checks will be viewable on GitHub. 
 
 If you feel that a specific technical check has mistakenly caused a submission failure, leave a comment on the failed PR after consulting the error log. The Chrome team will investigate and reach out if further action is required.
-# Browser Behavior 
+
+## Browser Behavior
+
 Chrome consumes the canonical RWS list on a regular basis (every 2 weeks) and ships it to clients as an updateable component. Individual clients (with internet access) will refresh the list they apply each time they restart, or on start-up, if newly downloaded.
 
 In addition to the formation requirements and validation requirements above, sets are subject to subset-level limitations imposed by the browser to help prevent misuse of subsets. The table below describes how Chrome treats each subset. 
@@ -265,20 +274,27 @@ In addition to the formation requirements and validation requirements above, set
 
 While there is no limit on the number of ccTLDs that may be associated with a single associated or service domain in the same set, a ccTLD variant inherits the restrictions imposed on its equivalent domain. For example, `requestStorageAccessFor(origin)` calls will be auto-rejected when called by a ccTLD variant which is an alias of a service domain.
 To test this behavior in Chrome, please consult the [Related Website Sets integration guide](https://developer.chrome.com/en/docs/privacy-sandbox/first-party-sets-integration/).
-# Set Lifetime 
+
+## Set Lifetime
+
 As a best practice, submitters should plan to review their sets periodically (e.g., annually).
-	
+
 Submitters should also expect that sets will be subject to expiration and / or renewal requirements. This prevents sets from becoming stale, as technical checks improve, additional subsets are created, and / or alternative technologies are introduced over time. For example, sets will need to be refreshed when Chrome begins phasing out third-party cookies. At that time, submitters may expect additional clarity around set renewal requirements.
-# Responsibilities of the Submitter 
+
+## Responsibilities of the Submitter
+
 The submitter is responsible for maintaining the integrity of their set(s) and should be able to demonstrate conformance with the formation requirements above.
-	
+
 For example, in the case that conformance with ownership requirements (for ccTLD variants and service domains) must be demonstrated, submitters should use resources verifiable by public documentation, or recognized in filing documentation with an incorporating or registration agency in the submitter's jurisdiction of incorporation or registration, or created or recognized by a government agency. Alternatively, in some cases, conformance with ownership requirements may be attested to by a professional opinion letter signed by a lawyer or public notary. The person signing the legal opinion should have a valid license within the jurisdiction of the country in which the main entity is operating by maintaining an office or residence.
-## Enforcement Activities ##
+
+### Enforcement Activities
 
 At this time, validation of set submissions will be based on the methods described in these Guidelines, and Chrome will not apply additional enforcement activity governing set submissions, however Chrome reserves the right to act in cases of egregious and blatant disregard of these Guidelines. All submissions are publicly visible and subject to the scrutiny of the broader web community, including users, civil society, and other interested parties.
 
 Chrome will continue to evaluate how best to maintain the appropriate guardrails for set submissions, including developing more rigorous technical checks and introducing additional enforcement mechanisms. If Chrome determines that additional verification steps are necessary to provide a safe and reliable ecosystem for users, the team will notify developers with the appropriate notice. 
-# Feedback 
+
+## Feedback
+
 Chrome is committed to engaging and receiving feedback from the broader ecosystem, including through the W3C (World Wide Web Consortium), on the future development of the Related Website Sets standard and this version of the Related Website Sets Submission Guidelines.
 
 For feedback on the Related Website Sets standard, please engage on GitHub or on [WICG calls](https://docs.google.com/document/d/10dMVqt2x8otohdJx4AZYccdX5Hp_lrxlT7QAO2adcfE/edit#heading=h.uc5qyqdrhfhv). For feedback or questions on these Guidelines, please file an issue in this repository.

related_website_sets.JSON

@@ -952,6 +952,16 @@
      "rationaleBySite": {
         "https://drimer.travel": "The travel portal for Drimer"
      }
-  }
+  },
+   {
+      "contact": "homepage_migration_engineers@zoom.us",
+      "primary": "https://zoom.us",
+      "associatedSites": [
+        "https://zoom.com"
+      ],
+      "rationaleBySite": {
+        "https://zoom.com": "marketing new homepages for SEO purposes"
+      }
+    }
   ]
 }