BASELINE: Update Chromium to 85.0.4183.14085-based

Change-Id: Iaa42f4680837c57725b1344f108c0196741f6057
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>

5 files changed, 167 insertions, 232 deletions

diff --git a/chromium/net/docs/bug-triage-labels.md b/chromium/net/docs/bug-triage-labels.md
index d32cde11826..1a9724e9221 100644
--- a/chromium/net/docs/bug-triage-labels.md
+++ b/chromium/net/docs/bug-triage-labels.md
@@ -10,22 +10,11 @@
     that die in the SSL negotiation phase, in particular, this is often the
     correct component.
 
-* **Internals>Network>DataProxy**
-
-    Flywheel / the Data Reduction Proxy.  Issues require "Reduce Data Usage" be
-    turned on.  Proxy URL is [https://proxy.googlezip.net:443](#), with
-    [http://compress.googlezip.net:80](#) as a fallback.  Currently Android and
-    iOS only.
-
 * **Internals>Network>Cache**
 
     The cache is the layer that handles most range request logic (Though range
     requests may also be issued by the PDF plugin, XHRs, or other components).
 
-* **Internals>Network>SPDY**
-
-    Covers HTTP2 as well.
-
 * **Internals>Network>HTTP**
 
     Typically not used.  Unclear what it covers, and there's no specific HTTP
diff --git a/chromium/net/docs/bug-triage-suggested-workflow.md b/chromium/net/docs/bug-triage-suggested-workflow.md
deleted file mode 100644
index 4807c72b95a..00000000000
--- a/chromium/net/docs/bug-triage-suggested-workflow.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# Chrome Network Bug Triage : Suggested Workflow
-
-[TOC]
-
-## Identifying unlabeled network bugs on the tracker
-
-* Look at new unconfirmed bugs since noon PST on the last triager's rotation.
-  [Use this issue tracker
-  query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed&sort=-id&num=1000).
-
-* Read the title of the bug.
-
-* If a bug looks like it might be network related, middle click (or
-  command-click on OSX) to open it in a new tab.
-
-* If a user provides a crash ID for a crasher for a bug that could be
-  net-related, see the [internal instructions on dealing with a crash ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id)
-
-* If network causes are possible, ask for a net-export log (If it's not a
-  browser crash) and attach the most specific internals-network label that's
-  applicable.  If there isn't an applicable narrower component, a clear owner
-  for the issue, or there are multiple possibilities, attach the
-  Internals>Network component and proceed with further investigation.
-
-* If non-network causes also seem possible, attach those components as well.
-
-## Investigating component=Internals>Network bugs
-
-* Note that you may want to investigate Needs-Feedback bugs first, as
-  that may result in some bugs being added to this list.
-
-* It's recommended that while on triage duty, you subscribe to the
-  Internals>Network component (but not its subcomponents). To do this, go
-  to the issue tracker and then click "Saved Queries".
-  Add a query with these settings:
-    * Saved query name: Network Bug Triage
-    * Project: chromium
-    * Query: component=Internals>Network
-    * Subscription options: Notify Immediately
-
-* Look through unconfirmed and untriaged component=Internals>Network bugs,
-  prioritizing those updated within the last week. [Use this issue tracker
-  query](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified).
-
-* If more information is needed from the reporter, ask for it and add the
-  Needs-Feedback label.
-
-* While investigating a new issue, change the status to Untriaged.
-
-* If a bug is a potential security issue (Allows for code execution from remote
-  site, allows crossing security boundaries, unchecked array bounds, etc) mark
-  it Type-Bug-Security.  If it has privacy implication (History, cookies
-  discoverable by an entity that shouldn't be able to do so, incognito state
-  being saved in memory or on disk beyond the lifetime of incognito tabs, etc),
-  mark it with component Privacy.
-
-* For bugs that already have a more specific network component, go ahead and
-  remove the Internals>Network component to get them off the next triager's
-  radar and move on.
-
-* Try to figure out if it's really a network bug.  See common non-network
-  components section for description of common components for issues incorrectly
-  tagged as Internals>Network.
-
-* If it's not, attach appropriate labels/components and go no further.
-
-* If it may be a network bug, attach additional possibly relevant component if
-  any, and continue investigating.  Once you either determine it's a
-  non-network bug, or figure out accurate more specific network components, your
-  job is done, though you should still ask for a net-export dump if it seems
-  likely to be useful.
-
-* Note that Chrome-OS-specific network-related code (Captive portal detection,
-  connectivity detection, login, etc) may not all have appropriate more
-  specific subcomponents, but are not in areas handled by the network stack
-  team. Just make sure those have the OS-Chrome label, and any more specific
-  labels if applicable, and then move on.
-
-* Gather data and investigate.
-    * Remember to add the Needs-Feedback label whenever waiting for the user to
-      respond with more information, and remove it when not waiting on the
-      user.
-    * Try to reproduce locally.  If you can, and it's a regression, use
-      src/tools/bisect-builds.py to figure out when it regressed.
-    * Ask more data from the user as needed (net-export dumps, repro case,
-      crash ID from chrome://crashes, run tests, etc).
-    * If asking for a chrome://net-export dump, provide this link:
-      https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.
-
-* Try to figure out what's going on, and which more specific network component
-  is most appropriate.
-
-* If it's a regression, browse through the git history of relevant files to try
-  and figure out when it regressed.  CC authors / primary reviewers of any
-  strongly suspect CLs.
-
-* If you are having trouble with an issue, particularly for help understanding
-  net-export logs, email the public net-dev@chromium.org list for help
-  debugging.  If it's a crasher, or for some other reason discussion needs to
-  be done in private, see [internal documentation for details](https://goto.google.com/network_triage_internal#getting-help-with-a-bug)
-
-* If it appears to be a bug in the unowned core of the network stack (i.e. no
-  subcomponent applies, or only the Internals>Network>HTTP subcomponent
-  applies, and there's no clear owner), try to figure out the exact cause.
-
-## Crashes
-
-For guidance on crashes see the internal documentation:
-
-* [Dealing with a crash ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id)
-* [Looking for new crashers](https://goto.google.com/network_triage_internal#looking-for-new-crashers)
-* [Investigating crashers](https://goto.google.com/network_triage_internal#investigating-crashers)
diff --git a/chromium/net/docs/bug-triage.md b/chromium/net/docs/bug-triage.md
index 25348795d97..ab02bbe8ff8 100644
--- a/chromium/net/docs/bug-triage.md
+++ b/chromium/net/docs/bug-triage.md
@@ -1,115 +1,96 @@
 # Chrome Network Bug Triage
 
-The Chrome network team uses a two day bug triage rotation.  The main goals are
-to identify and label new network bugs, and investigate network bugs when no
-label seems suitable.
+The Chrome network team uses a two day bug triage rotation. The goal is to
+review outstanding issues and keep things moving forward. The rotation is time
+based rather than objective based. Sheriffs are expected to spend the majority
+of their two days working on bug triage/investigation.
+
+## 1. Review untriaged bugs
+
+Look through [this list of untriaged
+bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-stars%20-opened&q=component%3AInternals%3ENetwork%20status%3Aunconfirmed%2Cuntriaged%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN%20-Needs%3DFeedback).
+
+* Go through them in the given order (top to bottom).
+  The link sorts them by priority and then recency.
+* The goal is to move them out of the untriaged bug queue and give them a priority.
+
+For each bug try to:
+
+* Remove the `Internals>Network` component if it belongs elsewhere
+* Dupe it against an existing bug
+* Close it `WontFix` if appropriate
+* Give the bug a priority. Refer to [this (internal) document for guidelines](https://goto.google.com/xnzwn)
+* If the bug is a potential security issue (Allows for code execution from remote
+  site, allows crossing security boundaries, unchecked array bounds, etc) mark
+  it `Type-Bug-Security`.
+* If the bug has privacy implications mark it with component `Privacy`.
+* Mark it as a feature request or task if appropriate
+* Ask the reporter to narrow down regressions, possibly by using
+  [bisect-builds-py](https://www.chromium.org/developers/bisect-builds-py). To
+  view suspicious changelists in a regression window, you can use the Change Log
+  form on [OmahaProxy](https://omahaproxy.appspot.com/)
+* CC others who may be able to help
+* Mark it as `Needs-Feedback` and request more information if needed.
+* Request a NetLog that captures the problem. You can paste this on the bug:
+  ```
+  Please collect and attach a chrome://net-export log.
+  Instructions can be found here:
+  https://chromium.org/for-testers/providing-network-details
+  ```
+* If a NetLog was provided, try to spend a bit of time reviewing it. See
+  [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for an
+  introduction.
+* Move to a subcomponent of `Internals>Network` if appropriate. See
+  [bug-triage-labels.md](bug-triage-labels.md) for an overview of the components.
+* If the bug is a crash, see [internal: Dealing with a crash
+  ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id)
+and [internal: Investigating
+crashers](https://goto.google.com/network_triage_internal#investigating-crashers)
+
+## 2. Follow-up on issues with the Needs-Feedback label
+
+Look through [this list of Needs=Feedback
+bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-modified&q=component%3AInternals%3ENetwork%20Needs%3DFeedback%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN).
+
+* Go through them in the given order (top to bottom).
+  The link sorts them by priority and then recency.
+* If the requested feedback was provided, review the new information and repeat
+  the same steps as (1) to re-triage based on the new information.
+* If the bug had the `Needs-Feedback` label for over a week and the
+  feedback needed to make progress was not yet provided, archive the bug.
+
+## 3. (Optional) Look through crash reports
+
+Top crashes will already be entered into the bug system by a different process,
+so will be handled by the triage steps above.
+
+However if you have time to look through lower threshold crashes, see
+[internal: Looking for new crashers](https://goto.google.com/network_triage_internal#looking-for-new-crashers)
+
+## 4. Send out a sheriff report
+
+On the final day of your rotation, send a brief summary to net-dev@chromium.org
+detailing any interesting or concerning trends. Do not discuss any restricted
+bugs on the public mailing list.
 
 ## Management
 
-Owners for the network bug triage rotation can find instructions on
-generating and modifying shifts
-[here (internal-only)](https://goto.google.com/pflvb).
-
-## Responsibilities
-
-### Required, in rough order of priority:
-* Identify new network bugs on the tracker.
-* Investigate recent `Internals>Network` issues with no subcomponent.
-* Follow up on `Needs-Feedback` issues for all network components.
-* Identify and file bugs for significant new crashers.
-
-### Best effort, also in rough priority order:
-* Investigate unowned and owned-but-forgotten net/ crashers.
-* Investigate old bugs.
-* Close obsolete bugs.
-
-All of the above is to be done on each rotation.  These responsibilities should
-be tracked, and anything left undone at the end of a rotation should be handed
-off to the next triager.  The downside to passing along bug investigations like
-this is each new triager has to get back up to speed on bugs the previous
-triager was investigating.  The upside is that triagers don't get stuck
-investigating issues after their time after their rotation, and it results in a
-uniform, predictable two day commitment for all triagers.
-
-## Details
-
-### Required:
-
-* Identify new network bugs on the bug tracker, looking at [this issue tracker
-  query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed+-commentby=425761728072-pa1bs18esuhp2cp2qfa1u9vb6p1v6kfu@developer.gserviceaccount.com&sort=-id&num=1000).
-
-  * All Unconfirmed issues filed during your triage rotation should be scanned
-    for suspected network bugs, a network component assigned and a
-    chrome://net-export/ log requested.  Suggested text: "Please collect and
-    attach a chrome://net-export log. Instructions can be found here:
-    https://chromium.org/for-testers/providing-network-details".
-    A link to the instructions appears on net-export, for easy reference.
-    When asking for a log or more details, attach the Needs-Feedback label.
-
-  * A triager is responsible for looking at bugs reported from noon PST /
-    3:00 pm EST of the last day of the previous triager's rotation until the
-    same time on the last day of their rotation.
-
-* Investigate [Unconfirmed / Untriaged Internals>Network issues that don't belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified),
-  prioritizing the most recent issues, ones with the most responsive reporters,
-  and major crashers.  This will generally take up the majority of your time as
-  triager. Continue digging until you can do one of the following:
-
-    * Mark it as `WontFix` (working as intended, obsolete issue) or a
-      duplicate.
-
-    * Mark it as a feature request.
+* Your rotation will appear in Google Calendar as two days. You are expected to
+  work on it full-time (as best you can) during those calendar days, during your
+  ordinary working hours.
 
-    * Mark it as `Needs-Feedback`.
+* Google Calendar [google.com_52n2p39ad82hah9v7j26vek830@group.calendar.google.com](https://calendar.google.com/calendar/embed?src=google.com_52n2p39ad82hah9v7j26vek830%40group.calendar.google.com&ctz=America%2FLos_Angeles)
 
-    * Remove the `Internals>Network` component, replacing it with at least one
-      more specific network component or non-network component. Replacing the
-      `Internals>Network` component gets it off the next triager's radar, and
-      in front of someone more familiar with the relevant code.  Note that
-      due to the way the bug report wizard works, a lot of bugs incorrectly end
-      up with the network component.
-
-    * The issue is assigned to an appropriate owner.  Make sure to mark it as
-      "assigned" so the next triager doesn't run into it.
-
-    * If there is no more specific component for a bug, it should be
-      investigated by the triager until we have a good understanding of the
-      cause of the problem, and some idea how it should be fixed, at which point
-      its status should be set to Available.  Future triagers should ignore bugs
-      with this status, unless investigating stale bugs.
-
-* Follow up on [Needs-Feedback issues for all components owned by the network stack team](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork+-component%3AInternals%3ENetwork%3EDataProxy+-component%3AInternals%3ENetwork%3EDataUse+-component%3AInternals%3ENetwork%3EVPN+Needs%3DFeedback&sort=-modified).
-
-    * Remove label once feedback is provided.  Continue to investigate, if
-      the previous section applies.
-
-    * If the `Needs-Feedback` label has been present for one week, ping the
-      reporter.
-
-    * Archive after two weeks with no feedback, telling users to file a new
-      bug if they still have the issue, with the requested information, unless
-      the reporter indicates they'll provide data when they can.  In that case,
-      use your own judgment for further pings or archiving.
-
-* Identify significant new crashes. See [internal documentation](https://goto.google.com/network_triage_internal#looking-for-new-crashers).
-
-### Best Effort (As you have time):
-
-* Investigate old bugs, and bugs associated with `Internals>Network`
-  subcomponents.
-
-* Investigate unowned and owned but forgotten net/ crashers that are still
-  occurring (As indicated by
-  [go/chromenetcrash](https://goto.google.com/chromenetcrash)), prioritizing
-  frequent and long standing crashers.
-
-* Close obsolete bugs.
+* Owners for the network bug triage rotation can find instructions on
+generating and modifying shifts
+[here (internal-only)](https://goto.google.com/pflvb).
 
-See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for
-suggested workflows.
+* An overview of bug trends can be seen on [Chromium
+  Dashboard](https://chromiumdash.appspot.com/components/Internals/Network?project=Chromium)
 
-See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
-and non-network bugs.
+* There is also an [internal dashboard with bug trends for Web
+  Platform](https://goto.google.com/vufyq) that includes network issues.
 
-See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for
-some help on getting started with chrome://net-internals debugging.
+* The issue tracker doesn't track any official mappings between components and
+  OWNERS. This [internal document](https://goto.google.com/kojfj) enumerates
+  the known owners for subcomponents.
diff --git a/chromium/net/docs/certificate_lifetimes.md b/chromium/net/docs/certificate_lifetimes.md
new file mode 100644
index 00000000000..ee413ef9157
--- /dev/null
+++ b/chromium/net/docs/certificate_lifetimes.md
@@ -0,0 +1,78 @@
+# Certificate Lifetimes
+
+As part of our ongoing commitment to ensuring users’ security, Google is
+reducing the maximum allowed lifetimes of TLS certificates.
+
+## Upcoming Changes
+
+Beginning with Chrome 85, TLS server certificates issued on or after
+2020-09-01 00:00:00 UTC will be required to have a validity period of 398 days
+or less. This will only apply to TLS server certificates from CAs that are
+trusted in a default installation of Google Chrome, commonly known as
+"publicly trusted CAs", and will not apply to locally-operated CAs that have
+been manually configured.
+
+Certificates that do not comply with this requirement will not work, and may
+cause webpages to fail to load or to render incorrectly.
+
+If a certificate that does not comply with this requirement is issued by a CA
+trusted in a default installation of Google Chrome, this will be treated as a
+failure to comply with the security policies necessary to being a trusted CA,
+and may result in the removal of trust of that CA’s certificates.
+
+## Technical Details
+
+* A certificate will be impacted by this restriction if either the notBefore
+  of the certificate is on or after 2020-09-01 00:00:00 UTC, or if the first
+  precertificate logged by the CA to a Certificate Transparency Log that is
+  qualified at time of issuance is on or after this date.
+* The validity period of a certificate is defined within RFC 5280, Section
+  4.1.2.5, as "the period of time from notBefore through notAfter, inclusive."
+* 398 days is measured with a day being equal to 86,400 seconds. Any time
+  greater than this indicates an additional day of validity.
+* To avoid the risk of misissuance, such as due to leap seconds or
+  CA-configured randomization, CAs SHOULD issue such server certificates with
+  validity periods of 397 days or less.
+
+## Frequently Asked Questions
+
+* Does this apply to locally-operated CAs, such as those used within
+  enterprises that use enterprise-configured configured CAs?
+  * No. This only applies to the set of CAs that are trusted by default by
+    Google Chrome, and not CAs that are operated by an enterprise and that
+    have no certification paths to CAs that are trusted by default.
+* Is there an enterprise policy to disable this enforcement?
+  * No. These changes are transparent and do not offer an enterprise control
+    to override, as they only apply to so-called "publicly trusted" CAs.
+    Enterprises that wish to have certificates with validity periods longer
+    than 398 days may do so by using a locally-operated CA that does not have
+    any certification paths up to a publicly trusted CA.
+* Does this mean I have to replace my existing certificates?
+  * No. This requirement only applies to new certificate issuance on or after
+    2020-09-01 00:00:00 UTC. Existing certificates whose validity period
+    exceeds 398 days will continue to work, while new certificates must comply
+    with these new requirements, such as when they are renewed or replaced.
+* Will this make certificates more expensive?
+  * As with past changes to the maximum certificate lifetimes, many CAs have
+    committed to providing additional certificates, as needed by the shortened
+    maximum lifetime, at no additional cost.
+* What will happen if a certificate is issued that does not meet these
+  requirements?
+  * Google Chrome will reject such certificates as having too long a validity
+    period, consistent with existing validity-period based enforcement.
+    Additionally, such certificates will be treated as a critical security
+    failure by the CA, and may result in further action taken on the CA that
+    may affect how current or future certificates from that CA function.
+    Chromium-based browsers will have this enforcement enabled by default, and
+    will need to modify the source to disable this.
+* What are other browsers doing?
+  * Apple previously announced this change for versions of iOS, iPadOS, macOS,
+    tvOS, and watchOS, as documented at
+    https://support.apple.com/en-us/HT211025, which will apply to all
+    applications, and not just those of Safari. This certificate lifetime
+    requirement is fully interoperable with Apple’s requirements.
+
+    Microsoft, Mozilla, Opera, and 360 have previously indicated their support
+    for these requirements, although have not yet made announcements at the
+    time of this post (2020-06-22). Other browsers, including those browsers
+    based on Chromium, may provide additional guidance or clarification.
diff --git a/chromium/net/docs/net-log.md b/chromium/net/docs/net-log.md
index 4097bc87a1d..ebf7ceee681 100644
--- a/chromium/net/docs/net-log.md
+++ b/chromium/net/docs/net-log.md
@@ -69,10 +69,9 @@ That said, changing core events may have consequences for external consumers of
 NetLogs, which rely on the structure and parameters to events for pretty
 printing and log analysis.
 
-The [NetLog
-viewer](https://chromium.googlesource.com/catapult/+/master/netlog_viewer/) for
-instance pretty prints certain parameters based on their names, and the event
-name that added them.
+The [NetLog viewer](https://netlog-viewer.appspot.com/) for instance pretty
+prints certain parameters based on their names, and the event name that added
+them.
 
 ### Example 1