Meeting minutes
<GameMaker> link?
https://
Have files avilable for datatransfer event
johanneswilm: (summarizes the thread)
whsieh: I don't think there was any privacy/security reason why it wasn't added...
… seems reasonable to add to the spec
<Zakim> BoCupp, you wanted to say that files should be read via async clipboard
BoCupp: Do we think that async clipboard applies? (Do they want to use that?)
… our intent is to make datatransfer more of a legacy api over time. Suspect we can't remove it, but would like to discourage use
whsieh: I agree with Bo's comments. Also have some other questions about the post.
… there's text uri and files. Was the question about both?
johanneswilm: Don't recognize the issue author... but want to get some common ground here--do we add to spec or not?
… understanding that this has just been shipped in firefox recently (and webkit)?
… I either want it in all the places, or none of them (want consistency)
… I don't want a dev to be suprised if its not supported in a browser.
… assume Firefox implemented because chrome also had it...
… so what's the reason that Chrome has it?
… could it be removed?
… or should we add a big note saying you can't rely on it.
whsieh: One drawback of async clipboard... it's async even to read types.
… if a webdev would like to preventDefault then they always have to do so, then get the async clipboard afterward?
… b/c one a sync and the other async--could be challenging in some circumstances.
BoCupp: what's the current status?
johanneswilm: Not in spec, but shipped in chromium.
… so, BoCupp you want to remove it?
… can this happen right away? Or we should just add it.
Do we think the spec should document reality (or idealized reality)
johanneswilm: This spec was a bit aspirational from the beginning...
… so now we're just trying to adjust the spec to implementations.
BoCupp: I would like to see a more precise test showing what the interoperable set is.
… We don't have to unship if it's been shipped.
… We could encourage webkit to add, or note its deprecation.
… on a call to getData we'd have to block the thread, go to the browser process, and grab the data (not ideal).
johanneswilm: First we aught to have a test to confirm.
… Second we want to see what the scope is (what is meant by this)
… Third want to understand if it can be removed. If not, then we should note in the spec that it may be removed in the future.
Action: johanneswilm to put together a test to confirm.
whsieh: does chrome/edge actually support text/uri-list?
BoCupp: I think support was just added.
whsieh: last I checked it didn't.
snianu: There's a chromium bug tracking, but not sure anyone's started working on it yet. Were some issues with how the list was populated.
… available in setData but not async clipboard
… definitely not in async clipboard.
whsieh: in copy/paste links, it doesn't seem to work in latest chrome 94.
… (just tested)
… to satisfy the use case, I think we should support text/uri-list in the async clipboard
BoCupp: agreed.
do we have a date to discuss #122?
github: https://
BoCupp: I do have a demo to look at this...
… I can paste a link that is a pre-read
johanneswilm: I think we need a demo to show the proposal, and to see the problems (as implemented in Safari) and then have a span of time to review the details and form an opinion.
… can we get the demos within the next few weeks before the next meeting?
BoCupp: I don't think we need to wait a month.
johanneswilm: So we can get a demo shortly?
Action: BoCupp to provide demo showing potential alternatives and problems for the composition commands
completed requested testing...
johanneswilm: I just wanted to inform the group that I completed test results and have a proposal to update the note.
Continue discussion on clipboard APIs
github: https://
BoCupp: Not sure this is the right issue...
<BoCupp> https://
BoCupp: Ah, in a different repo: https://
github: https://
BoCupp: we were able to resolve half the discussion. Agreed to add a non-normative note on the format that is used to communicate with native apps (and vice-versa)
… from native->web: current read behavior of nav.clipboard, you get sanitized content.
… for exchange with office apps (or similar) the fidelity is too low (loss of formatting, for example)
… so we want to add an "unsanitized" option to the read API.
… (trying to match ctrl+v)
… we want raw content from the pickle jar (if exist) or from well-known HTML format.
… if you get that raw data, then native->web works great even for apps not yet updated.
… (also want to talk about web->native)
… when writing, there is also sanitization happening today.
… if we can't support well-known HTML format write, then our partners won't be able to support the API because it cuts off existing support already provided by the setData legacy API.
… today in all browser setData is a raw-write for HTML to clipboard. If they lose that in async clipboard it blocks them.
… (it's a downgrade for existing apps already having migrated to async clipboard)
whsieh: As discussed there are a few privacy/security issues at play (not fully address from last time)
… in webkit the getData/setData, for these webkit treated as a security fix--was surprising to hear this was only limited to one of them.
… on copy/paste of content to native apps, they can reach into the pickle jar. So this can already work without a sanitized write.
… Without any explicit Api changes
… there are privacy issues native->web copy/paste.
… e.g., Word does add some things (like filepaths) into the clipboard and could expose directory structure to the web, and would be a non-starter for unsanitized read.
BoCupp: Problem: some existing native apps would take a long time to update (they only read from the well-known format today). They can't simultaneously use the new API (when avaiable) and the old one. (They have to pick one.)
… This then creates a blocker until apps updated to read from new pickle jar.
whsieh: So native app side, they would try to read from pickle jar?
BoCupp: an existing app--doesn't know about the pickle jar yet.
… today they read and get full fidelity.
whsieh: problem is... web pages adopt new API, old version of native apps would get ?
… they can't use both setData AND nav.clipboard.write (it's one or the other)?
johanneswilm: What would happen in that case?
BoCupp: Maybe last write wins? But code is not written to handle that (one overwrites anything else).
… the writes are basically atomic for a write (and the results that get generated)
… might be able to specify how they work together?
… but want to have unsanitized write using the new API.
GameMake_: I understand that new version is not backward compatible... how is this new version back compatible?
… so how does old version of Word work?
… Given a new API (unsanitized write).. How does the old version of word get this today?
BoCupp: Word is coded to read a well-known HTML format. WebApps fills this format today with whatever they want (and it goes through unsanitized).
… using setData API.
… on async write, we started sanitizing content and putting it into the same "slot" that Word reads from.
… am proposing that the write on async clipboard fill the same slot in the same way.
GameMake_: So, when on web, when using new API with unsanitized version, then only the unsanitized version is being written?
… thinking that sanitization was to improve security. So, how does this not become a problem.
BoCupp: threat was for arbitrary (new) formats (never accessible from the web) before. And Apps wouldn't be prepared and would be vulnerable to this. (The web being able to write to those format names.)
… Those were the threats we were concerned about.
… I don't think apps (like Word) aren't aware of the risk, as they are already using the HTML format.
… I think native apps, getting HTML should be ready.
GameMake_: So the new sanitized format flag only work for well-known formats?
BoCupp: the behavior of write not only allows arbitrary mime-types to be written (sanitized), pre-existing well-known types to flow through in the way they did in the past.
… am primarily focused on HTML format write now. (But may want to expand to other well-known, existing types.)
… For read, there must be an explicit option to "give me raw".
… (restating) we built a new API, but customers won't move to it (because it's a loss of functionality available today).
GameMake_: Didn't know why we chose to open the hole...
BoCupp: Agree that we did too much (sanitizing on write for well-known)
GameMake_: Not sure I see the complete problem
… if we were solving for a problem, we can't just ignore that problem...
… but if we bringing this back to a prior state, I could be more supportive.
BoCupp: In the security process, we fix/patch the holes. They've supposedly been addressed in the past (or continue to be so).
… when the async clipboard write was proposed in the prior group (with garykac's proposal), I opposed the change.
… was there a real threat, we would have tried to solve that. But the change wasn't based on a threat, it was just a suggestion.
… If there was a motivation for the change, I'd really like to know what it was.
GameMake_: I definitely want to know what the reason was.
johanneswilm: If Safari was the only one that removed it, then maybe they can tell us what the issue was?
whsieh: Don't know of a specific native app that might have been taken by the exploit.
… Just don't want to expect all native apps (moving forward) to be able to do the sanitization steps.
… It's hard to get that right.
<BoCupp> why would native Word need to worry about stripping onmouseover events?
<BoCupp> that's a web app concern
whsieh: the Browser is in the middle, and should be responsible for sanitizing.
… is also at odds with the compatibility story.
whsieh: to BoCupp, maybe not native word, but perhaps an electron app?
… there are some corner cases we wouldn't expect them to catch.
BoCupp: For electron, they have access to sanitization on read (default) (if they are web-based).
whsieh: this requires them to use the web API...but they aren't limited to that given they are native?
… my understand would be the only way to access the data would be through opt-in unsanitized read.
BoCupp: special meeting to continue this discussion?
… given we're out of time
johanneswilm: I propose we meet again on the 15th.
BoCupp: Sounds fine.
… I do want to make progress... if we're running in circles I don't want to waste folks time.
Action: add a special meeting on October 15th (same time/place)
travis: will just cover this topic on the 15th.
whsieh: I'm sure we can come to some consensus ;-)
Thanks everyone! I think we covered a lot of ground today.
github-bot, end topic