Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit report delivery per page #142

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Limit report delivery per page #142

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
77f637b
Limit report delivery per page
paulmeyer90 Dec 10, 2018
7122d3f
Limit reporting api under saveData
paulmeyer90 Feb 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 29 additions & 11 deletions index.src.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,6 +129,9 @@ <h1>Reporting API</h1>
text: session; url: dfn-session
text: success; url: dfn-success
text: trying; url: dfn-try
spec: netinfo; urlPrefix: https://wicg.github.io/netinfo
type: dfn
text: saveData; url: savedata-attribute
</pre>
<pre class="biblio">
{
Expand Down Expand Up @@ -636,6 +639,13 @@ <h3 id="media-type">Media Type</h3>
The media type used when POSTing reports to a specified endpoint is
`application/reports+json`.

<h3 id="report-count">Report Count</h3>

Each <a>environment settings object</a> has a <dfn>report count</dfn>, which
is a <a spec=infra>map</a> from <a>report type</a> (string) to non-negative
integer. <a>report count</a> is used to track how many <a>reports</a> of
each <a>report type</a> have been generated in the current page.

<h3 id="queue-report" algorithm>
Queue |data| as |type| for |endpoint group| on |settings|
</h3>
Expand All @@ -644,7 +654,7 @@ <h3 id="queue-report" algorithm>
(|endpoint group|), an <a>environment settings object</a> (|settings|), and an
optional {{URL}} (|url|), the following algorithm will create a <a>report</a>,
and add it to <a>reporting cache</a>'s queue for future delivery.

1. Let |report| be a new <a>report</a> object with its values initialized as
follows:

Expand All @@ -661,22 +671,30 @@ <h3 id="queue-report" algorithm>
: [=report/attempts=]
:: 0

2. If |url| was not provided by the caller, let |url| be |settings|'s
2. Let |environment| be |settings|'s <a>realm execution context</a>'s
<a spec=ecmascript>realm</a>'s <a spec=ecmascript lt=realm>ECMAScript
global environment</a>.

3. Execute [[#notify-observers]] with |environment| and |report|.

4. If |settings|'s <a>report count</a> contains an entry
with <a spec=infra>key</a> |type|, then increment that entry. Otherwise,
create an entry in |settings|'s <a>report count</a>
with <a spec=infra>key</a> |type| and <a spec=infra>value</a> 1.

5. If |settings|'s <a>report count</a>[|type|] is greater than 100 and the
current <a spec="netinfo">saveData</a> preference is true, return.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dcreager curious, do you have a sense for the rough expected size of each report upload today? I'd love to understand the overall cost of this feature to the user.

@paulmeyer90 I think what you're proposing is reasonable, but I believe it diverges from our current implementation in Chrome — correct? As in, we have a hard cap of 100 reports (per type) regardless of data saver preference.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the current Chrome implementation, there's at most 1 upload per minute for each URL in the reporting policy. The upload would contain a batch of reports; the size of the upload would depend on the number of reports generated during that minute.

For NEL, I don't have access to the sizing data for Google's real-world reports anymore, but @sburnett might. The example reports in the spec clock in at 300-400 bytes each. The biggest variable is the URL; everything else is a pretty consistent size. (Note that's just for NEL; other types of report might be much larger and/or more variable in size.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently in Chrome, there is a 100 report limit in the report buffer (we won't buffer more than that, so if many more come at once, still only 100 will be delivered), but no overall limit for the number of reports delivered. It also currently does not behave differently when data saver is on.

Copy link
Member

@igrigorik igrigorik Feb 14, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the current Chrome implementation, there's at most 1 upload per minute for each URL in the reporting policy.

@dcreager that's a great point. We don't currently spec this.. should we? This seems like a good pattern that we should encourage; I've heard many past complaints about CSP violations triggering dozens to hundreds of requests.

Currently in Chrome, there is a 100 report limit in the report buffer (we won't buffer more than that, so if many more come at once, still only 100 will be delivered), but no overall limit for the number of reports delivered.

@paulmeyer90 to confirm, the combined interaction here is: there is a single upload once a minute and the buffer for an individual entry type is allowed to accumulate up to 100 reports within this window — is that correct? Update: nm, @dcreager confirmed the above in his followup comment.. :)


6. If |url| was not provided by the caller, let |url| be |settings|'s
<a>creation URL</a>.

3. Set |url|'s {{URL/username}} to the empty string, and its {{URL/password}}
7. Set |url|'s {{URL/username}} to the empty string, and its {{URL/password}}
to `null`.

4. Set |report|'s [=report/url=] to the result of executing the <a>URL
8. Set |report|'s [=report/url=] to the result of executing the <a>URL
serializer</a> on |url| with the <em>exclude fragment flag</em> set.

5. Append |report| to the <a>reporting cache</a>.

6. Let |environment| be |settings|'s <a>realm execution context</a>'s
<a spec=ecmascript>realm</a>'s <a spec=ecmascript lt=realm>ECMAScript
global environment</a>.

7. Execute [[#notify-observers]] with |environment| and |report|.
9. Append |report| to the <a>reporting cache</a>.

Note: <a>reporting observers</a> can only observe reports from the
same <a>environment settings object</a>.
Expand Down