22018 2013-05-13 09:56:12 +0000 Consider adding getCompositionAlternatives() in InputMethodContext 2014-04-08 06:58:34 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - IME API unspecified PC All RESOLVED FIXED P2 normal --- 1 kochi kochi adrianba bugs mike public-webapps travil public-webapps-bugzilla oldest_to_newest 87589 0 kochi 2013-05-13 09:56:12 +0000 As described in https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html consider adding getCompositionAlternaties() in InputMethodContext interface. "Returns a copy (per call) of the current list of alternate candidate strings from the InputMethodContext object. The InputMethodContext object can produce alternates while it has a composition in progress. As soon as hasComposition() returns false, then getCompositionAlternatives() will always return an empty list. The list of alternatives is not updated "live"; it is only updated between compositionupdate events." No parameters. Return type: sequence DOMString 87604 1 bugs 2013-05-13 14:58:28 +0000 Need to be careful with privacy. It is not clear whether user-specific alternatives should be exposed to web page. 87640 2 kochi 2013-05-14 10:28:00 +0000 Possible solutions to privacy concerns: * Do not send user-defined candidates * Do not send any personalized candidates * Randomize the sequence Possible implementation restriction / optimizations: * Do not send all candidates (some conversion may have hundreds of candidates). Implementation-wise, usually candidate window shows about at most 10 candidates at a time, and the number of the candidates that can be retrieved at once may be limited at the number. At least retrieving all the candidates may block the script execution for unexpectedly long time and better to be avoided. 88304 3 travil 2013-05-28 22:01:27 +0000 IME input is disabled for password control, at least on Windows platform, so we don’t need to worry about exposing previous passwords to web apps--however, we know that many sites use other input controls for passwords, so this is still a very real concern. I agree that not sending all candidates is a good limitation to add in the implementation of this API, both for the benefit of performance and usefulness. Usually the top candidates visible for end users are the only things matter for web apps. 88371 4 kochi 2013-05-29 10:22:40 +0000 We discussed the privacy issue and compared the merit which this API provides and the concerns, we propose this to be dropped from the spec. As an alternative, an API that a user agent might send suggestion data to IME could be possible; e.g IME can show candidates mixed with these suggestions, which is less privacy-critical but still serves similar use case. 90335 5 kochi 2013-07-04 07:24:47 +0000 Let's defer this for the later version. We should take the privacy issue of this seriously. 92367 6 travil 2013-08-20 18:06:44 +0000 Just a quick followup--we have shipped (in IE11 Preview) a version of our proposed IME spec, including the getCompositionAlternatives() API. It passed our internal privacy review. However, we understand that for standardization, it may have a higher bar on privacy. There are a number of mitigations that could be applied to strengthen the privacy aspect of this API such as: * limiting the number of linguistically equivalent alternatives (to say 20?) * generating the list of alternatives any way the UA seems fit such as from standard dictionaries, IME-generated candidates, etc., but with the suggestion that user dictionaries are excluded. * alternatives can be presented in random order Thanks. 103547 7 kochi 2014-04-08 06:58:34 +0000 Added to Editor's draft: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#widl-InputMethodContext-getCompositionAlternatives-sequence-DOMString at revision https://dvcs.w3.org/hg/ime-api/rev/3311d294f6e1