Clipboard stuff

27 January 2022



Meeting minutes

<BoCupp> https://docs.google.com/document/d/1De7MYQ3ZJ1bpIn47dkTm6UZ93YviX3UBoEbedfIlj_s/edit?usp=sharing

bo: agree that custom formats should eb exchangeable, but the ideas about degree of sanitization vary

bo: apple's position is to only offer sanitized, mozilla's is to allow custom formats, but unclear whather unsanitized should be default or offered as option

Anne: we could allow unsanitized data as a custom data.

bo: we are already shipping the proposal as it is. we are working on shipping it in chromium

bo: we have some limited options to modify it. this might work for us.

anne: legacy API and async API should deliver the same thing

anne: default paste handler needs a sanitizer always

bo: do you have a proposal

anne: no

bo: timing is important. it will be difficult in 6 months. it should still be possible in 6 weeks.

anne: it should be a relatively small delat on top of anupam's work

bo: important to get the general concept written down

right away

wenson: is this mainly for data transfer? ... so for the async. should we keep a single write method, or should we have both a wirte and a custom write method?

anne: maybe we only want to support this in async api if async is the way forward

anne: alternatively, sub class clipboard api (?)

bo: clipboarditem is roughly the entire clipboard. whereas in apple you have multiple clipboards + multiple items. each of those is multiple formats also.

wenson: yes, when you copy 3 photos, that's 3 items and each of those is offered transcoded to multiple formats

in ios anyway

bo: we only have one item there. we only have a macos implementation

anne: do we need a clipboard both with custom and non-custom items

bo: clipbaord needs custom representations in addition to standardized on the same item (for examle excel cells)

bo: we need to be able to put both unknown and wellknown formats unsanitized on clipboard

anne: two things: async and old api should work similarly. chromium less sanitization

2. item: if websites really need unsanitized data, they need to be able to get around sanitization

bo: I don't think we need to cut off access to builtin sanitizer

bo: we should give access to the kind of output that default handler would use

bo: 2nd type: if you say they can just use a different custom type to get around sanitization - out problem is we want interaction with old apps

anne: if you give old api same result as async api, you should cover that

bo: we could live with that, but possibly not google

anupam: if we can get to allow for removal of unsanitized on write

bo: so discussion would be on read. and that's a compatibility issue and possibly a security issue

bo: it would be good to give access to the sanitized form on read

bo: today you can assume that chromium browser is sanitizing data that is being pasting. If you have to opt in with unsanitized option, you know you have to take care of sanitizing.

wenson: all editors accepting unsanitized data have to deal with this already

wenson: we sanitize cross-origin

smaug: how about web app to native?

wenson: also

but native apps can make the data appear as if it's same-origin

<BoCupp> https://chromestatus.com/metrics/feature/timeline/popularity/2369

wenson: this is intended behavior and will not change

bo: not sure how much it is used and what hard limit is

anne: I think there is no hard limit. it depends

bo: we could change to above proposal I think

anne: you would have to ask explicitly for custom type to get the unsanitized version

bo: so you have to indicate which one you want when getting/reading

anne: we need to differentiate between wellknown types (png, html, etc.) and custom ones, which can be anything. and they can also include the wellknown ones

bo: so you can write both custom and default ones? also web app?

anne: yes

bo: so should we reconsider on sanitization on read (?)

anne: we should ship initial version, find out how people are using it

bo: I think we should put out an explainer and see if we can get build consensus around that with mozilla, etc. . we already have users using the api as we have it

bo: or just create a new issue and put some sample code in there to see if we can move ahead with such a proposal

anne: sure, I can write up an issue. but be aware that the current proposal has no standing given that there was no consensus around it

bo: yeah, I know. but we really tried to get a solution and there seemed to be no possibility for consensus with apple at the time.

anne: I'm just trying to get us to a place where we can have an API that we can all implement some time during the next few years

anne: there is no plan to remove the old api, and if we only sanitize in the new one, that won't work

anne: on legacy API - we assume that it doesn't sanitize and the new one does.

bo: yeah in chromium one does sanitize and the other one does not

