RFP: Web Share API about standards-positions HOT 32 CLOSED

Hi all, sorry I haven't commented lately. (And note, I'm not part of Mozilla so my opinion is void w.r.t. implementation, but since we're discussing the merits of the specs themselves, I thought I'd participate.)

Let's start with do no harm. That is, we should oppose anything that is actively harmful for the web, that's part of the point of this whole repo/process.

Agreed.

I believe WebShare in its current form is an (unfortunate) example of this (per the silos in the screenshot from @marcoscaceres above).

To be fair, that screenshot is from Apple's proprietary share system, totally unrelated to Web Share.

Firefox has a similar share system built right into the browser (sorry this is a screenshot from an old Firefox):

You might say these affordances allow the user to easily share into large content silos like Facebook and Twitter. Firefox has a (proprietary) API allowing any service to create its own share target in here, so it's better than Apple which has a fixed list.

On Chrome (for Android) we have a similar share button, which shares to any installed app. That does take you away from the Web, into Android land, but it's an open ecosystem there; it's just as easy to share into an email client than into Facebook.

So far, this has nothing to do with Web Share. Web Share is merely an API for triggering this UI that already exists in most browsers, and sharing data into any targets the user agent wants to provide (the Web Share spec isn't opinionated about what the targets should be). So whether Web Share is biased towards large content silos is a product of the user agent's choices.

Thus, I think Web Share (even ignoring Web Share Target) does more good than harm. To understand this, we have to separate the concepts of "web vs native apps" from "open ecosystems vs content silos". Yes, Web Share without WST does tend to take users away from the web in Chrome's Android implementation (though that wouldn't be true in Firefox, which would presumably use the existing share targets, which are web sites). But your argument here is not about taking users from the web into native applications. It's about encouraging users to share content into vertical silos like Facebook and Twitter.

I would argue that Web Share is a net positive because it replaces the status quo, which is this:

(i.e., every web page directing users to a fixed set of targets, typically only the 2--4 big social players)

with a generic open-ended API that, at worst, presents the user with the same fixed choice of social services, but at best, allows the user to choose their own service. (At the discretion of the user agent.) Even right now, without Web Share Target standards, Firefox could hook navigator.share up to its entire ecosystem of share targets, keeping users within the web and able to choose their own endpoints.

So even while we don't yet have a standard solution for specifying share targets on the web, Web Share is a decentralizing technology, not centralizing.

I'm also confident in the good intentions from the authors, having had a chat with @mgiuca nearly 2 years ago about it.

Thanks. I do very much agree with your goals, and I believe the proposed API furthers those goals. I am not doing this because someone at Google told me we need a share API. I'm doing this because I fundamentally believe in decentralization through user choice of service.

So with respect to the above, I would rather not merge the two specs, since the latter is significantly more complex than the former. I am not trying to make the case that "Yes, Part 1 will make things worse but (a possibly-never-to-exist) Part 2 will make things all better." Rather, I think Part 1 will make things better right now, and then Part 2 will make things even better.

from standards-positions.

I just wanted to voice my support for this Web Share API proposal, and reference earlier work by Mozilla in this area with the Web Activities API.

The very simple Web Share API proposed here is a pragmatic approach to this long standing feature request for the web.

Extending this proposal to facilitate the sharing of different file types (e.g. images, audio and video), perhaps with an additional field in the shareData dictionary to specify a MIME type would make it even more useful, but starting with the basic feature set may be a good idea.

Also note the companion Web Share Target API proposal which isn't quite as far along, but would be essential to ensure the "sharing" doesn't just flow in one direction from the web to native apps.

from standards-positions.

Intent to experiment for Web Share.

I'm going to update our position to "worth prototyping", as we are currently working out how we could implement this in a platform neutral manner.

from standards-positions.

Ok, here is my personal position on this - but if enough people agree, then we can make it official. If you have a different opinion, then add it (please "don't @ me"!).

Since forever, web applications have co-existed with native applications. The Web Share API is an important (in Marcos' opinion, not Mozilla's position) addition to the Web because:

1. it provides more utility for users in that they can share specific data between web pages and native applications. In Marcos' opinion, this MAY make the web more useful to users. Particularly if they can share data between web applications, and native applications or system services (e.g., sharing directly with a contact, putting the data on the clipboard - see screenshot below showing iOS support for Web Share.).

2. it provides a potential gateway that could allow Web Applications to share data with other Web Applications (via the Web Share Target API - though this remains unproven as far as interoperability goes).

1 above is immediately of value to a web browser, in that it allows specific sharing of web site data with native applications that will never be Web Applications (e.g., some system applications).

