Trust and Safety

[connorjclark]

Summarizing our latest meeting.

Initial Work For Trust and Safety

is-on-https

We want to align on the "mixed content" issues that will be landing in CDT soon. See this issue for more: #10615

COEP

One approach would be to fail if there is no COEP header. However, we are hesitant to do this because the benefits aren't universally applicable.

The approach we're going with is simply listing the frames that are blocked due to the embedder policy. This information will come from the backend, but it's still a WIP.

Existing audits

In addition, we want to re-home these existing audits:

• external-anchors-use-rel-noopener
• redirects-http
• geolocation-on-start
• notification-on-start
• vulnerabilities

#10623

Place in the report

We have two options:

1. A new category
2. Group in best-practices

If we did 1, there's a question of how to present the score–badge vs score (and pass/fail vs numerical score). Due to that, we are leaning towards option 2.

[paulirish]

COEP/COOP thoughts

Great resources:

• https://developers.google.com/web/updates/2020/03/devtools#COOP-COEP
• https://web.dev/coop-coep/
• https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit

There are two kinds of audits we could write for this right now:

1. You haven't enabled these policies yet, but you should. IMO there's no way we could do this before we are encouraging devs to enable CSP. The eng work with enabling any of these is large and risks real production breakage, so it's another level entirely from most of our recommendations.
2. You enabled these policies and there are currently things broken as a result. IMO this is the role of devtools. (And what devtools is doing). I see it Lighthouse's role as basically telling you "hey you have errors in the console". And turns out, there are already console errors notifying the user of failed network requests, so essentially we already have basic coverage here.

---

Handling Audits.issueAdded in general

In the long run, I think we should have a unique audit in Lighthouse for every Audits.InspectorIssueCode. Our implementation can probably be quite generic, routing issue codes to audits. (And ideally we have tests to ensure we add new audits for any new codes). This is good coverage for the case where these sorts of console errors moved permanently into the Issues panel.

To recap on LH's plans for T&S items:

• Samesite cookies: No specific work planned. Why? 90% of the time, it's relevant to 3rd parties and just noise for 1st party devs.
• COEP/COOP: No specific work planned.
• Mixed-content/HTTPS: Some work. See Alignment with new DevTools Mixed Content issues #10615
• Generic Audits.IssueAdded handling: rough plans. Once implemented, LH have audits for each InspectorIssueCode including samesite and mixedcontent. (We also expect coep issues to be added there).

[connorjclark]

You enabled these policies and there are currently things broken as a result. IMO this is the role of devtools. (And what devtools is doing). I see it Lighthouse's role as basically telling you "hey you have errors in the console". And turns out, there are already console errors notifying the user of failed network requests, so essentially we already have basic coverage here.

In the long run, I think we should have a unique audit in Lighthouse for every Audits.InspectorIssueCode.

There's an inconsistency here. I think what's been unsaid is we don't want to invest engineering work on a low-impact audit, which you've identified COEP issues in Lighthouse as. Which I agree with.

In order to do COEP stuff today we'd have to do some eng work (has not landed in the protocol yet), but once it is landed in the backend it's straightforward to consume. At that point, we'd want to make an audit for COEP issues, right?

[paulirish]

Big 👍 with everything you just said.

[connorjclark]

BlockedByResponseIssueDetails has landed for COOP/COEP.

After we make an audit surfacing those issues (for COOP/COEP), and #10615, we can close this issue. Future things related to security/safety will go in this new best practices group.

[connorjclark]

We have done this initial work, T&S will be an ongoing things (such as issue catch all, csp audit, etc...)