On Fri, Sep 3, 2021 at 12:31 PM Scott Helme <[email protected]> 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.
>
> 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?


>
> 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 [email protected]
>> wrote:
>>
>>> Contact [email protected]
>>>
>>> Explainerhttps://github.com/w3c/reporting/blob/master/EXPLAINER.md
>>>
>>> Specificationhttps://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 componentInternals>Network>ReportingAndNEL
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EReportingAndNEL>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/585
>>>
>>> TAG review statusIssues 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 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 nameDocumentReporting
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1062359
>>>
>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1156814
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/feature/5712172409683968
>>>
>>> Links to previous Intent discussionsIntent to prototype:
>>> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXZad6XfTEYihLFWJz3OJOori5Zox2%3DtY3TGn5%3DOeA39A%40mail.gmail.com.

Reply via email to