Closed timja closed 3 years ago
Used only by this method which appears never to have been called except by diagnostics. I think we could just deprecate it and make it unconditionally return null (also this clone) and be done with it.
In the current state Jenkins Web UI won't work without cookies, its session manager depends on that.
Technically it would be possible to ask for permissions if the approval cookie is not set. Whether it is feasible or not -TBD
First point, related to the Cookie Consent, the law is clear concerning which cookie are exempt from any consent. One type of exemption is for the "user‑interface customisation" (source). I consider the resolution to be used only for customization of the interface and nothing else. As the product is open-source, you can check yourself that the resolution is never used for any other objective. From my PoV it comply completely to be put in that category and so, do not require any consent.
Second point, related to the GDPR, the definition of what is personal data :
"‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;" (source)
As you may know, the resolution distribution among the population is somewhat standard and cannot be used to strictly identify someone. So from my PoV, there is no reason the screen resolution is a personal data or an information usable to identify the person.
If you find something else that could be impacted by the GPDR or are not convinced by my arguments, just tell me.
Since the change from teilo has been included in Jenkins 2.317 and the issue is noted in the 2.317 changelog, can this issue be closed?
so my change made the cookie "secure" when using https for Jenkins - which meant it could be sent to different server software (if you had Jenkins on https://site.example.com and something else on http://site.example.com) which would be a bit strange - but that would be the only part that affects information leak (and as Wadeck points out screen resolution is not PII - but something that should only be sent to Jenkins).
So yes I would close this as either invalid or fixed. I do not believe we need "consent" for this based on my understanding of the DPA / GDPR etc.
A new European regulation on the collection of identifying information, General Data Protection Regulation ("GDPR"), combines with existing legislation regarding consent being required before saving of cookies on any given domain.
As stupid as it may seem, screen resolution is regarded as identifying information, and it's stored immediately upon loading a Jenkins server, courtesy https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/model/View/index.jelly#L48
This needs to be optional, pending implementation of a "Cookie Consent" feature, for any Jenkins server accessible in Europe to be legally compliant.
Originally reported by directhex, imported from: screenResolution cookie not marked as secure