Old notes to be hidden from file structure #4
Description
layout: default
title: GDPR Notes
This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes.
Implies that we are OK to analyse user data (without emails / without user identities) for statistical and research purposes.
To ascertain whether means are reasonably likely to be used to identify the
natural person, account should be taken of all objective factors, such as the
costs of and the amount of time required for identification, taking into
consideration the available technology at the time of the processing and
technological developments. The principles of data protection should
therefore not apply to anonymous information, namely information which does
not relate to an identified or identifiable natural person or to personal
data rendered anonymous in such a manner that the data subject is not or no
longer identifiable
- GRT data doesn't include user IDs.
- Stats: User Page
includes user IDs, but these are extremely hard to attribute to an
identifiable person. You must identify probably users of a tool (we have
over 1.2k users) based on their research or some other property. And then there
is nothing you can do with that ID since it isn't published anywhere else.
The application of pseudonymisation to personal data can reduce the risks to
the data subjects concerned and help controllers and processors to meet their
data-protection obligations.
using user IDs is probably sufficient here. See above discussion, but it would
require a copy of the galaxy database which is not available except via access
from cn029, or via the database server itself.
Natural persons should be made aware of risks, rules, safeguards and rights
in relation to the processing of personal data and how to exercise their
rights in relation to such processing. In particular, the specific purposes
for which personal data are processed should be explicit and legitimate and
determined at the time of the collection of the personal data.
We could improve the registration form to link to our terms.
Personal data should be processed only if the purpose of the processing could
not reasonably be fulfilled by other means. In order to ensure that the
personal data are not kept longer than necessary, time limits should be
established by the controller for erasure or for a periodic review.
Only PD we keep is email, making this easy. email is absolutely necessary
(post-workflow email notification, bug report communications, etc.)
Personal data should be processed in a manner that ensures appropriate
security and confidentiality of the personal data, including for preventing
unauthorised access to or use of personal data and the equipment used for the
processing
As an admin I do not need to know a user's email address basically ever. This
could be hidden from me in a lot of places.
the only times that come to mind are:
- when I'm discussing a bug with a user and need to impersonate them (but their
email is in the bug report email and I could use that for launching
impersonation.) - I'm testing something in a user who has previously permitted me to
impersonate them.
So, basically, we could reduce the impersonate select box to an empty textbox
where we have to supply an email address. We could additionally allow users to
consent to impersonation, some users may not wish to. We could do this with
user preferences (and maybe giving us a nice way to link to it, so we could
write in an email "Hey, please allow me to impersonate you [link] and I'll
check out what's going on.")
Where processing is based on the data subject's consent, the controller
should be able to demonstrate that the data subject has given consent to the
processing operation. In particular in the context of a written declaration
on another matter, safeguards should ensure that the data subject is aware of
the fact that and the extent to which consent is given.
- Need to check what all is based on consent.
- is ToS plain enough language?
- do we declare what we collect and why?
Controllers that are part of a group of undertakings or institutions
affiliated to a central body may have a legitimate interest in transmitting
personal data within the group of undertakings for internal administrative
purposes, including the processing of clients' or employees' personal data.
So we're allowed to discuss people over email.
The processing of personal data to the extent strictly necessary and
proportionate for the purposes of ensuring network and information security
So IP address logs for 24 hours are OK under this. And we could really just
discard if we move to CA auth'd stuff.
The processing of personal data for purposes other than those for which the
personal data were initially collected should be allowed only where the
processing is compatible with the purposes for which the personal data were
initially collected. In such a case, no legal basis separate from that which
allowed the collection of the personal data is required. ... Further
processing for archiving purposes in the public interest, scientific or
historical research purposes or statistical purposes should be considered to
be compatible lawful processing operations.
This could probably be theoretically used to justify retaining email addresses
indefinitely? But I'm not sure and it doesn't really sit right with me. We
don't collect any other personal information (name, email) that this could be
used with.
OOOH This might be able to be used to justify giving access to an account when
the user departs the lab or so.
If the personal data processed by a controller do not permit the controller
to identify a natural person, the data controller should not be obliged to
acquire additional information in order to identify the data subject for the
sole purpose of complying with any provision of this Regulation. However, the
controller should not refuse to take additional information provided by the
data subject in order to support the exercise of his or her rights.
Identification should include the digital identification of a data subject,
for example through authentication mechanism such as the same credentials,
used by the data subject to log-in to the on-line service offered by the data
controller.
No idea what to do with this. Wish they gave concrete examples. We aren't
obligated to discover the identity of a natural person matching "jane-doe
jane@example.com" in our galaxy user database, but if they ... supply a
physical address? we cannot refuse to take this. I think. Not sure how the last
sentence even relates.
The controller should be obliged to respond to requests from the data subject
without undue delay and at the latest within one month and to give reasons
where the controller does not intend to comply with any such requests.
1 month to respond to emails.
Furthermore, the data subject should be informed of the existence of
profiling and the consequences of such profiling. Where the personal data
are collected from the data subject, the data subject should also be
informed whether he or she is obliged to provide the personal data and of
the consequences, where he or she does not provide such data. That
information may be provided in combination with standardised icons in order
to give in an easily visible, intelligible and clearly legible manner, a
meaningful overview of the intended processing.
So our login page should say "You are not legally obligated to supply your
name, you are free to choose a pseudonym to better protect your privacy."? Maybe?
Where personal data can be legitimately disclosed to another recipient, the
data subject should be informed when the personal data are first disclosed to
the recipient. Where the controller intends to process the personal data for
a purpose other than that for which they were collected, the controller
should provide the data subject prior to that further processing with
information on that other purpose and other necessary information. Where the
origin of the personal data cannot be provided to the data subject because
various sources have been used, general information should be provided.
I think this means we need to be very clear that when we enable OpenID Connect
authentication, that it is explicit that "OIDC users can update their
information there. We will obtain a username from that service to use with your
account"
The controller should use all reasonable measures to verify the identity of a
data subject who requests access, in particular in the context of online
services and online identifiers. A controller should not retain personal data
for the sole purpose of being able to react to potential requests.
good to know.
To strengthen the right to be forgotten in the online environment, the right
to erasure should also be extended in such a way that a controller who has
made the personal data public should be obliged to inform the controllers
which are processing such personal data to erase any links to, or copies or
replications of those personal data.
Think we're safe from this too. No PD exposed to third parties.
Where, in a certain set of personal data, more than one data subject is
concerned, the right to receive the personal data should be without prejudice
to the rights and freedoms of other data subjects in accordance with this
Regulation. Furthermore, that right should not prejudice the right of the
data subject to obtain the erasure of personal data and the limitations of
that right as set out in this Regulation and should, in particular, not imply
the erasure of personal data concerning the data subject which have been
provided by him or her for the performance of a contract to the extent that
and for as long as the personal data are necessary for the performance of
that contract. Where technically feasible, the data subject should have the
right to have the personal data transmitted directly from one controller to
another.
I think this could be read as "when a user requests deletion and has shared
datasets with other users, we should remove the related datasets."
Or, maybe this isn't at that level since datasets aren't PD, but something
smaller like cleaning up roles, we're erasing members of a set without
affecting the rights of others.
The data subject should have the right not to be subject to a decision, which
may include a measure, evaluating personal aspects relating to him or her
which is based solely on automated processing and which produces legal
effects concerning him or her or similarly significantly affects him or her,
such as automatic refusal of an online credit application or e-recruiting
practices without any human intervention.
My reading of this is that it does not affect our desire to automatically
decide where to send user jobs based on aspects about them. Because: there are
no legal effects, it does not significantly affect them, and the examples are
much stronger than just where to process data.
Such processing includes ‘profiling’ that consists of any form of automated
processing of personal data evaluating the personal aspects relating to a
natural person, in particular to analyse or predict aspects concerning the
data subject's performance at work, economic situation, health, personal
preferences or interests, reliability or behaviour, location or movements,
where it produces legal effects concerning him or her or similarly
significantly affects him or her
This seems like we shouldn't ever try to categories users as "genomics users"
or try to predict what tools they might be interested in. If we do, we'll need
to take a much closer look at this.
where personal data are processed which reveal racial or ethnic origin,
political opinions, religion or philosophical beliefs,
If we allowed users to choose what news they wanted to see on their home page,
we probably couldn't really look at this data and see "oh, jane doe enabled
[left wing news source]" since that would revear her political opinions to us
and we don't need those for our processing. Or at least if we ever did look,
we'd have to be very sure to pseudonymise/anonymize first and only look at bulk
results.
aware that a personal data breach has occurred, the controller should notify
the personal data breach to the supervisory authority without undue delay
and, where feasible, not later than 72 hours after having become aware of it,
unless the controller is able to demonstrate, in accordance with the
accountability principle, that the personal data breach is unlikely to result
in a risk to the rights and freedoms of natural persons
good to know.
Provisions should be made for the possibility for transfers in certain
circumstances where the data subject has given his or her explicit consent,
where the transfer is occasional and necessary in relation to a contract or a
legal claim, regardless of whether in a judicial procedure or whether in an
administrative or any out-of-court procedure, including procedures before
regulatory bodies. Provision should also be made for the possibility for
transfers where important grounds of public interest laid down by Union or
Member State law so require or where the transfer is made from a register
established by law and intended for consultation by the public or persons
having a legitimate interest. In the latter case, such a transfer should not
involve the entirety of the personal data or entire categories of the data
contained in the register and, when the register is intended for consultation
by persons having a legitimate interest, the transfer should be made only at
the request of those persons or, if they are to be the recipients, taking
into full account the interests and fundamental rights of the data subject.
Or maybe this is a better one to justify transferring user data to their boss?
We need to find a solid justification to that (in addition to written approval
by their boss.) (113) is sounding good as well except for "supervisory
authority needs to be informed." It would be optimal if we could share the
account data BUT mask all access to personal data.
Since we're resetting the password/changing the email on the account to make it
accessible, maybe this isn't something we need to worry about since no PD is
transferred. they are proving to us they know the identity of the user (via
their email address)
Art 13(1)a: the identity and the contact details of the controller and,
must be listed prominently on gdpr page
Art 13(1)c: the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;
need to be clearer about this probably.
13(2)a: the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;
are we doing this well enough in the data stuff?
Art 14 Information to be provided where personal data have not been obtained from the data subject
- Where personal data have not been obtained from the data subject, the
controller shall provide the data subject with the following information:
ugh OIDC.
(a) the identity and the contact details of the controller and, where applicable, of the controller's representative;
(b) the contact details of the data protection officer, where applicable;
(c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;
(d) the categories of personal data concerned;
(e) the recipients or categories of recipients of the personal data, if any;
(f) where applicable, that the controller intends to transfer personal data to a recipient in a third country or international
organisation and the existence or absence of an adequacy decision by the Commission, or in the case of
transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or
suitable safeguards and the means to obtain a copy of them or where they have been made available
2 In addition to the information referred to in paragraph 1, the controller shall provide the data subject with the
following information necessary to ensure fair and transparent processing in respect of the data subject:(a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;
(b) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;
(c) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject and to object to processing as well as the right to data portability;
(d) where processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;
(e) the right to lodge a complaint with a supervisory authority;
(f) from which source the personal data originate, and if applicable, whether it came from publicly accessible sources;
(g) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the log
Need to check this.
3 The controller shall provide the information referred to in paragraphs 1 and 2:
(a) within a reasonable period after obtaining the personal data, but at the latest within one month, having regard to the specific circumstances in which the personal data are processed;
(b) if the personal data are to be used for communication with the data subject, at the latest at the time of the first communication to that data subject; or
(c) if a disclosure to another recipient is envisaged, at the latest when the personal data are first disclosed.
Need to check this.
Article 37(1) The controller and the processor shall designate a data protection officer in any case where:
(a) the processing is carried out by a public authority or body, except for courts acting in their judicial capacity;
(b) the core activities of the controller or the processor consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale;or
(c) the core activities of the controller or the processor consist of processing on a large scale of special categories of data pursuant to Article 9 and personal data relating to criminal convictions and offences referred to in Article 10
I interpret this to mean that we do not need a DPO:
- We are not a public authority.
- core activities do not require systematic monitoring of data subjects on a large scale
- we do not process SPD.