2018/Düsseldorf/gdpr

From IndieWeb
Jump to: navigation, search

GDPR Basics was a session at IndieWebCamp Düsseldorf 2018.

Notes archived from: https://etherpad.indieweb.org/gdpr


IndieWebCamp Düsseldorf 2018

Session: GDPR Basics

When: 2018-05-05 13:30

Participants

  • ... add names

Notes

NOTE: none of this is legal advice

  • GDPR is all about personal data
    • this is any data that can be connected with a person, like e-mail, photo's, even IP-adresses
  • there are three roles:
    • The data controller. This is the person owning the website.
    • The user.
    • The data processor. This can be the hosting provider.
  • there can be a lot of parties involved with one page-load, such as the hosting provider, Google Analytics, TypeKit, Youtube.
    • As Data Controller, you need a data processor agreement with all these parties.

The question is asked: when does this apply? If you have a website in Chili, and an EU-user visits your site?

  • It applies as soon as you process data from a user from the EU.

Weird example: https://gdpr-shield.io, a service to block all traffic from the EU

  • It's probably not technically possible to block all EU-users, but the effort made will help in court.

Strictly speaking, personal sites are not affected, but once you state you're a freelancer, or if there's any way to link you as a company / commercial thing, you need to comply to GDPR. This is probably the majority of the current IndieWeb.

Joschi, Sebastian and Balthazar are collecting an overview of all Data Processing Agreements of known services: https://tollwerk.github.io/data-processing-agreements/

For Germany, using Google Analytics and/or Piwik will probably be subject to explicit agreement of the user. (This is a Germany-only thing, not EU.)

  • The law says: processing of personal data is prohibited.
  • There are, however, six different argumentations to get exceptions on this rule
    1. Public interest (e.g. if you're a terrorist, there is a public interest)
    2. Vital/critical interest (e.g. medical staff, have vital interests to have your blood type)
    3. Laws (e.g. there is a legal requirement to store your invoices. After the law of ten years expires, GRPD requires you to delete it immeadiately)
    4. Contracts (e.g. selling things via a webshop is a contract, you can store the address to send the order (but only the address). E-mail newsletters are okay here too)
    5. Legitimate interest (this is a hard one, see below)
    6. Explicit consent (e.g. you have permission of the user, explicitly. The user has the right to revoke this.) (this is the worst argumentation of them all)

'Legitimate interest' is the part where you can fight in court. It's where you say: "I think I have an interest in this data, and I think you don't have an objection." You still need to inform your user. This is for things that can make your service a nicer service, but it will be for non-mandatory data. Generally, you will want a reason higher on the above list.

There is a principle: collect as little data as you need.

You should have a data processing agreement lying around, just in case someone asks for it. (And they can ask.)

(Sidenotes for freelancers and agencies: as a freelancer, you should state that you are not responsible for the legal part of the website/service, but also state that the client is responsible for it.)

  • Two things GDPR explicity mentions:
    • Privacy by design.
    • Privacy by default.
  • if it's not necessarily for your service to store the data, don't store it (or delete it as soon as possible)
  • It's us developers who are responsible for thinking about and acting upon these principes. The clients will not know enough.


You should start documenting all the processes where you using / creating personal data. It's important to be aware, but you're actually have to document what you do. The absurt example is: when you have a random pile of business cards, there is nothing about it. But as soon as you order it alphabetically, it's a data system. Then you need contracts with any person (e.g. your cleaner) who might get in contact with that data system.