PASS Roadmap 2024

PASS Roadmap 2024

Goal

Build a system where users can share important housing information about themselves, simply by connecting with each other and uploading existing documents.

• Allow this data and associated documents to be easily shared with case workers and anyone else the user wants.
• Prevent unauthorized access to this data, and allow a user to revoke previously granted access.
• Facilitate easy communication between the user and everyone they are sharing their data with.
• Make this data interoperable with HMIS systems throughout the United States.
• Make this data shareable with people who are not using Solid.

Work - Part 1

Get document sharing working smoothly

1. Add option to register with PASS through an existing pod. This will allow PASS to be used independently by offices with no knowledge of each other, and still interoperate.
2. Remove all "Pod URL" and "WebID" inputs. Replace them with direct selections from the contacts list. Streamline the initial contacts list input to generate the proper web ID based off reduced input. Make manual webID entry an "advanced" option or "bad case" scenario.
3. Redesign final signup screen to include a guided walkthrough of the user's POD and what they can do with PASS. Walk them through how permissions and sharing work.
4. Convert the documents table to use a SparQL query against Community Solid Server's SparQL endpoint. This will allow us to both reduce the number of network fetches we must perform, and allow the server to enforce permissioned access to resources.
5. Revamp document sharing and UI. Currently, individual document sharing works, but is not in sync with the documents table. Synchronize the "read state" of the table for each user. Update the UI to communicate who a document is currently shared with. Revamp the "share documents folder" button to show when some documents in the folder are shared, but not others.
6. Add a notifications system so a user can be informed if a document is shared with them. This can be implemented with Solid Webhooks.

Work - Part 2

Improve communication with contacts, and extend our structured data support

1. Revamp messages to be a live chat like a text message chain. Currently it looks like an email inbox, and you must refresh. This is annoying to do on desktop, and difficult on mobile. The live chat can be enabled with the solid notifications protocol.
2. Extend the Civic Profile to include tracking of current location, past locations, current mailing address, and past address. The current location can be anything (what 3 words, GPS coordinates, cross street). The mailing address should be a legal address.
3. Allow the user to share the civic profile with contacts like they do documents.
4. Expand the civic profile to include the most common data fields from the HMIS Data Ontology.

Stretch Goals

Implement PDF rendering and scraping

1. Implement a PDF template creation flow through which we can create PDF templates that understand Civic profile data.
2. Implement a way to share these templates with users.
3. Implement a rendering engine that allows users to render these templates with data from their pod.
4. Implement a way to scrape data from uploaded documents and automatically populate the civic profile with it. Graphmetrix has a feature like this already, which may be worth investigating.

These stretch goals provide a solution to the "first user" social networking problem. Why should the first person join the PASS network? They can use it to easily fill out monotonous government forms.

---

Change in Direction Notes

Last year we enforced some design standards and directions that I think we can reconsider this year:

1. Redirect features from complying with the Solid Protocol Standards to connecting with a customized Community Solid Server. We tried last year to restrict development to just what was supported by the Solid Protocols. However, the Solid Protocol documents are not finalized, nor will they be finalized in the forseeable feature. Their bid to create a W3C working group has been rejected. Additionally, many core aspects of the spec are still in flux. The Solid Webhooks have been added and implemented in the past year, and changes to the WebID structure are still being debated. Trying to parse out from this political situation what features we should use and what we shouldn't has proved challenging. The Community Solid Server provides a good touchstone for what we can expect a solid server to support, and insulates us from many of the more difficult forms of these debates. This means that, if Community Solid Server provides a feature, we may use it. If we want a new feature that is not currently implemented by Community Solid Server (but is consistent with the Solid spec), we may implement an extension and use it.

2. Change our target user from the case manager to the person facing home insecurity. The target server provider is still the nonprofits. Our research of the past year has shown us that case managers already have several pieces of professionally designed software that cater to their workflows. Competing with these existing systems is not a challenge a volunteer group like PASS can take on[^1]. The challenges faced by these systems also are not interesting. They are largely a collection of finely-tuned admin consoles, not the kind of work that is attractive to volunteers. Refocusing our work on primarily the person facing home insecurity has multiple advantages:

   1. It reduces the scope of situations PASS has to handle.
   2. It aids a group not commonly considered in civic tech
   3. It sheds light on issues not commonly discussed in tech groups.
   4. It allows PASS to become more versatile by focusing on a few basic features. For example, with the feature set described in parts 1 and 2, a person could use PASS to securely share their location with friends and not interact with the document aspects or government aspects at all.
   5. It allows PASS to focus on simpler problems that are more attractive to volunteers.
   6. As we have a narrower scope, we will be able to simplify onboarding
   7. It means we don't need to handle multiple user types

3. Focus on a user with this profile:

   1. The user is an adult, english speaking resident of the state of Oregon of sound mind and body who may be facing housing challenges
   2. The user is not "tech savvy," but is able to find their way around their computer, and would be able to understand simple, non-technical descriptions of new software.
   3. The user's only access to a computer may be through a public library.
   4. The user wants to be able to share documents and information about themselves with other people. This means we will not worry about cases where a person is too mentally unwell to be trusted with software. This use case is immensely difficult to tackle at every level of society. It introduces the question of data custody which can only be taken on with the assistance of a lawyer who specializes in this area. At this stage in the project, we do not have the resources to tackle such questions.

The purpose of all these changes is to focus PASS on a core feature set that its volunteers are able to implement within the year, while also keeping the project extensible. In the future, we may be able to implement integrations with existing case manager work flows, but first we need to build an app that is worth integrating with.

---

Topics for Further Discussion

This section is for subjects that were brought up by members during roadmap planning, but have not been included in the current roadmap. Each topic had its own reasons why they were not included, but most of these topics either seemed to require too much work to be implemented by the PASS team within one year, or because it was not clear how the features would interact with the other features in the roadmap. Anyone is welcome to take up any of these features and draft a plan on how to approach them, if they think the feature can be reasonably completed by the PASS team within one year. Following a presentation, the PASS team can then decide whether to include this in the roadmap.

Client Side Encryption

Currently, PASS does not implement any encryption systems. We expect the server to implement all required security measures. There are many advantages to Client-side encryption:

1. The user will no longer have to trust that the server is securing their data properly.
2. The data will be more resistant to government surveillance
3. If the server is hacked, the user's data isn't compromised

However, it has tradeoffs:

1. Interoperability becomes more challenging. Now, an interoperating app must understand both the data shape, and the data decryption mechanism. We must also trust that all interoperating apps will continue to enforce the encryption without error
2. It limits what actions the server can perform on the data. E.G. we can no longer run a server-side SparQL queries, as the data is illegible to the server. We would be limiting most interesting behavior to client-only.
3. It doesn't hide ALL information from the server. In spite of point 2, the server will still be aware of the size of the person's data, the general partitioning of it, who is accessing the data, and how often they are accessing the data. Even this metadata may be important, so the user must still put some trust in the server.
4. There is not currently a standard key or credentials management system in Solid. PASS would need to roll its own and get all interoperating groups on board. Since we are a group of volunteers with relatively little experience in security, this will be a tough sell.
5. The user must remember 2 passwords now: the password to their Solid Server account/webId, and their decryption password. These passwords may be the same in many cases. However, if a pod is linked to several different solid webIds, there may be multiple passwords to remember.
6. It is much more difficult (perhaps impossible) to recover lost accounts. As long as data is encrypted server-side, if the user forgets their password, they can call up the server administrator and persuade the admin to reset their password for them. If the data is client-side encrypted, this password reset won't give them access to their data again. The data is effectively lost.
7. It is unclear how a person should share an encrypted document.

It also doesn't solve all the security problems faced by Solid Pods. Solid systems are vulnerable to compromised client apps. It is easy for a hacker or scammer to put up an impostor client app or hack a widely used one. This is a problem with our open source project. A hacker could simply fork the repo and publish their own false version of PASS. The user wouldn't be able to tell the difference without a careful inspection of the client. Since the data is decrypted client side, the hacker will have full access to it in spite of our security measures. And, since client apps can be updated at any time without the user's knowledge, it is difficult for a user to assess if an app is compromised. Even if the user does a full code audit, the app maker can deploy a change immediately after the audit and invalidate it.

Some possible approaches:

