Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better document our policies #2336

Open
baltpeter opened this issue Aug 31, 2023 · 10 comments
Open

Better document our policies #2336

baltpeter opened this issue Aug 31, 2023 · 10 comments

Comments

@baltpeter
Copy link
Member

We have a few unwritten policies that we should really document properly. I'll collect them here as I come across them.

@baltpeter
Copy link
Member Author

baltpeter commented Aug 31, 2023

@baltpeter
Copy link
Member Author

@baltpeter
Copy link
Member Author

  • Sources should be the minimal set that covers all information in the record, preferring privacy policies over other types of sources.

@baltpeter
Copy link
Member Author

baltpeter commented Oct 6, 2023

  • Clearer guidelines on what should be listed under runs (products/services and other companies with joint controllership).
    • Product names that are already part of the company name should not be included in runs.
  • runs should typically only include the official name with no further explanations.
  • No generic descriptions ("Mobile apps") in runs.
  • We need a source for each runs entry that contains the exact name as a string.

@mal-tee
Copy link
Member

mal-tee commented Oct 6, 2023

We sometimes put other urls in the runs entries like this: ACME GmbH (acme.com)

@baltpeter
Copy link
Member Author

  • "Statement of purpose": We collect the contact details that should be used for privacy-related requests to the company.

@baltpeter
Copy link
Member Author

  • Slug should never change.

@baltpeter
Copy link
Member Author

  • Guidelines on when we need separate or combined records for different countries, services, and/or companies (-> identical contact details, joint controllership).

@baltpeter
Copy link
Member Author

  • The goal of the company database is not to collect all available data on a company, or even all data related to data protection practices of the company. Our goal is only to tell users where they should send requests to a company. We thus only collect the preferred/suggested way to contact them for such purposes through each medium.

    If, for example, there multiple email addresses listed in the privacy policy, we only include the most appropriate on in the record. Such considerations can and should be documented in the PR, but should not be included in the record. If we later learn that another email address is better, we update the record.

@baltpeter
Copy link
Member Author

  • The company database is not a database of controllers but of contact details for sending data protection requests to companies, services, etc.

    In many (most, even) cases, requests should be sent to the controller directly and this should thus be reflected in the record. But there are also cases where the controller should only be mentioned under runs but not under name and address.

    Company structures It's not really possible to postulate hard guidelines on this, the more complicated cases are often judgement calls. These should always be made keeping in mind the goal of the company database, deciding on how the information is most useful for users.

    A few examples as a guide:

    • The social network GiveMeLikes is run by GiveMeLikes International Ltd. at Some Road 123, 12345 Some City, Some Country. The privacy policy says that requests should be directed to the controller and lists an email for them.

      This is pretty much the simplest and most common case. Here, the name in the record should be GiveMeLikes International Ltd., the address should be Some Road 123\n12345 Some City\nSome Country and the mentioned email address should be listed under email.

    • The video sharing sites TokTokTokTik and Rhythmtically are run by Heaven AB at Some Road 123, 12345 Some City, Some Country. Users can contact prayer@heaven.com for support. The privacy policy says that data protection requests should be sent to the external data protection officer DPO4You Inc. at DPO Street 456, 67890 DPO City, DPO Country or via email to requests@dpo4you.com.

      This case is also very common. Since both services are run by the same company and their contact details are also identical, we only need one record. The name should be Heaven AB and runs should list both TokTokTokTik and Rhythmtically.

      Since data protection requests should go to the DPO, the address should be c/o DPO4You Inc.\nDPO Street 456\n67890 DPO City\nDPO Country and the email should be requests@dpo4you.com. All other details mentioned above are not in scope for our database and should thus not be included in the record.

    • The online shops BestG00ds and CheapG00ds are run by Frank's Retail LLC at Some Road 123, 12345 Some City, Some Country. Customer service inquires can be sent to support@bestg00ds.com or support@cheapg00ds.com respectively. The privacy policy says that data protection requests should be sent to Frank's Online Empire LLC at Some Road 125, 12345 Some City, Some Country or via email to privacy@bestg00ds.com or privacy@cheapg00ds.com respectively.

      This case is getting more complicated. Since we now have two services that, while run by the same company, require different contact details, we need two separate records. Here, the names should—as an exception—be BestG00ds and CheapG00ds (and not the legal name) such that users can distinguish the two records. The address should be c/o Frank's Online Empire LLC\nSome Road 125\n12345 Some City\nSome Country for both. The emails should be privacy@bestg00ds.com and privacy@cheapg00ds.com, respectively.

      Frank's **Retail** LLC should be listed under runs for both records. Again, all other information listed above is out of scope and should not be included in the record.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants