meeting notes 2024-02-08

[17:01] <dandclark> scribe: dandclark
[17:01] <dandclark> present+
[17:02] <Comandeer> present+
[17:02] --> edgar (~uid184785@c080ddbb.public.cloak) has joined this
channel.
[17:02] <dandclark> topic: Spec defines 'double' in a way that collides
with WebIDL #89
[17:02] <dandclark> github: https://github.com/w3c/edit-context/issues/89
[17:02] * github-bot OK, I'll post this discussion to
https://github.com/w3c/edit-context/issues/89 (Spec defines 'double' in a
way that collides with WebIDL).
[17:02] <snianu> present+
[17:02] <smaug> present+
[17:03] <johanneswilm> present+
[17:03] <smaug> dandclark: double isn't actually hooked up with anything,
so there is no known use for it
[17:04] <smaug> dandclark: if it is not used, we should just remove it
[17:04] <smaug> johanneswilm: is use cases appear in the future, we can add
more types
[17:05] <smaug> johanneswilm: anyone fine removing it
[17:05] <smaug> yes
[17:05] <smaug> https://github.com/w3c/edit-context/issues/88
[17:05] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[17:05] <smaug> topic https://github.com/w3c/edit-context/issues/88
[17:05] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[17:06] <smaug> dandclark: the spec doesn't handle the bounds of the
selection start/end
[17:06] <smaug> dandclark: should we clamp or throw ?
[17:07] <smaug> smaug: Range does throw
[17:08] <smaug> johanneswilm: throwing error could make it easier to find
issues in js code
[17:10] <smaug> johanneswilm: it would be good to give a way to find js
issues
[17:10] <smaug> smaug: are there APIs which do clamp?
[17:11] <smaug> dandclark: maybe the right answer is to throw
[17:12] <smaug> dandclark: hopefully we can find that no one relies on the
current behavior
[17:12] <smaug> dandclark: and also if we can find counter example where
clamping does happen
[17:14] <smaug> smaug: by default we should try to follow existing old APIs
[17:14] <smaug> dandclark: I'll investigate
[17:14] <smaug> topic: https://github.com/w3c/edit-context/issues/81
[17:14] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[17:14] * github-bot Successfully commented on
https://github.com/w3c/edit-context/issues/89
[17:15] <smaug> dandclark: we should allow backwards selection
[17:15] <smaug> smaug: sounds good
[17:16] <dandclark> topic: Support navigator clipboard inside SW
[17:16] <dandclark> github: https://github.com/w3c/editing/issues/458
[17:16] * github-bot OK, I'll post this discussion to
https://github.com/w3c/editing/issues/458 (Support navigator.clipboard
inside of Service Workers).
[17:17] <dandclark> PatrickKettner: I'm part of webextensions group
[17:17] <dandclark> ...: focused on standardizing extensions across webplat
[17:17] <dandclark> ...: Move to manifest V3 is a major focus. Move
background script from dom to ServiceWorker.
[17:18] <dandclark> ...: One of the difficulties with migrating is
clipboard access
[17:18] <dandclark> ...: Would be great if navigator.clipboard was exposed
for use in extensions
[17:18] <dandclark> ...: I have a collection of use cases for web and
extension-based SWs
[17:18] <dandclark> smaug: I'd be curious to know use cases for web
[17:19] <dandclark> ...: Without those we can't move anything through spec
[17:19] <dandclark> ...: Discussed this with Rob from Mozilla
[17:19] <dandclark> PatrickKettner: We could extend it, want to try
inheriting from the web first
[17:19] <dandclark> ...: Recent use cases were enterprise-focused. E.g.
clipboard exfiltration
[17:20] <dandclark> ...: Sync data that's been copied to their backends.
Not user-focused, it's site focused.
[17:20] <dandclark> ...: It's polyfillable. SW allows a more centralized
place though
[17:20] <dandclark> ...: Other use case is clipboard syncing
[17:21] <dandclark> ...: Useful for education, certain cooporate
environments. Tutorial where it's useful to push complex stuff to clients'
clipboards.
[17:21] <dandclark> ...: Polyfillable without SW but simpler if exposed on
SW.
[17:21] <dandclark> ...: Last one is about data security, encrypting
clipboard contents.
[17:21] <dandclark> ...: If it's sensitive, encrypt it with a key
[17:22] <dandclark> ...: Only the owner of certain content could understand
secure content being copied, or doesn't work outside secure environment
[17:22] <dandclark> ...: Or, automation based of clipboard content. Things
happen automatically when copy certain types of content. E.g. rewrite link
to markdown.
[17:22] <dandclark> ...: Or rewrite rich text content
[17:22] <dandclark> ...: Checking current value of text is, certain website
can make sure you're copying it to certain format
[17:22] <dandclark> ...: There's lots of examples, I can go over more.
[17:23] <dandclark> smaug: Many of the use cases you can do without SW.
[17:23] <dandclark> ...: Everything we can do without this change. This
change is about improving developer experience.
[17:23] <dandclark> PatrickKettner: Everything we can do without this
change. This change is about improving developer experience.
[17:23] <whsieh> q+
[17:24] <dandclark> ...: This is about reducing complexity, ensuring things
are more well-built, less code has to be written.
[17:24] <dandclark> whsieh: I'm not too familiar with Chromium
implementation, do they show prompt when you access clipboard without user
gesture?
[17:25] <dandclark> PatrickKettner: For extensions, you have separate
permissions model. Extension dev has to request clipboard read and write.
There is standard and optional permission.
[17:25] <dandclark> ...: Current message mentions can read/write all
contents on clipboard.
[17:25] <dandclark> ...: We encourage people to use optional, which is jit.
User gets a prompt they can approve/reject
[17:25] <dandclark> ...: On the web there's a popup prompt. User can
rescind at any time.
[17:26] <dandclark> ...: There isn't a prompt every time. That's just my
understanding, could be incorrect
[17:26] <dandclark> whsieh: Our model (webkit) is prompt every time
[17:26] <dandclark> ...: That data is read off clipboard
[17:26] <dandclark> ...: If you copy password, could be problematic
[17:27] <dandclark> ...: May want a policy where if you've granted
permissions through webextensions, with higher bar for user trust, we could
take that as hint of trust to let the page read/write
[17:27] <dandclark> PatrickKettner: My understanding is that's how it works
now with execCommand in WebKit
[17:28] <dandclark> whsieh: Depends on how you trigger paste. cmd-v is one
case, if  you trigger via button it's different. Depending on where user
mouse is, show an option to paste. Doesn't seem this works well for SWs.
[17:28] <dandclark> PatrickKettner: For extensions, we have UI affordance
[17:28] <dandclark> ...: In Chrome, it's like other extensions permissions
prompts. Not modalized, it's just a popup
[17:29] <dandclark> ...: From dev point of view, you can check if you have
permission, do something in accordance with that.
[17:29] <dandclark> whsieh: That sounds good
[17:29] <dandclark> PatrickKettner: That could be a requirement
[17:29] <dandclark> smaug: But SWs don't need to be bound to any UI
[17:29] <dandclark> PatrickKettner: If no UI, you could reject, say if you
don't want to trust ServiceWorker if there's no UI
[17:30] <dandclark> ...: Microsoft did work to have clipboard permission
prompting be supported in Chrome
[17:30] <dandclark> ...: If you dont' want to trust that a background SW is
trustworthy you can automatically reject
[17:31] <dandclark> estade: Don't think we'd allow access to clipboard
without UI affordance, and no way to have affordance with ServiceWorker.
[17:32] <dandclark> estade: Blanket access doesn't require user gesture.
But regardless of what you press, page has to be focused. That's by design.
Difficult to get stakeholders to align on changing that.
[17:32] <dandclark> ...: Having something constantly monitor your clipboard
seems open to abuse.
[17:33] <dandclark> ...: There are other ways to do this, e.g. in
enterprise you could have an app that monitors this (not web app)
[17:33] <-- snianu (~snianu@c080ddbb.public.cloak) has left this server
(Ping timeout: 180 seconds).
[17:34] <dandclark> ...: E.g. we just made it so extensions when they have
extensions permission can use web api because it's effectively the same
thing. But we've historically moved back and forth on the exact behavior we
want with respect to permissions. Pretty sure the focus requirement is a
pretty hard one.
[17:34] <dandclark> ...: Comparing to DataTransfer, stance of security team
has been that we'd unlaunch it if we could.
[17:35] <dandclark> ...: It seems tough to me to extend this to offscreen,
invisible pages.
[17:36] <dandclark> PatrickKettner: That's fair. And we can solve these
problems without work in this group. But we'd like to have reduced the code
devs write from hundreds of lines to 1.
[17:36] <dandclark> johanneswilm: You mentioned execCommand to get access
to clipboard. Is there any alternative to that?
[17:36] <dandclark> PatrickKettner: No that's the only option
[17:36] <dandclark> ...: Extensions have a number of services; content
scripts, background scripts...; if you are content script, they have full
DOM access. So can get navigator.clipboard.
[17:37] --> snianu (~snianu@c080ddbb.public.cloak) has joined this channel.
[17:37] <dandclark> ...: But non-DOM surfaces (workers), you don't have
access. YOu only have execCommand, through a special invisible-DOM thing
where you have an RPC connection into the DOM environment. Offscreen
document is a hack to get things that don't exist in SW available in SW.
[17:38] <dandclark> ...: In Google there's extensions that are clipboard
managers, they have to use offscreen document and execCommand.
[17:38] <dandclark> johanneswilm: I understand the security concerns but
getting rid of that usage of execCommand seems good to have on the horizon
somehow.
[17:38] <dandclark> smaug: I don't know why that needs to be use, you'd
stiill have clipboard API access in hidden document
[17:38] <dandclark> PatrickKettner: Don't have access.
[17:39] <dandclark> ...: The read/write permissions don't get passed to
navigator permissions. In Chrome 122 this changed; you need document focus,
and we can't have that in this case. Have access to it, but can't use it
because don't have focus.
[17:40] <dandclark> snianu: If authors can get accesss to clipboard
somehow, what's the security concern? It's not like with focus command
you're preventing web authors from accessing clipboard. Authors will just
use execCommand.
[17:40] <dandclark> ...: and we won't be able to remove them. We're trying
to move partners to clipboard APIs by giving them more capabilities.
[17:41] <dandclark> estade: clipboard API is more ergonomic, want to
switch. But just because you can do something with execCommand it's very
insecure. The fact you can make an extension that monitors clipboard state
without using browser is bad, shouldn't continue. It's a sec vuln that
could blow up on HN or a blog somewhere. Have to find some way to have
equivalent to the intent behind user focus to narrow this down.
[17:42] <dandclark> ...: Good use case is when user clicks button and that
accesses clipboard. But current proposal allows much wider use cases. Need
to look at making things more restrictive over time, not more lax.
[17:42] <dandclark> ...: Have to capture the fact that the user clicked the
button, make sure they know what's going on.
[17:42] <dandclark> ...: There's a way to achieve this but I don't think
it's as easy as just exposing the API
[17:43] <dandclark> PatrickKettner: Agree, we'd love to get rid of
execCommand. Would block it if we had another way. In Chrome, certain APIs
are tied to user-generated events. Can restrict that here. Where would that
be defined?
[17:44] <dandclark> estade: Sounds promising. Guessing it's a webextensions
thing. Document itself doesn't have context of user interaction
[17:44] <dandclark> PatrickKettner: You can tie to user action though event
chain
[17:44] <dandclark> ...: Not sure about requirements are needed to proceed
on that.
[17:45] <dandclark> smaug: Right now the clipboard api is on user
activation which is tied to <missed>.
[17:45] <dandclark> PatrickKettner: It's running in offscreen doc, like
invisible tab. WIthin that it's a standard docuemnt that has RPC back to
server
[17:45] <dandclark> smaug: There are APIs in serviceworker that would
require user interaction?
[17:45] <dandclark> PatrickKettner: Yes
[17:46] <dandclark> estade: Lots of extension APIs, why does this need a
separate page? Why is that not directly an extension API <missed>
[17:47] <dandclark> PatrickKettner: Say you wanted to copy current crbug
URL to clipboard. Content script could inject that into page, but now it
has full access to page. SW doesn't have full access to page, only to
clipboard. So scope is reduced security-wise.
[17:47] <dandclark> ...: Today when you're implementing that, have to do
iwth off-screen document and execCommand.
[17:47] <dandclark> estade: So only two actions can be triggered when press
button are inject content script...there's not long list of APIs that can
be triggered
[17:48] <dandclark> ...: When you have page action icon and user selects
it, I would guess that there's 50-100 extension APIs you can just call in
response to that. But sounds like all you can do is run some JS.
[17:48] <dandclark> PatrickKettner: You can call extension APIs when you do
those things, and run arbitrary JS.
[17:48] <dandclark> PatrickKettner: The only non-web-standard thing in
offscreen document is send message to SW.
[17:49] <dandclark> PatrickKettner: Dev flow is you do something in content
script, send message to SW, everything has to be serialized
[17:50] <dandclark> johanneswilm: How do we proceed? Question is should web
extensions group be involved in this?
[17:50] <dandclark> PatrickKettner: I can represent that group and Google
extensions team as intermediary.
[17:50] <dandclark> ...: Main concern is understanding if this is definite
no, definite yes, or not sure yet
[17:50] <dandclark> ...: If this group doesn't like this we can look into
extending extensions API
[17:50] <dandclark> smaug: So far I haven't heard too convincing use cases
for the web.
[17:51] <dandclark> ...: Based on discussion with Rob earlier, think it
makes more sense to do this on webextensions side first, bring it back if
there are more compelling use cases for web.
[17:51] <dandclark> PatrickKettner: Webkit position?
[17:51] <dandclark> whsieh: I agree with Olli.
[17:52] <dandclark> topic: [Delayed Clipboard Rendering] Privacy issue
while reading data for web custom types
[17:52] * github-bot Successfully commented on
https://github.com/w3c/editing/issues/458
[17:52] <dandclark> github: https://github.com/w3c/editing/issues/439
[17:52] * github-bot OK, I'll post this discussion to
https://github.com/w3c/editing/issues/439 ([Delayed Clipboard Rendering]
Privacy issue while reading data for web custom types).
[17:52] <dandclark> snianu: TAG had feedback on this, had same privacy
concern. Proposed mitigations that don't work. I responded in thread.
[17:53] <dandclark> ...: At this point, issue has been dragging for too
long. Privacy issue is from web custom format. Can we do this just for
builtin formats?
[17:53] <dandclark> ...: Can standardize all the infrastructure for this
separately without web custom formats, privacy issue doesn't have to block
that.
[17:54] <dandclark> ...: Can we separate the two things? Make web custom
formats as separate proposal, move forward with that separately if we find
some mitigation.
[17:54] <dandclark> ...: But that wouldn't require API changes to async
clipboard API.
[17:55] <dandclark> ...: Proposal is standardize for builtin formats.
Secondary proposal to restrict custom formats to just 1. But if that's
controversial let's resolve to just support builtin formats for delayed
clipboard rendering.
[17:55] <dandclark> smaug: Concern is if we do it only for builtins, and
then want to do it later for custom formats, what if API shape needs to be
different.
[17:55] <dandclark> smaug: Could be confusing.
[17:56] <dandclark> snianu: With the builtin formats, only change is to add
callback instead of Blob.
[17:57] <dandclark> ...: If we dont' have calbacks for web custom formats,
if we find some other way for devs to do that it would be some other API.
To support web custom format we could add overloaded constructor. It's
easily extendable. Don't have to change entire API surface.
[17:57] <dandclark> smaug: If there's something that can support both use
cases, hopefully we can build something forward-compatible.
[17:57] <dandclark> snianu: Only thing that changes is the callback.
[17:58] <dandclark> snianu: Say we add more security restrictions, that
doesn't need a web API change. If you use web custom format  you are
subject to these restructions, if not it just works.
[17:58] <dandclark> snianu: Builtin formats add real value.
[17:58] <dandclark> ...: And we're adding more.
[18:00] <dandclark> whsieh: Hard to imagine case where having callback
wouldn't be backwards-compatible.
[18:00] <dandclark> whsieh: Provides value in short term.
[18:00] <dandclark> smaug: Maybe.
[18:00] <dandclark> whsieh: Even then, callback could return object we add.
[18:01] <dandclark> smaug: Would be nice to see concrete proposal. E.g. I'd
like to see using streams to write the data.
[18:01] <dandclark> snianu: Looking into streams doesn't have to block the
current API.
[18:02] <dandclark> snianu: Proposal is the same, just don't allow custom
formats.
[18:02] <dandclark> smaug: Callbacks were resolved, but what they actually
do was not resolved.
[18:03] <dandclark> ...: Producing data as blob requires lots of memory,
streams could solve that.
[18:03] <dandclark> snianu: Could extend it to support streams in callback.
[18:03] <dandclark> snianu: Could also talk to partners about this.
[18:04] <dandclark> snianu: Some are interested in that. COuld do it
separetely , doesn't have to block this.
[18:04] <dandclark> smaug: That's fine. Let's get issue filed.
[18:04] <dandclark> snianu: I'll file issue and link it.
[18:05] <dandclark> RESOLVED: Privacy concern doesn't exist if we only
support built-in formats. We'll do builtins first and then custom formats
in the future.
[18:06] <snianu> https://github.com/w3c/clipboard-apis/issues/191
[18:06] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").

-- 
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org