LGTM2
/Daniel
On 2021-09-07 16:06, Ian Clelland wrote:
On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, <yoavwe...@google.com
<mailto:yoavwe...@google.com>> wrote:
On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <scott.he...@gmail.com
<mailto:scott.he...@gmail.com>> wrote:
Hey Yoav,
Thanks for linking me in, I'm happy to provide my feedback here.
Transparency: I'm Scott Helme, the founder of Report URI
<https://report-uri.com/>, which is a commercial service for
allowing websites to collect reports sent via the Reporting API.
We have a pretty strong position on the privacy concerns of
websites collecting reports and outline all of the efforts we
take to mitigate those concerns in our documentation. The
change proposed here seems like a step in the right direction
and as, I believe, the largest service of our kind in the
world, we would like to show our support.
That's great to hear, thanks!
The interoperability and compatibility section states that "no
collectors should have been relying on this behaviour" and I
can indeed confirm that we don't rely on this behaviour and
also agree that no other collector should rely on this
behaviour either.
The only concern I have is the idea of introducing another way
to configure the reporting endpoint for NEL and eventually
deprecating Report-To. Unless there's a particularly good
reason for doing so, I'd like to avoid the confusion and added
work for existing users of the Report-To header to have to
make another change. It would be more convenient for sites
currently using Report-To to continue to do so for NEL and
document based reports, only making the change to add
Reporting-Endpoints if they wish to do so. Is there an
intended benefit of eventually deprecating Report-To in favour
of yet another header?
Thanks for the feedback, Scott! :)
I believe the future NEL changes are not part of this intent.
Ian - am I correct? If so, what's the best venue for Scott (and
others) to provide that feedback and be involved in that conversation?
That's correct; this intent is just for providing the new mechanism;
we deliberately introduced the new header in order to allow NEL to
continue to function in existing deployments.
My eventual plan is to remove support for configuring
document-centered reports with Report-To, and only then to start the
process of transitioning network-centered reports, like NEL, away from
header-based configuration (if that turns out to be possible), but
that will be a separate process, with its own intents.
The Network Reporting spec
<https://w3c.github.io/reporting/network-reporting.html> is probably
the best forum for talking about how to eventually configure those
reports; please file issues here
<https://github.com/w3c/reporting/issues> for that.
(As an aside, the biggest benefit of switching NEL away from headers,
as I see it, is that Report-To is currently a cookie-like mechanism,
where headers received with one document will affect the processing of
subsequent requests. It's unavoidable, certainly, that *some* state
needs to be persistent for NEL to actually function, but it would be
better if there were an origin-scoped mechanism, to avoid all of the
issues with using headers for this.)
Ian
Kind regards,
Scott.
On Friday, 3 September 2021 at 10:12:01 UTC+1 Yoav Weiss wrote:
*LGTM1*
Thanks for working on this. IIUC, the motivation for this
change is feedback from other vendors to enable
non-persistent document-level reporting.
I'm glad to see that reflected in Mozilla's position.
On Thursday, September 2, 2021 at 8:21:50 PM UTC+2
icle...@chromium.org wrote:
Contact emails
icle...@chromium.org
Explainer
https://github.com/w3c/reporting/blob/master/EXPLAINER.md
<https://github.com/w3c/reporting/blob/master/EXPLAINER.md>
Specification
https://w3c.github.io/reporting/
<https://w3c.github.io/reporting/>
Summary
Splits the reporting cache into a per-document cache
for document-generated reports, and the existing cache
for network reports. There is currently a single
reporting cache per profile, which means that reports
from unrelated documents can potentially be sent in a
single request. This also introduces the
Reporting-Endpoints HTTP response header for
non-persistent configuration of document-generated
reports.
Blink component
Internals>Network>ReportingAndNEL
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EReportingAndNEL>
TAG review
https://github.com/w3ctag/design-reviews/issues/585
<https://github.com/w3ctag/design-reviews/issues/585>
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
For isolation, risks are low, as there has never been
a guarantee of any reports being combined; reports
could always have been delivered to endpoints
one-at-a-time, and no collectors should have been
relying on this behaviour. It is possible that some
parties may have been taking advantage of the fact
that reports from unrelated windows could be delivered
together, but eliminating that is exactly the point of
this change.
Gecko: Positive
(https://mozilla.github.io/standards-positions/#reporting
<https://www.chromestatus.com/admin/features/launch/5712172409683968/5?intent=1>)
Also see
https://github.com/mozilla/standards-positions/issues/104
<https://github.com/mozilla/standards-positions/issues/104>
which
mentions the current changes.
WebKit: No signal (email thread bumped recently)
Link?
Web developers: No signals
FWIW, I'm trying my luck
<https://twitter.com/yoavweiss/status/1433718028563271682>.
Ergonomics
The Reporting API is designed to be used in tandem
with other features which generate reports.
Activation
There should be no activation risks at all associated
with the improved report isolation. The biggest issue
will likely be the potential for confusion between the
old Report-To header and the new Reporting-Endpoints
header. Either header can be used to configure
document-based reports (for compatibility), but only
Report-To can configure the endpoint groups for
Network Error Logging. Once that API has a new
configuration mechanism, we will be able to deprecate
the Report-To header completely.
Security
No additional security risks associated with the new
header.
Debuggability
Isolating reports from different documents may enable
better debugging support from DevTools; currently
reports are all sent out-of-band, and combined with
reports from other documents, and so cannot easily be
seen in DevTools; the netlog viewer is the only access
developers have to that traffic. Separate work is
ongoing to improve the debuggability of the reporting
header syntax and endpoint connectivity issues; that
is not covered by this intent.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
Yes
Flag name
DocumentReporting
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1062359
<https://bugs.chromium.org/p/chromium/issues/detail?id=1062359>
Launch bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1156814
<https://bugs.chromium.org/p/chromium/issues/detail?id=1156814>
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5712172409683968
<https://www.chromestatus.com/feature/5712172409683968>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/_CIlziJRPME/m/w_4qFmKSAgAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/_CIlziJRPME/m/w_4qFmKSAgAJ>
This intent message was generated by Chrome Platform
Status <https://www.chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJEfFNfAyon74kke2wbeSmQzuW0KJEYuaZ6av5gWz8YtQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJEfFNfAyon74kke2wbeSmQzuW0KJEYuaZ6av5gWz8YtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/355976b3-b5cb-2d9b-e738-77e460146b83%40gmail.com.
