Bug 222838 – PCM: Align fraud prevention token naming with issue 73 in the Privacy CG repo

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[John Wilander]

The below names for fraud prevention token link attribute, well-known locations, and report fields were suggested in https://github.com/privacycg/private-click-measurement/issues/73 and we should update WebKit’s implementation accordingly.

# Link Attribute

attributionsourcenonce/attributionSourceNonce: This is the random nonce the click source provides so that subsequent requests for signing an unlinkable token can be done with knowledge of the context of the click even though the user has left the click source webpage.

Example: <a href="https://shop.example" attributionsourceid="55" attributeon="https://shop.example" attributionsourcenonce="ABCDEFabcdef0123456789">Link to be measured</a>


# Well-Known Locations

/.well-known/private-click-measurement/sign-unlinkable-token/: This is the well-known location where the browser sends an unlinkable token together with the attribution source nonce to get a token signature.

/.well-known/private-click-measurement/get-token-public-key/: This is the well-known location where the browser fetches the public key associated with the private key used for signing tokens. Note that this key is associated with signatures that validate both unlinkable and secret tokens.


# Attribution Report Fields

source_secret_token: This field in the JSON report will contain the secret token associated with the unlinkable token signed by the click source. Note that the source prefix is needed here to allow for a similar token from the attribute-on website.

source_secret_token_signature: This field in the JSON report will contain the secret token signature associated with the unlinkable token signature from the click source. Note that the source prefix is needed here to allow for a similar signature from the attribute-on website.

Example:

{
  "source_engagement_type": "click",
  "source_site": "https://news.example",
  "source_id": 55,
  "attributed_on_site": "https://shop.example",
  "trigger_data": 10,
  "source_secret_token": <encoded token>,
  "source_secret_token_signature": <encoded signature>,
  "version": 2
}

[John Wilander]

<rdar://75115427>

[John Wilander]

Created attachment 422447 [details]
Patch

[John Wilander]

Comment on attachment 422447 [details]
Patch

Win bot build failure is unrelated.

[Brent Fulgham]

Comment on attachment 422447 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=422447&action=review

I think the patch works as advertised, but I'm a little confused by the source code name changes (at least in the context of the Issue 73).

> Source/WebCore/loader/PrivateClickMeasurement.cpp:227
> +void PrivateClickMeasurement::setSourceSecretToken(SourceSecretToken&& token)

I'm a little confused by the code renaming. If 'sign-secret-token' became 'sign-unlinkable-token', and 'get-unlinkable-token-public-key' became 'get-token-public-key' why all of this flipping of secret and unlinkable? It seems like sourceSecretToken -> sourceUnlinkableToken makes sense, but why didn't "setSourceUnlinkableToken' just become "setTokenPublicKey" or something?

> Source/WebCore/loader/PrivateClickMeasurement.h:298
> +    struct SourceSecretToken {

If this used to represent the unlinkable token, why isn't this now called 'SourcePublicKeyToken' or something?

[John Wilander]

(In reply to Brent Fulgham from comment #4)
> Comment on attachment 422447 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=422447&action=review
> 
> I think the patch works as advertised, but I'm a little confused by the
> source code name changes (at least in the context of the Issue 73).
> 
> > Source/WebCore/loader/PrivateClickMeasurement.cpp:227
> > +void PrivateClickMeasurement::setSourceSecretToken(SourceSecretToken&& token)
> 
> I'm a little confused by the code renaming. If 'sign-secret-token' became
> 'sign-unlinkable-token', and 'get-unlinkable-token-public-key' became
> 'get-token-public-key' why all of this flipping of secret and unlinkable? It
> seems like sourceSecretToken -> sourceUnlinkableToken makes sense, but why
> didn't "setSourceUnlinkableToken' just become "setTokenPublicKey" or
> something?
> 
> > Source/WebCore/loader/PrivateClickMeasurement.h:298
> > +    struct SourceSecretToken {
> 
> If this used to represent the unlinkable token, why isn't this now called
> 'SourcePublicKeyToken' or something?

There are three pieces of data in flight here:
· The public key which is used to generate tokens and validate them.
· The unlinkable token which is sent to the click source website for signing right after a click.
· The secret token which is kept secret in the browser engine until it's time to send the attribution report. This token cannot be linked to the unlinkable token but the signature of the unlinkable token can be transformed to also be valid for the secret token. This is the magic of blinded signatures – you sign one token at Event A and later at Event B receive another token which you've never seen before but with your own signature which proves that you trusted (an) Event A.

I'll go through the names you called out to make sure I didn't mess something up myself.

Thanks for the review!

[John Wilander]

Comment on attachment 422447 [details]
Patch

It looks correct after a check of the names you mentioned, Brent.

[EWS]

Committed r274087: <https://commits.webkit.org/r274087>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 422447 [details].