Hey Martin,
On 3/31/23 3:38 AM, Martin Thomson wrote:
I will note that the current state of the specification does not seem
to match IETF Privacy Pass documents. I think that shipping is
premature on that basis.
Mozilla deferred our position on this because the specifications were
not in a particularly healthy state at the time. That situation
doesn't seem to have changed much.
I think the spec has improved significantly from where it was just a few
months ago, that said...
More concerning is the lack of a widely acceptable key consistency and
correctness mechanism. A more rigorous analysis of the information
transfer properties of the proposed system will be needed before we
can be confident that this is OK to ship.
It would be great if you could file issues with these concerns:
https://github.com/WICG/trust-token-api/issues/new
(I'm sorry Steven that I didn't notice this before I had a chance to
discuss this in person this week, but I've been overwhelmed and
blink-dev isn't something I watch closely.)
On Sat, Mar 18, 2023 at 4:29 AM 'Steven Valdez' via blink-dev
<[email protected]> wrote:
Folks from Mozilla have done some recent analysis on the
privacypass protocol and some supportive of the general protocol,
however we haven't gotten any newer signals on whether the PST
system where some sites are issuers and other sites redeem tokens
is of interest to them. Apple has been pursuing Private Access
Tokens, which is a version of privacypass with the device vendor
acting as the issuing party.
On Fri, Mar 17, 2023 at 12:46 PM 'Mike West' via blink-dev
<[email protected]> wrote:
I'm quite excited to see this ready to ship, thanks for the
work you've put into it over the years.
Both Mozilla and Apple's positions seem dependent upon
analysis of the underlying Privacy Pass protocol. Have you had
additional communication with them about how things are going,
since it's been a while since the initial request in both cases?
-mike
On Friday, March 17, 2023 at 5:35:06 PM UTC+1 Steven Valdez wrote:
Contact emails
[email protected], [email protected], [email protected]
Explainer
https://github.com/WICG/trust-token-api
<https://github.com/WICG/trust-token-api>
NB: We'll rename the repository to private-state-token-api
when it's adopted by the antifraud CG.
Specification
https://wicg.github.io/trust-token-api
<https://wicg.github.io/trust-token-api>
Design docs
https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
<https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit>
Summary
The Private State Token API is a new API for propagating
user signals across sites, without using cross-site
persistent identifiers like third party cookies for
anti-fraud purposes. Anti-fraud methods that rely on third
party cookies will not work once third party cookies are
deprecated. The motivation of this API is to provide a
means to fight fraud in a world with no third party
cookies. The API prevents cross-site identification by
limiting the amount of information stored in a token.
Blind signatures prevent the issuer from linking a token
redemption to the identity of the user in the issuance
context.
Private State Token API does not generate or define
anti-fraud signals. This is up to the corresponding first
party and the token issuers. The API enforces limits on
the information transferred in these signals for privacy
concerns. Private State Token API is based on the Privacy
Pass protocol from the IETF working group
<https://datatracker.ietf.org/wg/privacypass/about/>. It
can be considered as a web-exposed form of the Privacy
Pass protocols.
The Private State Token API was formerly known as the
Trust Token API. It is renamed to more accurately reflect
its functionality.
Blink component
Internals>Network>TrustTokens
NB: As a part of the process of renaming the Trust Token
API to the Private State Token API, the blink component
will also be renamed.
TAG review
https://github.com/w3ctag/design-reviews/issues/414
<https://github.com/w3ctag/design-reviews/issues/414>https://github.com/w3ctag/design-reviews/issues/780
<https://github.com/w3ctag/design-reviews/issues/780>
TAG review status
No concerns, aside from lack of clear interest from other
browsers
Risks
Interoperability and Compatibility
We intend to update the underlying cryptographic and token
issuance protocols to align with the eventual Privacy Pass
standard. This will affect compatibility with the small
number of token issuers. Private State Token API fetch
requests include a token type and version field that
enables backward compatibility while allowing possible
extensions for future token types and versions.While we
will have a standard deprecation path of supporting
multiple versions, we expect this to be easier with this
API as each issuer using this API will need to register to
become an issuer and will provide contact information as
part of that process.
Gecko: Defer
<https://mozilla.github.io/standards-positions/#trust-token>
WebKit: Pending
(https://github.com/WebKit/standards-positions/issues/72
<https://github.com/WebKit/standards-positions/issues/72>),
already shipping similar technology
https://developer.apple.com/news/?id=huqjyh7k
<https://developer.apple.com/news/?id=huqjyh7k>(see PST
vs. PAT
<https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md>for
more information about the differences in the technologies).
Web developers: Positive
A limited set of developers provided feedback on Private
State Tokens, indicating that the tool was valuable for
anti-fraud capabilities while also acknowledging some
utility challenges (1). Other developers also found that
Private State Tokens provided ability for authentication
purposes (as illustrated by its use in the Privacy Sandbox
k-Anonymity Server) (2).
1:
https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf
<https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf>
2:
https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic
<https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic>
Other signals:
Ergonomics
N/A
Activation
Using this feature requires spinning up a (or partner with
an existing) Private State Token issuer that can issue and
verify trust tokens, which is non-trivial. Verifying
properties of the Signed Redemption Record or the client
signature requires additional cryptographic operations. It
would be beneficial to have server-side libraries that
developers can use to help make using this API easier.
Sample code can be found at
https://github.com/google/libtrusttoken.
Security
N/A
WebView application risks
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
As this feature does not deprecate or change behavior of
existing APIs, we don't anticipate any risk to
WebView-based applications.
Debuggability
This API is debuggable via the DevTools Application Data
panel and the operations are exposed in the Network panel.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, Chrome OS,
Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
<https://wpt.fyi/results/trust-tokens?label=experimental&label=master&aligned>*,
some of the tests are currently failing as renaming/API
changes in preparation for shipping these feature haven't
propagated to those tests yet. Additionally, due to the
requirements of having a server-side issuer (with bespoke
crypto) to fully test the API, a majority of the testing
is done in wpt_internal with a bespoke python
implementation of a PST issuer.
Flag name
TrustTokens (in the process of being renamed to
PrivateStateTokens)
Requires code in //chrome?
False
Non-OSS dependencies
Does the feature depend on any code or APIs outside the
Chromium open source repository and its open-source
dependencies to function?
Yes. Token operations are dependent on having the key
commitment information configured. Chrome (and Chromium
implementations that consume components from component
updater) supports this via a component, other clients will
need to consume the component or come up with their own
method of shipping the key commitment information to the
client.
Estimated milestones
Chrome for desktop:113
Chrome for Android:113
Android Webview:113
Anticipated spec changes
Open questions about a feature may be a source of future
web compat or interop issues. Please list open issues
(e.g. links to known github issues in the project for the
feature specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure
of the API in a non-backward-compatible way).
The major feature changes we expect are likely to be
around the versions of tokens we support, as other use
cases may need differing properties from those provided
with the initial API and other format/API changes to align
better with standardization and interop (see the
Interoperability and Combatibilitysection up above). Most
potentially web-observable changes in our open issues
(https://github.com/WICG/trust-token-api/issues
<https://github.com/WICG/trust-token-api/issues>) are
around ergonomics of using the APIs and ways to use the
API in more locations/manners which should pose minimal
compatibility risk to existing users of the API.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5078049450098688
<https://chromestatus.com/feature/5078049450098688>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA>
Intent to experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/stu7iXTWBwAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/stu7iXTWBwAJ>
Intent to extend origin trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/fpfbKgJF8Vc/m/aC8HJfGdDwAJ
This intent message was generated by Chrome Platform
Status <https://chromestatus.com/>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/633d35ef-2bd9-43c3-9799-8243ff24d764n%40chromium.org?utm_medium=email&utm_source=footer>.
--
Steven Valdez | Chrome Privacy Sandbox | [email protected] |
Cambridge, MA
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxB9WoK8nJ4J_R8L7cyb6JtidzJopoN5xxSdS4--4kbEuQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DXb_rRjf0PcjbvQH7i2ctwx1P-etgGsP4NfxJPbd42QtQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPLxc%3DXb_rRjf0PcjbvQH7i2ctwx1P-etgGsP4NfxJPbd42QtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5af1b02-26b4-8433-21b4-2d0f57fe4c1b%40chromium.org.
