Add a way to inject metrics into the shared URL

[mgiuca]

FR from Discourse: https://discourse.wicg.io/t/web-share-api-for-sharing-content-to-arbitrary-destination/1561/10

The developer wants a way to automatically insert a query parameter onto the shared URL like "utm_source=$TARGET_APP", which would identify which app the user chose to share to, so that the sending app can gather metrics about where their incoming links are coming from. For example:

1. User is on https://example.com and clicks a Web Share button.
2. The site calls navigator.share with `url: 'https://example.com``.
3. Picker is shown. User chooses Facebook.
4. API injects utm_source=facebook into the URL.
5. User shares a post on Facebook.
6. User's friend clicks the link from Facebook mobile app and friend's browser opens https://example.com/?utm_source=facebook.

This is a bit worrying from a privacy perspective -- the sender is not supposed to know which app the user chose to share to. But this is a lot more indirect because the sender only gets info about the shared app once the friend clicks the link in Step 6, so there's nothing to directly tie the app to the user. Will have to think on this.

This isn't something I'd want to do automatically. I'd want the sender to be able to opt in by adding a new data field to ShareData, e.g., add_target_to_url: 'utm_source'.

My final concern is that we don't have a good scheme to name the target app. I suppose if it's a Web Share Target it would be the full URL to the app's manifest scope. If it's an Android app, it would be the Android package name, etc. So we wouldn't get something as clean as "facebook"; it would be more like "com.facebook.katana" (the Android app). It's also a bit messy because it would be the name of the app the user shared to, not the name of the app the friend clicked the link in (so if the user shared to the Android app, but the friend clicked the link on the web, the utm_source would still show the Android app package name). This all seems very messy.

[PaulKinlan]

Hmm, I think the use-case is not that strong for any change to the API. They could already but their own campaign id on the url that is passed to share, and then look at the referrer from the click in facebook.

(ignore syntax errors below) user a chrome: navigator.share (https://example.com/?utm_source=nativeshare) user a picks facebook and shares user b opens facebook sees link, clicks it. loads page. user b chrome: parses query string, ah native share. parses referrer, ah Android native app. or parses useragent etc etc.

[mgiuca]

mobtec (the requester): "There are no referrer. It will be the first visit. It will be count as direct access."

Not exactly sure what this means, but I think when User B is in a mobile app it won't be possible for the website to discover where it came from.

[PaulKinlan]

Chrome is supposed to receive information about the calling all via an android-app: uri... Lemme go and check if this was implemented (it was supposed to be)

On Wed, Dec 7, 2016, 11:28 PM Matt Giuca notifications@github.com wrote:

mobtec (the requester): "There are no referrer. It will be the first visit. It will be count as direct access."

Not exactly sure what this means, but I think when User B is in a mobile app it won't be possible for the website to discover where it came from.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WICG/web-share/issues/13#issuecomment-265606960, or mute the thread https://github.com/notifications/unsubscribe-auth/AACxxtDcus2j6-FaMjv2Kqpz2WtXCJ0Hks5rF0E4gaJpZM4LF_vp .

[chaoaretasty]

I would be against such an addition to Web Share. Firstly it would be codifying a specific querystring name to referrers which feels wrong to me (Google Analytics isn't the only game in town nor is utm a larger standard).

But that is secondary to the larger privacy concerns. The site being shared might not get the app data but the person the site is shared with is now getting their privacy breached.

Currently encoding this sort of campaign information in a URL is something of a handwave and limited to either direct campaigns, being built by a share button on the site (thus limited to the ones it is built to share) or by a social media site choosing to add their referrer to the URL.

With this change say I share a link with a friend using an app they might not want to be known. Let's also say that it also happens to be a link to a site they are already logged in on. Maybe it's a "married by dating" app and a link to Facebook. My friend follows the link and now Facebook knows they use that given dating app because I just shared a cat pic with them.

Yes currently the referrer header can leak this sort of information but that is under the control of the referring site about itself and the user-agent (and thus also browser extensions). In this scenario the site being shared uses the user-agent to add referral information about a third party application and we've gone from easing an existing pattern to something that leaks new information about a user.

[mgiuca]

I would be against such an addition to Web Share. Firstly it would be codifying a specific querystring name to referrers which feels wrong to me (Google Analytics isn't the only game in town nor is utm a larger standard).

I wouldn't be baking utm_source into the standard. My proposal above was to let the sharing site specify a URL template (I said a dictionary field above: "add_target_to_url: 'utm_source'", but I think it would be better for it to just be a template substitution, like url: 'https://example.com/my_story?utm_source=%{referrer}', for example -- note that utm_source is something that the sharer specifies, not part of the spec; it could be anything).

say I share a link with a friend using an app they might not want to be known. Let's also say that it also happens to be a link to a site they are already logged in on. Maybe it's a "married by dating" app and a link to Facebook. My friend follows the link and now Facebook knows they use that given dating app

Actually it's the inverse. If you are on a dating site and share a cat video to Facebook, well firstly it's likely that you're sharing the URL of the dating site regardless of the referrer feature because the site is going to share a URL into itself to Facebook. If you are on site A and click "share to site B" you are generally going to expose the fact that you use site A to users of site B.

But that aside, the referrer information being added by the UI will be about the target site -- in this case, Facebook. Basically the only new information Facebook is going to get is that it was shared to Facebook. Then later, the dating site will be able to find out that it was shared to Facebook.

The privacy concern is there but it's what I said in my original post, not what you're saying.

Yes currently the referrer header can leak this sort of information but that is under the control of the referring site about itself

My proposal would also be under the control of the referring site, and would not work by default.

Anyway having said that, your feedback is noted and my preference would be to not do this if at all possible.

[awebdeveloper]

If you ask me "chain is as strong as it's weakest link". There are already ways to know the reffer site by many means. This proposal is in no way lowering it further.

[gui-poa]

Hi, all.

Just to let it more clear..

When you share a link by email or whatsapp, they are counted as direct access. So, without an utm_source (in example), is impossible to identify which app brought this access.

Different when you share it by social networks, because they do a redirect before go to the link. m.facebook.com, lm.facebook.com, l.facebook.com, etc...

Thanks.

[ewilligers]

I think this is a bad idea.

Suppose I copy/paste from A to B, and then copy/paste from B to C, then copy/paste from C to A. Neither A or C know that I used site B. This is appropriate. B might be a personal note taking web app. Nobody else needs to know about it.

Now suppose we are using web share, and B is a personal link bookmarking web app. Suppose I web share from A to B, then later web share from B to C, then click the link to return from C to A. This proposal would give site A a way to learn that I used site B.

[mgiuca]

Yep, that's exactly right.

To continue ewilligers@ 's example: if Site B (the Share Target) wants to identify itself, it can add "utm_source=SiteB" onto the URL that it received. Then when the user copies the link out from B to C, it will still be associated with B.

It shouldn't be up to Site A whether site B exposes itself onto the shared URL.

This proposal would give site A a way to learn that I used site B.

I believe this is exactly the use case that's being requested. But it is an anti-pattern, which we don't want to support.

I'm going to close this now.