Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Yoav Weiss' via blink-dev]

Still LGTM

On Tue, Sep 21, 2021 at 10:48 PM Ian Clelland 
wrote:

> In an exciting last minute turn of events, I've made progress on fixing
> one of the last outstanding bugs regarding our implementation of the new
> Reporting API spec, and I'd like to amend this intent to include that
> change, but I think I might need API owners to take another look at it.
>
> The original Reporting API specified that credentials should always be
> sent with the HTTP POST to reporting endpoints, like other requests. Chrome
> never implemented this, and until now, has never sent credentials with
> reports.
>
> This behaviour was changed with the new Reporting API, and the eventual
> outcome of https://github.com/w3c/reporting/issues/161 was that the spec
> restricted credentials to same-origin report uploads.
>
> Fixing https://crbug.com/1163645 now means that Chrome can send
> credentials with the reports, if and only if the reporting endpoint is
> same-origin with the document which generated the reports. I'd like to add
> that change to our initial release of the new header.
>
> To avoid introducing any backwards compatibility issues, and to try to
> avoid any unintended consequences of enabling credentials for existing
> deployments, I'd restrict this to only apply to the new Reporting-Endpoints
> header, and not to the older Report-To header. No existing behaviour should
> be changing as a result of this.
>
> I'd normally consider this a bug fix which aligns the initial release with
> the spec, but since it is an expansion of the scope of this intent, and
> since any mention of credentials should at least get the attention of
> privacy folks, I think this warrants getting folks to take a look again.
>
> Thanks,
> Ian
>
>
> On Mon, Sep 20, 2021 at 1:30 PM Ian Clelland 
> wrote:
>
>>
>>
>> On Thu, Sep 9, 2021 at 3:05 PM Mike West  wrote:
>>
>>> LGTM3.
>>>
>>> That said, we really need to stop renaming things that we've shipped. I
>>> think there's reasonable justification for doing so in this case, and given
>>> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
>>> for the `Report-To` model), it seems reasonable to me to follow through
>>> with an eventual deprecation. But more generally, shipping creates some
>>> unavoidable ossification. I might be over-reacting a bit to a few intents
>>> I'm recalling, but I think we need to carefully consider the cost of
>>> renaming vs the cost of asking developers to internalize a shift in
>>> behavior.
>>>
>>
>> Agreed -- we certainly thought long and hard about whether we could keep
>> the existing naming; the fundamental problem we ran into was in being able
>> to ship this without breaking NEL, and eventually concluded that since it
>> was impossible to know, with the existing Report-To header whether the
>> intended usage was going to be ephemeral (like the new header) or
>> persistent (like with NEL), that we couldn't change the semantics of
>> Report-To and also keep backwards compatibility.
>>
>>
>>>
>>> What's the long-term plan for `Report-To`? Do you have a deprecation
>>> path you think is feasible, or are we going to end up trying to align it to
>>> `Reporting-Endpoints` as an alias at some point in the future?
>>>
>>
>> We do want to deprecate it; that needs to happen along two different
>> paths:
>>  - We need to remove support for having Report-To configure document
>> reporting; that is, Reporting-Endpoints should be the only mechanism for
>> those reports.
>>  - We need to ship a better configuration mechanism for NEL & co., one
>> which is correctly origin-scoped, and does not allow an arbitrary
>> misconfigured document to overwrite the persistent configuration for the
>> rest of the resources at that origin. Most recently, I had proposed using
>> Origin Policy as that mechanism, but the future of that spec is unclear.
>>
>> Once both of those have been done, we will be able to deprecate the
>> Report-To header.
>>
>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell 
>>> wrote:
>>>
 LGTM2

 /Daniel
 On 2021-09-07 16:06, Ian Clelland wrote:



 On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
 wrote:

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

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Ian Clelland]

In an exciting last minute turn of events, I've made progress on fixing one
of the last outstanding bugs regarding our implementation of the new
Reporting API spec, and I'd like to amend this intent to include that
change, but I think I might need API owners to take another look at it.

The original Reporting API specified that credentials should always be sent
with the HTTP POST to reporting endpoints, like other requests. Chrome
never implemented this, and until now, has never sent credentials with
reports.

This behaviour was changed with the new Reporting API, and the eventual
outcome of https://github.com/w3c/reporting/issues/161 was that the spec
restricted credentials to same-origin report uploads.

Fixing https://crbug.com/1163645 now means that Chrome can send credentials
with the reports, if and only if the reporting endpoint is same-origin with
the document which generated the reports. I'd like to add that change to
our initial release of the new header.

To avoid introducing any backwards compatibility issues, and to try to
avoid any unintended consequences of enabling credentials for existing
deployments, I'd restrict this to only apply to the new Reporting-Endpoints
header, and not to the older Report-To header. No existing behaviour should
be changing as a result of this.

