Meeting minutes
Hello, is this the right channel for Web Share?
<krosylight> yes
Agenda
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]
https://github.com/w3c/web-share/pull/184
Mozilla, the canShare() API was not fit for purpose
Marcos: We did a prototype of the replacement.
Marcos: Also want to limit what types of files can be shared.
e.g. executable files.
<marcosc> https://github.com/w3c/web-share/issues/178
Eric: canShareFiles() discussion might be blocked on the topic of whether we have a list of approved file types.
Approved file types
Marcos: Worried about being able to share a .exe file.
(or some other executable type
)
Marcos: We can either look at the file extension or the MIME type.
Marcos: Easy path is that we ask the sharer to include the MIME type. Hard path is MIME sniffing.
Marcos: We would probably want to go to the cheap solution, MIME sniffing is too complex.
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.
Marcos: Web-to-web is fine, but yes this is a problem for native.
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?
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.
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.
Marcos: We can let browsers add their own types to the allowlist.
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).
Marcos: Comes back to the issue we had on iOS where the underlying native apps / OS were allowing things they shouldn't be.
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.
Matt: Anything you might want to download, you might want to email. And anything you want to email, you should be able to share.
hartmanng: Similarly, you might share random stuff to Google Drive or a storage app. Not necessarily just images and videos.
Eric: Chrome security, when shipping Web Share, told us they wanted us to treat it like a download.
Eric: Chrome is still filtering by filetype (with a fairly small allowlist of image formats).
Eric: We might still block executables, but we could change to a blocklist, as we transition to launch on desktop platforms.
Marcos: On Gecko, I think we just allow any download.
Marcos: We still have a use case for something like canShare.
https://github.com/w3c/web-share/issues/127 <- file types bug
NotWoods: There is an "allowed to download" check in HTML. Should we use that?
<NotWoods> https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks
<NotWoods> https://html.spec.whatwg.org/multipage/links.html#allowed-to-download
I commented on #127:
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.
Marcos: We need a way to know if you are allowed to share a thing before you try to share it.
Marcos: Also for the basic feature detection of "is file sharing supported at all?"
Marcos: Need to decide if it's OK to have canShare() or if we should do something different.
Matt: Diff between canShare (already implemeted but not specced) and canShareFiles (proposed).
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.
Eric: Proposed canShareFile: Can be used to know if you can share a particular MIME type or format.
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.
<marcosc> examples: https://github.com/w3c/web-share/issues/108#issuecomment-697689527
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.
Marcos: "canShareFiles" just its existence shows that file sharing is supported.
Eric: TAG wanted our methods to be on an object, not just a bunch of them at the top-level.
Marcos: We can push back on that.
Marcos: We're not super polluting the navigator space.
Hoch: Other OSes have added small extra one-off fields, like "formatted text" or "HTML".
Hoch: Similar to how Clipboard API keeps adding more subtypes.
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.
[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.]
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?
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.
Tiger: Proposed overloading canShare with a string.
<ericwilligers> canShare('files', 'text/cvs')
<marcosc> canShare("thing", options)
canShare('files') by itself returns whether feature is supported
canShare('files', ___) tells you about the details
<marcosc> ... if (navigator.canShare.length > 1) ...
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).
Eric: Not too worried about legacy stats.
Eric: We can add usage counters for each usage.
Scheme restriction.
<marcosc> https://github.com/w3c/web-share/issues/178
Eric: We (Google) didn't want to limit to just http/https.
Marcos: Let's just solve the immediate problem, and then leave it open to opening up schemes later.
Hoch: Windows share contract has two fields, one that takes everything, one that takes only http/https. Highly recommend taking the latter.
<ericwilligers> https://github.com/w3c/web-share/issues/178#issuecomment-697064051
[Resolved to continue research offline.]
Matt: Living standard?
Marcos: Either approach works.
Matt: Concern that it will be hard to get PRs in.
Alex: Features can be designed in separate "feature editions" and then the PR is a formality to merge it in.
We're at time, thanks everybody.
<mgiuca> Did that work?
<marcosc> meeting adjourned
<mgiuca> ^
<mgiuca> Cheers, bye.
<marcosc> thanks for scribing mgiuca!
<beverloo> always good to see you, marcosc! :)