ASF hosted binaries collecting user data without an explicit opt-in

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
Hi!

after seeing this thread on legal-discuss:
    https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E

I'd like to ask a policy related question.

What we currently have is a whole bunch of binaries hosted
by ASF: https://ignite.apache.org/download.cgi#binaries that
collect user data and ship it away to a host currently not
associated with ASF (nor does it seem to be associated with
Ignite's PMC). The host name is ignite.run (and, as a side note,
as it turns out the connection to that host in Ignite releases prior
to 1.9 is unsecure:
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
)

Is this something ASF should be concerned with from a standpoint
of the policy that we have for binary convenience artifacts that are
hosted on our end?

Would it make it different if ignite.run and the data collected
by it was managed by an Ignite PMC as opposed to an unidentified
3d party?

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Julian Hyde-3
If the binaries are built from the released source code I don’t think we should restrict what the binaries do. The question is whether the community is aware of what the code is doing, and considers it to be in the best interests of the project.

The answer seems to be yes, and yes. I saw that the issue was discussed on dev@ignite[1], and had a corresponding JIRA case[2], and no objections were raised. If anyone has problems with that behavior (including security bugs) they should raise it with Ignite's PMC.

Julian

[1] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%3CCALV17Qod61yu63__Cs9ekGu+KVxHPpKXmpAGNdoNRz1t8_T9SA@...%3E <https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%3CCALV17Qod61yu63__Cs9ekGu+KVxHPpKXmpAGNdoNRz1t8_T9SA@...%3E>

[2] https://issues.apache.org/jira/browse/IGNITE-775 <https://issues.apache.org/jira/browse/IGNITE-775>



> On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik <[hidden email]> wrote:
>
> Hi!
>
> after seeing this thread on legal-discuss:
>    https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E
>
> I'd like to ask a policy related question.
>
> What we currently have is a whole bunch of binaries hosted
> by ASF: https://ignite.apache.org/download.cgi#binaries that
> collect user data and ship it away to a host currently not
> associated with ASF (nor does it seem to be associated with
> Ignite's PMC). The host name is ignite.run (and, as a side note,
> as it turns out the connection to that host in Ignite releases prior
> to 1.9 is unsecure:
>   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
> )
>
> Is this something ASF should be concerned with from a standpoint
> of the policy that we have for binary convenience artifacts that are
> hosted on our end?
>
> Would it make it different if ignite.run and the data collected
> by it was managed by an Ignite PMC as opposed to an unidentified
> 3d party?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Greg Stein-4
The Infrastructure team is taking this to the Apache Ignite PMC. This is
completely improper.

On Mon, Jun 5, 2017 at 9:34 PM, Julian Hyde <[hidden email]> wrote:

> If the binaries are built from the released source code I don’t think we
> should restrict what the binaries do. The question is whether the community
> is aware of what the code is doing, and considers it to be in the best
> interests of the project.
>
> The answer seems to be yes, and yes. I saw that the issue was discussed on
> dev@ignite[1], and had a corresponding JIRA case[2], and no objections
> were raised. If anyone has problems with that behavior (including security
> bugs) they should raise it with Ignite's PMC.
>
> Julian
>
> [1] <a href="https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%">https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> [hidden email]%3E <
> <a href="https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%">https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> [hidden email]%3E>
>
> [2] https://issues.apache.org/jira/browse/IGNITE-775 <
> https://issues.apache.org/jira/browse/IGNITE-775>
>
>
>
> > On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik <[hidden email]>
> wrote:
> >
> > Hi!
> >
> > after seeing this thread on legal-discuss:
> >    https://mail-archives.apache.org/mod_mbox/www-legal-
> discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_
> V1REQ9hUERCFog%40mail.gmail.com%3E
> >
> > I'd like to ask a policy related question.
> >
> > What we currently have is a whole bunch of binaries hosted
> > by ASF: https://ignite.apache.org/download.cgi#binaries that
> > collect user data and ship it away to a host currently not
> > associated with ASF (nor does it seem to be associated with
> > Ignite's PMC). The host name is ignite.run (and, as a side note,
> > as it turns out the connection to that host in Ignite releases prior
> > to 1.9 is unsecure:
> >   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
> > )
> >
> > Is this something ASF should be concerned with from a standpoint
> > of the policy that we have for binary convenience artifacts that are
> > hosted on our end?
> >
> > Would it make it different if ignite.run and the data collected
> > by it was managed by an Ignite PMC as opposed to an unidentified
> > 3d party?
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
In reply to this post by Julian Hyde-3
On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde <[hidden email]> wrote:
> If the binaries are built from the released source code I don’t think we should restrict what the binaries do.

