Contact emails [email protected], [email protected], [email protected], [email protected] Explainer/Specification
https://explainers-by-googlers.github.io/user-dictionary-leaks/ Summary This experiment would change when spelling and grammar hints are applied to text fields to reduce the of websites ability to extract information about the user’s dictionary, specifically: - Hints would not be applied to a text field that has not had user interaction (an autofocus <https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autofocus> is insufficient, there must be a click or key press of some kind relative to that field). - Hints would only be applied once per user interaction (the text cannot be changed programmatically and have hints applied without a click or key press of some kind relative to that field). Blink component Blink>Editing>Spellcheck <https://issues.chromium.org/issues?q=customfield0:%22Blink%3EEditing%3ESpellcheck%22> TAG review https://github.com/w3ctag/design-reviews/issues/1148 Motivation The user’s dictionary may contain sensitive information, for example some operating systems import the contents of the user’s address book to assist with the spelling of names/addresses. Although direct indicators of the ::spelling-error and ::grammar-error cannot be extracted, it’s possible to extract indirect information from browsers without rate limits on the application of these hints. In Chrome and Firefox, it’s possible to have an autofocused <https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/autofocus> text area cycle programmatically through a series of misspelled words, and for the site to monitor indicators of rendering performance to notice when hints are applied. This allows sites (or their third-party embeds) to detect which words are or aren’t in the user’s dictionary, which could leak sensitive information stored there (for example, their contacts' names). Safari already has rate limits in place which only check for and apply hints once per user interaction with the text field (e.g., a key input or click). Risks Interoperability and Compatibility Safari is already in full compliance with these changes, while Firefox and Chrome are only in partial compliance with the first one (they do count autofocused fields, but don’t apply new hints to fields that aren’t in active focus). Gecko: https://github.com/mozilla/standards-positions/issues/1294 WebKit: https://github.com/WebKit/standards-positions/issues/546 Debuggability This isn’t exposed to DevTools. Measurement UMA will be added to the SpellChecker <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/spellcheck/spell_checker.h> class that notes when hints are registered to the document so that browsers in and out of the experiment can be compared. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No, this isn’t observable outside browsertests. Flag name on about://flags N/A Finch feature name RestrictSpellingAndGrammarHighlights Rollout plan 1% experiment on stable to see if this causes any drop in key metrics. Requires code in //chrome? No Tracking bug https://crbug.com/415712674 Estimated milestones 143 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5080415048171520 -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJnHAOx7Khuqgu-xLgmu3R4UYeqfrkqVasuQx4A0JK_vg%40mail.gmail.com.