anne: and so a large part of the discussion has been infleunced by the fact that there is this difference between old and new api

anne: you need to decide for the entire clipbaord,

bo: actually, you can specify a list (?) so that you can get all tghe various items at the same time

bo: otherwise you would end up in a situation where after reading one format, when you read the next format, it's already the next clipboard item

bo: the way it currently is, you have to specify preference upfront and you get it if it exists.

anne: I would like to have option to get access to multiple formats of same clipboard item

bo: we only have 3 wellknown types currently

bo: I would like for all the formats to be available and not one removed from custom fromats list even if it is wellknown (?)

bo: we are currently working on the clipboard and trying to improve it.

anne: if native app writes to general clipboard without marking it, the web should not get this byde fault without sanitization

anne: it needs to be put into custom space

bo: I disgaree. PDF, for example, is being given access to. some may be sanitized. others may be fine as they are.

anne: so we add it to the built-in list?

bo: so what does adding it to the list really mean then?

anne: that it's fine to work with and wehther not it needs extra sanitization

bo: so say we approve PDF. that means that now the app can take it from either pickle jar or from default clipboard.

anne: so you give raw clipboard api

bo: no, because we only map mime types to pickle jar or default clipboard if we decided format is fine

bo: if it's in the pickle jar, you can get it. native apps need to be updated to put it there

it may be that in the future, we allow more formats and then they don't need to get it from the pickle jar any more.

anne: so we should coordinate known types

bo: there is some basic understanding. but the beauty of the pickle jar is that we can upgrade the format to work without the pickel jar

and we can allow that without having to coordinate between browsers

there is no harm to allwoing some formats start in pickle jar and later turn into wellknown format

johannes: is there a way for editors to know that in some browsers that there will be more sanitization than in others?

johannes: could we add some language that makes it clear that authors need to test in all 4 browsers?

bo: some language like that would be ok

anne: we could specify that the custom types are unsanitized. for the builtin types, browsers may want to do some sanitization.

bo: we have agreement on unsanitized bucket

bo: we have some disagreement on the wellknown types

anne: we should write into spec that for wellknown types, browsers may do sanitizing.

bo: we would like to take a hint from author on what is asked for (sanitized or non-sanitized)?

wenson: how about meta tag

bo: yeah not our preferred option

anne: unsanitized option shouldn't exist forever

wenson: compatiblity gap can be described in documentation, potentially outside of spec.

bo: I feel like we are going over the same points again. can we summarize actions? I know one: if anne creates counterproposal, we will take a look at it.

bo: I think we are in the same place we were in the start: unsanitized version doesn't go into spec. I don't think we are converging.

wenson: mozilla and safari some to agree

bo: I think you are further appart when it comes to goals

anne: I am much more positive

anne: it sounds like having more mime types and not an "unsanitized option" has more support

bo: we can take a look at a counter proposal. but we will not be driving it.

bo: we need to then evaluate whether it will work on our current customers.

bo: we will not slow down to get consensus here as we are already implementing and shipping and have tried for a long time.

anne: there was a lot of cirticism right from the start.

bo: this process has taken a long time

bo: normal problem with standardization process - it's important for one group to ship something and other's don't see it as urgent.

bo: we get often into this situation. I cannot tell me boss: wenson from Apple doesn't agree as we need to ship something ASAP.

wenson: why not just work a meta tag? will that not solve it?

wenson: the meta tag would just be temporary

bo: I think there is an assumption that read never needs sanitized content

wenson: that would allow blink to ship something right away

anne: I have to leave

bo: it sounds like an "out" as it just means you don't have to change anything.

bo: it's possible the situation changes if this is something mozilla would be willing to work on

bo: I can come back with feedback from Microsoft on this

smau: it has been difficult to bring feedback as the spec has been in a weird state.

smaug: it was in a very early state

bo: that's fair

bo: actions: anne write counter-proposal. we will consider metatag.

<smaug> Nice experience on using jit.si

<BoCupp> agree good Jitsi worked well

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


No scribenick or scribe found. Guessed: johanneswilm

Maybe present: Anne, anupam, bo, johannes, smau, smaug, wenson