21:58:36 RRSAgent has joined #webapps 21:58:36 logging to https://www.w3.org/2020/10/27-webapps-irc 21:59:09 Meeting: WebShare API 21:59:20 Chair: Marcosc 21:59:45 rrsagent, make log public 21:59:55 rrsagent, draft minutes v2 21:59:55 I have made the request to generate https://www.w3.org/2020/10/27-webapps-minutes.html marcosc 22:03:38 krosylight has joined #webapps 22:04:07 beverloo has joined #webapps 22:04:16 PJ has joined #webapps 22:04:27 ericwilligers has joined #webapps 22:04:29 mgiuca has joined #webapps 22:04:52 Hello, is this the right channel for Web Share? 22:04:53 hartmanng has joined #webapps 22:05:28 Hoch_ has joined #webapps 22:05:55 yes 22:06:11 https://github.com/w3c/web-share/issues/162 22:06:36 scribe: mgiuca 22:07:06 TOPIC: Agenda 22:07:08 Agenda: https://github.com/w3c/web-share/issues/162#issuecomment-711626840 22:07:19 The canShare() method has been shown to be somewhat unfit for purpose, with one implementer reluctant to ship it (Gecko). Some alternatives are in the works - in particular #184 or some variant of it (Gecko is experimenting with canShareType()). Concerns have also been raised about sharing arbitrary files with share targets. At least one implementer would like to see the list of possible types restricted by expanding #185. The proposal is to on[CUT] 22:07:30 Topic: https://github.com/w3c/web-share/pull/184 22:07:53 Mozilla, the canShare() API was not fit for purpose 22:08:06 Marcos: We did a prototype of the replacement. 22:08:22 Marcos: Also want to limit what types of files can be shared. 22:08:26 e.g. executable files. 22:08:36 https://github.com/w3c/web-share/issues/178 22:09:21 q+ 22:09:50 Eric: canShareFiles() discussion might be blocked on the topic of whether we have a list of approved file types. 22:10:01 TOPIC: Approved file types 22:10:33 Marcos: Worried about being able to share a .exe file. 22:10:40 (or some other executable type 22:10:40 ) 22:10:49 Marcos: We can either look at the file extension or the MIME type. 22:11:25 Marcos: Easy path is that we ask the sharer to include the MIME type. Hard path is MIME sniffing. 22:11:26 q+ 22:11:46 Marcos: We would probably want to go to the cheap solution, MIME sniffing is too complex. 22:12:50 mgiuca: What's to stop the sharer from setting a mime type image/jpeg on a .exe file, Windows isn't going to care about the MIME type so we shouldn't rely on it. 22:13:00 Marcos: Web-to-web is fine, but yes this is a problem for native. 22:14:29 Matt: Are there any examples of native share targets that can be exploited by this method? Don't they mostly just take the files up to the server, not save them locally? 22:16:39 Matt: I would like to recommend that we don't mandate this in the spec, but we add a recommendation to treat it like a download. User agents can warn based on the file type. 22:20:24 GameMaker has joined #webapps 22:23:09 PJ: I don't want to block use cases that come up organically such as users in emerging markets sharing APKs directly to each other because of low internet quality. 22:23:29 Marcos: We can let browsers add their own types to the allowlist. 22:24:09 PJ: We should let OS mechanisms to protect users from running untrusted code (e.g., Android would make the user turn on a setting to sideload an APK). 22:24:45 Marcos: Comes back to the issue we had on iOS where the underlying native apps / OS were allowing things they shouldn't be. 22:25:00 Hoch: Sending to an email app, you might want to share an APK or an app to an email to share it to someone else. 22:26:08 Matt: Anything you might want to download, you might want to email. And anything you want to email, you should be able to share. 22:27:25 hartmanng: Similarly, you might share random stuff to Google Drive or a storage app. Not necessarily just images and videos. 22:27:38 Eric: Chrome security, when shipping Web Share, told us they wanted us to treat it like a download. 22:28:30 Eric: Chrome is still filtering by filetype (with a fairly small allowlist of image formats). 22:28:48 Eric: We might still block executables, but we could change to a blocklist, as we transition to launch on desktop platforms. 22:29:46 Marcos: On Gecko, I think we just allow any download. 22:30:13 Marcos: We still have a use case for something like canShare. 22:30:57 https://github.com/w3c/web-share/issues/127 <- file types bug 22:31:28 q+ 22:32:20 NotWoods: There is an "allowed to download" check in HTML. Should we use that? 22:32:31 https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks 22:32:34 https://html.spec.whatwg.org/multipage/links.html#allowed-to-download 22:32:44 q- 22:33:49 I commented on #127: 22:33:50 TPAC 2020: Resolved to make a change to the spec to let browsers determine their own rules for blocking based on file type. We can discuss further having a formal list of allowed / blocked types, but no consensus on that. @NotWoods suggests https://html.spec.whatwg.org/multipage/links.html#allowed-to-download as a starting point. 22:34:36 Marcos: We need a way to know if you are allowed to share a thing before you try to share it. 22:34:49 Marcos: Also for the basic feature detection of "is file sharing supported at all?" 22:35:11 Marcos: Need to decide if it's OK to have canShare() or if we should do something different. 22:36:19 Matt: Diff between canShare (already implemeted but not specced) and canShareFiles (proposed). 22:36:43 Eric: canShare, you pass a dictionary, the same format as share(), and the UA looks at that to see if it understands the files member. 22:36:59 Eric: Proposed canShareFile: Can be used to know if you can share a particular MIME type or format. 22:37:18 The difference is that you don't need to actually *have* a file to pass to canShareFile, you can just ask a general question about a MIME type. 22:37:29 examples: https://github.com/w3c/web-share/issues/108#issuecomment-697689527 22:38:36 Marcos: If you just want to check if you can share files or not, you have to pass a dictionary with some file in it. 22:38:55 Marcos: "canShareFiles" just its existence shows that file sharing is supported. 22:39:48 Eric: TAG wanted our methods to be on an object, not just a bunch of them at the top-level. 22:40:02 Marcos: We can push back on that. 22:40:11 Marcos: We're not super polluting the navigator space. 22:42:20 Hoch: Other OSes have added small extra one-off fields, like "formatted text" or "HTML". 22:42:30 Hoch: Similar to how Clipboard API keeps adding more subtypes. 22:42:45 Hoch: I don't see any on the horizon for share, but wouldn't be surprised if in 5 years we've added some more top-level types. 22:48:16 [Some discussion about polluting the namespace. Consensus that having a hypothetical handful of canShareX methods in navigator would be "bad-ish" but we can live with it.] 22:48:41 Hoch: Would it be OK if in the future people only use the existence of canShareX to see if X is supported, rather than actually calling it? 22:49:05 Matt: Yes, that's fine. Standard feature detection checks whether the method name exists. If you want to know a detailed check, you call the method and see what it tells you. 22:49:37 Tiger: Proposed overloading canShare with a string. 22:49:39 canShare('files', 'text/cvs') 22:49:43 canShare("thing", options) 22:51:14 q+ 22:52:16 canShare('files') by itself returns whether feature is supported 22:52:28 canShare('files', ___) tells you about the details 22:52:37 ... if (navigator.canShare.length > 1) ... 22:52:58 Matt: I like this API design. One concern is that it makes it harder for us to deprecate the legacy usage because we can't easily distinguish legacy usage (passing a dict) from the new usage (string). 22:53:06 Eric: Not too worried about legacy stats. 22:53:11 Eric: We can add usage counters for each usage. 22:54:52 Topic: Scheme restriction. 22:55:08 https://github.com/w3c/web-share/issues/178 22:55:41 Eric: We (Google) didn't want to limit to just http/https. 22:56:02 Marcos: Let's just solve the immediate problem, and then leave it open to opening up schemes later. 22:56:39 Hoch: Windows share contract has two fields, one that takes everything, one that takes only http/https. Highly recommend taking the latter. 22:58:04 https://github.com/w3c/web-share/issues/178#issuecomment-697064051 22:59:08 [Resolved to continue research offline.] 22:59:13 Matt: Living standard? 22:59:28 Marcos: Either approach works. 23:00:47 Matt: Concern that it will be hard to get PRs in. 23:01:12 Alex: Features can be designed in separate "feature editions" and then the PR is a formality to merge it in. 23:02:10 We're at time, thanks everybody. 23:02:21 scribe: nobody 23:02:25 Did that work? 23:02:28 meeting adjourned 23:02:40 ^ 23:02:43 Cheers, bye. 23:02:46 rrsagent, draft minutes v2 23:02:46 I have made the request to generate https://www.w3.org/2020/10/27-webapps-minutes.html marcosc 23:02:55 thanks for scribing mgiuca! 23:05:22 always good to see you, marcosc! :) 23:06:15 present+ 23:06:40 present+ Matt Giuca 23:06:57 present+ Kagami Rosylight 23:07:19 present+ Eric Willigers 23:07:40 regrets+ Martin Thompson 23:07:54 present+ Peter Beverloo 23:08:04 present+ Alex Russell 23:08:25 present+ Tiger Woods 23:08:35 rrsagent, draft minutes v2 23:08:35 I have made the request to generate https://www.w3.org/2020/10/27-webapps-minutes.html marcosc 23:09:38 present+ Hoch Hochkeppel 23:10:32 present+ PJ 23:10:55 present+ hartmanng 23:11:10 rrsagent, draft minutes v2 23:11:10 I have made the request to generate https://www.w3.org/2020/10/27-webapps-minutes.html marcosc