Design questions for Signed Exchanges

[jyasskin]

I'm requesting TAG input on some design questions we discussed at the 2019-02 Tokyo meeting. #235 is already closed, so I'm filing a new issue.

• Name: Signed Exchanges
• Specification URL: https://wicg.github.io/webpackage/loading.html and https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
• Explainer, Requirements Doc, or Example code: https://github.com/WICG/webpackage/
• Tests: https://github.com/web-platform-tests/wpt/tree/master/signed-exchange
• Primary contacts: @jyasskin, @nyaxt

Questions:

1. Do you have ideas to help ensure that web servers don't sign personalized content, which can allow various attacks?
   1. Does it make sense/help things to require that a signed exchange is fetched with credentials="omit"? This requires at least a new attribute on <a> tags to set its credentials mode and Fetch infrastructure to handle that on navigations.
2. How would you trade off the extra security of validating content in real time vs the surveillance that allows?
3. Similarly, do you have ideas on how best to notify a publisher that their certificate has signed such-and-such exchange, without revealing private information about who's reading the content? Purge mechanisms WICG/webpackage#376 could handle this ... by revealing that private information.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[hober]

Issues potentially related to these questions:

• Can SXG be used to track users? WICG/webpackage#387
• Should a SXG document be considered SecureContext or not? WICG/webpackage#388
• Long-lived content WICG/webpackage#399
• Avoiding Built-In Tracking in Signed Packages WICG/webpackage#422

[jyasskin]

WICG/webpackage#424 tries to record the threat model that Safari's using to prevent tracking. It would be useful to have an anti-tracking threat model at the TAG level so we could analyze platform features in a consistent way. @hober, are you at all interested in helping to drive that?

[hober]

It would be useful to have an anti-tracking threat model at the TAG level so we could analyze platform features in a consistent way. @hober, are you at all interested in helping to drive that?

I think such an effort would be better driven by someone for whom this is an area of expertise.

[torgo]

Discussed at Tokyo f2f....

[torgo]

We discussed and requested some further info on the relevant flows - maybe some flowcharts.. There will also be a breakout on this topic at TPAC.

[torgo]

Hi @jyasskin - We're just picking this up again at our f2f and I see we haven't got any further info from you on documenting the flows. Considering it's been a few months, could you let us know status on this? Is this something where you still need TAG advice / feedback and if so, could you indicate what specific areas you are looking for feedback on? Considering @hober's comment above maybe we should close this issue for now?

[ylafon]

Also, regarding WICG/webpackage#376 do you need a 'stale' state there, so that mechanism like stale-while-revalidate but adapted to signed exchanges would fit the invalidation use-case? I would imagine that a revalidation would reset the staleness state of the content, to void checking too often and revealing information about the reader.

[torgo]

Hi @jyasskin we're just coming back to this and we haven't had any updates since December, but I do see that there have been some recent updates to the specs... Can you please leave an update here also addressing the question I asked on 3-December, above? If there's no feedback you're currently waiting for from the TAG then maybe we should close this issue? We're in the middle of our f2f this week and I'd like to close this issue now unless you we hear from you.

[torgo]

Based on feedback from @jyasskin we're going to close this for now. As discussed, please re-open when there is something new for us to take a look at. Thanks!