Luke: Looks like a replacement request.

Matthew: From last week, didn’t see it yet. Jeffrey put a comment that this replaces design-reviews#997.

Luke: Dubious of privacy impacts on painting on the canvas. Because it can read back pixel data, it might lead to fingerprinting. Think accent colors in form elements. That is being handled, but still, many things could be left over.

Yves: There were timing attacks in the past. Can be bad. Needs care.

Hadley: Luke, if you’re interested in this, read the design review and participate in the private brainstorming thread.

Xioacheng: This is a new version of a previous proposal. I am very interested, but at the same time I think it needs a lot of work. First concern: privacy. We raised privacy concerns previously. What kind of data an be drawn into a canvas. In the current explainer they listed a range of things they considered. They also listed things they can't consider regarding privacy, like scrollbars etc.

...I am concerned they're not doing enough. I'm wondering if they have higher-level criteria for judging what's sensitive and what is not. The list is incomplete - we may find later that things should've been considered privacy-sensitive.

...the paint event is a new event. The idea is whenever the rendering of a child of the canvas changes, a paint event is triggered. Then the listener can update the image in the canvas. I think we need more work on the kind of changes that can trigger this paint event. There are some changes that might not trigger the update of the rendering. E.g. video playback, or image animation, or just a blinking caret. These kinds of changes... not sure if they're completely exposed to JS. UA can do lots of optimizations to put them on other threads. I am wondering if there would be interop risks, e.g. if some new implementation offloads work to a differnet thread, but we require them to change it.

...Also concerned as to whether we want to keep the descendents as interactive, or how to achieve interativity, Current approach seems hacky. The draw element-image method returns a transform matrix, and then put that matrix on the element's styles so it's transformed. This feels both unergonomic, and error-prone. What if we draw the same element twice? What if there are multiple elemlents but we draw them in an order that's different to DOM order?

Lola: You said that using the trasnform matrix and applying to element is hacky. If we draw the same element twice, what is the effect? Wouldn't we want the same thing to happen to both of them?

Xiaocheng: There's no way to apply one transform to one of the elements only - e.g. when we are doing hit testing.

Lola: Makes sense.

Matthew: APA is looking at it.