Meeting minutes
<BoCupp> https://
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://
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