Planning TPAC 2023.

[mikewest]

Suggestions thus far (including initial brainstorming from the 2023-06-21 call):

• "Unique" origins for blobs.
• The storage model in a post third-party cookie world (e.g. cross-site cookie semantics)
• Web Crypto
  • Secure curves draft publication, more modern algorithms
  • End-to-end encryption for web applications
• Source Code Transparency
• Permissions
  • Policies
  • Default-none permission policies (with onunload deprecation as context)
  • Shifting to 'self' by default
  • Page Embedded Permission Control (PEPC)
  • Permission API
  • State reported by .query()
  • Registry
• Cross-Origin Isolation
  • Current status?
  • Deployment challenges?
  • COOP: restrict-properties
• Securer Contexts' injection mitigation
• Private Network Access updates.
• Your suggestion here...

[arichiv]

Working on a proposal re: https://github.com/whatwg/html/issues/8481#issuecomment-1523647179 that might be good for discussion

[mozfreddyb]

I would like to know more about Source Code Transparency. A link would suffice.

[shhnjk]

I'd like to discuss gradually moving powerful permissions to permission policies 'self' by default.

[marcoscaceres]

I’d be interested in discussing some ideas around end-to-end encrypted mail, and maybe leveraging Web Crypto for that. A 20 minute time slot for that would be greatly appreciated.

[mikewest]

Hey @mozfreddyb!

I would like to know more about Source Code Transparency. A link would suffice.

@twiss proposed that topic in https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-06-21-minutes.md#:~:text=...%3A%20Unrelated%20to%20that%3A%20ad%20hoc%20conversation%20in%20this%20call%20around%20source%20code%20transparency.%20Source%20served%20by%20web%20apps%20is%20the%20same%20as%20everyone%20elses%27.%20Can%20we%20verify%20it%20to%20be%20the%20%22correct%22%20version%20for%20some%20definition.%20Prevent%20a%20host%20from%20serving%20one%20version%20to%20one%20person%2C%20another%20to%20another. They might have more context?

[twiss]

Yes; the goal would be to have a mechanism to verify that the source code of a web app appears in some transparency log (similar to Certificate Transparency), to allow auditors to check the source code, and make it impossible to surreptitiously serve a malicious version of a web app to one user, for example.

This is aimed at solving the "in-browser cryptography problem", about which many blog posts have been written, but actually is not limited to applications using client-side cryptography but would be useful to any web app that processes or stores data locally only (or indeed encrypts the data it sends to the server), and where the server isn't necessarily (intended to be) a fully trusted party.

One way to achieve this would be to actually build it on top of Certificate Transparency, for example by including the hash (of a web package?) of the source code of the web app in the certificate itself. But I'd be happy to discuss the problem in general and other potential solutions as well, of course :)

[twiss]

Btw, @marcoscaceres:

I’d be interested in discussing some ideas around end-to-end encrypted mail, and maybe leveraging Web Crypto for that. A 20 minute time slot for that would be greatly appreciated.

I'd be happy to discuss that as well, and curious what ideas you have in mind? (We do use Web Crypto for E2EE mail in the web app wherever possible, though there are indeed some gaps.)

Since I've been involved with the "crypto refresh" of the OpenPGP standard, I could talk a bit about the cryptography in use there (if there's interest), some of which might be generally useful to add to Web Crypto (e.g. AES-OCB). I'm slightly less familiar with S/MIME (the other email encryption standard) but we could discuss that as well, ofc :)

[mikewest]

Permissions API came up in https://github.com/w3c/permissions/issues/414, which seems like it might fit into our discussions.

[marcoscaceres]

Ah yeah, about https://github.com/w3c/permissions/issues/414 ... definitely want to discuss that too.

[ShivanKaul]

I'd previously talked about Request OTR at the 19 July WebAppSec meeting. Interested in seeing if folks would want to consider adopting the work as a deliverable, so some time for that on the agenda would be great!

[shhnjk]

• "Unique" origins for blobs

I've transfered this issue to whatwg/html (which is a better suited venue).

[jayaddison]

Yes; the goal would be to have a mechanism to verify that the source code of a web app appears in some transparency log (similar to Certificate Transparency), to allow auditors to check the source code, and make it impossible to surreptitiously serve a malicious version of a web app to one user, for example.

Chiming in after learning about this Source Code Transparency idea while checking for subresource integrity updates.

As a web application author I'd be interested in SCT. My use case is primarily app delivery integrity: making sure the user receives the intended content, and only the intended content, if-and-when the app's static resources begin migrating onto CDNs.

I like the idea of a transparency log, and would likely opt-in to that. Short-term I've added something that I don't expect any users or browsers are likely to inspect automatically: a DNS 'B record' (in fact, it has type TXT for now since no B record type exists) that contains a hash of the start_url referred to by the progressive web application's webmanifest. Roughly speaking my thinking there was to deploy an integrity anchor somewhere separate-but-related to the web origin of the app.

[mikewest]

Draft agenda for TPAC is up at https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-TPAC-agenda.md. Will leave this open until Wednesday for feedback/additions/removals. :)

[mikewest]

Closing this out. Minutes from TPAC are up at:

https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-14-TPAC-minutes.md and https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-15-TPAC-minutes.md

[jayaddison]

Re: Source Code Transparency: I'd suggest that placing code hashing credentials in an X.509 cert could limit the distribution model to applications that are deployed over HTTPS -- it certainly seems to make TLS a requirement for the client. Conversely, a DNS-based approach would be available without that dependency. I admit that most applications today are no doubt intentionally delivered using HTTPS.

This is coming from a perspective of: application delivery integrity could be seen as equally important to application delivery confidentiality - perhaps moreso. If my neighbour can see that I received the same banking application that they did, we know we're in the same boat.

[mikewest]

I believe @twiss was planning on shifting the source code transparency discussion into a distinct repository that could be easier to follow than this somewhat unrelated discussion of a group's meeting agenda. :)

Daniel, perhaps there's value in creating a placeholder repo sooner rather than later to gather ideas as you sketch a proposal in more detail?

[twiss]

Yes, I'll try to do so next week (as this week I'm traveling). And thanks for the feedback @jayaddison - I'll take it into account when sketching an initial proposal and then we can discuss it more in depth when there's a repo ^.^

[jayaddison]

That sounds great - thank you!

[twiss]

I've created a repo here: https://github.com/twiss/source-code-transparency. I've also added a slightly more detailed proposal in the explainer, trying to take into account the feedback I got in the meeting and here.

If you have any feedback, please open an issue or discussion there :blush: