2021/Pop-ups/Very Sensitive Data on Your Personal Website

🗣☺️ Very Sensitive Data on Your Personal Website 2021 is an IndieWebCamp Pop-ups 2021 session.

Summary

Let's come together to discuss using our websites to host, post, share, and store sensitive data, including medical records, habit logs, personal media files, and private writing.

What are the use cases for posting sensitive data on your own website? What plumbing is needed to host and share sensitive data within (and outside) the IndieWeb? What even is "sensitive" data, anyway?

Details

• facilitators: Maxwell Joslyn
• Date: 2021-06-26
• Time: 11:00 Pacific
• event: https://events.indieweb.org/2021/06/indiewebcamp-pop-up-very-sensitive-data-on-your-personal-website-DNjCEi05jHfH
• Video: ▶️02:08:08s
• hashtag: #verysensitivedata
• https://etherpad.indieweb.org/sensitivedata-popup

Possible Topics

What's Sensitive?

Medical Information

• Directly provide past appointment outcomes, diagnosis records, and other medical case history to medical professionals
• Reduce need for direct authorized contact between providers' offices, or between GP and specialist
• Your medical history is part of your identity; it's reasonable to want to control/maintain canonical archive of materials
• Authorize medical providers to retrieve data from your website
  • Just imagine: doctor's office gives you an email address or other identifier...
  • ...You login to your website and authorize that identifier to view medical data relevant to your appointment. e.g. authorization an x-ray image at example.com/2021/05/28/xray.
  • This hypothetical use case provides additional motivation for well-known types of UX, such as "invitation" interface for adding identities to an allow list.
  • There should be a difference between authorizing individual medical providers to view your data, and authorizing the hospital/clinic/group to which the provider belongs (h/t Johannes Ernst)

Quantified Self

• Good and bad habits
  • Can be embarassing to admit that you're tracking data to ween yourself off, say, alcohol
  • Crucially, it can also be embarrassing to publicly track a good habit, especially something like cookin which "everyone already knows" (not true)
• Measure so-called "gross" events for health purposes, without giving your data away to 3rd parties
  • "literal shit posting" (h/t Kartik Prabhu)
  • blood sugar measurements

Journals and Drafts

• Ideas written during heightened emotional states, or which the author later came to regret
• Must be kept private, lest the author be reflected by material which they did not intend to represent themselves

Files and Media

• Backups of emails, text messages, and personal photos
• Owning your participation in a public mailing list, without publicly exposing the actual emails
• Access control on posts is part of the Micropub ecosystem (see "Post Properties: Visibility and Audience")...
  • ...but file uploads and media endpoint behavior deliberately underspecified in Micropub
  • Should sensitive files only be accessible when embedded in posts, as links/images?

Financial Records

• Martijn van der Ven is interested in posting his tax returns
• Aaron Parecki currently tracks his budget privately in YNAB

How Can Such Data Be Protected?

Preserving Others' Privacy on Your Site

• Reply contexts
  • Suppose Angelo Gladding makes a private post with Maxwell Joslyn in the audience. Maxwell Joslyn sees it and writes a reply.
  • It's probably not OK for Maxwell Joslyn to write a public reply to Angelo Gladding's private post!
  • Even the URL of a private post may be sensitive if it contains a content-based slug!
• Private RSVPs for public events
  • If I'm sending a private RSVP to a public event, I hope hope both parties correctly implemented the code which keeps the RSVP private!
  • considerations for displaying number of RSVPs and information about attendees

URL Design

• Even the existence of a private URL may be sensitive if it contains a content-based slug!
• Sortable/guessable URLs can leak existence of private posts
  • Suppose my public permalinks for a given day's posts end in /1, /2, /3, /7, /8, /9, /10.
  • That is potentially evidence that I made private posts at /4, /5, and /6!

Making Use of visibility and audience Properties

• If Tantek Çelik is on Maxwell Joslyn's site, is logged in, and is viewing a private post, Tantek Çelik should be able to see the post is private, and that he is on its allow list
  • Should Tantek Çelik be able to see the audience list itself, so he knows with whom he may share?
• How much interop is there currently for the audience property? How much is progress on visibility/audience interop tied into the progress of private Webmention?
• There's no widespread agreement about the structure of the audience property. Different implementations might allow for...
  • List of names which is implicitly an allow or block list
  • Explicit allow and block lists within the audience property
  • Changes in allow and block semantics based on visibility (e.g. given an audience list, it's an allow list for a private post, and a block list for a public one)
  • Representation of per-person permissions (e.g. Tantek Çelik can only read a post, while Angelo Gladding can read it or edit it with Micropub updates)
• Ton Zijlstra brings up the intriguing idea of changing the content of a post depending on who is viewing it:
  • "The _same_ post has less details for increasing social distance: a sentence like “Had a conversation with a colleague / initial / full name today at a restaurant / name of venue” depending on reader."
  • e.g. "Had a conversation with Bob Exampleson at Denny's" vs. "Had a conversation with a colleague at a restaurant"
  • fluffy's original friends-only hacks (added onto her Movable Type templates back in the day) supported that although it was incredibly unwieldy to do. Publ also has a mechanism which could theoretically be used for that but she hasn't found it worthwhile to actually make use of.

What we did back in LID (Light-Weight Digital Identity) days

The idea was to treat the identity of the visitor (i.e. their URL) similar to the way HTTP (should) deal with content negotiation: return something different based on who is doing the asking. Example at the time: VCard. An anonymous client might just get a VCard with a name entry. A friend might get phone numbers and physical addresses. A business acquaintance just work info. This depends on managing essentially an ACL on the server side.

Governance

• Who gets to decide what information is public, private, or is available to a limited audience?
• Who gets to decide what that limited audience is?
• Who gets to republish?

See Also

• 2021/Pop-ups
• Code of Conduct