Skip to content
This repository has been archived by the owner on Mar 27, 2024. It is now read-only.

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Security and Privacy design #5

Closed
SQLClause opened this issue Aug 21, 2020 · 5 comments
Closed

Security and Privacy design #5

SQLClause opened this issue Aug 21, 2020 · 5 comments

Comments

@SQLClause
Copy link
Member

We will be handling a lot of PII data.
How to make sure we keep the data safe?
How do we make sure that both attendees stay in control of their data?
And give them a way to share as much or little as they want with the sponsors?

What do we do with indirect PII data?

@Stuart-Moore
Copy link

Do we want to hold it at all? A lot could be pushed out to a 3rd party to handle (ie; meetup), this could even be left to the organiser to pick which would save having to find a solution that works in all jurisdictions.

Also using some form of federated auth (live.com, github, facebook, etc) removes that from scope as well

@way0utwest
Copy link
Contributor

I would propose that each data element be discussed as an issue to be sure that we appropriately decide to hold or not hold it.

At the very least, we will need some PII to contact individuals and relate their digital registration to a particular individual.

I would be against allowing organizers to pick and choose, as the issues are complex and the respect for privacy varies dramatically.

@MichaelAdrianJohnson
Copy link
Contributor

Agree with Steve, We need a secure by design approach, it would take only a single breach to violate trust.

@MsSQLGirl
Copy link

Pivoting to the user point of view (attendees and speakers), I'd like to propose the following capabilities please.

As an attendee and/or speaker, I can:

  1. Subscribe and unsubscribe to any upcoming / current events. e.g. Data Saturday Sydney <any year>, Data Saturday New York <any year>.
    For attendees: this subscription generally relates to (but not limited to) registration, sponsor announcements, event announcements (e.g. new Data Saturday event announcements).
    For speakers: the subscription generally relates to CfS.
  2. Subscribe and unsubscribe to any upcoming / current events from the local region. e.g Data Saturday Sydney 2021, Data Saturday Sydney 2022.
    For attendees: This subscription generally relates to (but not limited to) registration, sponsor announcements, event announcements.
    For speakers: the subscription generally relates to CfS.
  3. Update my personal details (and may be delete?), including anonymization, and update my preferences easily.
    This may include linking and unlinking to social media, sessionize and others, where applicable.
    An example of anonymizing my details - if attendee / speaker wishes to be deleted from the system, while it's still important for the organizer to get information about attendee numbers, this count should be possible :)

For items 1 and 2, the granularity would require a good balance of what makes sense for users (too many options to subscribe and unsubscribe would not be great from usability) and for organizers.

Thoughts?

@github-actions
Copy link

Accessibility Links:
Audio Link:https://gofile.io/d/941MSw
Image Link:https://gofile.io/d/C4NOpB

@dataplat dataplat locked and limited conversation to collaborators Mar 19, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants