Privacy section should discuss browser implementation issues

[clelland]

Browsers often have concrete knowledge of a user's actions, or of the contents of a cross-origin response, where that information would never be exposed to a page, but might nonetheless trigger a deprecation warning for the user or local developer. These should not be exposed as deprecation reports, and we should make it clear in the spec that not all deprecations are reportable.

[davidben]

I'd maybe class this under both security, since this is also about the same-origin policy.

For a typical CSS/JS/HTML feature, deprecation reports are clearly a no-op here: deprecation reports trigger based on (1) the set of deprecated APIs in the browser, and (2) the APIs used by the document. (1) is public information and a property of the UA implementation. (2) is known to the document, since documents can see their own code.

When both those properties hold, deprecation reports are clearly safe. They're a great way to keep sites working for users when APIs get removed.

But there are other parts of the platform where (2) does not hold. Web content cannot see no-cors cross-origin responses, only some limited side effect, such as height/width information on cross-origin images. That means some kinds of deprecation reports would actually break some-origin policy. Examples:

• If some feature of JPG is getting deprecated, the embedding document should not receive reports from no-cors, cross-origin images.
• If some TLS feature is getting deprecated, the embedding document should not receive reports from cross-origin fetches.

I say "the embedding document", because it might be possible to make it go to the cross-origin resource instead (suitably partitioned), but I suspect we don't have a way to capture that with reporting endpoints being a document-level option. Even so, for same-origin cases, we don't currently expose everything. This is probably more under privacy than security. For example:

• We don't expose the browser-observed server certificate to web content. Doing so would be a privacy issue for anyone behind a TLS-terminating proxy, such as an antivirus. Not that those aren't already very problematic, but, in those cases, the certificate seen by the browser is machine-specific.
• Is the TLS cipher suite seen by the browser okay? In this TLS-terminating cases, it is usually, but not necessarily, the same as what the server saw. On the other hand, it's unlikely to be machine-specific in the way the certificate is.

I believe NEL needs to grapple with some of those cases. Hopefully we can reuse some of those expectations.

Another thing to worry about is that, even if revealing the existence of the deprecation report is fine, we also need the content to be safe. For instance, URLs of cross-origin resources may not be known to the document after redirects are followed. We need to be careful referencing them in reports, whereas we might have previously freely mentioned them in the DevTools console.

[davidben]

I tried to dig this issue up recently and had a hard time finding it because it's titled wrong. Can the title be renamed to "Cross-origin information leak when sending deprecation reports triggered by subresources"? I.e. it's not an implementation issue, but a security problem with the current design.

[clelland]

Absolutely, although I don't know if it's actually a design problem -- it's more of a caution to implementers to be sure that specific deprecations only report on things that should be visible to the frame which configured reporting

[davidben]

Ah, that's fair. It's not an issue with deprecation reports as a concept, but it's a limitation on when it is okay to use a deprecation report. I don't think that's an "implementation issue" though. That reads to me like this is something where implementing what the spec prescribes is tricky. This is something else.

Specifically, the reason I care is that Blink decided to automatically send a deprecation report on every CountDeprecation call, which is very much not safe for all deprecations. Of course, we can resolve this by saying that such deprecations are outside the scope of the Blink process, but this is a fairly subtle problem and, without clear specification text, there's no guidance to users of this spec that this is actually something to worry about.