From 4ec4c3844a6f05d711ae421f3c923f015dcb160f Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Tue, 12 Sep 2023 23:49:52 +0200 Subject: [PATCH] Publish minutes of 2023-09-12 TPAC meeting --- _minutes/2023-09-12-wecg-tpac.md | 241 +++++++++++++++++++++++++++++++ _minutes/README.md | 4 +- 2 files changed, 243 insertions(+), 2 deletions(-) create mode 100644 _minutes/2023-09-12-wecg-tpac.md diff --git a/_minutes/2023-09-12-wecg-tpac.md b/_minutes/2023-09-12-wecg-tpac.md new file mode 100644 index 00000000..b803afec --- /dev/null +++ b/_minutes/2023-09-12-wecg-tpac.md @@ -0,0 +1,241 @@ +# WECG TPAC 2023, Public Notes—Sep 12, 2023 + + * Chair: Simeon Vincent + * Scribes: Devlin Cronin, Rob Wu, Simeon Vincent + * Location: Seville, Spain + * Time: Tue 12 sep, 5pm - 6:30 PM CET (https://everytimezone.com/?t=64ffaa00,384) + * Call-in details: [WebExtensions CG, 12th September 2023](https://www.w3.org/events/meetings/304c12b4-3fd1-41ce-9402-87aac7891c4f/) + + +## Agenda: [TPAC 2023](https://github.com/w3c/webextensions/issues/385#issuecomment-1710769877) + +| Start | Duration | Description | +| - | - | - | +| 17:00 | 5 min | Intro | +| 17:05 | 20 min | Automated compatibility testing | +| 17:25 | 25 min | Declarative Net Request | +| 17:50 | 20 min | User Script API | +| 18:10 | 20 min | WebAuth RP ID | +| 18:30 | --- | End | + + +## Attendees (if remote, please add yourself) + +Counter-Clockwise around the table for in-person + + 1. Rew Islam (Dashlane) + 2. Anders Åberg (Bitwarden) + 3. Alex Rosenska (Google Chrome) + 4. Sam Macbeth (DuckDuckGo) + 5. Ali Spivak (Google Chrome) + 6. Kiara Rose (Apple) + 7. Patrick Kettner (Google Chrome) + 8. Simeon Vincent (Unaffiliated) + 9. Rob Wu (Mozilla) + 10. Devlin Cronin (Google Chrome) + 11. Oliver Dunk (Google Chrome) + 12. Carlos Jeurissen (Jeurissen Apps) + 13. Tomislav Jovanovic (Mozilla) + 14. Richard Worth (Capital One) + 15. Andreu (Igalia) + 16. Timothy Hatcher (Apple) + 17. David Johnson (Apple) + 18. Brian Weinstein (Apple) + 19. Rob Hudson (Apple) + 20. Mukul Purohit (Microsoft) + 21. Tim Cappalli (Microsoft) + 22. Dirk Balfanz (Google) + 23. Nick Steele (1Password) + + +## Meeting notes + +(Intro) + + * [devlin] Welcome back to the second day of the WECG meeting at TPAC. We'll go around the room and introduce ourselves. Remote attendees, please add yourselves to the doc as well. + +(Automated compatibility testing - Rob) + + * [Issue 441](https://github.com/w3c/webextensions/issues/441): Is there any interest in creating extension-specific test harness like the WPT one + * [rob] yesterday, we established the need to test extension APIs across browsers. We agreed the WPT framework would be good to build upon. I hope today we can establish concrete steps for how to get there. + * [kiara] I sat in on the meeting today and raised our desire to use WPT to test extensions. They're on board and said it should be feasible. Next steps would be figuring out how we intend to use it, coming up with an API to use, coming up with a few tests and having people review them in the WPT repo. + * [patrick] I started digging in the implementation; I added a hello world, loading an extension in Chrome, doesn't do anything practical beyond that yet. The way wpt is structured, it builds upon the WebDriver protocol. In Chrome you can load it before the runner loads, in Firefox you can't, you have to load it after the runner. The Chrome behavior seems to work with WPT but need to figure out if Firefox behavior is supported. Additionally, Safari folks expressed yesterday that they would prefer a way to load extensions with flat files (opposed to packaging binary archives). + * [kiara] Update, we should be able to load an extension unpacked in WebDriver. + * [patrick] To clarify, you would be willing to do the work to make that happen; it cannot happen right now. + * [kiara] Yes, but it cannot happen right now. + * [patrick] All the blockers from other browser vendors are trivial, so that's great news + * [tomislav] Current limitation from Firefox's side is that only packaged extensions can be loaded, but we can fix that. + * [patrick] Larger question is digging into the more error-prone side of the platform. For example if an extension is malformed. Makes sense to make these consistent across browsers. + * [timothy] The biggest issue I see there is that Chrome rejects a lot of unknown keys in manifest files, so having one common manifest file may be difficult + * [devlin] On the Chrome side we're also supportive of making the changes to make these warnings rather than errors. + * [tomislav] What would be the next step after we load an extension? + * [patrick] The default way I have it structured at the moment mirrors WPT; opens up an HTML document. When that document is loaded, a meta tag specifies the extension. The browser loads the extension. The extension does whatever tests and reports the results through a content script or send message. The main HTML has a single assert that it exists and gives the results from the extension. + * [tomislav] Then on the extension side, we all have the test namespace, but at least in Firefox, it doesn't assert in the context of where it's called. It's not out-of-the-box usable. + * [patrick] There's already a harness that does this within WPT. The basic assertions work across all three browsers. + * [tomislav] The web extension would send a message to the page, but what the extension needs to test… + * [patrick] That's handled by the assertion file. It's a userland library. It uses the same assertions that work everywhere else, you just need to load it in the context of an extension. + * [sam macbeth] I had a couple of questions. Test organization: can WPT support it? In web extensions land, we have this case that there are expected divergences between platforms. Can we specify tests for only certain browsers? + * [patrick] Yes. + * [tomislav] That is already supported by WPT. + * [sam macbeth] Certain APIs, e.g. DNR, need to load other resources like other web pages. Is that supported? + * [patrick] Yep, that's heavily used by other WPT + * [tomislav] Very happy about all of this. Would like to ask others that develop extensions and test them in their own CI, how would this help you in your work? Could we do something to help you? + * [sam macbeth] You mean for our integration tests for our extension? What we use in DDG is Playwright, a cross-platform testing framework. You can load an extension and access the context there. What we don't get there is the test in Firefox – might be able to get that with the Firefox debugging protocol, but don't have the resources right now. It might be that this would be a better basis for a framework, but too early to say. + * [patrick] Within WPT there's the WAVE consortium that's focused on testing A/V capabilities. If there's interest, we can take a similar approach to make the extension test suite available to others. I would not recommend integrating WPT in your own test process. + * [tomislav] Yeah, I'm wondering if this would be useful to companies like DDG to move part / all of their tests outside their code. Do you have only full tests with the DDG extension, or do you have "this part of extensions should behave this way"? + * [sam macbeth] Two types of extensions, unittests and integration tests. Unit tests you use any JS test runner in an execution context. Integration tests load up the whole DDG extension, lets you test end-to-end. + * [tomislav] if we can make it useful to DDG and others, they can contribute tests, too. + * [patrick] Is this about integration tests or unit tests to verify that the extension API works? + * [sam] it would help to clarify what the integration test are meant to do. The tests to verify the extension platform would be useful to us. For example, I recently investigated Safari's capabilities. Having these tests would help us verify what does and does not work across browsers. + * [patrick] Like wpt.fyi + * [sam] Yes + * [tomislav] And if a test wasn't available yet, you could contribute it + * [patrick] To make next steps as concretely clear as possible, it would be to continue trying to make it work in Chrome, and then moving onto other browsers (since they need to be changed – though changes mostly trivial). By the end of this week, there will be a PR to WPT, whether or not it's mergeable. + * [rob] Does it support loading multiple extensions at runtime? + * [patrick] Maybe? WPT? + * [rob] What you're building - the prototype. + * [patrick] yes and no. In Firefox, yes. In Chrome, you have to load the extensions when setting up the test environment. We might be able to load a large set and programmatically enable or disable them at runtime. It may also be possible to expand the management API to support functionality similar to chrome.runtime.reload. It's not a complete blocker. + * [rob] That's not fully equivalent to installing an extension normally, but these implementation details can be figured out later. + * [sam macbeth] Other tricky things to test: browser UI interaction (page actions, permission prompts) and extension lifecycle traces, e.g. extension updates + * [patrick] Upgrade is not a problem for boring reasons. … In Chrome there are protected APIs in WebDriver. I don't know how likely this is to be exposed because of security concerns. In Firefox I believe you're completely scriptable. Is this an option? + * [rob + tomislav] In theory yes. + * [patrick] and for Safari, I have no idea – I know AppleScript exists + * [timothy] This is something we allow - anything is allowed without prompting in a testing environment, so that the prompt does not get in the way. + * [tomislav] I believe I recollect we do that for some permissions or something + * [patrick] Yeah, I know the Chrome workarounds, just not the other browsers. Worst case scenario, can click on a specific X-Y coordinate. To start, though, I'd avoid testing anything with UI. + * [tomislav] Yes, we have low-hanging fruit that we can start with. + * [patrick] If DDG or other partners that have been building cross-browser testing stuff (...) + * [timothy] One area that comes to mind is the ability to open windows outside of extensions for testing. E.g., mobile safari window.create(), remove(), update() don't exist – they depend on the user creating windows. We might just want to skip those tests for now on mobile + * [patrick] Have you worked with WPT + * [timothy] Nope + * [patrick] Asking as this could be a solved problem, but I don't know. + * [tomislav] I suspect most of the things we want have been done, either exactly or analogously. + * [timothy] We'll look into it. + * [patrick] Next step is the PR for WPT, then making sure it's adequately promoted. + * [devlin] perfect time to stop and move on + +(Declarative Net Request – Oliver) + + * [oliver] There are a bunch of specific proposals in the WECG, like limits on dynamic rules, safe rules, etc. I'd like to see where we want DNR to be in the future. + * [oliver] One specific topic is dynamic rules - are there concerns with dynamic rules, the number of rules, etc.? + * [timothy] We don't have a concern + * [devlin] Might be good to explain why we have a concern on Chrome. We have a couple of different reasons. First, stability and recoverability of the process. Rules contained in the extension package are guarded against corruption on disk, either intentional or unintentional. Technically local malware is out of Chrome's threat model, but we can be more resilient. For static rules we can do that, and extract the rules from the package. + * [devlin] Second concern is around wanting as much of the extension's logic as possible contained in the extension package. If you give malicious developers access to rules, 20 or 20000, you're still dealing with a malicious actor. + * [devlin] In Chrome we have client-side telemetry that can see the registered dynamic rules. That is scalable only to a limited extent. Static rules can be statically analyzed, but dynamic rules cannot. + * [rob] From the Firefox implementation and runtime perspective, being able to load rules outside of the browser incurs additional overhead. Without restriction, extensions may register too many rules without pruning rules. Chrome's intentionally low starting limit encouraged developers to get more efficient about what rules they keep and pruning old ones. + * [oliver] Devlin, you mentioned corruption, can you give context on repair mechanisms? + * [devlin] The history of the repair mechanism goes back to ~2013 when we instituted the rule that extensions had to come from the web store. Before this extensions could be installed from anywhere and we found that malicious extensions were taking advantage of this. Because of the way an extension's ID is determined comes from the public key in the manifest, a local extension can have the same ID as a packed extension in the store. This is an intentional feature and critical for testing purposes. But it also meant that it's very easy to pretend to be an extension you're not or to have local binaries modify extensions on disk. It's a low bar if you have a well known directory and extension to insert malicious code in a known extension. The content verification mechanism raises the bar on that attack vector, but does not prevent it entirely. Since the introduction of this capability, it has proved useful for other parts of the browser. + * [timothy] So that's more about modification than corruption. We have a similar feature in Safari, rules are code-signed and modified rules are rejected. + * [oliver] Does this change anyone's perspective on rule limits? + * [timothy] I don't know whether on-disk modification is relevant to dynamic rules. + * [devlin] Playing devil's advocate against ourselves, I acknowledge that 20 or 20,000 rules are dangerous. Do other browsers also require this? + * [tomislav] We also require signed extensions. + * [tomislav] From the POV of someone who did not implement DNR (Rob did), DNR seems not as dangerous. There are other ways to do worse things. + * [devlin] Depends on a few other pieces. Might be a good segway into "safe rules". There's a class of rules that are very hard to abuse. There are others that are very easy to do very bad things. Redirects. If you redirect jQuery and Google Analytics you can essentially hijack the web. If you consider everything an extension can do, there are easier ways to exploit users. But with everything else we're tightening up in Manifest V3, that limits some of those other options. They're not technical limits, we often discuss them as guardrails or limits, but they help keep good actors on rails and safe. + * [tomislav] So in theory, your Enhanced Safe Browsing feature can reveal that extensions can do more than described, and be a reason to investigate further? + * [devlin] Potentially, and we can see what rules they're using. We can see when they're redirecting Google Analytics, but that only works across large numbers of users. If it's targeted attacks, that won't appear in these metrics. That might be a good segway into safe rules, as we seem to be aligned that there are some operations that are safer than others. + * [sam macbeth] Content blocking extensions rely on dynamic rules heavily; the things an extension want to block changes quite frequently. Our DDG extension is currently trying to work around the dynamic rules by integrating less frequently updated rules in the extension package, which requires us to increase the frequency of our extension updates and align the release cadence with rulelist updates. + * [devlin] We understand that that is the case. The model we expect most content blocking extensions to follow is defining most of their rules in static rules and using dynamic rules as patches between static releases. You can imagine updating DDG every week, and adding dynamic rules to patch differences every hours. + * [oliver] Also worth noting that this isn't something we'd want to address in the group, but we can optimize this process in the store to improve review times for these cases. + * [oliver] So the safe rules proposal is basically working on the basis about some rules being safe. You might be getting close to the limit and want to add more dynamic rules. [Proposal](https://docs.google.com/document/d/1srkkCJkl4X2KOOUwnpDd-kvm8AY70eZBAYI4m836bvQ/edit#heading=h.bz47t7liilts) shared in [issue 319](https://github.com/w3c/webextensions/issues/319) (“Increase the maximum number of dynamic rules”), add safe and unsafe categories (naming to be finalized). The simplest division would be saying "block and allow rules are safe". We did some research, AdGuard shared that 98 - 99% of their rules fall into those categories (in issue 319). We could raise the limits without risking the concerns with dynamic rules we mentioned earlier. Any thoughts? Safari, Firefox, thoughts? Would we want to have this across-browser? + * [rob] From the Firefox side, I'm supportive of the functionality, but I'm concerned about scoping the work being done. The original proposal included allowAllRequests which isn't required but not free to support. + * [oliver] The proposal does call out that we could potentially expand the definition in the future (e.g., CSP restrictions are probably safe, but more nuanced) + * [tomislav] I think it makes sense to divide between what you expect is safe and what you need to scrutinize more closely. + * [oliver] Timothy? + * [timothy] I'll need to read the proposal more in detail, but seems reasonable to me + * [oliver] Cool, I think we can continue the discussion on the thread + * [devlin] Time check: 5 minutes + * [ioliver] What are wish list items for DNR? + * [tomislav] Cosmetic rules is a popular request. “Safe CSS” such as hiding elements may be safe to do. That does obviously not fit with the name of the DNR API. Bikeshedding aside, would that be something fitting in DNR? + * [devlin] I'm still concerned about grouping these with Declarative Net Requests. I'm supportive of declarative style rules, but I don't think it belongs in that namespace. + * [rob] Would suggest focusing our remaining time on use cases. + * [sam macbeth] General concern with DNR development going forward. Feature detection of what is available. If a static rule fails (depending on the failure), it's a hard failure. + * [rob] Is it a hard failure? + * [sam macbeth] Rule failure causes the list to not load. + * [rob] In firefox, it's a soft failure (invalid static rules are ignored). Invalid dynamic/session rules result in a rejection. + * [oliver] I don't think this has come up in the community group before. We should probably create an issue to track. + * [patrick] Is there a way in firefox at runtime to find out if there's something being ignored? + * [rob] no + * [devlin] Would be nice to be able to call something like declaratriveNetRequest.getFailedRules() + * [rob] I would be supportive of that. + * [timothy] Introduce a declarativeNetRequest.isRuleSupported() -> bool + * [simeon] Time check; let's move on + +(User Script API Recap – Devlin) + + * [simeon] I'd like to check on the status of the userScripts API. Checking on the current state of Chrome, which are built upon the userScripts API proposal published in the WECG. Wondering whether the direction of the API is sufficient to cover the use cases of user script managers. + * [devlin] I believe we aligned that the functionality that exists in the MVP design is sufficient to allow developers to migrate. There are a few small improvements beyond what is included in the MVP, namely messaging APIs between the isolated world and the user script world. What we expect is that much of the operation of user script managers in MV3 will be very similar to how they work in MV2. Importantly, it was unclear whether or not a few of the items we identified in the future work section of our proposal were just proposals or were concrete work we're planning to work on. Highest priorities inter-world communication and support for multiple worlds. We are planning to work on them. We think they're important capabilities and plan to work on them in follow-on updates. + * [rob] That's a good summary of what we have discussed (at TPAC). + * [devlin] We don't want to let perfect be the enemy of good and block the ability of user script managers to adopt this API for another 6 months or more. + * + * [rob] Also want to raise discussion about the use of this API. There are other types of extensions that want similar capabilities. I'm proposing that we also support synchronous injection of content scripts in the main world. + * [devlin] A little orthogonal to user scripts. What Rob and I were discussing was providing a new browser.dom API that could inject content synchronously. It would not allow remotely hosted code. It would take a function and an arguments array. This would support use cases like scriptlets which need to synchronously inject. I'm differentiating this from user scripts as it would be on a different namespace and would not allow remotely hosted code. + * [rob] I wanted to highlight this as it's a related capability we should support. I raised this in early discussions on the user script API design ([issue 279](https://github.com/w3c/webextensions/issues/279)), as the primitive is relevant to extensions that are not user script managers ([issue 284](https://github.com/w3c/webextensions/issues/284)). I'll flesh out a proposal and submit it for review in the group. + +(WebAuth RP ID – Devlin to kick off to others) + + * [Issue 238](https://github.com/w3c/webextensions/issues/238): WebExtensions should use asset links model for WebAuthn RP ID + * [rew] I have a slide deck to help. We have a simplified representation of the WebAuthN flow. + * Link to slides: “RP ID and web extensions“ https://docs.google.com/presentation/d/1p6uuyS0mjqQbX39X0iny_aXLzto8HZspt1SYlUFng7M/edit + * [rob] FYI: Slide deck has already publicly referenced in issue 238 at https://github.com/w3c/webextensions/issues/238#issuecomment-1623965791 + * [rew] You call navigator.credentials.create. The credential you create will be tied to the origin. In a browser extension, you can do the same, but the “RP ID” will not necessarily be tied to the website. For example, Dashlane may create multiple applications and there is no way to associate the two. + * [rew] Today mobile apps can associate themselves with a domain. This links the bundle ID or app ID to the domain, but there's no equivalent in extensions. There's no association between the extension's origin and the application URL. + * [devlin] If you install a Chrome and Edge extension the RPID will be based on the origin including the scheme. So even with two extensions with the same ID they will not be compatible. + * [rew] One proposal is to introduce an equivalent ability to link an extension origin to a domain. The OS for mobile apps validates this link. I'm not sure what would perform this association. + * [tim cappalli] The browser would be the equivalent to the OS in this model. + * + * [tomislav] Is that the main use case? Let's get to what you're trying to achieve. + * [tim cappalli] We're essentially looking to associate a web domain to an extension-specific scheme. + * [rew] It could also be used on a web app + * [tim cappalli] If I create a web application for the Dashlane mobile app, it's automatically associated with the Dashlane origin. + * [devlin] I discussed this a little with Rew earlier and I wasn't sure why Dashlane doesn't just embed an iframe and use the Dashlane origin from there. That might be viewed as a hack or it might be leveraging the platform. + * [tim cappalli] That could work, but I would think that is a hack. The user wouldn't see the extension's origin, they'd see the. + * [devlin] + * [tim cappalli] So you're saying load the Dashlane page inside an iframe in the extension? + * [devlin] Yes. + * [rew] I think you can call navigator.credentials from a popup. I think this is confusing because an extension developer may think that you can use this authentication across the extension. It seems like something is missing. Either its not possible to accomplish this today or it's possible in a surprising way. + * [devlin] I could see this as either being desirable or undesirable from a developer point of view. For example, Dashlane stable and Dashlane beta. It may or may not be good from the developers point of view to have these different extensions isolated from each other. + * [carlos] Using an iframe currently does not seem possible as it does not comply with the same-origin policy. + * [Dirk Balfanz?] credentials.create does currently not support cross-origin in level 2, but there is a proposal to add it to level 3. This has not been met with universal approval though, so I don't believe it's possible to do this across all browsers. + * [timothy] Not familiar with WebAuthn; In Safari we'd be fine with allowing extensions to be associated with the domain, because the extension is associated with an app and a domain. We go to great lengths to hide the randomized extension URL, and put effort in showing the extension name instead in cases such as permission prompts. + * [devlin] Are there use cases here that are not solvable or that are overly onerous/ugly. Sounds like it may be possible to do something with cross-origin iframes. If nothing else we should explore this more in order to gauge the priority. For example, if the only way to do this is to open a new tab and that's disruptive to the user experience, that's not great. + * [devlin] … I would almost say that you should be able to declare any origin as long as you have host permissions to it. Because that's true today. + * [carlos] This would also be useful when importing extensions between browsers (e.g. Firefox has recently introduced a feature to import extensions from Chrome) and there might be more use cases for associations. + * [devlin] That's interesting. I hadn't considered that. A similar thing we've discussed is not having a host permission confirmation if you can prove you own the domain. For example, if Dashlane can prove they own the extension and domain, then the extension should be able to modify the site because of course it can. + * [tim cappalli] For clarity, what is a host permission in this context? + * [devlin] Security boundary in extensions that allows extensions to inject scripts, modify the page, extract content, basically get full access to a set. + * [tomislav] It can also call navigator.credentials in the context of the web page. + * [devlin] To me, the existing ability to do so means that it would be misleading if we were to suggest that only one specific extension is in control of the credentials. I don't see any meaningful security benefit from supporting this RP ID in WebAuth. + * [??] I'm not too familiar - can the mechanism as described here do that? + * [nick] (introduces himself as 1Password representative) Yes we can do that. + * [rew] Maybe I'm missing some of the details, but wouldn't the browser be fetching this data from the domain, not the extension? + * [devlin] Yes. But me, a malicious extension, can inject whatever I want on a website after the proper authentication has completed. A script can reach in and extract the data it wants from the page. + * [rew] Doesn't that break the WebAuthN security model? + * [devlin] Yes + * [nick] You can't intercept the signing event, but you can intercept the response coming out which is a valid attack. + * [carlos] Wouldn't that mean that it's more secure for an extension to perform this work because the extension would get the RP ID rather than a website? Since the RP ID would only be accessible by extensions and linked extensions. While a RP ID from a website could be received by extension content scripts. + * [devlin] From the POV of security (with Dashlane as an example), storing data in the extension origin would actually be an improvement, because other extensions cannot access other extensions' origins. Of course it depends on the threat model; most don't consider malicious extensions part of the threat model. + * [nick] So, I go to dashlane.com and a malicious extension has full access to the page. You wouldn't be able to extract a passkey from the page. Same for bitwarden, etc. You couldn't access the key + * [??] it would be the assertion + * [devlin] It wouldn't let you get the raw key, but nothing here is about the raw key. + * [tomislav] What does this actually mean? What's the actual threat model? It already has access to the attestation. If you can access the entire vault data on the page, then a malicious extension has full access to this data. So what are we actually trying to protect? + * [nick] If you run malicious code on your own client, we have no meaningful way of interdicting that. + * [devlin] That's our stance as well. If you run a malicious extension on a site it has access to, well, it has access. To me, this browser validation step is meaningless. + * [tomislav] It doesn't buy us any security benefit. + * [devlin] right, this is just an alternative to providing a host permission. Extensions can get exactly the same functionality by just requesting a host permission. + * [tim c] On the web platform we need both sides. On the extension, we only need the name binding (with the assumption that the security isn't broken) + * [devlin] I can understand the name binding use case. In that case we take out the browser validation, and bikeshedding aside, allow extensions to specify a RP ID in the manifest.json file, provided that the extension is granted host permissions. + * [nick] So, the attacker gains a response, they can use it once. Are we assuming continued access? + * [tim c] Not with a passkey. It's always 0. + * <much webauthn terminology> + * [oliver] I don't think it's that hard to get full access to the key. If a malicious extension is present at signup it can use its own key in the `navigation.credentials.create` response. + * [devlin] … If you want data that is secure from extension, it can't be exposed on a web origin. I think we're all in agreement that extensions are scary. + * [devlin] I think we're agreed that browser validation doesn't do anything in this case, but we can still introduce a manifest key. + * [devlin] Before we commit to this, I wonder what this looks like without special support. + * [tomislav] Might be better not to implement that or else password vaults that aren't in the room will assume this is safe and rely on this. + * [??] It's less about the thread model we are experiencing, more about making passkeys available to the web. + * [rob] time check - at time. + * [devlin] Speaking for Chrome, would be valuable to understand how far you can get today in order to help inform follow-on conversations. + * [tomislav] I realize we're asking you to do work, but it would be interesting to get your point of view on the threat model and understand what you can accomplish with the current platform. + +This is the second WECG meeting at TPAC. The next meeting is the regular one in two days: [Thursday, September 28th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6514c200,384). diff --git a/_minutes/README.md b/_minutes/README.md index bfb32ad0..70da3cfa 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,24 +10,24 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2023-09-12 at 5 PM CET at [TPAC 2023](https://github.com/w3c/webextensions/issues/385) = https://everytimezone.com/?t=64ffaa00,384 - 2023-09-14 at 8 AM PDT = https://everytimezone.com/?t=65024d00,384 - 2023-09-28 at 8 AM PDT = https://everytimezone.com/?t=6514c200,384 ## Past meetings +* 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md)) * 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md)) * 2023-08-31 ([minutes](2023-08-31-wecg.md)) * 2023-08-17 ([minutes](2023-08-17-wecg.md)) * 2023-08-03 ([minutes](2023-08-03-wecg.md)) * 2023-07-20 ([minutes](2023-07-20-wecg.md)) -* 2023-07-06 ([minutes](2023-07-06-wecg.md))
All past meeting notes **2023** +* 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md)) * 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md)) * 2023-08-31 ([minutes](2023-08-31-wecg.md)) * 2023-08-17 ([minutes](2023-08-17-wecg.md))