|
| 1 | +**Security and Privacy questionnaire** |
| 2 | +Answering the questions from https://www.w3.org/TR/security-privacy-questionnaire/ |
| 3 | + |
| 4 | +What information does this feature expose, and for what purposes? |
| 5 | +- With the reporting functionality offered by Connection Allowlists, the reporting destination gets the URL that any resource request on the site was trying to reach but was disallowed due to Connection Allowlists. |
| 6 | + |
| 7 | +Do features in your specification expose the minimum amount of information necessary to implement the intended functionality? |
| 8 | +- Yes Connection Allowlists exposes the minimum amount of information necessary. For example for redirects, they are either all allowed or not and so the report does not carry the redirected URL if it was disallowed. |
| 9 | + |
| 10 | +Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either? |
| 11 | +- No |
| 12 | + |
| 13 | +How do the features in your specification deal with sensitive information? |
| 14 | +- N/A |
| 15 | + |
| 16 | +Does data exposed by your specification carry related but distinct information that may not be obvious to users? |
| 17 | +- No |
| 18 | + |
| 19 | +Do the features in your specification introduce state that persists across browsing sessions? |
| 20 | +- No |
| 21 | + |
| 22 | +Do the features in your specification expose information about the underlying platform to origins? |
| 23 | +- No |
| 24 | + |
| 25 | +Does this specification allow an origin to send data to the underlying platform? |
| 26 | +- No |
| 27 | + |
| 28 | +Do features in this specification enable access to device sensors? |
| 29 | +- No |
| 30 | + |
| 31 | +Do features in this specification enable new script execution/loading mechanisms? |
| 32 | +- No |
| 33 | + |
| 34 | +Do features in this specification allow an origin to access other devices? |
| 35 | +- No |
| 36 | + |
| 37 | +Do features in this specification allow an origin some measure of control over a user agent’s native UI? |
| 38 | +- No |
| 39 | + |
| 40 | +What temporary identifiers do the features in this specification create or expose to the web? |
| 41 | +- None |
| 42 | + |
| 43 | +How does this specification distinguish between behavior in first-party and third-party contexts? |
| 44 | +- It does not. Each context can opt-in to Connection Allowlists via a response header. |
| 45 | + |
| 46 | +How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode? |
| 47 | +- No difference b/w regular and incognito modes |
| 48 | + |
| 49 | +Does this specification have both "Security Considerations" and "Privacy Considerations" sections? |
| 50 | +- https://wicg.github.io/connection-allowlists/#security covers "Security Considerations" |
| 51 | + |
| 52 | +Do features in your specification enable origins to downgrade default security protections? |
| 53 | +- No |
| 54 | + |
| 55 | +What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document? |
| 56 | +- If a document with Connection Allowlist is recovered from the BFCache, its connection allowlists will continue to be applied to its network access. |
| 57 | + |
| 58 | +What happens when a document that uses your feature gets disconnected? |
| 59 | +- A document’s Connection Allowlists are only applicable to that document’s network requests. So when it's disconnected there are no network requests it makes and Connection Allowlists is not applicable. |
| 60 | + |
| 61 | +Does your spec define when and how new kinds of errors should be raised? |
| 62 | +- Yes |
| 63 | + |
| 64 | +Does your feature allow sites to learn about the user’s use of assistive technology? |
| 65 | +- No |
| 66 | + |
| 67 | +What should this questionnaire have asked? |
| 68 | +- N/A |
| 69 | + |
0 commit comments