4 ms·

On this point GDPR is pretty simple. In general security do not require consent, nor does cookies that are used for functional aspects of the sites. A simple g

by belorn 6y ago

On this point GDPR is pretty simple. In general security do not require consent, nor does cookies that are used for functional aspects of the sites. A simple guideline is to imagine if someone breaks into your server and steal data. If that data can come to harm real people somewhere then you likely have something which you needed to have gained consent in order to handle. On top of that there is an additional exception for data only used for security purposes.

labawi 6y ago
Second paragraph is false, first one is partially true. There are many legitimate reasons for storing and processing data, and you should not ask for consent needlessly - among other reasons, because consent can be withdrawn, at any time, and you are obliged comply stop processing and remove data - unless you have other legitimate reasons, in which case the whole exercise seems pointless. Whether the data can be used to harm real people has significant correlation with whether it is covered by GDPR, but does not relate to consent. It can also be of relevance on what security precautions are required and when weighing right to privacy vs. needs to process specific data. As a typical example, you do not need (and shouldn't ask for) consent for data and purposes that are reasonably necessary for the services customers ask for. You are not allowed to share / use for unrelated purposes other than allowed by other stipulations. Also, information on data collection / processing should be reasonably, easily accessible.
dotancohen 6y ago
This is completely wrong. I don't want to pick your comment apart, but I suggest actually reading the GDPR. It is available in every European language.
- belorn 6y ago
  I suggest you read the Recitals 47 to 49 of the GDPR, especially 49. It is liked here https://gdpr-info.eu/recitals/no-49/ https://gdpr-info.eu/recitals/no-49/ but it is short enough to fit a HN comment. It is called Network and Information Security as Overriding Legitimate Interest, a name which has the word overriding in it. Pretty clear language. The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. GDPR is compatible with information security and do not interfere with it. The section is technology neutral in that you can use cookies, logs, firewalls, blacklists, oracles or any other methods that include data processing and as long the purpose is strictly necessary and proportionate to ensure network and information security than that is acceptable as according to Recital 49.
  - dotancohen 6y ago
    Thank you. I was referring to this: > A simple guideline is to imagine if someone breaks into > your server and steal data. If that data can come to harm > real people somewhere then you likely have something which > you needed to have gained consent in order to handle. The website admins and developers are not those who decide what data is covered, based on any idea we might have as to what may be likely to cause harm. Rather, the GDPR defines personal data and the rules for handling it differ between controllers and processors. I should have typed up a more thorough answer. In any case, there are always more and more nuances to be discovered about the GDPR depending on field. I'm not a lawyer and I'm glad to always be corrected and updated.
    - belorn 6y ago
      > what may be likely to cause harm Never said that the information needed to be likely to cause harm, but simply can. The exact phrase that GDPR use is "Any information that relates to an identified or identifiable living individual". An example where any information that related to an identified or identifiable living individual would be harmful would be in a court. Any information about juries, judges, accused or defendant is potentially harmful if abused. All legal systems depend on the presumption of privacy in this regard, and all legal system that I know have processes in places to replace individuals when that harm can be actualized. A similar situation is possible when it comes to information being distributed to a very large audience. Unimportant "harmless" information can be perfectly safe in a small group, but if millions of people see it in a harmful context then such harmless information can turn harmful. Any person operating a forum, a voice chat group, or a place where any two people meet should treat any logs with the threat model of it being leaked and the information harming real people. I should have clarified in the above comment that information that related to an identified or identifiable living individual should always be assumed as potentially harmful, and thus involving a risk to the identified person. This is the problem GDPR is mostly attempting to solve, and thus the situation for which the operator need to act on. Similar, if the information is of such nature that it can't be harmful, it is also very unlikely to be information that relate to an identified or identifiable living individual. When GDPR came it a lot of people asked similar questions as the parent post. What about Apache logs? What about login credentials and sessions. What about CRM and customer registers? The collective answer from that conversation, as I remember (and much of those discussion can be found archived), was that the question depend on the context. If its purely for security then the operator can likely continue on as before per the above quoted section, with some caveats to proportionality. For most everything else, look to the purpose of the GDPR.

by belorn 6y ago

labawi 6y ago

Second paragraph is false, first one is partially true. There are many legitimate reasons for storing and processing data, and you should not ask for consent needlessly - among other reasons, because consent can be withdrawn, at any time, and you are obliged comply stop processing and remove data - unless you have other legitimate reasons, in which case the whole exercise seems pointless. Whether the data can be used to harm real people has significant correlation with whether it is covered by GDPR, but does not relate to consent. It can also be of relevance on what security precautions are required and when weighing right to privacy vs. needs to process specific data. As a typical example, you do not need (and shouldn't ask for) consent for data and purposes that are reasonably necessary for the services customers ask for. You are not allowed to share / use for unrelated purposes other than allowed by other stipulations. Also, information on data collection / processing should be reasonably, easily accessible.

dotancohen 6y ago

This is completely wrong. I don't want to pick your comment apart, but I suggest actually reading the GDPR. It is available in every European language.

belorn 6y ago
I suggest you read the Recitals 47 to 49 of the GDPR, especially 49. It is liked here https://gdpr-info.eu/recitals/no-49/ https://gdpr-info.eu/recitals/no-49/ but it is short enough to fit a HN comment. It is called Network and Information Security as Overriding Legitimate Interest, a name which has the word overriding in it. Pretty clear language. The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. GDPR is compatible with information security and do not interfere with it. The section is technology neutral in that you can use cookies, logs, firewalls, blacklists, oracles or any other methods that include data processing and as long the purpose is strictly necessary and proportionate to ensure network and information security than that is acceptable as according to Recital 49.
- dotancohen 6y ago
  Thank you. I was referring to this: > A simple guideline is to imagine if someone breaks into > your server and steal data. If that data can come to harm > real people somewhere then you likely have something which > you needed to have gained consent in order to handle. The website admins and developers are not those who decide what data is covered, based on any idea we might have as to what may be likely to cause harm. Rather, the GDPR defines personal data and the rules for handling it differ between controllers and processors. I should have typed up a more thorough answer. In any case, there are always more and more nuances to be discovered about the GDPR depending on field. I'm not a lawyer and I'm glad to always be corrected and updated.
  - belorn 6y ago
    > what may be likely to cause harm Never said that the information needed to be likely to cause harm, but simply can. The exact phrase that GDPR use is "Any information that relates to an identified or identifiable living individual". An example where any information that related to an identified or identifiable living individual would be harmful would be in a court. Any information about juries, judges, accused or defendant is potentially harmful if abused. All legal systems depend on the presumption of privacy in this regard, and all legal system that I know have processes in places to replace individuals when that harm can be actualized. A similar situation is possible when it comes to information being distributed to a very large audience. Unimportant "harmless" information can be perfectly safe in a small group, but if millions of people see it in a harmful context then such harmless information can turn harmful. Any person operating a forum, a voice chat group, or a place where any two people meet should treat any logs with the threat model of it being leaked and the information harming real people. I should have clarified in the above comment that information that related to an identified or identifiable living individual should always be assumed as potentially harmful, and thus involving a risk to the identified person. This is the problem GDPR is mostly attempting to solve, and thus the situation for which the operator need to act on. Similar, if the information is of such nature that it can't be harmful, it is also very unlikely to be information that relate to an identified or identifiable living individual. When GDPR came it a lot of people asked similar questions as the parent post. What about Apache logs? What about login credentials and sessions. What about CRM and customer registers? The collective answer from that conversation, as I remember (and much of those discussion can be found archived), was that the question depend on the context. If its purely for security then the operator can likely continue on as before per the above quoted section, with some caveats to proportionality. For most everything else, look to the purpose of the GDPR.