• Implement a client side encryption mechanism like double ratchet, but make it optional and only for advanced users. This will mitigate some of the more difficult userland problems with client side encryption like 5 and 6. Don't worry about interoperability for now.
• Implement a server-side encryption module for community solid server. This is more immediately useful to anyone using CSS, which makes it more likely someone will notice flaws in it, and fix them. It will also have impact outside our app. And it will weaken one attack vector for hackers without making solid apps more difficult to write.
• Talk to other solid app creators about their key sharing systems.

A proposal will need to creatively balance these trade-offs and benefits.

"Sharing Space" and Document Provenance

Some federal offices seem interested in setting up document provenance systems. I.E. putting information on a digital document so that you can later tell where it came from. This can be done using public key encryption and signing. If we generate "sharing copies" of data to send to other users, we may be able to apply for research grants from the federal groups interested in this.

This is an interesting idea, and may be able to provide better data security than what is currently provided by solid. However, it probably requires fully re-architecting the app. Something like this is plausible:

1. The user has a private pod. The user may access and upload to the pod, but no one else can. No data from this pod is ever directly shared.
2. Inside that private pod is a list of all the user's contacts
3. There are 2 public portions of the pod:

• an inbox which the user's contacts may add to (but not read).
• A collection of type indexes. These describe the shapes of data available in the pod. Contacts may reference these to figure out how to retrieve data.

5. The contacts submit data access requests in the form of SparQL or GraphQL queries. They use the type indexes to discover how to write these.
6. The pod server does preprocessing on the query, and based on policies set up by the user, decides to either reject the request and send an error response, approve the request and send the data, or wait for the user's approval.
7. Upon finalizing the content of the response, the pod server adds signature and provenance information to it. The source data is never shared. Only the copy generated by the query result.
8. The pod server itself provides an app that allows users to manage these access requests and data. It does not allow other apps to manage access requests.

This would also allow a system that's more compliant with government data access regulations. A recent study argues that Solid is not GDPR compliant, in large part because its data access request system is quite weak. An architecture like above would allow us to use Solid for our own compliant access request system. This also helps with a critique we've received from some case managers. Often, they only want to see the minimum amount of information necessary to do their job. If they see extra information, they risk violating data access regulations. A query system gives them strong control over exactly what data they're seeing.

However, this approach seems incompatible with many of the current features of PASS. Document sharing, for example, would need to be fully retooled as a request for a certain type of document. It would also require researching alternative access control systems to what is provided by SoLiD out of the box, and probably implement something ourselves. A proposal here would require a description of what an access request looks like, how the system should determine whether an access request is valid, and how the system should present the request to the user. Access Control Policies may be a good place to start for this.

Location Tracking

A current item in the roadmap includes a location recording and sharing feature. Location tracking, and anything that can be perceived as such, will be a touchy subject for the homeless community. Many fear that their location will get into the hands of law enforcement or other groups that are trying to harm them.

The system described in the roadmap is intended to behave as a location sharing system, like sending your GPS location to a friend in a text message, or enabling location sharing in SnapChat. However, the feature described in the roadmap would make a person's most recently recorded location visible to:

• The user
• Anyone the user is sharing their location with
• The server administrator

Alternative ways to balance the concerns of location privacy vs location sharing are welcome.

Community Pods

Wilf: It would be useful if, when someone signs up for an organization through PASS, that organization is able to supply them with a contacts list, documents, etc. Perhaps any time you connect with a "community pod" you receive all their data.

Tim: This is a cool idea and something worth exploring. Could make a good subject for a hackathon. CSS has root pods, which could be useful for the server administrator to store general updates and notifications. We could also use webhooks to allow someone to declare themselves a community pod, and allow others to hook up to their updates.

Modularizing the System

Wilf + Kahung: There are currently a lot of features in PASS. Is it possible to break them up into separate, individual, systems?

Tim: In theory that could be useful, but it's not 100% clear to me what that would look like. IME apps have a hard time limiting themselves to doing "just one thing." They generally need a combo of 3-4 related things to do anything interesting. This could be similar to what SolidOS is trying to do. And the solid data modules project is working to make common, shareable data formats to boost interoperability.

[^1]: For an example of such a system, look at ArkCase. NOTE: ArkCase is not used by any group in Oregon that we are looking at interacting with. It is provided as an illustration of the complexity of the systems that are used in Oregon, most of which are inaccessible to us.