Merge branch 'main' of https://github.com/GoogleChrome/developer.chro…

…me.com into sync-23817412

site/en/blog/immutable-document-domain/index.md

@@ -6,7 +6,7 @@ description: >
 subhead: >
   If your website relies on setting `document.domain`, your action is required.
 date: 2022-01-11
-updated: 2023-01-14
+updated: 2023-04-07
 authors:
   - agektmr
 tags:
@@ -18,12 +18,18 @@ alt: >
 
 **Updates**
 
+- **April 7, 2023**: We've identified [an issue](https://crbug.com/1429587)
+  before shipping this change in Chrome 112. `document.domain` setter to be
+  removed by default is currently suspended and the new shipping milestone is
+  not determined yet. Please check back on this blog post or subscribe to
+  [blink-dev](https://groups.google.com/a/chromium.org/g/blink-dev/) and [this
+  thread](https://groups.google.com/a/chromium.org/g/blink-dev/c/nrLl0IxSxSI/).
 - **January 20, 2023**: Updated timeline—`document.domain` setter will be
-    removed by default starting from Chrome 112. Also, [a mention about
-    enterprise policy](#enterprise-policy) to control the `document.domain`
-    behavior is added.
+  removed by default starting from Chrome 112. Also, [a mention about enterprise
+  policy](#enterprise-policy) to control the `document.domain` behavior is
+  added.
 - **July 25, 2022**: Updated timeline—`document.domain` setter will be removed
-    by default starting from Chrome 109.
+  by default starting from Chrome 109.
 - **February 4, 2022**: Updated with the new timeline - we'll show a warning in
   the Issues panel starting from Chrome 100, removing `document.domain` setter
   by default starting from Chrome 106.

site/en/blog/new-in-chrome-112/index.md

@@ -78,7 +78,7 @@ Nesting can help with:
 * Reducing file size.
 * Refactoring.
 
-Checkout [this article](/articles/css-nesting/) for tips to make the most of CSS nesting and you can find the support for nesting in devtools [here](blog/new-in-devtools-112/#nesting).
+Checkout [this article](/articles/css-nesting/) for tips to make the most of CSS nesting and you can find the support for nesting in devtools [here](/blog/new-in-devtools-112/#nesting).
 
 ## Algorithm update for `<dialog>` initial focus. {: #dialog }
 

site/en/blog/privacy-sandbox-unified-origin-trial/index.md

@@ -240,7 +240,7 @@ Check for the `attributionReporting` object in the `window` and
 the Permissions Policy for "attribution-reporting".
 
 ```javascript
-if ('attributionReporting' in window && document.featurePolicy.allowsFeature('attribution-reporting')) {
+if (document.featurePolicy.allowsFeature('attribution-reporting')) {
   // Attribution Reporting API enabled
 }
 ```

site/en/docs/extensions/mv3/messaging/index.md

@@ -23,7 +23,7 @@ messages][section-external] section.
 ## Simple one-time requests {: #simple }
 
 If you only need to send a single message to another part of your extension (and optionally get a
-response back), use the simplified [runtime.sendMessage()][runtime-send-msg] method or [tabs.sendMessage()][tabs-send-msg]
+response back), use the simplified [`runtime.sendMessage()`][runtime-send-msg] method or [`tabs.sendMessage()`][tabs-send-msg]
 method. This lets you send a one-time JSON-serializable message from a content script to the
 extension, or vice versa. To handle the response, use the returned Promise. For backward
 compatibility, you can alternatively pass a callback as the last argument. You cannot use both a
@@ -313,7 +313,7 @@ chrome.tabs.sendMessage(tab.id, {greeting: "hello"}, function(response) {
 });
 ```
 
-
+[mdn-promise]: https://developer.mozilla.org/docs/Learn/JavaScript/Asynchronous/Promises
 [native-client]: /docs/extensions/mv3/nativeMessaging/#native-messaging-client
 [native-host]: /docs/extensions/mv3/nativeMessaging/#native-messaging-host
 [native-messaging]: /docs/extensions/mv3/nativeMessaging/
@@ -336,4 +336,4 @@ chrome.tabs.sendMessage(tab.id, {greeting: "hello"}, function(response) {
 [tabs-connect]: /docs/extensions/reference/tabs#method-connect
 [tabs-send-msg]: /docs/extensions/reference/tabs#method-sendMessage
 [wiki-second-level]: https://wikipedia.org/wiki/Second-level_domain
-[wiki-cross-site]: https://wikipedia.org/wiki/Cross-site_scripting
+[wiki-cross-site]: https://wikipedia.org/wiki/Cross-site_scripting

site/en/docs/privacy-sandbox/attribution-reporting/index.md

@@ -276,36 +276,19 @@ conversion on an advertiser site.
 
 Summary reports are generated as follows:
 
-*  When the user clicks or sees a specially configured ad, the browser—on the user's local device—records this event, alongside the attribution configuration data that was specified.<br>
-*  Later on, when the user converts, the browser matches this detailed clicks or views event ("attribution source event") with detailed conversion data ("attribution trigger data") defined by an ad tech company, following a specific logic that is defined by the ad tech. The output of this process is an aggregatable report.<br>
-*  Aggregatable reports are encrypted by the browser and sent to the ad tech server. From the ad tech server, the aggregatable reports are sent to the aggregation service to produce a summary report.<br>
+*  A user clicks or views a specially configured ad. The browser—on the user's local device—records this event, alongside pre-specified attribution configuration data.
+*  Later on, when the user converts, the browser matches this detailed click or view event (known as the _attribution source event_) with detailed conversion data (known as _attribution trigger data_). The dimensions of detail captured are pre-defined by an ad tech company, and the browser follows specific logic that is defined by the ad tech. The browser outputs this data in an _aggregatable report_.
+*  Aggregatable reports are encrypted by the browser and sent to an ad tech server. From the ad tech server, the aggregatable reports are sent to the [aggregation service](/docs/privacy-sandbox/aggregation-service/) to produce a summary report.
 *  Summary reports are then made available to the ad tech. Note that summary reports are not delayed to the same extent as event-level reports.
 
-
-{% Details %}
-{% DetailsSummary 'h3' %}
-How it works in detail: aggregate reports
-{% endDetailsSummary %}
-
-Ad links can be configured with attributes that are specific to ad conversions.
-
-When the user clicks or sees a specially configured ad, the browser—on the user's local
-device—records this event, alongside the attribution configuration data that was specified.
-
-Ad tech-defined code is then executed within a worklet to define contributions, namely joints of
-ad-side and conversion-side data.
-
-These contributions (raw reports) are sent encrypted to an ad tech server, and
-then over to aggregation services that will compute aggregate reports in a
-[privacy-preserving](#privacy) way.
-
-Note that aggregate reports are not be delayed to the same extent as event-level reports.
-
-{% endDetails %}
+Read more about [summary reports](/docs/privacy-sandbox/summary-reports/).
 
 ## Privacy
 
-### Overview
+Unlike third-party cookies, the Attribution Reporting API
+allows advertising companies to gain insights into
+conversions **without tracking an individual's activity
+across sites**.
 
 Let's take a person named Bob. Bob sees an ad while reading
 the news on `news.example`. One week later, Bob buys shoes on
@@ -324,22 +307,19 @@ include purchases, activity, and credit card information on
 ad conversions. But it hinders user privacy:
 Bob's activity is tracked across sites with a high level of detail.
 
-Unlike third-party cookies, the Attribution Reporting API
-allows advertising companies to gain insights into
-conversions **without tracking an individual's activity
-across sites**. A small amount of information is joined
-across sites&mdash;enough to measure conversions, but not
-enough to track Bob's activity across sites in detail. Bob's
-activity on `news.example` and on `shoes.example` remains
-separate.
-
 {% Img
   src="image/O2RNUyVSLubjvENAT3e7JSdqSOx1/aurePszyAGz9Osu3G0XN.jpg",
   alt="Side-by-side view of today's web (joined identity) and tomorrow's web (partitioned identity)",
   width="800", height="314"
 %}
 
-### In detail
+A small amount of information is joined
+across sites&mdash;enough to measure conversions, but not
+enough to track Bob's activity across sites in detail. Bob's
+activity on `news.example` and on `shoes.example` remains
+separate.
+
+### Protections in each report type
 
 **Event-level reports** link an ad-side identifier with a small amount of
 conversion-side data. While they do provide cross-site information about a
@@ -357,6 +337,7 @@ event-level and aggregate reports.
 <figure>
 {% Img src="image/O2RNUyVSLubjvENAT3e7JSdqSOx1/mDdo2XLyGLBCAlgH7MPZ.png", alt="", width="800", height="1237" %}
 </figure>
+
 {% Details %}
 {% DetailsSummary 'h3' %}
 In detail: event-level reports and privacy

site/ja/blog/privacy-sandbox-unified-origin-trial/index.md

@@ -132,7 +132,7 @@ if ('runAdAuction' in navigator && document.featurePolicy.allowsFeature('run-ad-
 `window` 内の `attributionReporting` オブジェクトと、「attribution-reporting」のアクセス許可ポリシーを確認してください。
 
 ```javascript
-if ('attributionReporting' in window && document.featurePolicy.allowsFeature('attribution-reporting')) {
+if (document.featurePolicy.allowsFeature('attribution-reporting')) {
   // Attribution Reporting API enabled
 }
 ```