Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Well-known url endpoint naming #59

Closed
johnivdel opened this issue Dec 11, 2020 · 6 comments
Closed

Well-known url endpoint naming #59

johnivdel opened this issue Dec 11, 2020 · 6 comments
Assignees
Labels
layering Layering additional data and functionality on top of PCM

Comments

@johnivdel
Copy link

Given the discussions on #30 and #56, would make sense to update the URL endpoint naming to reflect the same principles? Namely, the other attributes have dropped the "ad" nomenclature.

For the Event-level Conversion Measurement API we are proposing using the following URL endpoints:

/.well-known/trigger-attribution for the path used to trigger attribution for a click.

/.well-known/report-attribution for the path where the report will be sent.

Currently, the same path is used for both triggering attribution and sending reports, /.well-known/ad-click-attribution. Assigning separate paths for these would make their usage/meaning more straightforward when being used across different context.

cc @johnwilander @csharrison

@johnwilander
Copy link
Collaborator

This currently sits as /.well-known/private-click-measurement in our implementation.

@csharrison
Copy link

/.well-known/trigger-attribution for the path used to trigger attribution for a click.

/.well-known/report-attribution for the path where the report will be sent.

This scheme looks good to me. @maudnals FYI

@eligrey
Copy link
Member

eligrey commented Dec 16, 2020

.well-known URIs coexist with each other and the suggested endpoints seem somewhat vague at first glance.

A good compromise could be to put these both under a common .well-known path:

  • /.well-known/private-click-measurement/trigger-attribution
  • /.well-known/private-click-measurement/report-attribution

@maudnals
Copy link

maudnals commented Dec 16, 2020

If a common well-known path is chosen as @eligrey suggests, maybe we could land on a common path that is agnostic to the API name?
Some ideas:

  • /.well-known/attribution/trigger-attribution and /.well-known/attribution/report-attribution
  • /.well-known/measurement/trigger-attribution and /.well-known/measurement/report-attribution // Maybe other/future measurement-related APIs could be nested under /measurement

@johnwilander johnwilander self-assigned this Jan 11, 2021
@johnwilander johnwilander added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 11, 2021
@johnwilander
Copy link
Collaborator

I've given this a great deal of thought since our last call and I want to go with scoped well-known locations. The reason is that there will be differences in how PCM and Conversion Measurement API work and we need to be able to design accordingly, without blocking each other from making progress. For instance, we are talking about third-party reporting endpoints stated in a well-known location (#57) and we are talking about fetching fraud prevention tokens and signing certificates from a well-known location (#27). This only introduces a scoping path element which an be replaced and the rest can be reused as best we can.

My preference is therefore:

  • /.well-known/private-click-measurement/trigger-attribution
  • /.well-known/private-click-measurement/report-attribution

… as proposed by @eligrey.

@johnwilander johnwilander removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 21, 2021
webkit-commit-queue pushed a commit to WebKit/WebKit that referenced this issue Jan 25, 2021
…attribution

https://bugs.webkit.org/show_bug.cgi?id=220902
<rdar://problem/73550632>

Reviewed by Brent Fulgham.