Since 2017, Apple has dropped supporting the Silos (Twitter, LinkedIn, and Facebook) as native share targets in macOS. Hopefully they realized that further entrenching those companies through preferential treatment was not a good idea (just a guess). However, there is a risk that other OSs (e.g., Windows 10) will give preference to its own products and (web) services.

A browser could implement its own Web Share UI - but I personally think that wouldn't be as rich or as useful as the OS provided UI. However, if OSs decide never to allow web applications to be share targets, then that's not super great... so that's the trade-off: build a custom web share UI (potentially not as useful - but worth prototyping?) or be at the mercy of OS-level Share (potentially harmful to Mozilla).

I would personally defer to the OS, because of the utility that it already provides. Case in point, iOS:

from standards-positions.

Some more info and links:

• Firefox bugs:
  • 1312422
  • 1402369
• This has since launched to stable on Chrome for Android. [Intent to ship thread]
• Chrome platform status
• Web Platform Tests
  • These are mostly manual tests (due to the nature of the UI). If implementing in Firefox, please ensure these tests pass manually. Let me know if you think there is a problem with the test.
• A major real-world test: m.twitter.com uses navigator.share. Just open any tweet, open its arrow menu, and click Share.

The main concern I have is with the API appearing and disappearing depending on registered share targets. I've requested that the API just have canShare() method on it, which could be user configurable to just always return false.

Thanks. Does that correspond to Issue 59 which you just filed? Let's continue the discussion there.

Really looking forward to seeing alternative implementations of this!

from standards-positions.

Thanks Marcos and Ben!

Re Web Share Target: please link to the WICG copy of this repo, not my personal copy (which may be out of date at any given time if I forget to push to it).

from standards-positions.

A bunch of us met at the Mozilla All Hands last week in Austin, including @snorp, @andreasbovens, @mixedpuppy, @annevk, @st3fan, and @garvankeeley (apologies if I forgot anyone!) to discuss the spec. This represented the DOM Team, Android/iOS Fennec, Products, and Firefox Extensions.

IIRC, we concluded that the current approach taken by the API seems to address the use cases we've had in mind, and we would encourage @dbaron mark this as under consideration (unless someone is willing to step up now and get formally assigned to work on this, in which case we should mark this as participating).

from standards-positions.

Just a quick note that the Firefox team removed the mentioned proprietary Social API in 2017 (because nobody was really using it and it wasn't fun to maintain):

https://www.fxsitecompat.com/en-CA/docs/2017/social-api-has-been-completely-removed/

from standards-positions.

Not sure who these questions are phrased at (me?). I'm not a Mozillian but I can answer on behalf of Google:

@dbaron:

I think browsers currently offer sharing UI for the current page's URL. So I think a bunch of what the Web Share API does is allow (a) pages to offer UI that triggers it rather than depending on in-browser UI and (b) allow the share to be a URL other than the current one and (c) allow a little more control over the textual data in the share. Right now I'm not especially convinced by the argument that opening this up in those ways encourages content silos -- but I'd be interested in specifics of what you think would happen in the presence of this API that wouldn't happen without it.

I think we see a fairly consistent desire from websites to put share UI inside the site client area, not just rely on use of the browser UI for sharing. Currently this practice of in-client-area share buttons encourages large content silos like Twitter and Facebook, since the site will only show buttons to share to specific, popular destinations. Web Share allows the user agent to show any share destination, which can be tailored to the user's preferences (e.g., hook into Firefox's in-browser share system).

I was trying to remember how Web Share Target worked... and before I looked at the spec again I was thinking it would use serviceworker-based registration. That made me wonder what the distinction is between things that should be registered via web app manifests and the things that should be registered via service workers. I don't immediately know the answer to that, but I feel like there ought to be one.

WST is registered in the manifest, and has nothing per se to do with service workers. It just opens a browser page at a specific URL (constructed by inserting query parameters into a URL). We're aware of certain specific use cases where people want to catch these shares programmatically in a service worker, rather than forcibly having a page opened. That's something we want to address separately in the launch event, something we also discussed at TPAC in the SW WG.

from standards-positions.

Without claiming expertise in this area, I've reviewed the specification and raised a few small concerns with the design of the API (mostly just nits) - but overall, I think it's worth supporting from a standards perspective.

The main concern I have is with the API appearing and disappearing depending on registered share targets. I've requested that the API just have canShare() method on it, which could be user configurable to just always return false.

On the plus side, there are already Web Platform Tests for the API. And Google has run an origin trial for it. We can reach out to @mgiuca if we need additional information about the trail and site adoption.

I'd also note that there is interest from the Fennec side. Hi, @andreasbovens!

We probably want input from @mixedpuppy, as he is really the authority on sharing at Mozilla. And @annevk has given this a lot of thought too, so would be great to get a 👍 from him.

from standards-positions.

Thanks. Does that correspond to Issue 59 which you just filed? Let's continue the discussion there.