Well, but that's not how we treat licensing for example. For example
-- there's plenty of ASF project that
allow GPL licensed extension to be pulled into the build. That
mechanics is part of the source code. However,
as per our policy, we will not allow this kind of a convenience binary
(containing GPL bits) to be hosted by
ASF infrastructure.

Now, there's nothing wrong with those kinds of binaries -- and 3d
parties host them all the time -- its just that
WE at ASF decided that it wouldn't be aligned with what we do.

What I'm concerned about is that a combination of binaries hosted by
ASF and a lack of opt-in AND an unsecure
nature of the communication AND unclear data handling policies can
potential make ASF liable if this kind of
data ends up containing sensitive information and gets exploited.

IANAL, but I could see EU being especially strict here.

> The question is whether the community is aware of what the code is doing, and considers it to be in the best interests of the project.
>
> The answer seems to be yes, and yes. I saw that the issue was discussed on dev@ignite[1], and had a corresponding JIRA case[2],

As for the discussion on JIRA, I expected the podling to listen to the
advice given by one of the mentors:
   https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
but apparently that never happened.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Konstantin Boudnik-2
In reply to this post by Greg Stein-4
Thanks Greg. I have already started the conversation on private@ignite
and opened IGNITE-5413
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jun 5, 2017 at 7:36 PM, Greg Stein <[hidden email]> wrote:

> The Infrastructure team is taking this to the Apache Ignite PMC. This is
> completely improper.
>
> On Mon, Jun 5, 2017 at 9:34 PM, Julian Hyde <[hidden email]> wrote:
>
>> If the binaries are built from the released source code I don’t think we
>> should restrict what the binaries do. The question is whether the community
>> is aware of what the code is doing, and considers it to be in the best
>> interests of the project.
>>
>> The answer seems to be yes, and yes. I saw that the issue was discussed on
>> dev@ignite[1], and had a corresponding JIRA case[2], and no objections
>> were raised. If anyone has problems with that behavior (including security
>> bugs) they should raise it with Ignite's PMC.
>>
>> Julian
>>
>> [1] <a href="https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%">https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> [hidden email]%3E <
>> <a href="https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%">https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> [hidden email]%3E>
>>
>> [2] https://issues.apache.org/jira/browse/IGNITE-775 <
>> https://issues.apache.org/jira/browse/IGNITE-775>
>>
>>
>>
>> > On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik <[hidden email]>
>> wrote:
>> >
>> > Hi!
>> >
>> > after seeing this thread on legal-discuss:
>> >    https://mail-archives.apache.org/mod_mbox/www-legal-
>> discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_
>> V1REQ9hUERCFog%40mail.gmail.com%3E
>> >
>> > I'd like to ask a policy related question.
>> >
>> > What we currently have is a whole bunch of binaries hosted
>> > by ASF: https://ignite.apache.org/download.cgi#binaries that
>> > collect user data and ship it away to a host currently not
>> > associated with ASF (nor does it seem to be associated with
>> > Ignite's PMC). The host name is ignite.run (and, as a side note,
>> > as it turns out the connection to that host in Ignite releases prior
>> > to 1.9 is unsecure:
>> >   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
>> > )
>> >
>> > Is this something ASF should be concerned with from a standpoint
>> > of the policy that we have for binary convenience artifacts that are
>> > hosted on our end?
>> >
>> > Would it make it different if ignite.run and the data collected
>> > by it was managed by an Ignite PMC as opposed to an unidentified
>> > 3d party?
>> >
>> > Thanks,
>> > Roman.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Raphael Bircher-2
In reply to this post by Roman Shaposhnik
Hi all,