The discussion in W3C Privacy CG concluded that we should use distinct
well-known URL paths for websites triggering attribution and for the
browser reporting attribution
(privacycg/private-click-measurement#59).

This patch changes the one location to these two:
/.well-known/private-click-measurement/trigger-attribution
/.well-known/private-click-measurement/report-attribution

Source/WebCore:

Existing tests updated.

* loader/PrivateClickMeasurement.cpp:
(WebCore::PrivateClickMeasurement::parseAttributionRequest):
(WebCore::PrivateClickMeasurement::reportURL const):

Tools:

* TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKitCocoa/EventAttribution.mm:
(TestWebKitAPI::TEST):

LayoutTests:

* http/tests/privateClickMeasurement/resources/redirectToConversion.php:
* http/tests/privateClickMeasurement/resources/redirectToConversionOnIPAddress.php:


Canonical link: https://commits.webkit.org/233305@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271799 268f45cc-cd09-0410-ab3c-d52691b4dbfc
bertogg pushed a commit to Igalia/webkit that referenced this issue Feb 1, 2021
…attribution

https://bugs.webkit.org/show_bug.cgi?id=220902
<rdar://problem/73550632>

Reviewed by Brent Fulgham.

The discussion in W3C Privacy CG concluded that we should use distinct
well-known URL paths for websites triggering attribution and for the
browser reporting attribution
(privacycg/private-click-measurement#59).

This patch changes the one location to these two:
/.well-known/private-click-measurement/trigger-attribution
/.well-known/private-click-measurement/report-attribution

Source/WebCore:

Existing tests updated.

* loader/PrivateClickMeasurement.cpp:
(WebCore::PrivateClickMeasurement::parseAttributionRequest):
(WebCore::PrivateClickMeasurement::reportURL const):

Tools:

* TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
(TestWebKitAPI::TEST):
* TestWebKitAPI/Tests/WebKitCocoa/EventAttribution.mm:
(TestWebKitAPI::TEST):

LayoutTests:

* http/tests/privateClickMeasurement/resources/redirectToConversion.php:
* http/tests/privateClickMeasurement/resources/redirectToConversionOnIPAddress.php:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@271799 268f45cc-cd09-0410-ab3c-d52691b4dbfc
johnivdel added a commit to WICG/attribution-reporting-api that referenced this issue Feb 18, 2021
This aligns with privacycg/private-click-measurement#59 (comment), which indicates that we should use a path component which indicates these are being used for the Attribution Reporting API
@johnwilander johnwilander added the layering Layering additional data and functionality on top of PCM label Feb 23, 2021
@johnwilander
Copy link
Collaborator

This has now been updated in the spec: f7e51be

JonWBedard pushed a commit to WebKit/WebKit that referenced this issue Apr 7, 2021
    PCM: Use different well-known locations for triggering and reporting attribution
    https://bugs.webkit.org/show_bug.cgi?id=220902
    <rdar://problem/73550632>

    Reviewed by Brent Fulgham.

    The discussion in W3C Privacy CG concluded that we should use distinct
    well-known URL paths for websites triggering attribution and for the
    browser reporting attribution
    (privacycg/private-click-measurement#59).

    This patch changes the one location to these two:
    /.well-known/private-click-measurement/trigger-attribution
    /.well-known/private-click-measurement/report-attribution

    Source/WebCore:

    Existing tests updated.

    * loader/PrivateClickMeasurement.cpp:
    (WebCore::PrivateClickMeasurement::parseAttributionRequest):
    (WebCore::PrivateClickMeasurement::reportURL const):

    Tools:

    * TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/Tests/WebKitCocoa/EventAttribution.mm:
    (TestWebKitAPI::TEST):

    LayoutTests:

    * http/tests/privateClickMeasurement/resources/redirectToConversion.php:
    * http/tests/privateClickMeasurement/resources/redirectToConversionOnIPAddress.php:

    Canonical link: https://commits.webkit.org/233305@trunk
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271799 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/232923.56@safari-611-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@271858 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JonWBedard pushed a commit to WebKit/WebKit that referenced this issue Apr 12, 2021
    PCM: Use different well-known locations for triggering and reporting attribution
    https://bugs.webkit.org/show_bug.cgi?id=220902
    <rdar://problem/73550632>

    Reviewed by Brent Fulgham.

    The discussion in W3C Privacy CG concluded that we should use distinct
    well-known URL paths for websites triggering attribution and for the
    browser reporting attribution
    (privacycg/private-click-measurement#59).

    This patch changes the one location to these two:
    /.well-known/private-click-measurement/trigger-attribution
    /.well-known/private-click-measurement/report-attribution

    Source/WebCore:

    Existing tests updated.

    * loader/PrivateClickMeasurement.cpp:
    (WebCore::PrivateClickMeasurement::parseAttributionRequest):
    (WebCore::PrivateClickMeasurement::reportURL const):

    Tools:

    * TestWebKitAPI/Tests/WebCore/PrivateClickMeasurement.cpp:
    (TestWebKitAPI::TEST):
    * TestWebKitAPI/Tests/WebKitCocoa/EventAttribution.mm:
    (TestWebKitAPI::TEST):

    LayoutTests:

    * http/tests/privateClickMeasurement/resources/redirectToConversion.php:
    * http/tests/privateClickMeasurement/resources/redirectToConversionOnIPAddress.php:

    Canonical link: https://commits.webkit.org/233305@main
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@271799 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/232923.56@safari-611-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-611-branch@271858 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
layering Layering additional data and functionality on top of PCM
Projects
None yet
Development

No branches or pull requests

6 participants
@eligrey @johnwilander @csharrison @maudnals @johnivdel and others