I'd forgotten that we had discussed that issue some time ago. I've withdrawn my objection - current design works ok.

from standards-positions.

Sorry to miss this discussion during All Hands. From what I have read about the current approach so far, it seems to bias or at least designed specifically for (in API and UX) large content silos, reinforcing the default centralization hegemony. I'd rather not even take this "under consideration" until we see evidence that the use-case of "share to your own website" is demonstrated by spec advocates, and preferably as easily as any "share to a social media silo" use-case.
Because if that's not the case (i.e. this API lowers friction purely for content silos), then I would say as an API it is actually bad for the web.
To be clear, I'm optimistically hoping that my worries are disproven.

from standards-positions.

Sorry to miss this discussion during All Hands. From what I have read about the current approach so far, it seems to bias or at least designed specifically for (in API and UX) large content silos, reinforcing the default centralization hegemony.

This is certainly true - in as far that a user agent supporting this API would only enable preregistered silos. For example, this is what Safari/OSX provides today (to be clear, Safari doesn't support the API... just provides share defaults via the OS):

Now, the separation between the Share API and the Share Target API is intentional because we want to incrementally evolve both specs. Similarly to Payment Request API and Payment Handler API, with Web Share, we get a (relatively) quick win by enabling "the silos", while also opening the opportunity for anyone to become a share target.

Because if that's not the case (i.e. this API lowers friction purely for content silos), then I would say as an API it is actually bad for the web.

Without the Share Target API, you would be absolutely correct. However, Share Target API is being developed in parallel for that reason.

To be clear, I'm optimistically hoping that my worries are disproven.

I think we all want to see Share Target succeed also, but it's a matter of resourcing and picking our battles. With Web Share, @mgiuca chose to initially attempt to solve just a small piece of the puzzle (which - hopefully I'm not mischaracterizing anyone's position here - those involved in the meeting concluded did a reasonable job, given what we understand of the use cases). Now, however, we may opt to evolve both standards together... but we know from Web Share and Web Activities that this can quickly spin out of control.

Thoughts about how we should proceed?

from standards-positions.

Let's start with do no harm. That is, we should oppose anything that is actively harmful for the web, that's part of the point of this whole repo/process.

I believe WebShare in its current form is an (unfortunate) example of this (per the silos in the screenshot from @marcoscaceres above).

I'm also confident in the good intentions from the authors, having had a chat with @mgiuca nearly 2 years ago about it.

In those two years however, vertical content silos have only become more of a problem, for the web, and frankly, whole societies/democracies.

I'd rather not help pour more fuel on the centralization trash fires.

from standards-positions.

Given the Share Target spec, which is supposed to address the centralization concerns, what would be the ideal way for this work to proceed (or for Mozilla to be in a position whereby we would support this work)?

One option might be to simply merge the two specs (?).

from standards-positions.

You're asking two (overall) questions in this thread:

1. " RFP: Web Share API " from the top.

IMO today's answer (which we should commit, and like any position, be open to changing when concerns change) : "harmful"

2. "what would be the ideal way for this work to proceed (or for Mozilla to be in a position whereby we would support this work)?"

We do not need to answer this "forward-looking" question to answer the first "present-state" question.

And this github issue is perhaps not the best place to discuss spec improvement suggestions. It's likely better to file a separate issue noting the above concerns on the spec's repo and link to it here (rather than discuss the issue in this repo), which would also better encourage spec advocates to participate in the discussion.

Aside: regarding the analogy "Similarly to Payment Request API and Payment Handler API" - the payment "silos" are not actively harming the web, unlike the social media silos.

from standards-positions.

@dbaron, unless you have follow up questions, could you kindly evaluate the arguments presented here and deliberate on a position?

@martinthomson, could you kindly assign @dbaron to this issue? I don't seem to have rights to do that.

from standards-positions.

We also removed the unsupported registerContentHandler which had some overlap in use-cases too but no other vendor wanted to support it.

from standards-positions.

I imagine that if there were a standardized way for a web site to announce itself as being able to be used as a sharing service, it would actually eliminate the current fracturing of the experience we currently have, with different browsers using different techniques to offer sharing (if they offer it at all). Certainly it would open up the sharing experience on Apple's browsers (assuming they choose to implement it), which currently cannot be expanded by a web site without a browser extension on Mac (or at all on iOS).

from standards-positions.

Sorry for the lag in responding here.

One initial thought is that I think we should probably list a position both for the Web Share API and for the Web Share Target API, because if we don't list both, a position on one is likely to be misinterpreted as applying to both. I looked at the latter somewhat recently as part of w3ctag/design-reviews#221; the former had a TAG review a while back in w3ctag/design-reviews#179.

I'll try to dig in further next week.

from standards-positions.

So briefly coming back to this after a while of not looking at it:

• I think browsers currently offer sharing UI for the current page's URL. So I think a bunch of what the Web Share API does is allow (a) pages to offer UI that triggers it rather than depending on in-browser UI and (b) allow the share to be a URL other than the current one and (c) allow a little more control over the textual data in the share. Right now I'm not especially convinced by the argument that opening this up in those ways encourages content silos -- but I'd be interested in specifics of what you think would happen in the presence of this API that wouldn't happen without it.

• I was trying to remember how Web Share Target worked... and before I looked at the spec again I was thinking it would use serviceworker-based registration. That made me wonder what the distinction is between things that should be registered via web app manifests and the things that should be registered via service workers. I don't immediately know the answer to that, but I feel like there ought to be one.

from standards-positions.

Does this diminish the value of the URL we show in the location bar as the subject/target that is shared?

The primary interface in browsers is based on using what is shown in the location bar. Giving sites the ability to share something else reduces the incentive to set window.location to something usable.

Not a big concern, but maybe worth considering the secondary effects.

from standards-positions.

Filed #176 for Web Share Target specific position.

I'd like to send an "intent to experiment" for this to dev-platform. I've been playing around with implementing Web Share locally, and will probably prototype this together with the Android folks. Not sure what will come of this yet, but the DOM side is pretty straight forward to implement.

from standards-positions.

I've translated my post about why we need a wider implementation of Web Share API, especially on Firefox.
See https://dascritch.net/post/2019/06/26/We-need-Web-Share

I think a polyfill WebExtension can do the job.

from standards-positions.

Thanks for your input @dascritch.

from standards-positions.

Is there a way to add methods in Navigator() ? (yes, i'm trying to create a webext polyfill)

from standards-positions.

Hi @dascritch, this is not the best place to have that particular discussion. If you’d like to create a polyfill, please see, for example: https://javascriptplayground.com/writing-javascript-polyfill/

from standards-positions.

Sorry for not cycling back to this one again for so long.

I think the main contention here is whether to mark this as worth prototyping or important.

I think I've tended to use important rather narrowly -- I've used it to describe things that we see as the important standards efforts we should be putting effort into to improve the web. While I think this is worth doing (though I also think it has some risks), I think it falls short of the standard I've been using for important so far. And I say that as someone who's a pretty frequent user of the feature (when using Twitter's UI for it, in Fenix), although I'd note that my prior workflow for doing that was to use in-browser UI in Fennec that I think is less accessible in Fenix.

I think there are some questions here about whether this reduces the importance/relevance of what's in the URL bar, but it is definitely something that sites want to show their own UI for, and that users are probably accustomed to seeing site UI for based on their experiences in native apps. So at least given the idea that we want to make it easy for users to migrate seamlessly from a native app to a web app (rather than, say, emphasizing the distinctions between native and web a bit more, which is a reasonable thing we might want to do), I think this seems like a good thing. But even if we do want to emphasize differences between native and web more, I don't think it's particularly a barrier to that.

from standards-positions.

I had incorrectly interpreted important as: "Mozilla are investing significant time/resources implementing and specifying this feature, so this must be important to Mozilla" - rather than a broader definition about overall value and importance to the Web. Since I wrote the above, I've adopted your definition.

I'd be happy to support a "worth prototyping", given that we have indeed already prototyped this feature (on Fenix and Window). It's still unclear if/when we will pref on this feature, but at least we've gone as far as fully prototyping it.

from standards-positions.

Should we expect Firefox to support Web Share API any time soon? I can't find more recent activity from Mozilla other than this 'needs prototyping' decision. https://mozilla.github.io/standards-positions/#web-share

The related 'Web Share Target API' is also 'worth prototyping' but doesn't have a corresponding Bugzilla bug. https://mozilla.github.io/standards-positions/#web-share-target

from standards-positions.

@gobengo please use the Bugzilla bug for Web Share API to check for info about Firefox support in particular. In this case it looks like it was implemented in Firefox 71: https://bugzilla.mozilla.org/show_bug.cgi?id=1312422 (also linked from the standards-position dashboard entry via the wrench).

You can also check the corresponding MDN page (also linked from the dashboard entry) if you only wanted to check whether or not Firefox (or another browser) supports it: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share#browser_compatibility

For Web Share Target API, I checked https://mozilla.github.io/standards-positions/#web-share-target and it also has a wrench icon link to its corresponding Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1476515

(Originally published at: https://tantek.com/2022/032/t1/)

from standards-positions.

Thanks Tantek. I reactivated a bugzilla account to post on this issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1312422#c44

I think that the bugzilla bug linked to from this dataset for Web Share API does not correspond to implementation of the Web Share API in all Firefox supported browsers, but just to some initial work ('DOM implementation') that set the stage.

from standards-positions.