Am .06.2017, 04:47 Uhr, schrieb Roman Shaposhnik <[hidden email]>:

> On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde <[hidden email]> wrote:
>> If the binaries are built from the released source code I don’t think  
>> we should restrict what the binaries do.
>
> Well, but that's not how we treat licensing for example. For example
> -- there's plenty of ASF project that
> allow GPL licensed extension to be pulled into the build. That
> mechanics is part of the source code. However,
> as per our policy, we will not allow this kind of a convenience binary
> (containing GPL bits) to be hosted by
> ASF infrastructure.
>
> Now, there's nothing wrong with those kinds of binaries -- and 3d
> parties host them all the time -- its just that
> WE at ASF decided that it wouldn't be aligned with what we do.
>
> What I'm concerned about is that a combination of binaries hosted by
> ASF and a lack of opt-in AND an unsecure
> nature of the communication AND unclear data handling policies can
> potential make ASF liable if this kind of
> data ends up containing sensitive information and gets exploited.
>
> IANAL, but I could see EU being especially strict here.
Absolutely, for me the described behavior is a no go. The binaries should  
not be distributed over ASF Mirrors.

Regards, Raphael

--
My introduction https://youtu.be/Ln4vly5sxYU

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Julian Hyde-3
In reply to this post by Roman Shaposhnik
Thanks for the explanation, Roman. I had no idea that policies for hosted binaries were stricter than for source code (other than the obvious effect on licensing when you bundle in dependencies).

Julian

> On Jun 5, 2017, at 7:47 PM, Roman Shaposhnik <[hidden email]> wrote:
>
> On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde <[hidden email]> wrote:
>> If the binaries are built from the released source code I don’t think we should restrict what the binaries do.
>
> Well, but that's not how we treat licensing for example. For example
> -- there's plenty of ASF project that
> allow GPL licensed extension to be pulled into the build. That
> mechanics is part of the source code. However,
> as per our policy, we will not allow this kind of a convenience binary
> (containing GPL bits) to be hosted by
> ASF infrastructure.
>
> Now, there's nothing wrong with those kinds of binaries -- and 3d
> parties host them all the time -- its just that
> WE at ASF decided that it wouldn't be aligned with what we do.
>
> What I'm concerned about is that a combination of binaries hosted by
> ASF and a lack of opt-in AND an unsecure
> nature of the communication AND unclear data handling policies can
> potential make ASF liable if this kind of
> data ends up containing sensitive information and gets exploited.
>
> IANAL, but I could see EU being especially strict here.
>
>> The question is whether the community is aware of what the code is doing, and considers it to be in the best interests of the project.
>>
>> The answer seems to be yes, and yes. I saw that the issue was discussed on dev@ignite[1], and had a corresponding JIRA case[2],
>
> As for the discussion on JIRA, I expected the podling to listen to the
> advice given by one of the mentors:
>   https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14512075&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
> but apparently that never happened.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
> Thanks for the explanation, Roman. I had no idea that policies for hosted binaries
> were stricter than for source code (other than the obvious effect on licensing when you bundle in dependencies).

Btw, this one is serious enough that I'd like us to update our release
policy based on the
learnings here.

So far it seems that there's an agreement on that having this type of
capability...
   1 ... in the source code disabled by default -- totally OK
   2 ... in the source code enabled by default -- questionable, but OK
   3 ... in the binary hosted by ASF disabled by default -- OK
   4 ... in the binary hosted by ASF enabled by default -- NOT OK

