-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Welcome to the courtbot wiki!
Design of the Application
The courtbot application exists to assist people who need to attend court. It provides timely reminders that help people get to court at the correct time. It may be helpful, if anyone has questions about this document, to edit it, place your questions in the document, save that and create a pull-request from it. Responses can then be made in the pull-request or in the main document.
The courtbot application has three main functions:
- connect to the Santa County Court site, at pre-defined intervals, and locally store case calendar information.
- allow a person to connect a phone number and a case number and save this connection.
- find case-connected phone numbers and text information to the phone number one or more times, at pre-determined intervals before a required court appearance.
The court website in Santa Clara County has a REST service behind it which vends data as JSON files. The keys to each court appearance on the calendars consists only of the case numbers, the list of parties and the scheduled time for the court appearance.
Strictly speaking, this service does not require any links to anything but the case number and scheduled time. The name of the parties may be helpful if we have an interface through which someone can locate their case, but this feature is not planned for the current release. On the other hand, we get the parties information with the response no matter what. It is just as easy to store it as not, while the application is not storage-constrained.
It has been brought up that we can decide not to store the court data and only fetch it when we need it. The application would be simpler if it does not store data. It would also mean that we do not need to worry about changes to the court data, such as when court dates are re-scheduled before they occur.
One reason to store the data ourselves, though, is to reduce risk. It is a general principle of engineering that, when one is building a system linked to other systems, constructing things so that a failure in one system immediately leads to a failure in other systems is not a good idea. There are times when data is extremely time dependent, such as stock prices in a stock market or bid information in an auction. Court data is not of this type. Court appearances are, in general, scheduled weeks or sometimes months in advance.
Another reason is that, because of how court appearances are scheduled, we do not have to worry about court dates being changed. In general, court appearances are only scheduled at other court appearances. Before an arrested person is arraigned, there is no scheduled court data as such. But there is also no case number before arraignment. At an arraignment, a subsequent court appearance is scheduled. Also, I believe that a court will only schedule one court appearance at a time. It may be known that several court appearances are needed, but the date and time of each one is only set at a court appearance. So the court calendar is, in general, only added to.
Also, it is easy to write code which looks at a newly observed court appearance on the calendar and determines, in the stored data, if this case number was seen to have scheduled at another future time. One then conforms that the previously observed court appearance date does not appear in the newly fetched calendar, whereupon one can delete the previously observed court appearance date and store the newly fetched court appearance date.
All that is needed here is that we connect a scheduled court appearance with a phone number. We do not need any other information about the person requesting a notification and, since any information we would collect about the requester would be PII (Personally Identifiable Information), it is better to not collect it.
We do need to keep the phone number and we can do that securely. See this OWASP Cheat Sheet on storing passwords. We can use the same techniques to store the phone number after it has been salted and peppered to ensure that it can be stored safely and retrieved when needed.
This implies that any person can ask to be notified about any case appearance. This may not be within our goals, but I cannot think of any reasons we should be bothered by this. The court appearance information is completely public and so notifying any person about any court date does not impinge upon any rights to privacy.
We can use one of a few or several different providers to send text messages. I would sugges that there is not much technical differences between them. The APIs are not complex and there is only so much one can do. Non-technical considerations should probably drive our decision on which texting provider to use.
We can notify at different times. Existing implementations may only notify once, one day before a court appearance date. I think we can do something a little smarter than that, but this is a good MVP design goal.