ReportingObserver

[RByers]

Hello TAG!

This is early, but new blink launch guidelines include asking for TAG feedback early. At this stage I wouldn't recommend reviewing the spec in detail - it's still under review with spec editors. But I'd at least appreciate a look at the explainer / use cases (and spec review is great too - but to avoid wasting your time I can ping again when it has actually landed).

This is part of "Reporting API" being driven by @mikewest which I don't see a TAG review request for yet. I'm personally working only on the JS interface in ReportingObserver and believe the two halves (HTTP vs. JS APIs) are largely separable and independently shippable. But if you prefer to treat this as a TAG review for all of Reporting that's fine with me too.

I'm requesting a TAG review of:

• Name: ReportingObserver
• Specification URL: WIP: PR, draft.
• Explainer, Requirements Doc, or Example code: Explainer
• Tests: Work in progress (will land with spec changes)
• Primary contacts: @rbyers @patrickkettner @paulmeyer90 @igrigorik @mikewest

Further details (optional):

• Relevant time constraints or deadlines: Being implemented in Chromium, aiming to ship sometime in Q4
• [ ] I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• [X] I have reviewed the TAG's API Design Principles

We'd prefer the TAG provide feedback as (please select one):

• [X] open issues in our Github repo for each point of feedback
• [ ] open a single issue in our Github repo for the entire review
• [ ] leave review feedback as a comment in this issue and @-notify [github usernames]

[travisleithead]

FYI: Re WICG/reporting#51, the current proposal application/reports+json looked good to me--and I commented as such on their issue.

[triblondon]

Picked up at London F2F. Passing on this at this time, there's still work to do for the authors to followup on our earlier feedback

[travisleithead]

• WICG/reporting#55 - New issue WICG/reporting#56 spun off to investigate sending crash reports specifically.
• WICG/reporting#54 - it is unclear if our feedback was understood. I think spanicker got it, but the feedback is that lifecycle event reporting is not a good fit. Do we agree?
• WICG/reporting#53 - Mike says there's a JSON serialization specified in IETF that he likes and they will go with. They appear to have addressed the question of a fallback URL already.

[torgo]

Discussed the idea of bringing some people together on a call for this issue or possibly for our f2f.

[torgo]

To agree how we want to proceed by next week. @slightlyoff to reach out to various parties.

[slightlyoff]

Per last week's call, the remaining substantive issue is JSON vs. Structured Headers for this design. There's a question here for @jyasskin about how Web Packaging decided to use Structured Headers. Is SH the new hotness? Or a fad? Is it fit-for-purpose for this API?

[slightlyoff]

Ok, so we spent a bit more time in today's meeting reading the SH spec and note that it doesn't support any sort of nesting in it's data-structures. Nearly every example in the Reporting API Explainer involves nesting, and the JS API specifically returns a list of report.

It seems that it would be possible to flatten some of these report types to confirm to SH restrictions. The Report-To header looks particularly ripe for this. As for report bodies, that's less clear.

@mnot: are your concerns with JSON limited to Report-To? If bodies are sent in JSON, does that still work for you?

[jyasskin]

@mnot and @reschke are better folks to ask than me. https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-01#section-1 (note the non-current draft number) discusses why not to use JSON in HTTP headers, but of course doesn't apply to payloads.

Note that the latest version of draft-reschke-http-jfv is https://tools.ietf.org/html/draft-reschke-http-jfv-08, not the -02 that the Reporting spec refers to.

If you go to Structured Headers, the difficulty is that Report-To is an array containing maps (so far we're good with a Parameterised List), containing an array (uh-oh, but sometimes doable with a space-delimited string), containing maps (nope).

[mnot]

I've added the reasons that I remember coming up in discussion here: https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#why-not-json

[mnot]

@jyasskin @slightlyoff I see that level of nesting in the payload in that explainer, but not the header field value. What am I missing?

[jyasskin]

@mnot http://wicg.github.io/reporting/#header describes the HTTP header with the amount of nesting I described. However, that specification describes the endpoints array as required, but the explainer doesn't include that field in its example. 🤷🏼‍♂️

Payloads are generated in http://wicg.github.io/reporting/#try-delivery.

[jyasskin]

Folks can follow the resulting HTTPWG discussion at https://lists.w3.org/Archives/Public/ietf-http-wg/2018AprJun/0324.html.

[mnot]

@jyasskin is this a representative example (ignoring the semantic sensibility of the values)?

[
    {
        "group": "foo",
        "include_subdomains": false,
        "max_age": 60,
        "endpoints": [
            {
                "url": "https://example.com/",
                "priority": 15,
                "weight": 10
            },
            {
                "url": "https://other.example.com/",
                "priority": 10,
                "weight": 10
            }
        ]
    },
    {
        "group": "bar",
        "include_subdomains": true,
        "max_age": 30,
        "endpoints": [
            {
                "url": "https://example.org/",
                "priority": 1,
                "weight": 5
            }
        ]        
    }
]

[jyasskin]

I defer to one of the spec's owners. @mikewest?

[slightlyoff]

Hey all,

We discussed again today, and given the new example of the structure that @mnot posted, it seems like JSON is indeed the only available, largely appropriate choice at the moment. Other designs require pre-guessing how to de-structure common, deep data with flat names or a new convention (not part of the SH design) to enable re-construction based on some sort of naming convention. The alternatives (Base64-encoding nested structured) seem just as bad.

Would love to see the issues filed get addressed, but don't see much need to hold this train for the use of JSON modulo previously raised points.

[mnot]

@slightlyoff there's also discussion in https://github.com/WICG/reporting/issues/53 that's currently blocked on https://github.com/WICG/reporting/issues/93.

[dcreager]

w3c/reporting#93 and w3c/reporting#53 have now been resolved. (Note the repo name changes; Reporting and NEL both moved from WICG → WebPerf last week)

[travisleithead]

@dcreager thanks for closing the loop. We appreciate all the consideration and discussions around SH vs. JSON. Given where the design has fallen, we don't have any more meaningful feedback at this time. Thanks for flying TAG!

[ylafon]

Also, it was noted that the fact that JSON contains separators like , (comma) can lead to interoperability issues with some intermediaries, as it is a separator used in common HTTP header syntax (it was an issue in the past with Cookies, for example).

[dcreager]

Thanks Yves! Is there a link to the discussion, or can you provide an example where an intermediary might mangle a JSON-encoded Report-To header? JFV should, for example, do the right thing if Report-To appears twice, and an intermediary decides to concatenate them with a , separator.