From e57b9fe94ff5158ea66213457a7755268113fc35 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:18:43 -0700 Subject: [PATCH 1/9] Add auto-expanding details explainer and privacy assessment --- .../auto-expanding-details-explainer.md | 17 ++++ .../auto-expanding-details-privacy.md | 95 +++++++++++++++++++ 2 files changed, 112 insertions(+) create mode 100644 explainers/auto-expanding-details-explainer.md create mode 100644 privacy-assessments/auto-expanding-details-privacy.md diff --git a/explainers/auto-expanding-details-explainer.md b/explainers/auto-expanding-details-explainer.md new file mode 100644 index 0000000..aca5b62 --- /dev/null +++ b/explainers/auto-expanding-details-explainer.md @@ -0,0 +1,17 @@ +Auto-expanding `
` explainer + +# The problem + +Today, users can’t search for content inside `
` elements when they are closed. If the user wants to search the page for content inside `
` elements with find-in-page, then they have to manually expand every `
` element in the page before they use find-in-page. + +# The solution + +The solution is to make the hidden contents of closed details elements searchable by find-in-page and have the browser automatically them when trying to scroll to their hidden contents. + +In addition to find-in-page, this feature should also work for Element fragments (navigating to a hash with an element id) and [ScrollToTextFragment](https://github.com/WICG/scroll-to-text-fragment/issues/173) in order to make content hidden inside `
` elements more findable and shareable. + +I have already [added this feature to the HTML spec](https://github.com/whatwg/html/pull/6466). + +# Privacy concerns + +I wrote a security and privacy self review [here](/privacy-assessments/auto-expanding-details-privacy.md). TL;DR this feature does not reveal any new sensitive information to the page due to the existing `scroll` events and `:target` psuedo selector. diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md new file mode 100644 index 0000000..f6f91a6 --- /dev/null +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -0,0 +1,95 @@ +# Auto-expanding `
` security and privacy self-review questionnaire + +## Questions to Consider + +### 2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? + +This feature will open details elements in response to find-in-page and ScrollToTextFragment. When a details element is opened, the page can observe it via the `toggle` event which is fired and the `open` attribute. It is necessary that we continue to fire this event and add the attribute when the details element is opened because the page may be relying on them to reconcile other state in the page or in script with the open state of the details element. + +### 2.2. Is this specification exposing the minimum amount of information necessary to power the feature? + +Yes. + +### 2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof? + +If you consider find-in-page queries or ScrollToTextFragment queries persinal information or PII, it is dealt with the same way "sensitive information" is in the next section. + +No new information stored on the device is exposed by this feature. + +### 2.4. How does this specification deal with sensitive information? + +The search queries present in the ScrollToTextFragment and find-in-page features may be sensitive information, and are considered in the "Privacy Considerations" section. + +### 2.5. Does this specification introduce new state for an origin that persists across browsing sessions? + +This feature does not store any new data in the browser. + +### 2.6. What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin? + +No information from the underlying platform is exposed by this feature. + +### 2.7. Does this specification allow an origin access to sensors on a user's device + +No. + +### 2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. + +This feature does not expose any information about an origin's state and does not enable sending or receving of any data to or from a network connection. + +### 2.9. Does this specification enable new script execution/loading mechanisms? + +No. + +### 2.10. Does this specification allow an origin to access other devices? + +No. + +### 2.11. Does this specification allow an origin some measure of control over a user agent's native UI? + +No. + +### 2.12. What temporary identifiers might this specification create or expose to the web? + +None. + +### 2.13. How does this specification distinguish between behavior in first-party and third-party contexts? + +If a match is found in a cross-origin iframe and a details element exists in a parent frame, this feature will not be used and the details element will not be automatically expanded. + +### 2.14. How does this specification work in the context of a user agent's Private Browsing or "incognito" mode? + +This feature will work the same regardless of incognito mode being enabled or disabled. + +### 2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section? + +I included a Privacy Considerations section further down this document. I did not include a Security Considerations section because I do not believe this feature exposes any security vulnerabilities. + +### 2.16. Does this specification allow downgrading default security characteristics? + +No. + +### 2.17. What should this questionnaire have asked? + +I have no suggestions to improve this questionnaire. + +## Privacy Considerations + +### 1. What privacy attacks have been considered? + +The page could observe the `toggle` event or the addition of the `open` attribute when this feature automatically expands details elements in an attempt to find out what the user was searching for with find-in-page or ScrollToTextFragment. If the page listens to the relevant events, it may be able to determine whether the user clicked on the details element to expand it or if it was automatically opened by this feature. + +### 2. What privacy attacks have been deemed out of scope (and why)? + +The aforementioned privacy attack is out of scope because it is less powerful than existing vulnerabilities for find-in-page and ScrollToTextFragment, meaning that this feature has a zero information delta with find-in-page and ScrollToTextFragment. + +For find-in-page, vulerabilities already exist which use the `scroll` event which is synchronous unlike the `toggle` event this feature will add. Every time find-in-page scrolls to a result, the page fires a `scroll` event. If the page creates a tiny scrollable area with every next possible character the user could type, it can recreate what the user typed into find-in-page. An example page which uses this attack can be found [here](/resources/find-in-page/search-incremental.html). If we were to remove the `scroll` events from find-in-page then this feature could become another vector for this attack, but this is unlikely to happen because it would break find-in-page for web pages which rely on the `scroll` event. This attack could be addressed regardless of the particular vector by adding a delay to find-in-page's scrolling which allows the user to type in enough characters to prevent the page incrementally building the user's search query, which Safari already does today. + +For ScrollToTextFragment, this feature exposes less than the existing `:target` pseudo selector added by ScrollToTextFragment. + +### 3. What privacy mitigations have been implemented? + +No privacy mitigations have been implemented. + +### 4. What privacy mitigations have considered and not implemented (and why)? + +Adding a delay to find-in-page's scrolling would help mitigate the possibility of this feature being used to snoop on find-in-page. Due to the existing `scroll` events, this feature does not make the situation any worse and therefore should not be blocked on adding a delay to find-in-page. However, I do plan on adding the find-in-page delay to chromium. From 387cefd205122b9e3bbe0e4f99470b4b02a9bf0c Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:43:48 -0700 Subject: [PATCH 2/9] Remove "I" --- explainers/auto-expanding-details-explainer.md | 6 +++--- privacy-assessments/auto-expanding-details-privacy.md | 8 ++------ 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/explainers/auto-expanding-details-explainer.md b/explainers/auto-expanding-details-explainer.md index aca5b62..b6fec76 100644 --- a/explainers/auto-expanding-details-explainer.md +++ b/explainers/auto-expanding-details-explainer.md @@ -9,9 +9,9 @@ Today, users can’t search for content inside `
` elements when they ar The solution is to make the hidden contents of closed details elements searchable by find-in-page and have the browser automatically them when trying to scroll to their hidden contents. In addition to find-in-page, this feature should also work for Element fragments (navigating to a hash with an element id) and [ScrollToTextFragment](https://github.com/WICG/scroll-to-text-fragment/issues/173) in order to make content hidden inside `
` elements more findable and shareable. - -I have already [added this feature to the HTML spec](https://github.com/whatwg/html/pull/6466). + +This feature has already been [added to the HTML spec](https://github.com/whatwg/html/pull/6466). # Privacy concerns -I wrote a security and privacy self review [here](/privacy-assessments/auto-expanding-details-privacy.md). TL;DR this feature does not reveal any new sensitive information to the page due to the existing `scroll` events and `:target` psuedo selector. +A security and privacy self review can be found [here](/privacy-assessments/auto-expanding-details-privacy.md). TL;DR this feature does not reveal any new sensitive information to the page due to the existing `scroll` events and `:target` psuedo selector. diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index f6f91a6..af91e9f 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -62,16 +62,12 @@ This feature will work the same regardless of incognito mode being enabled or di ### 2.15. Does this specification have a "Security Considerations" and "Privacy Considerations" section? -I included a Privacy Considerations section further down this document. I did not include a Security Considerations section because I do not believe this feature exposes any security vulnerabilities. +A Privacy Considerations section can be found further down in this document. There is no Security Considerations section because this feature does not expose any security vulnerabilities. ### 2.16. Does this specification allow downgrading default security characteristics? No. -### 2.17. What should this questionnaire have asked? - -I have no suggestions to improve this questionnaire. - ## Privacy Considerations ### 1. What privacy attacks have been considered? @@ -92,4 +88,4 @@ No privacy mitigations have been implemented. ### 4. What privacy mitigations have considered and not implemented (and why)? -Adding a delay to find-in-page's scrolling would help mitigate the possibility of this feature being used to snoop on find-in-page. Due to the existing `scroll` events, this feature does not make the situation any worse and therefore should not be blocked on adding a delay to find-in-page. However, I do plan on adding the find-in-page delay to chromium. +Adding a delay to find-in-page's scrolling would help mitigate the possibility of this feature being used to snoop on find-in-page. Due to the existing `scroll` events, this feature does not make the situation any worse and therefore should not be blocked on adding a delay to find-in-page. However, the find-in-page delay is planned to be implemented in chromium. From 7e93c6c2eb42884d85cfd3b11cb7b77e19c7e581 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:47:31 -0700 Subject: [PATCH 3/9] Update explainers/auto-expanding-details-explainer.md Co-authored-by: vmpstr --- explainers/auto-expanding-details-explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explainers/auto-expanding-details-explainer.md b/explainers/auto-expanding-details-explainer.md index b6fec76..49181f3 100644 --- a/explainers/auto-expanding-details-explainer.md +++ b/explainers/auto-expanding-details-explainer.md @@ -6,7 +6,7 @@ Today, users can’t search for content inside `
` elements when they ar # The solution -The solution is to make the hidden contents of closed details elements searchable by find-in-page and have the browser automatically them when trying to scroll to their hidden contents. +The solution is to make the hidden contents of closed details elements searchable by find-in-page and have the browser automatically open them when trying to scroll to their hidden contents. In addition to find-in-page, this feature should also work for Element fragments (navigating to a hash with an element id) and [ScrollToTextFragment](https://github.com/WICG/scroll-to-text-fragment/issues/173) in order to make content hidden inside `
` elements more findable and shareable. From 0ddadb7b72906b6450969f65939939de5a76dbb8 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:48:38 -0700 Subject: [PATCH 4/9] typo --- explainers/auto-expanding-details-explainer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/explainers/auto-expanding-details-explainer.md b/explainers/auto-expanding-details-explainer.md index 49181f3..5852045 100644 --- a/explainers/auto-expanding-details-explainer.md +++ b/explainers/auto-expanding-details-explainer.md @@ -14,4 +14,4 @@ This feature has already been [added to the HTML spec](https://github.com/whatwg # Privacy concerns -A security and privacy self review can be found [here](/privacy-assessments/auto-expanding-details-privacy.md). TL;DR this feature does not reveal any new sensitive information to the page due to the existing `scroll` events and `:target` psuedo selector. +A security and privacy self review can be found [here](/privacy-assessments/auto-expanding-details-privacy.md). TL;DR this feature does not reveal any new sensitive information to the page due to the existing `scroll` events and `:target` pseudo selector. From fd6275ef6bf4503c58e3b9ff484f41296be8abf7 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:48:58 -0700 Subject: [PATCH 5/9] Update privacy-assessments/auto-expanding-details-privacy.md Co-authored-by: vmpstr --- privacy-assessments/auto-expanding-details-privacy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index af91e9f..e444b19 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -12,7 +12,7 @@ Yes. ### 2.3. How does this specification deal with personal information or personally-identifiable information or information derived thereof? -If you consider find-in-page queries or ScrollToTextFragment queries persinal information or PII, it is dealt with the same way "sensitive information" is in the next section. +If you consider find-in-page queries or ScrollToTextFragment queries personal information or PII, it is dealt with the same way "sensitive information" is in the next section. No new information stored on the device is exposed by this feature. From 93ca461d299a9b549e470da02b1f620f6b87c11a Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 13:49:07 -0700 Subject: [PATCH 6/9] Update privacy-assessments/auto-expanding-details-privacy.md Co-authored-by: vmpstr --- privacy-assessments/auto-expanding-details-privacy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index e444b19..b403a42 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -34,7 +34,7 @@ No. ### 2.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts. -This feature does not expose any information about an origin's state and does not enable sending or receving of any data to or from a network connection. +This feature does not expose any information about an origin's state and does not enable sending or receiving of any data to or from a network connection. ### 2.9. Does this specification enable new script execution/loading mechanisms? From 9bb48da64cca49e74ef725da9dfdf9967b8b6fdc Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 17:29:16 -0700 Subject: [PATCH 7/9] update third-party contexts --- privacy-assessments/auto-expanding-details-privacy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index b403a42..5f5192e 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -54,7 +54,9 @@ None. ### 2.13. How does this specification distinguish between behavior in first-party and third-party contexts? -If a match is found in a cross-origin iframe and a details element exists in a parent frame, this feature will not be used and the details element will not be automatically expanded. +ScrollToTextFragment doesn't work on cross-origin iframes, so that isn't a concern for this feature. + +Find-in-page does work on cross origin iframes, but every time find-in-page scrolls to a match in an iframe it will continue to emit `scroll` events which are already revealing more information than this feature would. ### 2.14. How does this specification work in the context of a user agent's Private Browsing or "incognito" mode? From 1fa7ffeb62726080f138de11996c9705ab303ab0 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 17:30:27 -0700 Subject: [PATCH 8/9] Update privacy-assessments/auto-expanding-details-privacy.md Co-authored-by: vmpstr --- privacy-assessments/auto-expanding-details-privacy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index 5f5192e..c906fbd 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -80,7 +80,7 @@ The page could observe the `toggle` event or the addition of the `open` attribut The aforementioned privacy attack is out of scope because it is less powerful than existing vulnerabilities for find-in-page and ScrollToTextFragment, meaning that this feature has a zero information delta with find-in-page and ScrollToTextFragment. -For find-in-page, vulerabilities already exist which use the `scroll` event which is synchronous unlike the `toggle` event this feature will add. Every time find-in-page scrolls to a result, the page fires a `scroll` event. If the page creates a tiny scrollable area with every next possible character the user could type, it can recreate what the user typed into find-in-page. An example page which uses this attack can be found [here](/resources/find-in-page/search-incremental.html). If we were to remove the `scroll` events from find-in-page then this feature could become another vector for this attack, but this is unlikely to happen because it would break find-in-page for web pages which rely on the `scroll` event. This attack could be addressed regardless of the particular vector by adding a delay to find-in-page's scrolling which allows the user to type in enough characters to prevent the page incrementally building the user's search query, which Safari already does today. +For find-in-page, vulnerabilities already exist which use the `scroll` event which is synchronous unlike the `toggle` event this feature will trigger. Every time find-in-page scrolls to a result, the page fires a `scroll` event. If the page creates a tiny scrollable area with every next possible character the user could type, it can recreate what the user typed into find-in-page. An example page which uses this attack can be found [here](/resources/find-in-page/search-incremental.html). If we were to remove the `scroll` events from find-in-page then this feature could become another vector for this attack, but this is unlikely to happen because it would break find-in-page for web pages which rely on the `scroll` event. This attack could be addressed regardless of the particular vector by adding a delay to find-in-page's scrolling which allows the user to type in enough characters to prevent the page incrementally building the user's search query, which Safari already does today. For ScrollToTextFragment, this feature exposes less than the existing `:target` pseudo selector added by ScrollToTextFragment. From 82ab85ff559f720b7f91b8f0039e11d94e25ba75 Mon Sep 17 00:00:00 2001 From: Joey Arhar Date: Wed, 15 Sep 2021 17:31:52 -0700 Subject: [PATCH 9/9] scrolling -> frequency of queries --- privacy-assessments/auto-expanding-details-privacy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/privacy-assessments/auto-expanding-details-privacy.md b/privacy-assessments/auto-expanding-details-privacy.md index c906fbd..e14d26b 100644 --- a/privacy-assessments/auto-expanding-details-privacy.md +++ b/privacy-assessments/auto-expanding-details-privacy.md @@ -90,4 +90,4 @@ No privacy mitigations have been implemented. ### 4. What privacy mitigations have considered and not implemented (and why)? -Adding a delay to find-in-page's scrolling would help mitigate the possibility of this feature being used to snoop on find-in-page. Due to the existing `scroll` events, this feature does not make the situation any worse and therefore should not be blocked on adding a delay to find-in-page. However, the find-in-page delay is planned to be implemented in chromium. +Adding a delay to the frequency find-in-page queries are sent to the page would help mitigate the possibility of this feature being used to snoop on find-in-page. Due to the existing `scroll` events, this feature does not make the situation any worse and therefore should not be blocked on adding a delay to find-in-page. However, the find-in-page delay is planned to be implemented in chromium.