15:33:18 RRSAgent has joined #editing 15:33:19 logging to https://www.w3.org/2022/01/27-editing-irc 15:33:20 RRSAgent, make logs Public 15:33:21 please title this meeting ("meeting: ..."), annevk 15:33:47 meeting: Clipboard stuff 15:34:22 https://docs.google.com/document/d/1De7MYQ3ZJ1bpIn47dkTm6UZ93YviX3UBoEbedfIlj_s/edit?usp=sharing 15:35:38 bo: agree that custom formats should eb exchangeable, but the ideas about degree of sanitization vary 15:36:48 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 15:38:40 GameMaker has joined #editing 15:39:57 present+ 15:43:04 Anne: we could allow unsanitized data as a custom data. 15:43:20 bo: we are already shipping the proposal as it is. we are working on shipping it in chromium 15:43:46 bo: we have some limited options to modify it. this might work for us. 15:44:12 anne: legacy API and async API should deliver the same thing 15:44:53 anne: default paste handler needs a sanitizer always 15:45:19 bo: do you have a proposal 15:45:22 anne: no 15:46:10 bo: timing is important. it will be difficult in 6 months. it should still be possible in 6 weeks. 15:46:38 anne: it should be a relatively small delat on top of anupam's work 15:47:11 bo: important to get the general concept written down 15:47:31 right away 15:49:33 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? 15:49:59 anne: maybe we only want to support this in async api if async is the way forward 15:50:19 anne: alternatively, sub class clipboard api (?) 15:51:27 bo: clipboarditem is roughly the entire clipboard. whereas in apple you have multiple clipboards + multiple items. each of those is multiple formats also. 15:52:04 wenson: yes, when you copy 3 photos, that's 3 items and each of those is offered transcoded to multiple formats 15:52:29 in ios anyway 15:52:51 bo: we only have one item there. we only have a macos implementation 15:53:43 anne: do we need a clipboard both with custom and non-custom items 15:54:45 bo: clipbaord needs custom representations in addition to standardized on the same item (for examle excel cells) 15:56:08 bo: we need to be able to put both unknown and wellknown formats unsanitized on clipboard 15:56:31 anne: two things: async and old api should work similarly. chromium less sanitization 15:56:58 2. item: if websites really need unsanitized data, they need to be able to get around sanitization 15:57:11 bo: I don't think we need to cut off access to builtin sanitizer 15:57:48 bo: we should give access to the kind of output that default handler would use 15:58:28 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 15:59:12 anne: if you give old api same result as async api, you should cover that 15:59:23 bo: we could live with that, but possibly not google 16:00:28 anupam: if we can get to allow for removal of unsanitized on write 16:01:16 bo: so discussion would be on read. and that's a compatibility issue and possibly a security issue 16:01:30 bo: it would be good to give access to the sanitized form on read 16:03:10 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. 16:03:31 wenson: all editors accepting unsanitized data have to deal with this already 16:04:07 wenson: we sanitize cross-origin 16:04:14 smaug: how about web app to native? 16:04:17 wenson: also 16:04:41 but native apps can make the data appear as if it's same-origin 16:05:04 https://chromestatus.com/metrics/feature/timeline/popularity/2369 16:05:09 wenson: this is intended behavior and will not change 16:06:32 bo: not sure how much it is used and what hard limit is 16:06:42 anne: I think there is no hard limit. it depends 16:08:33 bo: we could change to above proposal I think 16:08:57 anne: you would have to ask explicitly for custom type to get the unsanitized version 16:09:13 bo: so you have to indicate which one you want when getting/reading 16:10:16 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 16:10:42 bo: so you can write both custom and default ones? also web app? 16:10:45 anne: yes 16:11:05 bo: so should we reconsider on sanitization on read (?) 16:11:47 ... 16:11:58 anne: we should ship initial version, find out how people are using it 16:12:47 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 16:13:26 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 16:14:15 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 16:14:57 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. 16:15:39 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 16:16:36 anne: there is no plan to remove the old api, and if we only sanitize in the new one, that won't work 16:17:10 anne: on legacy API - we assume that it doesn't sanitize and the new one does. 16:17:37 bo: yeah in chromium one does sanitize and the other one does not 16:18:32 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 16:19:59 ... 16:20:27 anne: you need to decide for the entire clipbaord, 16:21:28 bo: actually, you can specify a list (?) so that you can get all tghe various items at the same time 16:22:15 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 16:23:12 bo: the way it currently is, you have to specify preference upfront and you get it if it exists. 16:23:33 anne: I would like to have option to get access to multiple formats of same clipboard item 16:23:54 bo: we only have 3 wellknown types currently 16:25:23 bo: I would like for all the formats to be available and not one removed from custom fromats list even if it is wellknown (?) 16:26:14 bo: we are currently working on the clipboard and trying to improve it. 16:27:14 anne: if native app writes to general clipboard without marking it, the web should not get this byde fault without sanitization 16:27:26 anne: it needs to be put into custom space 16:27:56 bo: I disgaree. PDF, for example, is being given access to. some may be sanitized. others may be fine as they are. 16:28:06 anne: so we add it to the built-in list? 16:28:23 bo: so what does adding it to the list really mean then? 16:28:52 anne: that it's fine to work with and wehther not it needs extra sanitization 16:29:32 bo: so say we approve PDF. that means that now the app can take it from either pickle jar or from default clipboard. 16:29:53 anne: so you give raw clipboard api 16:30:22 bo: no, because we only map mime types to pickle jar or default clipboard if we decided format is fine 16:30:56 bo: if it's in the pickle jar, you can get it. native apps need to be updated to put it there 16:31:16 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. 16:31:56 anne: so we should coordinate known types 16:32:46 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 16:33:04 and we can allow that without having to coordinate between browsers 16:33:42 there is no harm to allwoing some formats start in pickle jar and later turn into wellknown format 16:42:04 johannes: is there a way for editors to know that in some browsers that there will be more sanitization than in others? 16:43:13 johannes: could we add some language that makes it clear that authors need to test in all 4 browsers? 16:43:27 bo: some language like that would be ok 16:44:29 anne: we could specify that the custom types are unsanitized. for the builtin types, browsers may want to do some sanitization. 16:44:59 bo: we have agreement on unsanitized bucket 16:45:43 bo: we have some disagreement on the wellknown types 16:46:30 anne: we should write into spec that for wellknown types, browsers may do sanitizing. 16:46:57 bo: we would like to take a hint from author on what is asked for (sanitized or non-sanitized)? 16:47:11 wenson: how about meta tag 16:47:33 bo: yeah not our preferred option 16:47:49 anne: unsanitized option shouldn't exist forever 16:48:59 wenson: compatiblity gap can be described in documentation, potentially outside of spec. 16:49:49 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. 16:50:34 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. 16:50:52 wenson: mozilla and safari some to agree 16:51:15 bo: I think you are further appart when it comes to goals 16:51:29 anne: I am much more positive 16:52:16 anne: it sounds like having more mime types and not an "unsanitized option" has more support 16:52:37 bo: we can take a look at a counter proposal. but we will not be driving it. 16:53:39 bo: we need to then evaluate whether it will work on our current customers. 16:54:27 bo: we will not slow down to get consensus here as we are already implementing and shipping and have tried for a long time. 16:55:53 anne: there was a lot of cirticism right from the start. 16:56:04 bo: this process has taken a long time 16:57:17 bo: normal problem with standardization process - it's important for one group to ship something and other's don't see it as urgent. 16:57:56 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. 16:58:44 wenson: why not just work a meta tag? will that not solve it? 17:00:00 wenson: the meta tag would just be temporary 17:00:36 bo: I think there is an assumption that read never needs sanitized content 17:01:04 wenson: that would allow blink to ship something right away 17:01:33 anne: I have to leave 17:02:53 bo: it sounds like an "out" as it just means you don't have to change anything. 17:03:25 bo: it's possible the situation changes if this is something mozilla would be willing to work on 17:03:39 bo: I can come back with feedback from Microsoft on this 17:04:27 smau: it has been difficult to bring feedback as the spec has been in a weird state. 17:05:04 smaug: it was in a very early state 17:05:29 bo: that's fair 17:06:14 bo: actions: anne write counter-proposal. we will consider metatag. 17:07:24 Nice experience on using jit.si 17:08:14 RRSAgent, please make logs public. 17:08:23 agree good Jitsi worked well 17:08:34 RRSAgent, please make logs public 17:08:51 Zakim, please end the meeting 17:08:51 As of this point the attendees have been GameMaker 17:08:51 RRSAgent, please draft minutes v2 17:08:51 I have made the request to generate https://www.w3.org/2022/01/27-editing-minutes.html Zakim 17:08:56 I am happy to have been of service, johanneswilm; please remember to excuse RRSAgent. Goodbye 17:09:00 Zakim has left #editing 17:09:25 excuse RRSAgent 17:09:36 zakim, excuse us 17:09:41 Zakim, excuse us