Add some security considerations for sites using this API

[jyasskin]

There's a nice paper at https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1C-3_23159_paper.pdf showing how server-side contact discovery APIs can be abused. The exploits don't directly attack this API, but developers using this API need to know that they should defend against them. A security considerations section in this spec seems like a good place to warn people.

[rayankans]

Thanks for sharing this Jeffrey, it was an interesting read.

This API already applies the only relevant mitigation outlined in the paper (Selective Contact Permissions). When a website requests contact permission from the user, only the contacts / fields explicitly chosen by the user are shared. This is covered in the Security and Privacy section, as well as the relevant algorithms in the spec.

Was there anything else in the paper you were particularly referring to?

[jyasskin]

I think this API's design is good w.r.t the hash reversal mitigations in the paper. The specification could usefully point out the Crawling Mitigations and maybe the "Strengthened Hashing-based Protocols" mitigation to developers who consume the API.

The paper also makes the interesting point that Signal's defense against insider attacks made it increase its rate limits, which made it more vulnerable to crawling. I haven't worked through how this API's one-time-picker design changes the effectiveness of the paper's "Incremental Contact Discovery" suggestion for tightening Signal's rate limits. It'd be good for our security/privacy considerations to say something about how the tradeoffs work.

[samuelweiler]

Much of the discussion from the explainer should probably be moved into the spec, proper, in a section on Security Considerations, separate from Privacy considerations. See https://www.w3.org/TR/security-privacy-questionnaire/#considerations