<div dir="ltr"><div class="gmail_extra">See inline.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-13 18:44 GMT+00:00 R. Tyler Croy <span dir="ltr"><<a href="mailto:tyler@monkeypox.org" target="_blank">tyler@monkeypox.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">(replies inline)<br>
<span class=""><br>
On Wed, 08 Jun 2016, Baptiste Mathus wrote:<br>
<br>
> +1. I've played with it some months ago and agree there's no privacy issue<br>
> IMO with the data already previously available.<br>
<br>
<br>
</span>I brought this up in the governance meeting[1] and decided not to push it<br>
towards an action after Daniel Beck expressed concerns abotu some changes<br>
Baptiste has been pushing in a few pull requests.<br>
<br>
Consider these JIRAs:<br>
<br>
 * Extension Point for contributing usage statistics - <<a href="https://issues.jenkins-ci.org/browse/JENKINS-32485" rel="noreferrer" target="_blank">https://issues.jenkins-ci.org/browse/JENKINS-32485</a>><br>
 * Split node monitors from core - <<a href="https://issues.jenkins-ci.org/browse/JENKINS-26466" rel="noreferrer" target="_blank">https://issues.jenkins-ci.org/browse/JENKINS-26466</a>><br></blockquote><div><br></div><div>First, as a reminder, and to get the context, please note that JENKINS-32485 was actually created, because breaking cycles was actually required to be able to make JENKINS-26466 forward.</div><div>In the past, I had had a question about <a href="http://jenkins-ci.361315.n4.nabble.com/Get-data-from-plugin-installations-in-the-real-world-td4641049.html">how plugin developers could have a way to push custom stats</a>, so this was somehow by chance a match.</div><div><br></div><div>Hence the resulting PR: <a href="https://github.com/jenkinsci/jenkins/pull/1985">https://github.com/jenkinsci/jenkins/pull/1985</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
There are two concerns which I would like to raise for you, Baptiste:<br>
<br>
<br>
1; Potential infrastructure impact feasibility of addition "usage stats"<br>
<br>
The way that usage statistics are reported is through an encrypted HTTP GET<br>
request to <a href="http://usage.jenkins-ci.org" rel="noreferrer" target="_blank">usage.jenkins-ci.org</a>. This limits the amount of data that can be<br>
transmitted, but generally allows us more guaranteed delivery since a Jenkins<br>
user's browser is what is used for reporting this information<br>
<br>
That encrypted payload is then decrypted, anonymized and then re-uploaded by an<br>
out-of-band process, after which the `infra-statistics` process takes over.<br>
<br>
A few questions:<br>
<br>
 - How much additional data is going to be crammed into that HTTP GET payload?<br>
   What happens when there's too much?<br></blockquote><div><br></div><div>Potentially, it could be a lot if someone screws, for sure. That's why I put a lot of Javadoc in the PR to make clear this was to be used with care, and strongly encourage developers to ask for reviews when using that feature. And possibly ping specifically the Security Officer (which Daniel seems to actually disagree with) for review.</div><div><br></div><div>But basically, this is already the case (anyone could quite easily use the current pipe, though there's currently no way to finally get it w/o discussing it upstream), though I can only agree this would be made easier to screw up.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
 - Is ther an estimate of what kind of additional transit and disk storage<br>
   requirements this is going to impose on project infrastructure?<br></blockquote><div><br></div><div>No. It's not possible. It's totally dependent on what "stats" each implementation would add. (Though again, I could stress a lot more in the javadoc that the data is required to stay small in any situation, even apart from the privacy aspects).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
 - How are plugin developers expected to "see" their custom usage stats at the<br>
   end of the processing cycle?<br></blockquote><div><br></div><div>At first, as explained, the only first goal was to actually send the exact same data as currently, but decoupled to make JENKINS-26466 feasible. So, not a whole lot of thought had been given to that (but many discussions happened here and there, more specifically in the <a href="https://github.com/jenkinsci/jenkins/pull/1985">PR</a> or on IRC mostly with Daniel).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
2: Potential privacy impact of additional usage stats<br>
<br>
The anonymization code for existing usage stats is successful at anonymizing<br>
because we know where "custom" fields or sensitive information might come from<br>
ahead of time. For example, custom plugins, hostnames, and things like that.<br>
Without knowledge beforehand of what metrics are going to be reported, I don't<br>
understand how we can ensure user privacy.<br>
<br>
 - How would we keep the anonymization code updated with the new metrics<br>
   potentially reported by plugins?<br>
<br>
 - How are we going to ensure that plugin authors don't purposefully or<br>
   accidentally publish personally-identifiable information?<br></blockquote><div><br></div><div>Code review. Very. Very. Strongly. Recommended.</div><div>Again, there's no magical solution. </div><div><br></div><div>Any plugin is able (spoiler: and some *already* do) to push stats data anywhere they want while Jenkins is running.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
I'm in agreement with Daniel that, right now, we can either open up census<br>
information, *or* we can merge the changes proposed by Baptiste. But in their<br>
current implementations, we cannot have both at the same time.<br></blockquote><div><br></div><div>Though I would like to be able to keep things as open as we can, I agree. IMO we would have to keep census closed with some checking to know new data has been added.</div><div>Again, about new data, we would prolly want to be /aggressive/ about new stats data pushed that would be discovered just then, i.e. w/o the associated code having been reviewed by the dev community. </div><div><br></div><div>I understand this is a tough subject. </div><div>I would understand if we decide to say PR 1985 must be trashed, and an alternative decoupling approach be looked for (though an extension point is indeed the usual approach to inverse control, and this approach was indeed advised by Jesse originally when I started working on it).</div><div><br></div><div>Hope this clarifies.</div><div><br></div><div>-- Baptiste</div></div></div></div>