Charter Review

Sarven: Review https://github.com/w3ctag/design-reviews-private-brainstorming/issues/193#issuecomment-3244825170

Matthew: APA has looked at this. I do think that this group seems to have been responsible for some positive change, so getting people into a working group is a good thing. They have adopted a novel-for-w3c approach, because they have consensus around differences. Aim to smooth those over eventually. Not sure if the CG will be kept (might be mentioned in charter). We might have an opinion about that, might say that keeping the CG is good. Not sure what else APA said.

Sarven: The charter does indicate coordination with the CG. A bit more specifically on deliverables, there were discussions from PLH (seemed uncertain?) definitely keeping the spec in CR snapshot. They anticipate changes constantly. They don't want to go to REC and have a final cutoff. That was their consensus. I didn't get much about what the coordination would look like, but presume that ... they have a good scope and only mention two deliverables. if the group thinks they need more specs, they will recharter to take more work on. The CG will intubate and add work to the charter as they go. That's based on inference from discussion and charter. ... There were concerns around manifest v3. Didn't dig too deeply, but there are differences in views between browsers. Highlighted in the review. If the CG has incubation experience, then whatever the version is arrived at, then the working group can take that on. Not a TAG call so much. What I thought was more important was to talk about threat models and trust models. There is the idea that CR is active, so they should have a threat modeling exercise and publish that as they go. Implementation experience shows authentication is a challenging part and it needs to be clearer how extensions are authenticated alongside other authentication methods on the platform. Parts might be from FedCM. They might need to iron that out. The point is not to come up with an authentication mechanism, but clarify it in their output.

Martin: Ask for clarification about authentication.

Sarven: Depending on the authentication with remote storage, how would an extension be identified? How might it be authorized to make requests and how would servers authorize requests from extensions? ... Dokieli is an application I work on, it also works as an extension. The feature to annotate webpages, enables the user to store annotations in their preferred storage. users need to authenticate to the extension, so the extension knows about storage and then have the storage system know that the client is authorized to write to that space. That depends on the authentication mechanism. Lots of question marks there.

Matthew: I found APA minutes. +1 to Sarven (on something). APA we did have some things we would want to check and review in the deliverables, but the charter seemed good. One thing is that they work closely with other groups, liaisonization, etc.. Might be good for threat modeling. Simeon, who might be a chair, contacted APA chairs if there was anything we would like to see included. We thought it was fine for us to do horizontal review of deliverables. There might be other groups where that needs to be clear. In terms of threat modeling and S&P, Ehsan's speciality, so we might file issues as interested individuals. On manifest v3, I do agree with Sarven that this is such a big change that this is not going to get consensus, which will cause fragmentation. The group has addressed this by acknowledging the issue and keeping awareness of it. I don't know if they are going to reconcile or just document differences. My own extension used to be a lot better, now you can't run the same code on all browsers. This group is a positive force for fixing that.

Lola: Can we thumbs up Sarven's document, or do you want to add some stuff? ... Did you want to mention authentication.

Sarven: Want to check with Christian? Did this capture the concerns you had?

Christian: It's fine, we could maybe just merge our comments into one. I wrote one as well. Combined would be good.

Sarven: We could merge, but I didn't feel comfortable with the text you had in the first two paragraphs. Do we need to repeat what the charter says?

Lola: Suggest Christian and Sarven work together on a resolution.

Sarven: We reviewed; sent feedback; not sure if 'out of scope' section was originally included in the PR wehre they made changes to the charter: https://github.com/w3c/charter-drafts/pull/711#discussion_r2434955131

... I made a suggestion on the PR that the packaging format and signing mechanism for extensions should not be out of scope. In my review, I said these seem like things that should be in scope - or at least not excluded - becuase standardising this would allow decentralized distribution of extensions. This seems like a laudable goal. There was some pushback on this from the group. I think browsers prefer to package extensions in their own way, for distribution via their own stores.

Ehsan: If you're a good actor, signing it is fine. If you're a malicious actor, and sign it, wouldn't it make the decentralized distribution of extensions easier? As there's no way to verify the reputation of the distributor. Might signing legitimize distribution of malicious code?

Sarven: Two things: (1) signing, and (2) packaging format. Anyone can self-sign and distribute right now. We could move that aside. Main thing is about format. Is there a reason why these formats need to be unique to the browser?

Lola: Struggling to see a reaosn why the format woudl/should be unique to the browser.

Martin: It's only specific to the browser to the extent that it has things that the extensions model demands (e.g. manifest, permissions) - it's a zip file otherwise.

Marcos: +1 to Martin

Sarven: E.g. you can't take an .xpi (Mozilla) and import it into Chrome. I should be able to import any extension into any browser. Trying to understand the pushback. There should be interop - better for consumers, implementers, publishers.

Martin: It's a shame that they specify almost everything you need, other than the very last thing that pulls it all together. This is useful input to the folks in this area, but it doesn't have to be in the charter.

Sarven: But they put it out of scope.

Martin: Agree it should not be explicitly put out of scope.

Sarven: Re misuse: to be able to install an extension you need to go to the store. To put it in the store, you need to sign in. So there's tracking. It then knows which devices are using extensions. Blatant centralization.

Martin: It is true; the folks doing it are doing so because they believe it's in the interests of users. There have been abusive extensions that do things like cryptojacking or other nasty things, as they have access to cookies and passwords. Browsers want to have the ability to yank extensions. Without that control system, people would self-sign. I understand it's a centralization problem, but it exists for a good reason, and that's hard to resolve. Firefox does allow sideloading, so it's not necessarily true that the extension store is the only place you can get them.

Sarven: Majority of users however aren't going to do temporary sideloading. Not concerned about stores having additional requirements on who can put things into their stores, or additional security measures. But an independent developer would have to publish multiple packages. Reminds me of 'this web page works best under IE'

Martin: We're slowly getting there.

Marcos: If you did have self-sovereign model, you'd have to strip out the powerful APIs. They see into everything and can read into your cookies and do all the things. They're literally acting as a UA.

Martin: If you stripped the capabilities out of the extensions, they'd be called web sites.

Lola: Sounds like we do want to consider asking them to add the packaging format in scope.

Martin: or at least not making it explicitly out of scope

Lola: I think they won't do it, if it's not mentioned. If it's in scope, maybe they can be held to some account.

Sarven: Agree it must not be listed in 'out of scope'. Peferably it would be listed as 'in scope'. I'd like to know if/what we should get back to them with here and wehether I or others should join one of their calls. I think they have one today.

Marcos: Packaging must've been part of the initial discussion going back many years. There must be good reasons why they left it out. They should state it, as it's such a glaring hole.

Lola: There is some discussion about this (in the PR thread linked above) - reasons given (paraphrasing the thread) around the prevelance of stores (re the CG charter), and lack of implementer interest (or actual opposition).

Sarven: So we should ask them to be clear on the reasons why these things were made 'out of scope'

Lola: May be worth doign that on the PR, or joining a discussion of theirs.

Christian: we need to ask Sarven. what he wanted to address... he's reopened it. but it's fine from my point of view. Action on Christian to ping Sarven.