#4 can get nuanced if we want to invest in ASF managed infrastructure that is
responsible for update tracking and user data collection. With my ASF hat on,
I'd say that INFRA should probably stay away from user data
collection/retention.

That still leaves a possibility of a a ping/pong API that only
consumes a name of ASF
project and its version and returns a JSON object of some kind as per
PMC choice.


Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Alex Harui-2
Is the use of Google Analytics also prohibited by #4?

-Alex

On 6/5/17, 8:16 PM, "[hidden email] on behalf of Roman Shaposhnik"
<[hidden email] on behalf of [hidden email]> wrote:

>On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
>> Thanks for the explanation, Roman. I had no idea that policies for
>>hosted binaries
>> were stricter than for source code (other than the obvious effect on
>>licensing when you bundle in dependencies).
>
>Btw, this one is serious enough that I'd like us to update our release
>policy based on the
>learnings here.
>
>So far it seems that there's an agreement on that having this type of
>capability...
>   1 ... in the source code disabled by default -- totally OK
>   2 ... in the source code enabled by default -- questionable, but OK
>   3 ... in the binary hosted by ASF disabled by default -- OK
>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
>#4 can get nuanced if we want to invest in ASF managed infrastructure
>that is
>responsible for update tracking and user data collection. With my ASF hat
>on,
>I'd say that INFRA should probably stay away from user data
>collection/retention.
>
>That still leaves a possibility of a a ping/pong API that only
>consumes a name of ASF
>project and its version and returns a JSON object of some kind as per
>PMC choice.
>
>
>Thanks,
>Roman.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

John D. Ament-2
In reply to this post by Roman Shaposhnik
While these are all great discussion points, I don't believe they're
relevant to incubator only and probably should have remained on the
legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
doesn't have an opinion about this, but it's good to know that the policy
may change (and I do personally have an opinion on said types of software).

John

On Mon, Jun 5, 2017 at 11:16 PM Roman Shaposhnik <[hidden email]>
wrote:

> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
> > Thanks for the explanation, Roman. I had no idea that policies for
> hosted binaries
> > were stricter than for source code (other than the obvious effect on
> licensing when you bundle in dependencies).
>
> Btw, this one is serious enough that I'd like us to update our release
> policy based on the
> learnings here.
>
> So far it seems that there's an agreement on that having this type of
> capability...
>    1 ... in the source code disabled by default -- totally OK
>    2 ... in the source code enabled by default -- questionable, but OK
>    3 ... in the binary hosted by ASF disabled by default -- OK
>    4 ... in the binary hosted by ASF enabled by default -- NOT OK
>
> #4 can get nuanced if we want to invest in ASF managed infrastructure that
> is
> responsible for update tracking and user data collection. With my ASF hat
> on,
> I'd say that INFRA should probably stay away from user data
> collection/retention.
>
> That still leaves a possibility of a a ping/pong API that only
> consumes a name of ASF
> project and its version and returns a JSON object of some kind as per
> PMC choice.
>
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Konstantin Boudnik-2
While I am completely agree with your point, and the Ignite graduation
is the water under the bridge, this is in an important point for the
current podlings to consider. Perhaps it could be done elsewhere as
well, but I am not sure where would be the best place for it.
Thoughts?

Thanks,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:

