Define a max size for storage

[hawkinsw]

I know that several participants have mentioned that they are uncomfortable with storage requirements, but I didn't see anything related specifically to this:

There is no defined maximum size (limit) for the amount of storage that a UA should allocate for reports that are not yet submitted. This seems like a potential security violation in the case where:

1. A report end point is invalid (therefore the report is stored for repeated retry)
2. Reports are generated rapidly (therefore storage use increases rapidly)

I hope that this is useful feedback. Please ignore/close if this is not important.

[clelland]

There is a report buffer defined for ReporingObserver, with a maximum size of 100 entries (per global scope), (https://w3c.github.io/reporting/#notify-observers) but no, I don't think any similar restrictions are applied to the report cache.

[hawkinsw]

So, are you saying that we do need such a thing? I am sorry to say that I can't quite understand whether you are saying this is a valid or invalid concern?

…

On Sun, Sep 15, 2019 at 10:23 PM Ian Clelland ***@***.***> wrote: There is a report buffer defined for ReporingObserver, with a maximum size of 100 entries (per global scope), ( https://w3c.github.io/reporting/#notify-observers) but no, I don't think any similar restrictions are applied to the report cache. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#178?email_source=notifications&email_token=ACCP2CW4QPIHGT32D3J3MLLQJ3U2PA5CNFSM4IW4ZJ7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6X666Y#issuecomment-531623803>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCP2CSATOF4CUSA7PY2R2LQJ3U2PANCNFSM4IW4ZJ7A> .

[jpchase]

To clarify, the max for the report buffer is per report type, per global scope (e.g. for types like deprecation, intervention, etc.). Agreed that applies to ReportingObserver, not the report cache.

In #142, there was discussion on limiting reports, but for delivery, not storage. That was coming from the perspective of respecting the user's bandwidth, so I believe the answer was to use throttling and batching to limit data use. I don't think that helps limit the size of the report cache.

In 7.2. Garbage Collection, it describes potentially cleaning up failed endpoints or delivery attempts. Having this as implementation-defined seems like a good solution to protect the storage used. The storage actually consumed could vary a lot between UAs, making hard to defining a good max size in the spec.

[hawkinsw]

To clarify, the max for the report buffer is per report type, per global scope (e.g. for types like deprecation, intervention, etc.). Agreed that applies to ReportingObserver, not the report cache.

In #142, there was discussion on limiting reports, but for delivery, not storage. That was coming from the perspective of respecting the user's bandwidth, so I believe the answer was to use throttling and batching to limit data use. I don't think that helps limit the size of the report cache.

In 7.2. Garbage Collection, it describes potentially cleaning up failed endpoints or delivery attempts. Having this as implementation-defined seems like a good solution to protect the storage used. The storage actually consumed could vary a lot between UAs, making hard to defining a good max size in the spec.

You are obviously exactly correct! We definitely want to keep this in the GC section. Moreover, I think that you are absolutely correct that we want to make it implementation-defined. However, I am still concerned that the spec's language (as it stands) does not leave open the possibility that implementers can cap reporting cache space and still be conformant. So, I would be interested in seeing something (not sure what, exactly) that addresses this in the storage section.

I am a little worried, too, that the Report Buffer might be vulnerable to the same issues. Again, though, I am more than happy to be overridden if these are stupid questions to raise.

Thanks for engaging with me on this.

[clelland]

We should allow a UA to impose limits on how many reports it is willing to retain before sending, and drop those that exceed that limit, making clear that a UA which does this is still conformant (without specifying an exact max; that may depend on the UA, user settings, and device characteristics)

I'll see about adding some wording to the spec to address that.