2021/Pop-ups/Very Sensitive Data on Your Personal Website
From IndieWeb
Jump to navigation Jump to search

Very Sensitive Data on Your Personal Website 2021 was 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

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

How Can Such Data Be Protected?

Preserving Others' Privacy on Your Site

  • Reply contexts
  • 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?

Notes

Archived from https://etherpad.indieweb.org/sensitivedata-popup

Participants

Topic Voting

To vote:

  1. (Optional) Read this event's wiki page for more context on each topic. 2021/Pop-ups/Very_Sensitive_Data_on_Your_Personal_Website
  2. Add a +1 below each topic that especially interests you.
  3. If a topic you want isn't here, add it! Then add your +1.

Making Use of Visibility and Audience Properties

+7

  • limited-audience posts
    • prior art: circles in Google+, groups on FB
    • Chris Aldrich - lots of manual work categorizing ppl into circles (or groups on FB
    • aliases e.g. fluffy friends vs. followers in Publ
      • note that the Publ ACLs are just whatever friendly name you want and there can be arbitrarily many nested arbitrarily-deep.
      • See entry auth list and ACL config file for more information on how that works/looks from the author's perspective
    • Aaron Parecki follows people in different communities using separate channels in Aperture
  • #conclusion Consensus seems to be that there isn't a user experience for this that works well right now in any platform.
  • #conclusion solve UI/UX for interests/hobbies/groups-related data storage, editing, access control and user viewability of same
  • this topic can be approached from reader view (what stuff do I want to see) and publishe view (what do I want to protect)

Preserving Others' Privacy on Your Site

+7

  • don't leak reply URLs
  • UI showing "this is a private post!"
    • fluffy: if other people in audience of protected post leave (private) comments on it, that shows (logged-in) reader who else is in audience
    • fluffy: use of short-URL w/ no content-based slug when "teasing" a private post (exposing existence but not content)
  • Chris Aldrich: one bonus of "teasing"

Journals and Drafts

+7

  • working on a tech book, want to share some chapters with friends while hiding others (feels like a rbac issue)
    • RBAC = Role-based access control
  • I have the exact same problem for a non-tech book lol

Files and Media

+6

Quantified Self

+5

Medical Information

+4

  • to inform friends of current health
  • to share specific info (e.g. recent MRIs) with a medial professional
  • there are risks because insurance companies and other organizations may use this to your detriment Of course, the same thing comes up with any data about you. Not exercising enough....looking for a new refinance...etc
  • "Sensitive Topics" like aspects of your identity that you might want to keep private, e.g. sexual orientation

Financial Records and Business Plans

+3

  • tax records (Martijn, Johannes) for self, sharing with family, etc
  • expenses/purchases
  • Martijn van der Ven shares for fun as a motivation.
    • In Sweden, anyone can request tax returns of others, so why not cut out the middle person?
    • One could also post a modified (possibly untrue) version on their site
    • David Shanske wishes they had that in the US...it would cut out a lot of political fighting.
  • post business plans on site to get early feedback from some friends, before you have a "company"

URL Designs

+2

How/whether to handle Webmention validation

+2

  • what is this specifically?

Discussion

Google+ Circles explanation: https://www.slideshare.net/padday/the-real-life-social-network-v2 (this is well worth reviewing for describing the problem in user terms)

Martijn van der Ven mentioned using audiences tied to languages various people may speak/understand

Separating concerns (strawman)

  • Identifying the visitor to the website (authentication)
  • How to map the visitor identity to a set of privileges (authorization via access control lists)
  • Managing/editing the access control lists including group membership
  • Returning the correct content based on the visitor's privileges
  • Creating the content and identifying who gets to see it
  • Indicating to the audience that the content is limited as a means of requesting it not be spread/shared
    • Are individual audience members aware of others in the audience for context?

{fluffy} mentioned that Publ_CMS can tell who has logged in to read a post, which is a way of discovering publics for the posts and constructing an audience implicitly. Also a bearer token can be generated so that users can retrieve authenticated feeds; see e.g. user profile

  • Note that login tracking only happens on posts which are set login-required

private always relies on the audience members not breaching the privacy. eg Cummings posting whatsapp screen photos of the Prime Minister dissing the Health Minister https://dominiccummings.substack.com/p/the-pm-on-hancock-totally-fucking

German law on photography is very different from the US https://allaboutberlin.com/guides/photography-laws-germany

on the other hand https://www.vox.com/recode/22539126/google-street-view-maps-dead-relatives tweet that spawned it https://twitter.com/STurner4077/status/1405152351112077317?s=20

Thought: posting sensitive data on a lag, making it public a certain amount of time after storing it, when it has become less of a possible attack vector. Or how about making everything public upon death, when it is no longer sensitive for me as the originator.

IndieWebCamp Sessions



IndieWebCamps
2023 Planning More Camps & Popups • Build a Website in an Hour (P) • Nuremberg
2022 Analog Meets Online (P) • Personal Libraries (P) • Create Day March (P) • Düsseldorf • Create Day July (P) • Berlin • Create Day September (P) • How to Make the IndieWeb More Approachable (P) • Create Day December (P)
2021 Respectful Responses (P) • Webmentions Beyond Webmention.io (P) • Very Sensitive Data (P) • Create Day July (P) • Microsub (P) • IndieAuth (P) • Gardens and Streams II (P) • Create Day October (P) • IndieAuth 2 (P) • Düsseldorf • Create Day December (P)
2020 Online • Austin • London (O) • Garden & Stream (P) • West (O) • Micropub (P) • IndieAuth (P) • Get Started with WP (P) • microformats2 (P) • Friendly WP Themes (P) • East (O) • Create Day (O)
2019 Austin • Online • New Haven • Berlin • Düsseldorf • Utrecht • 9th IndieWeb Summit (Portland) • Amsterdam • Oxford • NYC • Brighton • Berlin2 • SF
2018 Baltimore • Düsseldorf • 8th IndieWeb Summit (Portland) • SF • Oxford • NYC • Nürnberg • Berlin
2017 Bellingham • Düsseldorf • Nürnberg • 7th IndieWeb Summit (Portland) • Istanbul • NYC • Berlin • Austin
2016 NYC • MIT • Nürnberg • Düsseldorf • 6th IndieWeb Summit (Portland) • NYC2 • Brighton • LA (Santa Monica) • Berlin • MIT2
2015 Cambridge MA • Germany (Düsseldorf) • Portland&Brighton (5th Summit) • Edinburgh • MIT • SF
2014 SF • NYC • Portland/NYC/Berlin (4th Summit) • UK (Brighton) • Cambridge MA • Online
2013 Portland (3rd Summit) • UK (Brighton) • Hollywood
2012 Portland (2nd Summit) • UK (Brighton)
2011 Portland (Summit)

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=2021/Pop-ups/Very_Sensitive_Data_on_Your_Personal_Website&oldid=88582"