I'd normally consider this a bug fix which aligns the initial release with
the spec, but since it is an expansion of the scope of this intent, and
since any mention of credentials should at least get the attention of
privacy folks, I think this warrants getting folks to take a look again.

Thanks,
Ian


On Mon, Sep 20, 2021 at 1:30 PM Ian Clelland  wrote:

>
>
> On Thu, Sep 9, 2021 at 3:05 PM Mike West  wrote:
>
>> LGTM3.
>>
>> That said, we really need to stop renaming things that we've shipped. I
>> think there's reasonable justification for doing so in this case, and given
>> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
>> for the `Report-To` model), it seems reasonable to me to follow through
>> with an eventual deprecation. But more generally, shipping creates some
>> unavoidable ossification. I might be over-reacting a bit to a few intents
>> I'm recalling, but I think we need to carefully consider the cost of
>> renaming vs the cost of asking developers to internalize a shift in
>> behavior.
>>
>
> Agreed -- we certainly thought long and hard about whether we could keep
> the existing naming; the fundamental problem we ran into was in being able
> to ship this without breaking NEL, and eventually concluded that since it
> was impossible to know, with the existing Report-To header whether the
> intended usage was going to be ephemeral (like the new header) or
> persistent (like with NEL), that we couldn't change the semantics of
> Report-To and also keep backwards compatibility.
>
>
>>
>> What's the long-term plan for `Report-To`? Do you have a deprecation path
>> you think is feasible, or are we going to end up trying to align it to
>> `Reporting-Endpoints` as an alias at some point in the future?
>>
>
> We do want to deprecate it; that needs to happen along two different paths:
>  - We need to remove support for having Report-To configure document
> reporting; that is, Reporting-Endpoints should be the only mechanism for
> those reports.
>  - We need to ship a better configuration mechanism for NEL & co., one
> which is correctly origin-scoped, and does not allow an arbitrary
> misconfigured document to overwrite the persistent configuration for the
> rest of the resources at that origin. Most recently, I had proposed using
> Origin Policy as that mechanism, but the future of that spec is unclear.
>
> Once both of those have been done, we will be able to deprecate the
> Report-To header.
>
>
>> -mike
>>
>>
>> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell 
>> wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2021-09-07 16:06, Ian Clelland wrote:
>>>
>>>
>>>
>>> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
>>> wrote:
>>>


 On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
 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
> , 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 

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Ian Clelland]

On Thu, Sep 9, 2021 at 3:05 PM Mike West  wrote:

> LGTM3.
>
> That said, we really need to stop renaming things that we've shipped. I
> think there's reasonable justification for doing so in this case, and given
> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
> for the `Report-To` model), it seems reasonable to me to follow through
> with an eventual deprecation. But more generally, shipping creates some
> unavoidable ossification. I might be over-reacting a bit to a few intents
> I'm recalling, but I think we need to carefully consider the cost of
> renaming vs the cost of asking developers to internalize a shift in
> behavior.
>

Agreed -- we certainly thought long and hard about whether we could keep
the existing naming; the fundamental problem we ran into was in being able
to ship this without breaking NEL, and eventually concluded that since it
was impossible to know, with the existing Report-To header whether the
intended usage was going to be ephemeral (like the new header) or
persistent (like with NEL), that we couldn't change the semantics of
Report-To and also keep backwards compatibility.


>
> What's the long-term plan for `Report-To`? Do you have a deprecation path
> you think is feasible, or are we going to end up trying to align it to
> `Reporting-Endpoints` as an alias at some point in the future?
>

We do want to deprecate it; that needs to happen along two different paths:
 - We need to remove support for having Report-To configure document
reporting; that is, Reporting-Endpoints should be the only mechanism for
those reports.
 - We need to ship a better configuration mechanism for NEL & co., one
which is correctly origin-scoped, and does not allow an arbitrary
misconfigured document to overwrite the persistent configuration for the
rest of the resources at that origin. Most recently, I had proposed using
Origin Policy as that mechanism, but the future of that spec is unclear.

Once both of those have been done, we will be able to deprecate the
Report-To header.


> -mike
>
>
> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2021-09-07 16:06, Ian Clelland wrote:
>>
>>
>>
>> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
>>> 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
 , 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
>>  is probably the
>> best forum for talking about how to eventually configure those reports;
>> please file issues here 

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Joe Medley' via blink-dev]

In which version will this ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Sep 9, 2021 at 12:05 PM Mike West  wrote:

