-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #640 from solid/2024-03-20-meeting
CG meeting notes 2024-03-20
- Loading branch information
Showing
1 changed file
with
125 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,125 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-03-20T14:00:00Z | ||
| * Call: https://meet.jit.si/solid-cg | ||
| * Chat: https://matrix.to/#/#solid_specification:gitter.im | ||
| * Repository: https://github.com/solid/specification | ||
|
|
||
| ## Present | ||
| * [Michiel de Jong](https://michielbdejong.com) | ||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * [Ted Thibodeau](https://github.com/TallTed) (he/him) ([OpenLink Software](https://www.openlinksw.com/)) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * Tim Berners-Lee | ||
| * Hadrian Zbarcea | ||
| * Jesse Wright | ||
| * [Sarven Capadisli](https://csarven.ca/#i) | ||
| * Theo | ||
| * Damon | ||
| * [Matthias Evering](https://solidweb.me/testpro/) | ||
| --- | ||
|
|
||
| ## Announcements | ||
|
|
||
| ### 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 Conduct](https://www.w3.org/policies/code-of-conduct/) | ||
| * 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 | ||
| * elf Pavlik | ||
|
|
||
|
|
||
| ### Introductions | ||
| * name: text | ||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Update on ecosystem tests work | ||
| URL: https://github.com/solid-contrib/ecosystem-tests | ||
|
|
||
| * MdJ: We're starting ecosystem tests with headless browsers. Making progress on switch from launcher-exploration to SAI. | ||
| * VB: Anyone would like to talk about these topics? | ||
|
|
||
| ### ACP Tooling | ||
| URL: https://www.inrupt.com/blog/podbrowser-sunset | ||
|
|
||
| * MdJ: Does podbrowser sunset create a gap that needs filling? | ||
| * VB: Postpone until MdJ is here? Okay. | ||
| * MdJ: Browsing ACP is currently hard. Do we see a gap that CG should focus on bridging? | ||
| * eP: Can we clarify what is the demand from devs? In SAI only authorization agent has to deal with ACP, apps don't need to touch it. | ||
| * SC: I would like to get a status update on ACP. The initial version was released and no further work was done on the spec or implementations AFAIK. | ||
|
|
||
| ### Spontaneous discussion about WAC, ACP, SAI, and app sandboxing | ||
| * MdJ: The PUMPKIN WG, in my opinion would choose ACP over WAC; this is just my impression. | ||
| * SC: Asking re CG's position as opposed to corridor (side) conversation. | ||
| * eP: CSS added support for ACP in v7 | ||
| * TBL: Origin should be implemented in NSS and CSS. Browsers set origin as a warning. In a way, it is already a broken system, and we need to work around it. If the agent is providing an Origin, the origin needs to support all the modes that are needed. | ||
| * MdJ: It is clear that some people want to use WAC, some ACP. We should support both, as well as SAI and Distry which Digita wants to bring. | ||
| * TBL: In spec, the server can choose, and clients have to support both. It would be nice if ACP would be a superset of WAC. | ||
| * TBL: What do you mean that apps don't need to deal with WAC or ACP? | ||
| * MdJ: In SAI, by the time app launches, it has to have the access it needs. | ||
| * eP: explaining authorization agent... | ||
| * TBL: People want to use Microsoft documents in Dropbox. in GitHub, we have collaboration with groups and can easily change access. | ||
| * MdJ: We probably should design for the world of untrusted apps. Currently, we have silos but that also keeps the data safe by partitioning it in the silos. With Solid, there is a risk that apps can get more access than user intends to give them. People expect to control who gets to see all their data. | ||
| * TBL: Would you do the same on your laptop? macOS moves away from asking if an app should have access to some documents. | ||
| * MdJ: As a power user, you may have more control, but as a regular user, you may want to have more protection. | ||
| * TBL: Why should I not trust, for example, Dokieli, if I want to help making it better? Do you think open source stuff should be given more power? | ||
| * MdJ: Even if software is perfect, things can happen by accident. If something dosn't need some access, it probably shouldn't get it. | ||
| * eP: I would like devs to build apps with comfort, and apps have least priviledge by default. | ||
| * SC: No matter whether app is open or closed source; bugs can happen. You need some kind of 3rd party that ensures that something will be well behaving. Some authoritative location that can assert level of trust. I don't know about having an authorization agent. At some point, user places some trust somewhere. If we only have authorization agent which is conforming and trusted. | ||
| * eP: comparing to AS in OAuth2 | ||
|
|
||
|
|
||
| ### Security Best Practices | ||
| URL: https://github.com/solid/security-bp/pull/2 | ||
|
|
||
| * eP: Virginia created a repo. I moved the PR. How should we follow up? I'm the only author currently, should I just create PRs and wait? Who else is interested to work on this? Maybe reach out and get more people to join? Aaron, maybe? We need at least 2 or 3 people; I'm concerned we don't have them. | ||
| * VB: If no one here is interested, how do we reach out? | ||
| * SC: I see this document as a long term investment. I think we should start collecting the data and follow the general guidelines. Maybe the correction levels are not mappable. Maybe raise monthly updates on the mailing list. Think of it along the lines of "Findings". | ||
| * TBL: The WG will have its own security findings. We should also have accessibility best practices. How do we know when we are done? Do we have some requirements document? Whenever something goes wrong, do we write it down? | ||
| * MdJ: The current text is mostly about hosting HTML files. | ||
| * eP: The countermeasure shouldn't require violation of the spec. | ||
| * TBL: This doc should have a more specific title | ||
| * eP: This specific issue is just the first one; the doc will gather more. | ||
|
|
||
| ACTION: eP send out email to the mailing list asking for collaboration | ||
|
|
||
| * eP: if we as a CG don't make sure Solid is secure, then that's a problem | ||
| * TBL: There was an issue raised in SolidOS: whenever you store Markdown and simple HTML, it can be attacked. It is hard to prevent people from breaking out of HTML which invokes JavaScript. It is hard to clean HTML to prevent this. We may need to keep track of the state of the art. | ||
| * MdJ: It should be responsibility of the app. | ||
| * TBL: For example, chat app has to sanitize HTML and markdown. | ||
| * SC: The web runs on HTML; the issue is not about the HTML. Any time the app needs to put something on the screen is a potential risk. It is not about HTML being bad. One could put JS in a string literal in Turle, and this could be potentially executed once it's in the DOM. | ||
| * [Little Bobby Tables](https://xkcd.com/327/) | ||
| * eP: we don't have to do everything in the same PR. Everybody can add PRs to this repo, without being committed as a co-author of this doc. | ||
|
|
||
| ### One Solid CG for single-app, multi-app, and multi-agent | ||
| * MdJ: How can we meaningfully structure our CG and spec stack so that it enables single-app Solid (e.g., Solid OS, WAC/ACP), as well as multi-app Solid (e.g., client-client specs, data modules, shape trees), as well as multi-agent Solid (e.g., advanced SAI, OAuth)? How does the possible creation of a "Pumpkin WG" affect our CG in making room for these three missions? | ||
| * eP: :thumbsup: I would add that each agent can own a number of storages (AKA pods). | ||
| * MdJ: In SolidOS, you have pod and SolidOS running on it. Than you have multi-app where interop is more important. And there is world with multi-agent collaboration. It is part of the previous two, but it has its own nuances. It seems like we are solving one problem in multiple ways. We were trying to write one spec. The curent spec being CRUD for LDP, seems best fit for SolidOS. When it comes to interop, SAI seems not like an extension of the Solid spec, but an alternative. | ||
| * eP: I see the multi-app, multi-agent, and each agent with multiple pods scenarios as a general case. All the single app/agent/pod variants seem like different special cases that the solution to the general case should still cover. | ||
| * SC: I'm not sure if there is a good answer. My feeling is to continue treating it as an incubation space. Keep on working with what we have; keep SAI, WAC, ACP, and see where it goes. | ||
| * MdJ: We should probably rewrite the homepage. | ||
| * TBL: Let's remember that we need to catch bugs. We don't know when/if the WG will start; we need to track security issues, have tests. For now, we are still in the working group mode. | ||
| * eP: I see need for common use cases and requriements derrived from them. This way we can evaluate proposals based on meeting particular requriements or not. | ||
| * MdJ: Since we are an incubation, we don't need a single set of requirements. We have a responsibility to hold the space and have ways to verify conformance. We shouldn't restrict which solutions people are using. If a particular solution doesn't meet a use case, it shouldn't be cut off. | ||
| * eP: We don't to disqualify based on meeting requirements (or not). We can just make evaluations available so that people can make informed choices when picking particular solutions. | ||
|
|
||
| ### Dealing with profile data and contact pickers | ||
| URL: https://github.com/solid/contacts/issues/5 | ||
| * MdJ: Profile data such as `foaf:name` can live in an addressbook entry, or on a public profile, or on an extended profile. This is where the contacts client-client spec and the webid-profile spec come together. Elf Pavlik proposed a Contacts Work Item for the CG. | ||
| * MdJ: Apart from where data about a person lives and how it is disclosed to apps, for multi-agent Solid we should look into how on-pod addressbook data can interact with OS-level SAI-agents data. | ||
|
|
||
| ### Adding a shape tree to each client-client spec | ||
| MdJ: In preparation of the hackathon, elf Pavlik, Jackson, and I concluded that apps should not be allowed to define their own shape trees. Instead, shape trees should live in trusted locations — maybe as part of client-client specs and hosted on solidproject.org? To be discussed. :) |