> While these are all great discussion points, I don't believe they're
> relevant to incubator only and probably should have remained on the
> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> doesn't have an opinion about this, but it's good to know that the policy
> may change (and I do personally have an opinion on said types of software).
>
> John
>
> On Mon, Jun 5, 2017 at 11:16 PM Roman Shaposhnik <[hidden email]>
> wrote:
>
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
>> > Thanks for the explanation, Roman. I had no idea that policies for
>> hosted binaries
>> > were stricter than for source code (other than the obvious effect on
>> licensing when you bundle in dependencies).
>>
>> Btw, this one is serious enough that I'd like us to update our release
>> policy based on the
>> learnings here.
>>
>> So far it seems that there's an agreement on that having this type of
>> capability...
>>    1 ... in the source code disabled by default -- totally OK
>>    2 ... in the source code enabled by default -- questionable, but OK
>>    3 ... in the binary hosted by ASF disabled by default -- OK
>>    4 ... in the binary hosted by ASF enabled by default -- NOT OK
>>
>> #4 can get nuanced if we want to invest in ASF managed infrastructure that
>> is
>> responsible for update tracking and user data collection. With my ASF hat
>> on,
>> I'd say that INFRA should probably stay away from user data
>> collection/retention.
>>
>> That still leaves a possibility of a a ping/pong API that only
>> consumes a name of ASF
>> project and its version and returns a JSON object of some kind as per
>> PMC choice.
>>
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Bertrand Delacretaz
In reply to this post by Roman Shaposhnik
On Tue, Jun 6, 2017 at 5:16 AM, Roman Shaposhnik <[hidden email]> wrote:
> ...So far it seems that there's an agreement on that having this type of
> capability...
>    1 ... in the source code disabled by default -- totally OK
>    2 ... in the source code enabled by default -- questionable, but OK
>    3 ... in the binary hosted by ASF disabled by default -- OK
>    4 ... in the binary hosted by ASF enabled by default -- NOT OK ...

I agree with that and IMO the place to document this is
https://www.apache.org/foundation/policies/privacy.html which already
mentions *.apache.org website analytics.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Shane Curcuru-2
In reply to this post by Alex Harui-2
While there may be technical issues out there, the policy issues can
have time for a thorough discussion before we make policy updates.

Alex Harui wrote on 6/5/17 11:25 PM:
> Is the use of Google Analytics also prohibited by #4?

That sounds like a different issue, unless a project is shipping docs
inside a release with GA code *in* the html docs that are then run when
a user installs the docs locally.  That would not be a good idea, BTW.

As Bertrand notes elsethread, GA on *.apache.org websites is fine as
long as the PMC is sure to comply with the ASF privacy policy:

  https://www.apache.org/foundation/policies/privacy.html

Separately, we have one example of auto-update checking which is OK:

  https://wiki.openoffice.org/wiki/Update_Service

>
> -Alex
>
> On 6/5/17, 8:16 PM, "[hidden email] on behalf of Roman Shaposhnik"
> <[hidden email] on behalf of [hidden email]> wrote:
>
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
>>> Thanks for the explanation, Roman. I had no idea that policies for
>>> hosted binaries
>>> were stricter than for source code (other than the obvious effect on
>>> licensing when you bundle in dependencies).
>>
>> Btw, this one is serious enough that I'd like us to update our release
>> policy based on the
>> learnings here.
>>
>> So far it seems that there's an agreement on that having this type of
>> capability...
>>   1 ... in the source code disabled by default -- totally OK
>>   2 ... in the source code enabled by default -- questionable, but OK
>>   3 ... in the binary hosted by ASF disabled by default -- OK
>>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
>>
>> #4 can get nuanced if we want to invest in ASF managed infrastructure
>> that is
>> responsible for update tracking and user data collection. With my ASF hat
>> on,
>> I'd say that INFRA should probably stay away from user data
>> collection/retention.
>>
>> That still leaves a possibility of a a ping/pong API that only
>> consumes a name of ASF
>> project and its version and returns a JSON object of some kind as per
>> PMC choice.
>>
>>
>> Thanks,
>> Roman.
>>

--

- Shane
  https://www.apache.org/foundation/marks/resources

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
In reply to this post by John D. Ament-2
On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:
> While these are all great discussion points, I don't believe they're
> relevant to incubator only and probably should have remained on the
> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> doesn't have an opinion about this, but it's good to know that the policy
> may change (and I do personally have an opinion on said types of software).

The reason I'm bringing it on the IPMC mailing list has nothing to do
with how long
ago Ignite graduated and everything to do with the following two points:
   1. It can be very useful to the future podlings
   2. I honestly don't know any other forum where I can meaningfully