> LGTM3.
>
> That said, we really need to stop renaming things that we've shipped. I
> think there's reasonable justification for doing so in this case, and given
> Mozilla's support for the `Reporting-Endpoints` model (and lack of support
> for the `Report-To` model), it seems reasonable to me to follow through
> with an eventual deprecation. But more generally, shipping creates some
> unavoidable ossification. I might be over-reacting a bit to a few intents
> I'm recalling, but I think we need to carefully consider the cost of
> renaming vs the cost of asking developers to internalize a shift in
> behavior.
>
> What's the long-term plan for `Report-To`? Do you have a deprecation path
> you think is feasible, or are we going to end up trying to align it to
> `Reporting-Endpoints` as an alias at some point in the future?
>
> -mike
>
>
> On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2021-09-07 16:06, Ian Clelland wrote:
>>
>>
>>
>> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
>>> 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
 , 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
>>  is probably the
>> best forum for talking about how to eventually configure those reports;
>> please file issues here  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...@chr

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Mike West]

LGTM3.

That said, we really need to stop renaming things that we've shipped. I
think there's reasonable justification for doing so in this case, and given
Mozilla's support for the `Reporting-Endpoints` model (and lack of support
for the `Report-To` model), it seems reasonable to me to follow through
with an eventual deprecation. But more generally, shipping creates some
unavoidable ossification. I might be over-reacting a bit to a few intents
I'm recalling, but I think we need to carefully consider the cost of
renaming vs the cost of asking developers to internalize a shift in
behavior.

What's the long-term plan for `Report-To`? Do you have a deprecation path
you think is feasible, or are we going to end up trying to align it to
`Reporting-Endpoints` as an alias at some point in the future?

-mike


On Thu, Sep 9, 2021 at 5:06 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2021-09-07 16:06, Ian Clelland wrote:
>
>
>
> On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss,  wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 
>> 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
>>> , 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
>  is probably the
> best forum for talking about how to eventually configure those reports;
> please file issues here  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
>
> Specification https://w3c.github.io/reporting/
>
> Summary
>
> Splits the reporting cache into a per-document cache for
> document-generated reports, and the existing cache for net

Re: [blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Daniel Bratell]

LGTM2

/Daniel

On 2021-09-07 16:06, Ian Clelland wrote:



On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss, > wrote:




On Fri, Sep 3, 2021 at 12:31 PM Scott Helme 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
, 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 
 is probably 
the best forum for talking about how to eventually configure those 
reports; please file issues here 
 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



Specification

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>N

[blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Ian Clelland]

On Mon., Sep. 6, 2021, 3:19 a.m. Yoav Weiss,  wrote:

>
>
> On Fri, Sep 3, 2021 at 12:31 PM Scott Helme  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
>> , 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
 is probably the
best forum for talking about how to eventually configure those reports;
please file issues here  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 emailsicle...@chromium.org

 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
 

 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, 

[blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Yoav Weiss' via blink-dev]

On Fri, Sep 3, 2021 at 12:31 PM Scott Helme  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
> , 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 icle...@chromium.org
>> wrote:
>>
>>> Contact emailsicle...@chromium.org
>>>
>>> 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
>>> 
>>>
>>> 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
>>> )
>>> 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
>> .
>>
>>
>>> 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 document

[blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Scott Helme]

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 
, 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?

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 emailsicle...@chromium.org
>>
>> 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 
>> 
>>
>> 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 
>> )
>>  
>> 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 
> . 
>
>
>> 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 issu

[blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

[Ian Clelland]

On Fri, Sep 3, 2021 at 5:11 AM 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 emailsicle...@chromium.org
>>
>> 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
>> 
>>
>> 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
>> )
>> Also see https://github.com/mozilla/standards-positions/issues/104 which
>> mentions the current changes.
>>
>> WebKit: No signal (email thread bumped recently)
>>
>
> Link?
>

https://lists.webkit.org/pipermail/webkit-dev/2021-September/031978.html (The
earlier message was from December, around the time of the I2P, but didn't
get any response then)


>
>> Web developers: No signals
>>
>
> FWIW, I'm trying my luck
> .
>
>
>> 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
>> 
>> ?Yes
>>
>> Flag nameDocumentReporting
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://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
>> .
>>
>

-- 
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/CAK_TSXKjM-H4pi8v3M8WfSPWZbOn15XZ7EfhOxOer-8PSmJttg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Reporting API: Isolate reports per-document and support the Reporting-Endpoints header

['Yoav Weiss' via blink-dev]

*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 emailsicle...@chromium.org
>
> 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 
> 
>
> 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 
> )
>  
> 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 
. 


> 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 
> 
> ?Yes
>
> Flag nameDocumentReporting
>
> Requires code in //chrome?False
>
> Tracking bughttps://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 
> .
>

-- 
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/41edde93-9f13-4b46-ad3a-1a8d24a08585n%40chromium.org.