If it ain't needed, the bits are recycled
Keeping excess data is irrelevant, costly, and inefficient.
The Process
- Overview
- The goals are around providing a means to prioritize with people, which is a time windowed event. We've focused on only what is necessary for function, privacy, and management. We utilize "localStorage" for the user's experience, which is automatically cleaned up either at the users discretion or after the event has expired (while user is on the site). We utilize Cloudflare and Digital Ocean which may act on our behalf for security, caching, trend analysis, etc. purposes. We utilize some script/style caching services provided by unpkg, jsdeliver, and cdnjs. Like all webservers, we receive the information that your browser, and any proxies, choose to send to us which may include things like ip address, language, etc. We may utilize this info for throttling, security, or other management purposes. We don't require a login, signup, or other personal info (name, address, etc.)...because it is irrelevant to the process.
- Creating an event
- When creating an event, our servers receive the timeframe, participant count, and group count & volumes #. (ex. "/60/7/000" = 60 seconds, 7 people, 3 groups wo/volume adjustments). Our servers then return a unique id. (ex. "20230123-22cc4e5c961") All other details are packaged into client-side only Url(s). You are then responsible for distributing the url(s) at your discretion. We save the packaged details to your browser's localStorage so that you can access the state of things. (FYI: if you clear/delete your localStorage or use a different browser, there will be no awareness) For internal use, we increment counters to see things like how many events were created. These counters are reset as needed.
- Participating in an event
- When people participate (from the url you provide), all the details are unpacked from the url. If the user participates, localStorage is used to save the event, to prevent multi-submission and for easy access of results. When a participation submission is made the id, group number, and up to 3 priorities (numerical index) are sent to the server. (ex. "/20230123-22cc4e5c961/213f" = id, group = 2, choice 1, choice 3, and no choice). The participant is given the opportunity to access the results once the timeframe has expired for a limited time.
- Results from an event
- When the participation timeframe has expired, the results will be calculated once the first user attempts to access them. The browser sends only the id. (ex. "20230123-22cc4e5c961") The results are provided back to the browser, where the browser merges the packaged details to provide a visual (and meaningful) result. Results are available for the same amount of time as participation was open for (ex. if open for 5 minutes, results are available for 5 extra minutes). The results, for the users' benefit, should be saved/printed/etc. within the timeframe if a longer retention is desired.
- After an event
- Once the final timeframe has concluded (2x the original when created), the server side details are purged. We have no control over the Url packaged details, where/how they were shared, or how long they will be retained in those systems. Events saved in localStorage are purged after the final timeframe has concluded, while the user is on the home screen. (FYI: if the user participates/etc., but never returns to the homescreen...the details will remain until the user clears localStorage) The results, for the users' benefit, should be saved/printed/etc. within the timeframe if a longer retention is desired.
Tech Talk
- "Server-Side" Storage
- Event, participation, and results are saved in Redis, with a TTL which is 2x the timeframe provided by the user. At most, that means any data "should" be auto-trashed within 7 days. If bug causes a TTL not to exists, we are working on a process to auto-delete any non-TTL'd user keys. Our hosting provider does take regular backups of Redis on a rolling expiration. However, backups are seen as a semi-2nd tier disaster recovery. In the event of a meltdown or whatever, where the data integrity seems in question ...we'll probably just flush the db because it's better for users to start over than have a further unpredictable state. We keep some summary stats (ex. counts) of how many events or participants overall, which are reset as needed.
- "Proxy" Storage
- We use Cloudflare and DigitalOcean. They will keep traffic stats and such which isn't really different from the rest of their customers. Refer to their policies for details.
- "Client" Storage
- We use the browsers localStorage. While a user is on the site, specifically the home page, we try to auto-clean up expired events shortly after there 2x expiration. The user at any time can just purge/delete their localStorage. However, it will cause them to lose the functional purpose of the service (unless they've saved links elsewhere).
- "Transient" Storage
- The service packages the true details as base64 json which is used for sending links to others. This means any system the user uses to transmit the url takes on the storage/privacy/etc. from there. It could mean the details about the subject are kept up to indefinitely, even if the final results (which are temporary) aren't.
- Can this service see the details?
- Hypothetically, if we wrote javascript to merge the results and save them somewhere, yes. Is that even remotely our concern or desire, no. If we wanted that info, we would have saved it all on the server and changed how the overall service works. We could publicly share all the counts/details we store for any event and "it wouldn't tell anybody anything of relevance"*. In fact, we count on the subject server-side data being more public-like. It allows us to support web-based caching patterns which allow the service to operate efficiently. (something much less doable if server data is completely private)