discuss changes to release policy

I'll take advice on #2, of course.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Wade Chandler-3
In reply to this post by Shane Curcuru-2
NetBeans has various anonymous data collections such as UI gestures and
actions logging, and optional uploading, sort of like GA, which tells us
what is or is not being used, auto update, exception reporting, driven by
users deciding to send anonymously or login to attach their name, which I
do that often. There may be others. So certainly good for us to be aware
of, and will have to bring it up.

Thanks

Wade


On Jun 6, 2017 8:34 AM, "Shane Curcuru" <[hidden email]> wrote:

> While there may be technical issues out there, the policy issues can
> have time for a thorough discussion before we make policy updates.
>
> Alex Harui wrote on 6/5/17 11:25 PM:
> > Is the use of Google Analytics also prohibited by #4?
>
> That sounds like a different issue, unless a project is shipping docs
> inside a release with GA code *in* the html docs that are then run when
> a user installs the docs locally.  That would not be a good idea, BTW.
>
> As Bertrand notes elsethread, GA on *.apache.org websites is fine as
> long as the PMC is sure to comply with the ASF privacy policy:
>
>   https://www.apache.org/foundation/policies/privacy.html
>
> Separately, we have one example of auto-update checking which is OK:
>
>   https://wiki.openoffice.org/wiki/Update_Service
>
> >
> > -Alex
> >
> > On 6/5/17, 8:16 PM, "[hidden email] on behalf of Roman Shaposhnik"
> > <[hidden email] on behalf of [hidden email]> wrote:
> >
> >> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde <[hidden email]> wrote:
> >>> Thanks for the explanation, Roman. I had no idea that policies for
> >>> hosted binaries
> >>> were stricter than for source code (other than the obvious effect on
> >>> licensing when you bundle in dependencies).
> >>
> >> Btw, this one is serious enough that I'd like us to update our release
> >> policy based on the
> >> learnings here.
> >>
> >> So far it seems that there's an agreement on that having this type of
> >> capability...
> >>   1 ... in the source code disabled by default -- totally OK
> >>   2 ... in the source code enabled by default -- questionable, but OK
> >>   3 ... in the binary hosted by ASF disabled by default -- OK
> >>   4 ... in the binary hosted by ASF enabled by default -- NOT OK
> >>
> >> #4 can get nuanced if we want to invest in ASF managed infrastructure
> >> that is
> >> responsible for update tracking and user data collection. With my ASF
> hat
> >> on,
> >> I'd say that INFRA should probably stay away from user data
> >> collection/retention.
> >>
> >> That still leaves a possibility of a a ping/pong API that only
> >> consumes a name of ASF
> >> project and its version and returns a JSON object of some kind as per
> >> PMC choice.
> >>
> >>
> >> Thanks,
> >> Roman.
> >>
>
> --
>
> - Shane
>   https://www.apache.org/foundation/marks/resources
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Bertrand Delacretaz
On Wed, Jun 7, 2017 at 4:53 AM, Wade Chandler <[hidden email]> wrote:
> ...NetBeans has various anonymous data collections such as UI gestures and
> actions logging, and optional uploading, sort of like GA, which tells us
> what is or is not being used, auto update, exception reporting, driven by
> users deciding to send anonymously or login to attach their name, which I
> do that often...

This will need to be reviewed in light of the ASF's privacy policy.
Best is to document the corresponding decisions in jira tickets or
wiki pages, in order to have a simple reference to provide to other
projects with similar needs.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Sean Busbey-2
In reply to this post by Roman Shaposhnik


On 2017-06-06 11:59 (-0500), Roman Shaposhnik <[hidden email]> wrote:

> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:
> > While these are all great discussion points, I don't believe they're
> > relevant to incubator only and probably should have remained on the
> > legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> > doesn't have an opinion about this, but it's good to know that the policy
> > may change (and I do personally have an opinion on said types of software).
>
> The reason I'm bringing it on the IPMC mailing list has nothing to do
> with how long
> ago Ignite graduated and everything to do with the following two points:
>    1. It can be very useful to the future podlings
>    2. I honestly don't know any other forum where I can meaningfully
> discuss changes to release policy
>
> I'll take advice on #2, of course.


Who owns release policy? I presume it's VP Legal, which would suggest legal-discuss.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey <[hidden email]> wrote:

> On 2017-06-06 11:59 (-0500), Roman Shaposhnik <[hidden email]> wrote:
>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:
>> > While these are all great discussion points, I don't believe they're
>> > relevant to incubator only and probably should have remained on the
>> > legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
>> > doesn't have an opinion about this, but it's good to know that the policy
>> > may change (and I do personally have an opinion on said types of software).
>>
>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>> with how long
>> ago Ignite graduated and everything to do with the following two points:
>>    1. It can be very useful to the future podlings
>>    2. I honestly don't know any other forum where I can meaningfully
>> discuss changes to release policy
>>
>> I'll take advice on #2, of course.
>
>
> Who owns release policy? I presume it's VP Legal, which would suggest legal-discuss.

I would really be surprised if VP Legal actually *owned* it. This
feels someplace between
INFRA, ComDev and Legal, but it still doesn't answer the question
who's a single throat
to choke.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Mark Thomas
On 07/06/17 17:53, Roman Shaposhnik wrote:

> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey <[hidden email]> wrote:
>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik <[hidden email]> wrote:
>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:
>>>> While these are all great discussion points, I don't believe they're
>>>> relevant to incubator only and probably should have remained on the
>>>> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
>>>> doesn't have an opinion about this, but it's good to know that the policy
>>>> may change (and I do personally have an opinion on said types of software).
>>>
>>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>>> with how long
>>> ago Ignite graduated and everything to do with the following two points:
>>>    1. It can be very useful to the future podlings
>>>    2. I honestly don't know any other forum where I can meaningfully
>>> discuss changes to release policy
>>>
>>> I'll take advice on #2, of course.
>>
>>
>> Who owns release policy? I presume it's VP Legal, which would suggest legal-discuss.
>
> I would really be surprised if VP Legal actually *owned* it. This
> feels someplace between
> INFRA, ComDev and Legal, but it still doesn't answer the question
> who's a single throat
> to choke.

Consider yourself surprised then. V.P. Legal owns the release policy.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ASF hosted binaries collecting user data without an explicit opt-in

Roman Shaposhnik
On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas <[hidden email]> wrote:

> On 07/06/17 17:53, Roman Shaposhnik wrote:
>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey <[hidden email]> wrote:
>>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik <[hidden email]> wrote:
>>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament <[hidden email]> wrote:
>>>>> While these are all great discussion points, I don't believe they're
>>>>> relevant to incubator only and probably should have remained on the
>>>>> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
>>>>> doesn't have an opinion about this, but it's good to know that the policy
>>>>> may change (and I do personally have an opinion on said types of software).
>>>>
>>>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>>>> with how long
>>>> ago Ignite graduated and everything to do with the following two points:
>>>>    1. It can be very useful to the future podlings
>>>>    2. I honestly don't know any other forum where I can meaningfully
>>>> discuss changes to release policy
>>>>
>>>> I'll take advice on #2, of course.
>>>
>>>
>>> Who owns release policy? I presume it's VP Legal, which would suggest legal-discuss.
>>
>> I would really be surprised if VP Legal actually *owned* it. This
>> feels someplace between
>> INFRA, ComDev and Legal, but it still doesn't answer the question
>> who's a single throat
>> to choke.
>
> Consider yourself surprised then. V.P. Legal owns the release policy.

Is legal-discuss then the appropriate forum to actually build the consensus?
I surely hope V.P. Legal won't play a BDFL with our release policy, will he?

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12