Enable Private Click Tracking, Attribution Reporting API and Ping on `a` tags

[cpauwels]

Description

As the web is transitioning to becoming more private, new technologies are emerging to enable private click tracking and click attribution. This is done with attributes on a link tags. Unfortunately, implementing these private click tracking methods invalidates AMP pages.

Please consider enabling the following attributes on a tags:

• impressiondata
• conversiondestination
• impressionexpiry
• reportingorigin
• attributionsourceid
• attributeon
• ping

Alternatives Considered

None, as adding the attributes renders the AMP pages invalid.

Additional Context

Private Click Measurement spec
Attribution Reporting API spec

This was initially brought up in #34449 , I just started implementing a proof of concept today and saw the page becoming invalid.

[Gregable]

@alanorozco @kristoferbaxter The validation change is easy to do. Would like your approval on the policy of whether or not we want these.

[kristoferbaxter]

Need a chance to review the spec and ask a few questions. I'll try to respond tomorrow.

[kristoferbaxter]

Only one question for @alanorozco, can we verify these attributes do not break linker behaviour for analytics purposes?

Everything else seems like a nice win for privacy on the web.

[alanorozco]

This works fine for me.

✅ Linker query param is added.
✅ Conversion is seen on chrome://conversion-internals/

<a
  href="https://example.com/linkable"
  conversiondestination="https://example.com"
  impressiondata="1283291"
  reportingorigin="https://adtech.example"
  impressionexpiry="864000000"
>
  linkable
</a>
<amp-analytics>
  <script type="application/json">
    {
      "linkers": {
        "proxyOnly": false,
        "enabled": true,
        "destinationDomains": ["example.com"],
        "linker1": {
          "ids": {
            "_foo": "CLIENT_ID(_foo)"
          }
        }
      }
    }
  </script>
</amp-analytics>

However, I'm trying to confirm the actual attribute names to allow in validation, since there was likely an API change. EDIT: See below

[alanorozco]

Chrome will be renaming some of these attributes in version 92, and we should expect the previous naming to stop working.

before	after
conversiondestination	attributiondestination
impressiondata	attributionsourceeventid
impressionexpiry	attributionexpiry
reportingorigin	attributionreportto

I'm still investigating browser support for the other attributes. attributionsourceid, attributeon are supported by WebKit. I'm unable to find info on ping thus far.

[maudnals]

(hi there, Chrome web DevRel here, I'm working on this API, chiming in as @alanorozco pinged me)

• ping is not part of Chrome's Attribution Reporting spec (maybe it's part of other specs). It looks like it's not part of WebKit's latest PCM spec, either (see spec). You should be able to safely ignore it for Attribution Reporting support.
• attributeon has been deprecated in favor of attributiondestination. I can confirm with certainty that attributiondestination is the correct attribute for Chrome. WebKit's spec seems to be using attributiondestination as well.
• I'm unsure about attributionsourceid. It looks like Chrome is using attributionsourceeventid and WebKit attributionsourceid. I'll explore why these are different and whether they ned to be aligned, but if possible in the meantime it may make sense to support both attributes.

[kristoferbaxter]

On the ping attribute, it's also part of the WhatWG html specification.

https://html.spec.whatwg.org/multipage/links.html

The ping attribute, if present, gives the URLs of the resources that are interested in being notified if the user follows the hyperlink. The value must be a set of space-separated tokens, each of which must be a valid non-empty URL whose scheme is an HTTP(S) scheme. The value is used by the user agent for hyperlink auditing.

Making it valid, and potentially ensuring it's a valid space-separated token list of https urls seems like a good idea.

[maudnals]

Closing the loop on attributionsourceid vs attributionsourceeventid: the difference is intentional, please see this discussion for details.

[Gregable]

We don't need it to be https if it's initiated on user action, a href isn't limited to https either.

Are relative URLs legit for these URLs? If not, then I think it's a validator-only change with no verification of the attr value. Otherwise, we also need to ensure that the cache also rewrites.

[Gregable]

@kristoferbaxter for the above questions.

[kristoferbaxter]

Sorry for missing these questions:

We don't need it to be https if it's initiated on user action, a href isn't limited to https either.

If the ping attribute only accepts space-separated https urls, then limiting to https as part of validation could make sense. However, I agree with you that it's enforcing a more specific rule than what the validator is designed for.

Are relative URLs legit for these URLs? If not, then I think it's a validator-only change with no verification of the attr value. Otherwise, we also need to ensure that the cache also rewrites.

Just allowing these attributes makes the most sense, in my opinion. The AMP Validator doesn't enforce HTML Validation broadly and it would be tough to do this consistently.