PING Comments On Mitigation Strategies #44
Conversation
index.src.html
Outdated
| @@ -610,6 +610,11 @@ <h2 id="mitigations"> | |||
| Mitigation Strategies | |||
| </h2> | |||
|
|
|||
| To mitigate the security and privacy risks you’ve identified in your | |||
| specification as you’ve filled out the questionnaire and consulted with PING, | |||
There was a problem hiding this comment.
This is possibly not a good idea, since we're again suggesting a soft requirement-like for consulting with PING (where in case of a TAG review, for example, we refrained from that. Let's simplify possibly?
As per the comment on the commit. I do not feel it breaks anything at it is already clear by now that consultations are encouraged.
index.src.html
Outdated
| privacy engineering practices. Examples | ||
| * [BATTERY-STATUS-API] <em>“The user agent should not expose high | ||
| precision readouts”</em> | ||
| * [SENSORS-API] <em>“Limit maximum sampling frequency”, “Reduce accuracy”</em> |
There was a problem hiding this comment.
Are there any more (possibly)?
There was a problem hiding this comment.
I've filed an issue to track finding more for a future version: w3cping#16
index.src.html
Outdated
| that file's parent directory and its contents as that is clearly not what is | ||
| expected. | ||
|
|
||
| Basic fingerprinting guidance can be found here. |
There was a problem hiding this comment.
Why fingerprinting in this place? I see no connection (in the writeup).
There was a problem hiding this comment.
Reference from incorporating another document into this one. Removed with w3cping@ea8d5ac.
index.src.html
Outdated
| requirements in their Device API Privacy Requirements document. | ||
|
|
||
| * APIs must make it easy to request as little information as required for | ||
| the intended usage. For instance, an API call should require specific |
There was a problem hiding this comment.
We can simply link to this document, or provide the long quotes in an annex or so (we already got some feedback about the document being lengthy)
There was a problem hiding this comment.
Should be addressed by w3cping@062d592 now.
index.src.html
Outdated
| reveals a user's location, and wouldn't be particularly useful if it didn't; | ||
| If the security or privacy risk of a feature cannot otherwise be mitigated in | ||
| a specification, optionally allowing an implementer to prompt a user may | ||
| provide the best security/privacy possible. If the specification does not |
There was a problem hiding this comment.
I'm not sure if I feel comfortable with saying that this 'may provide the best ... possible'. For example consider the AOM model where this would still result in risks.
There was a problem hiding this comment.
Revised with w3cping@b81de7d to make clear that it is an option and it reduced but does not remove risk.
index.src.html
Outdated
|
|
||
| It is possible that the risk of a feature cannot be mitigated because the | ||
| risk is endemic to the feature itself. For instance, [[ GEOLOCATION-API ]] | ||
| reveals a user’s location, and wouldn’t be particularly useful if it didn’t; |
There was a problem hiding this comment.
Today I would argue that it would be useful if providing course location details + information on precision. Should we change this part of the text not to endorse the default behavior of geolocation?
There was a problem hiding this comment.
Revised with w3cping@6420040 to make clear this is about how the geolocation api works rather than opining on it.
index.src.html
Outdated
| the user may choose to accept. This risk is also present and should be | ||
| accounted for in features that expose personal data or identifiers. | ||
|
|
||
| Designing such prompts is difficult as is determining the duration and timing |
There was a problem hiding this comment.
It will be unclear for the reader what we mean by 'timing'. Do we really need this?
There was a problem hiding this comment.
Revised with w3cping@db29182.
index.src.html
Outdated
| Every feature in a spec should be considered guilty (of harming security | ||
| and/or privacy) until proven otherwise. | ||
| of a feature is to drop the feature. | ||
| Every feature in a spec should be considered guilty of harming security |
There was a problem hiding this comment.
Maybe we should rephrase (in the end) the guilt part to risk part
There was a problem hiding this comment.
Addressed with w3cping@4707eac
|
|
||
| Specifications that expose such sensitive data should include a | ||
| recommendation that websites and applications adopting the API — but not | ||
| necessarily the implementing user agent — conduct a privacy impact assessment |
There was a problem hiding this comment.
What do we mean by "not necessarily the implementing UA"? Why are we adding this?
| @@ -5,6 +5,7 @@ <h1>Self-Review Questionnaire: Security and Privacy</h1> | |||
| Shortname: security-privacy-questionnaire | |||
| Level: 1 | |||
| Editor: Lukasz Olejnik, Independent researcher, [email protected] | |||
| Editor: Jason Novak, Apple Inc., https://apple.com | |||
There was a problem hiding this comment.
Erm, do you have a mail or a site? Otherwise, should I edit out my mail to my site? Asking on consistency.
There was a problem hiding this comment.
I've seen folks put either a site or an email.... I went with site.
…k/security-questionnaire into week-04-mitigation-strategies
…k/security-questionnaire into week-04-mitigation-strategies
Let's not abuse the word "preserving". Used in privacy (and beyond, too) circles too often as it looses its actual meaning.
Because why not.
|
Looks good to me. |
Collective feedback from PING on the mitigation strategies section of the questionnaire.