Add meeting minutes 2024-05-21 (Special Topic Meeting)

meetings/2024-05-21.md

@@ -0,0 +1,115 @@
+# W3C Solid Community Group: Special Topic Meeting
+
+* Date: 2024-05-21T14:00:00Z
+* Call: https://meet.jit.si/solid-cg
+* Chat: https://matrix.to/#/#solid_specification:gitter.im
+* Repository: https://github.com/solid/specification
+* Status: Draft
+
+
+## Present
+
+* [Matthias Evering](https://solidweb.me/testpro/)
+* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
+* Aaron Coburn (Inrupt)
+* [Virginia Balseiro](https://virginiabalseiro.com/#me)
+* [Sarven Capadisli](https://csarven.ca/#i)
+* [Rahul Gupta](https://cxres.pages.dev/profile#i)
+* John Kirkwood
+* Otto-AA
+
+## 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 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.
+
+### Chair
+* Virginia Balseiro
+
+### Scribe
+* Virginia Balseiro
+* Sarven Capadisli
+
+---
+
+## Topics
+
+### Security Best Practices
+
+URL: https://github.com/solid/security-bp/pull/2
+
+* eP: Let's keep in mind different levels where the decisions are made.
+* eP: Anything that is not a requirement in the spec, is left up to be decided by Developer, Provider or the User.
+
+
+|   Who    |  Where   |
+| -------- | -------- |
+| W3C CG or other space following Open Standards development | Incubation |
+| W3C WG (informed by above)   | Notes and Recommendations     |
+| Developers | Implementation  |
+| Provider | Deployment configuration  |
+| User | Account settings  |
+
+[Provider]
+ME: I'm not sure if what I maintain is valid as reference.
+I have documented everything (solidweb.org, solidweb.me and teamid.live) here:
+- https://github.com/serverproject-dev/solidweb.org/blob/master/config/readme.md
+- https://github.com/serverproject-dev/solidweb.me/blob/main/config/readme.md
+- https://github.com/serverproject-dev/teamid.live/blob/main/README.md
+
+* SC: "Authority" / decision of URI owner / content creator.
+* eP: We should jump into specifics. In practice, unless spec requires something, user is final authority. User can only choose whatever implementation provided. 
+* eP: Based on Otto's work. Comes from their implementation experience. People should have best information to make decisions. None of these policies ??? are normative. Considerations. Audience is implementors and providers. 
+* Otto: In Solid pods data is stored in same origin. HTML files on the same origin ??? Main problem is if in same origin/site security policies do not apply by default. 
+* AC: There are a category of attacks which rely on the browser's trust on a domain. If yo have a set of Solid pods which each have their own domain they can circunvent this issue, but on same domain and even sub-domains, you can engage in phishing, using service workers to exploit access controls. 
+* TBL: That we've known for a long time. Should this be a surprise that when we give ??? Do we have any reason to be surprised that we have security issues when we give different users pod with the same domain? 
+* eP: Deployment suggestion to keep storages separate. If Pod only stores RDF/media it's less risky that people deploy apps. Depends on usage those risks will vary. 
+* TBL: Even when a Pod has RDF. In practice you end up serving HTML file which downloads JS, which ens up running on the same domain as the Pod. 
+* eP: I don't agree with the assumption that one has to serve HTML from a pod. It's risky to navigate to SolidOS instance and authenticate. 
+* SC: Who has used a webpage without JS in the past week? 
+* TBL: Static webpages exist. 
+* SC: If storages are limited to RDF/media nobody is going to bother migrate to Solid because they can't host a webpage with even light JS unless they use a very custom server that allows that type of thing. HTML trumps RDF and JS is even more common, whether we like it or not. Pod is a generic storage. Could host anywhere from RDF to homepages with JS to media files. 
+* TBL: "JS+HTML trump RDF", we're building new systems. We can think of a system without JS. Worth flagging security issues are worse if you have pods on same domain.
+* eP: Many web APIs only provide JSON and nobody suggests people navigate to those endpoints. Client app will do fetching and is responsible for rendering and presenting. We need to work in a way that those different approaches are possible. 
+* AC: General separation between API and web apps. Lots of the issues have to do with whether Solid is an API or a platform for hosting webapps. There are providers that will have a hard stance. If we focus on a single answer we will lose focus ??? specially for sensitive data being hosted. Example from GH: you can host any file, if you want to make use of GH Pages where these files are rendered, they will be on different domain. If you're able to serve arbitrary files, people can start to misuse the trust placed on the GH app. Same kind of security issue that you can exploit in Solid. 
+* VB: Security concern is valid. Concerned about sandboxing as a solution because of what SC is saying re anyone wants to host a pod which is a valid use case, not just HTML, SVG but CSS can have some concerns. It also blocks an entire type of application, like dokieli, notion or, ??? that wants to interactively write to a pod. Also hear the argument about diferent providers doing different things. It is one thing re having a security concern, and then it is another hting about sandboxing. Most implementers will want to use safe-first choice and conform to secutiy bp. Not saying the sandbox is not the solution but ??? maybe we should spend more time on what other possibilities we have so they don't block all the use cases - probably common for a pod.
+* eP: Let's keep in mind there are different use cases and requirements. Health-care, finance.. more sensitive. Risks are higher. Let's do our best to document that if you need to run several pods on same domain don't use HTML, if you do need HTML run pods on different domains. 
+* TBL: It's important to keep in mind all different scenarios in which people use pods. There's the Data Kitchen, all the code from SolidOS wrapped in MacOS application. Bunch of code which acts like a browser. Different security profiles. 
+* RG: Rather naive questions but browsers need these assumptions for a certain reason. Extending the standards for ??? so that pods have to be on different subdomains? 
+* Otto: Not only put pods on same origin but also different trust levels for same origin. Even if only one pod, two different actors can still abuse the same origin. 
+* TBL: Change CORS difficult because we're not changing the browsers. One pod could change so origin is not the principle that any solid container can be treated as an origin instead of domain name.
+* JK: From healthcare/personal health record perspective. Making sure from protocols one can manage their own data or delete or give data to others. Trying to get my technology arms around this. Listening and seeing where it's going. 
+* eP: We will not find a solution today. We need to iterate and keep working on the document. Let's focus on the specific pull request. We can then iterate. Can we start on the PR as a starting point? 
+* VB: I'd like us to add comments to the PR. I personally need more time to look into this. Would like another session, e.g., next week. 
+* eP: I'm worried that we have PRs hanging. Otto created issue over a year ago. SC, what's the main change you would like to see to have this PR merged? How can we see that next week we can have it merged? 
+* SC: Not all on me, I raised some things because I felt some of the assumptions around what solid storage is or isn't. Some are not completely hashed out with respect to web architecture. Better detailing on specific scenarios where there's a recommendation where come Pod providers can take into account. If it's multiple storages under same origin, and all these other criteria, multiple users, etc. we suggest to sandbox, etc. Also state which use cases it would block. On one hand you're going all in on security but also cutting out a bunch of use cases. There are legitimate reasons. 
+* VB: +1
+* TBL: This community is disfunctional in how it works. Does it by trying to get it right by each PR. This PR is better than no PR. So let's merge it. Whatever discussion we have around PR are useful but if there's a mistake fix it. We should not get the PR right but have it merged.  Easer to read merged PR than a PR.
+* VB: Agree we shouldn't delay forever, that's fine. Also don't think that something easier to read is reason to merge. There is ways to read the PR, default view. Agree w/ SC on detailing different cases. I disagree that we should merge things because they ??? the disfunction is not having more review but if we don't have enough input then there is deficiency in knowledge / people. On the solidproject.org website. Happy to explain that but not topic of this meeting.
+* eP: I can take action to...
+
+ACTION: eP to add additional information on those different cases. 
+
+* eP: We can schedule another session next week with the goal to merge by the end of next session. It'd be better than having nothing. 
+* SC: Reasonable compromise. Point is not to hold off until it's perfect. Take basic assumptions into account. Compromise is update with those comments. If that makes it into the PR for next week and other people show up. 
+* VB: +1
+* SC: Point of reviewing is to cover what we're saying. Document like security best practices has a dfferent tone/expectation as to what it is. If "best practice" boils down to few individuals with limits/preferences on use cases and communciate that as a way that is as if representative of how everyone else is using solid.. that may not be accurate. I'm aware we can always update but aware also of how long it takes to update. I don't see a survey.. what data are we using to say this is best practice? I don't disagree with the recommendations, but being mindful of what it says. 
+* RG: Sense I get from this PR it is trying to do too much. Is there a minimum we can extract? 
+* TBL: Yes!
+* eP: This is initial PR, hard to make other PRs if no initial document. Could you say how you would like to split? 
+* RG: Just have the PR where we list the problem. Then make PR addressing that issue. 
+* VB: I don't think that's going to work. We have an initial document that lists things. Good compromise is what eP suggested have those considerations, here is as a potential issue and how to mitigate. We can add more stuff for use cases and build around this issue. But having problem stated in one PR and merge that, probably not great. Still want a document that's sensible in the first merge.
+* TBL: Maybe change it to say this document is a fairly random selection of things we've - small number of people - come up. Not complete overview of security issues of Solid. It has to set expectations.
+* VB: We should change the title?
+* TBL: Yes, "Security Observations of Solid"
+* RG: Leave title as is, in the introduction say that it is random / we'll have comprehensive in the future.