Capability URL problem bigger than advertized

[annevk]

Given that quite often capability URLs are origin + path I think https://w3c.github.io/reporting/#capability-urls needs improving. It's rather seldom that capabilities are stored in username/password/fragment. While good that they are stripped, selling that as solving the problem (apart from body) is not good.

[dcreager]

You're right that stripping username/password from the URL isn't enough! The analogous section in the NEL spec (last paragraph of §9) instead says that if you're encoding permissions in URL paths, you should run your own collectors and not upload reports to third parties. Would you consider that language sufficient?

[annevk]

Yeah, that seems more reasonable. In particular whatever we say should work for GitHub's gists and Flickr (at least I remember that using these, not sure if that's still the case).

[clelland]

I've taken another stab at the wording here, trying to include:

• what this spec does -- strip explicit credentials and fragments from the report's URL;
• what extensions should do -- strip similar information from any URLs defined in the body;
• and what sites deploying reporting need to be aware of -- that sensitive information in URL paths is not stripped, and that if they use such URLs, they may need to also deploy their own collectors.

I've also referenced the TAGs findings directly.