Create 2024-06-19.md (#667)

* Create 2024-06-19.md

* Apply suggestions from code review

Co-authored-by: Ted Thibodeau Jr <[email protected]>

---------

Co-authored-by: Ted Thibodeau Jr <[email protected]>

meetings/2024-06-19.md

@@ -0,0 +1,130 @@
+# W3C Solid Community Group: Weekly
+
+* Date: 2024-06-19T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Chat: https://matrix.to/#/#solid_specification:gitter.im
+* Repository: https://github.com/solid/specification
+* Status: Agenda
+
+
+## Present
+* [Michiel de Jong](https://michielbdejong.com)
+* Sungpil Shin
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* [Pierre-Antoine Champin](https://champin.net/#pa)
+* Jeff Zucker
+* Grace Elcock
+* Rahul Gupta
+* Maxime Lecoq-Gaillard
+
+## Announcements
+* MLG has started to work on a spec on indexing within Solid which will present some conclusions of the research conducted with INRIA and Startin'Blox.
+
+### Meeting Guidelines
+* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
+* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
+* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
+* Join queue to talk.
+* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.
+
+### Participation and Code of Conduct
+* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/).
+* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
+* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
+* If this is your first time, welcome! please introduce yourself.
+
+
+### Scribes
+* Michiel
+
+## Topics
+
+### Heads up for next week topic focused on directories related works
+
+* eP: Yesterday we discussed with Jeff and Hadrian doing it next week
+* eP: Jeff is going to present his ongoing efforts
+* eP: Pavlik is going to present his more recent prototype https://elf-pavlik.github.io/solid-efforts/
+* eP: We will discuss future plans and synergies between those two and other related efforts.
+* MdJ: So the main vulnerability is the link to the IDP
+* eP: I give that as an example
+* RG: maybe start a follow-up issue for the countermeasure
+* eP: I think I'll start a new PR to add a proposed countermeasure, and link them together
+* eP: Jeff, can this PR be merged?
+* Jeff: yes
+
+### initial WebID Document considerations
+
+URL: https://github.com/solid/security-considerations/pull/9
+
+* eP: This PR was created 2 weeks ago. Some things need a little more protection. There was a lot of discussion. Maybe only describe the attack, not the counter-measure? Ready to merge?
+
+### Add advisement on applicability of security policy based on authentication state and resource semantics 
+
+URL: https://github.com/solid/security-considerations/pull/8
+
+* eP: I asked Sarven to give an example
+* eP: when you browse the storage as html, that will generally not be authenticated
+* PA: It might be risky to assume that authenticated requests can only occur with some form of JavaScript. In the future, browser may include part of the mechanisms.
+* MdJ: That already happens with basic auth and with cookies.
+* MdJ: We're all guessing here what Sarven means. I asked him for an example; let's leave it at that.
+* eP: Cookies have other problems. I'll create a separate issue about that.
+
+### Document attacks based on poorly secured discovery mechanism
+
+URL: https://github.com/solid/security-considerations/issues/12
+
+* eP: If applications can attack the discovery mechanism, they can inject all sorts of things.
+* MdJ: Isn't this a duplicate of the first topic?
+* eP: Yes, but it's an extension, more elaborate.
+* Jeff: I would like to back up a bit. Any app that runs as user Jeff on my linux box can do anything it wants to files that are owned by user Jeff. How is that any different from Solid?
+* eP: I think it's very different. It's common with web applications that they are only authorized to something specific.
+* MdJ: Same on desktop, right?
+* eP: We should investigate how sandboxing works on desktop.
+* PA: I have a few ideas about the issue, but am not an expert. Jeff, what you said is true, and this model has proved insufficient for non-technical users; that's why mobile devices are much more strict in sandboxing, and linux now also gets stricter sandboxing with things like snap and flatpack.
+* MdJ: I agree. I think desktop is doing that more and more in the last 5 years or so.
+* eP: We should in general follow the principle of least authority.
+* PA: +1
+* eP: In SAI, users cannot even discover the existence of some data unless the owning user chose to reveal it. IMO, Solid performs very poorly in that regard, at the moment.
+* RG: Solid apps are web apps, not like apps you installed. Security measures on the web have to be stricter than on desktop.
+* MLG: Maybe we shouldn't install malicious applications. It's a matter of trust. We could vet applications with the community (like an app store).
+* MdJ: Yes, but then still there is going to be some risk.
+* eP: Web apps, you don't install them; you browse to them. In SAI, you authorize the app. For the trust, we've been looking into OIDC federation which allows some signatures, and more like an app store. Myself, I have a dual boot on my desktop, because I also don't trust all desktop apps.
+* Jeff: Every document is potentially vulnerable to attack, not just the discovery documents. I understand the need and the push for security. We should not focus just on that; also on the question of how we do make data available.
+* eP: Indeed, it's not black or white. We need to establish trust levels for different parts of the system. Authorization agent has a higher trust level, etc.
+* MLG: The videos from Inrupt encourage using multiple separate pods. That can help, too.
+* MdJ: Yes, like Pavlik's dual boot.
+* eP: Yes. I also wrote that this morning.
+
+
+### BDD style and the importance of use cases
+
+* eP: If we define the expected behavior of the system well, we will be able to better evaluate proposals, by seeing whether what is being proposed leads to the expected behavior.
+* eP: Behavior can include desired behavior as in regular use cases and undesired behavior as in attacks from Security Considerations draft.
+* eP: On the basis of use cases, we can compare different proposals, like SAI vs Type Indexes, and maybe in half a year, have a decision.
+* MdJ: We talked about it in previous meeting. This would work for a single team. We are more of an incubation space. Neither SAI nor Type Indexes is going away and both are allowed in the space.
+* Jesse: I think both are great, but we should try to get more use-case-driven development.
+* eP: +1
+* eP: I want to respond to Michiel. It's good to have multiple proposals in an incubation space. But at some point, for interop, we need to decide. We can provide two alternative mechanisms, but only if we can explain the reason. Failing to agree feels unacceptable to me.
+* Jesse: +1
+* Jeff: The majority of developers ignore both SAI and Type Indexes. A few of them use one or the other. "It's not a standard, it's not something I can depend on, why should I use it?" The longer we are in that period of ambivalence, the worse it's going to be in the long run. If we're going to have client-to-client interop, we need to give that consideration. Placing all of this on the server is a different view.
+* PA: And yet, they use Solid.
+* eP: I will start writing use cases that show the behaviour we're aiming for with SAI.
+* MdJ: I don't think there's a lack of arguments for why SAI is better than Type Indexes. Maybe we should acknowledge that different people use Solid differently. There is a single storage protocol, but it doesn't have fine-grained access control. 
+* eP: But how do app devs know which to choose?
+* MdJ: App devs just publish their apps and their data needs; the rest is out of scope for them.
+* eP: But what about data discovery by the app.
+* MdJ: Just support both.
+* eP: We should agree on one.
+* MdJ: It is not just between SAI and Type Indexes. There are web nodes, IPFS, etc. As an app developer, you may hope that there is a single way, but that's not the reality.
+* eP: PA?
+* PA: I don't have much help to give here. but some thoughts.... This is not a WG. The CG charter doesn't require us to choose a single solution. For WGs, it's a necessity to reach agreement. The goal of a CG is more incubation. But I feel your pain. I started to develop my own Solid apps, and it's difficult to choose what to do, what to support. There's this mantra of being strict in what you produce and flexible in what you accept, but this diversity is a pain. We should try to reach a balance between healthy incubation and the proverbial bazaar.
+* MdJ: Look at the possible outcomes, if we need to decide between Type Indexes or SAI. If we choose one, the other group would be sad. I don't think either is an option. I couldn't choose either one.
+* eP: That's why I talk about BDD. We should work harder at finding consensus. It shouldn't be personal. We need a way to objectively evaluate proposals without getting attached to any one of them.
+* Jesse: +1
+* PA: +1
+* PA: Solid has a broad scope. There may be different ways for multiple things to exist. Some use cases may be too niche, and others more desirable. That's also how consensus works.
+* eP: Maybe we need to introduce different storage types. but at least there would be a good foundation to explain it. Even if we don't achieve unification, we should at least have due diligence.
+* Jeff: I agree with PA. It's a broad ecosystem, and it's premature to pick one authorization mechanism. But I want to come back to the point about clients and servers. Suppose we want to give developers the choice between SAI and Type Indexes. How is that implemented? Some IDPs produce WebID documents that don't link to Type Indexes, and other don't link to SAI. We don't have a clear pathway there. I'm in favour of pursuing both approaches. There are plenty of places where there are multiple ways of doing things, I don't think that's a weakness.
+* eP: I think the spec should require what is in the WebID doc.
+* MdJ: Yes, that makes sense.
+* Jeff: My opinion is that, if there is a proposal that has reached the level of SAI and the Type Indexes, a number of people have worked on it, in the CG and with implementations, then it's the responsibility for those writing WebID docs to take that into account. Rather than deciding for one or the other, I think we should make it a strong recommendation to WebID providers to include certain things in the WebID document, and allow clients to create their own third option. There has to be a way for a client to experiment with that.