Privacy concerns? Supposedly doesn't collect new information about the user. Drawing data can already be collected with the canvas.

Sangwhan: why is it on the navigator?

Yves: about i18n - how do they recognise vertical vs horizontal, mixed ltr and rtl?

Sangwhan: guessing they delegate it off to a native library? It's unclear

Yves: they have the basic order of strokes, but wondering about the result of the API? Text, text with information about orientation?

Sangwhan: when you create a handwriting recognizer you pass the language you want to recognize

Yves: for japanese you can write it horizontally or vertically

Sangwhan: I don't think I've seen implementations supporting vertical on a digitizer, but theoretically people might

Yves: prediction result is a JS object containing the strings.. one string without i18n information is probably missing something

Sangwhan: how do you deal with codeswitching?

Yves: right, you have an EU language with Arabic mixed in. Multiple strings with different information, how do they handle that? We make them get a review from the i18n group?

Sangwhan: what is distance measured in? Pixels?

Hadley: would guess pixels but they should make that explicit

Yves: physical or logical pixels?

Sangwhan: and how does it tie in with the API? Will ask.

Sangwhan: you can collect more information than the canvas with a dedicated writing surface. People would consider this as a handwriting input method rather than a scribbleboard. Can probably be used to collect more information? not from the API level but from how users interact with it? Not convinced it operates on the same magnitude as canvas. I don't recall ever writing a full sentence on the canvas surface. More likely you would write a full sentence here.

Yves: tablets are the main use of handwriting recognition

Amy: could be purposed to collect signatures, even though they are not needed to be recognised?

Sangwhan: and why do they want this exposed to the web? should be an IME?

Skipped.

Proposed comment:

During our May 2021 vf2f, @cynthia and myself did another pass at this review, thank you for all of the answers. Regarding adding a direction hint to the recognizer - we found that to be a useful futureproofing feature and recommend that you do. After going over the privacy & security questionnaire I am still not clear if the API exposes additional fingerprinting capabilities. With exposure of strokes, ordering of strokes and timing of strokes, I worry that models can be trained to easily recognize patterns for various disabilities. This will be a very unfortunate byproduct of this API. Is this something that you considered and could expand on?

Sangwhan: this was proposed closed a while ago and then Richard came in and wrote some stuff

Dan: it keeps getting updated which is good

Sangwhan: they can discuss with Richard on the issue but from our end it's okay.. problem is rtl and ltr switching.. eg. writing arabic and then numbers and back to arabic.. becomes icky with handwriting recognition. I don'tk now of an engine that does this well. The API and design doesn't factor this is in is based on the current state of affairs

Dan: I don't think we need to weigh in on that, one of the things that Rossen said in may was it's not clear about fingerprinting.. I would note that there's a very comprehensive privacy considerations section in the explainer which talks about the different fingerprinting risks associated with different types of recognisers which looks like they've spent some time thinking about this which is good to see. From that perspective they've taken some feedback from TAG into account.

Yves: the rtl ltr discussion started during review but it's still continuing, I don't think we should close we should wait for completion of the discussion on that aspect. And it's good that richard came up with very specific examples.

Amy: shouldn't that conversation be in i18n horizontal review ticket?

Sangwhan: that's issue 4 on their end with details and they're discussing there so that's fine. Can continue over there. From a design perspective I think we're okay.

Yves: as long as it's tracked somewhere

Sangwhan: it is tracked and linked to our issue

Dan: I think we should close it. [writes comment]. Multistakeholder?

Sangwhan: apple might implement it..

Dan: no signal no signal.. web developers like it

Sangwhan: a challenge - to be able to ship such a feature you need a handwriting recognition engine and not many companies have that. Mozilla doesn't have one. They'd have to duck tape some open source thing into the browser ot implement this. There is a bit of a only rich companies can implement this problem and I'm not sure if that should be factored in to a design review.

Thanks for the very comprehensive privacy & security section in the explainer. We're basically fine with the design. Since this relies on the presence of a handwriting recognizer software component that raises some concerns about implementability - especially across lower spec devices and in open source efforts.  There seems to be an issue regarding multi-stakeholder support as there's no documented support from other browser engines on Chrome Status - can you provide any feedback there?  What is the trajectory for this spec after **incubation** in WICG?  Where do you see this going?

Dan: comment left

Propose closing at plenary