Concerns Regarding Privacy and Functionality of Web Share API

[SoniEx2]

The Web Share API allows websites to identify when the user does a share action, in a way they otherwise couldn't.

We feel like sharing should not be something websites can invoke/detect, but should instead be a part of the browser somehow, perhaps in the native context menu.

[mgiuca]

Please see the Privacy Considerations section of the spec.

When we designed this API, we were extremely conscious of leaking private information about the user's system to the website in question. There is no way for the site to learn which apps are installed and capable of receiving a share, nor is it possible for the site to learn the identity of the app that was chosen. They can only know that a share took place.

That doesn't materially give the site any privacy information. Sure, it could be useful for gathering metrics about how many times an article was shared, but it doesn't let the site know which apps the user is using or who they shared it with. I think the utility of having the site be able to put a share button in context far outweighs the potential information a site can get by learning that the user clicked a share button.

Also, compare it to the situation we had (and still have on many sites today) without Web Share: sites build their own share button with a selection of target sites like Twitter, Facebook, etc, and then they know exactly which site you shared it to, and can customize the URLs to track links back from those destination sites. Web Share gives the site strictly less information than a button they build themselves.

I'll close this as it isn't actionable other than to drop support for the API altogether.

[SoniEx2]

that is too much information.

they're just gonna put web share under an additional menu, anyway (perhaps an "Other" option alongside "Twitter", "Facebook", etc). so they get to have all the ultratracked popular share targets and they get information about external sharing.

which also makes it inconvenient to use external share targets, due to the added step.

the solution is regulation, not Web Share API. yes, we are requesting that you consider dropping the Web Share API altogether.

[mgiuca]

I can't help websites placing the Web Share invocation as "other" alongside existing share targets (and yes they do do it). All I can do is provide an alternative API.

What you're essentially (perhaps rightly) saying is that web developers won't use the privacy-restricted API because they want to gather more data than the API provides. That means the API is the opposite of spyware - it's literally something that developers are rejecting or deprioritizing because it doesn't help them spy on users. (The antidote to that is that on the flip side, it adds more value to users, because they can choose to share it with non-web apps like chat.)

they get to have all the ultratracked popular share targets and they get information about external sharing.

The data point they get when the user picks "other" is zero. "User picked an alternative share target". That doesn't give any information about the user, not even fingerprinting bits, because it doesn't tell you anything about their device capabilities.

the solution is regulation, not Web Share API

The primary goal of the Web Share API is not the privacy benefit (that is just a requirement of being a web API). It's the interoperability benefit of letting the user choose any share target they wish, no matter how obscure. The goal is to avoid entrenchment of large social websites like Facebook and Twitter from being enshrined as the "only share targets" on millions of other sites, and instead allow the user to pick which apps they want to share to.

Regulation can solve the tracking issue. In the mean time, we are building interop technology with built-in privacy.

we are requesting that you consider dropping the Web Share API altogether

This API has been available for seven years and is now a W3C REC and standard in all major browsers. You haven't presented any compelling privacy argument to drop it.

[SoniEx2]

the interop solution is to implement the share button in browsers' context menus.

meanwhile, regulation can solve the "website picks share targets" problem.

with regulation, we could have best interop with best privacy.

[saschanaz]

While your suggestion for better browser integration sounds nice, unshipping an API needs stronger compelling reasons than "this might be a problem". You have to prove that this API enables significant real-world harm against users.

[SoniEx2]

it looks like this API was originally developed as part of Google Chrome's EEE-the-web project. personally, embracing it feels like being complicit in google's EEE project, which would be a form of real-world harm against users.

[saschanaz]

By real world harm I mean harm that caused by this API, not whatever the broader idea behind it (which I don't think is provable).

[SoniEx2]

okay, but, just as old cases can get reopened after judges are convicted of corruption, it would be helpful to re-evaluate Web Share in the context of google's EEE project.

in this context, yes, Web Share gives websites one additional piece of information: that the user likes to share things externally. and yes, this can be used to serve ads, and yes, it can also be used for political repression ("oh you're sharing stuff with unapproved services" kinda stuff).

there are arguments for not trusting it.

[marcoscaceres]

the interop solution is to implement the share button in browsers' context menus.

All browsers already implement share in their UIs. A user can choose either the Web Share API on the page, or they can choose to share from the share button in the browser UI.

@SoniEx2, as Working Group Chair, I kindly remind you of the W3C's Positive Work Environment at W3C: Code of Conduct. Statements like "embracing it feels like being complicit in google's EEE project" are out of line. Please refrain from making assertions and saying working group members are somehow "complicit" in whatever you think "google's EEE" is.

[SoniEx2]

huh? :raised_eyebrow:

google's approach to undermining privacy has been extensively documented by privacy advocacy groups. there have been news reports as recent as this week of google's activities. if we do something and we find out a hypothetical BadGuy benefits from it, that does, in fact, make us complicit and we have a responsibility to deal with it. if it's a project we maintain, we would consider our options up to and including shutting down the project, if necessary. and we would welcome folks bringing up the issue so that we can be aware of it. we would hope we can expect the same from the W3C.

we're pretty sure the Code of Conduct is meant to protect the kinds of statements we're making here, particularly as per section 3.3 of the Code.

[marcoscaceres]

Ok, let's do it this way: can you present the Working Group with evidence that the Web Share API is being used nefariously or in some complicit manner to undermine privacy? And if so, how often is it being used in that way.

[SoniEx2]

preliminary evidence shows websites do attach tracking information to links shared via Web Share API, which are not otherwise present in normal navigation, e.g. ?feature=share in youtube links. (youtube in specific doesn't appear to show a predefined set of popular share targets alongside Web Share API, at least.)

we want them to stop doing that. that's the entire issue.

(any sharing API, be it Web Share API or some URI-based alternative, would allow them to attach this tracking information. the only solution is to not have one, and create the expectation of finding and, through the native context menu, sharing the permalink of a post or page.)

[marcoscaceres]

I’m not sure how that is tracking? That like saying ?feature=button is tracking when someone clicks on a button. Same with a link.

The fact that someone shared a link or data through some feature doesn’t constitute any sort of significant privacy violation. If it was attaching personally identifiable information or an ID or something, then that would be concerning.