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

[Greg Stein]

On Tue, Jun 13, 2017 at 1:00 AM, Roman Shaposhnik 
wrote:
>...

> There's also this:
> https://issues.apache.org/jira/browse/IGNITE-775?
> focusedCommentId=14513325=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-14513325
>
> which I find very intriguing.
>
> But I've got to say -- we need INFRA (Greg?) to tell us what they are
> and what they are NOT
> willing to do to enable something like that.
>

If the query is pushed out to the DNS substrate of the Internet, then Infra
really doesn't have much to support :-) ... we'll happily add DNS records
for such.


> If the default is not much -- I think we have no choice but to say
> that since ASF can't
> provide the infrastructure to reliable and securely collect user data
> project that publish
> convenience binaries off of Apache Infra shouldn't do that.
>

The basic policy of Infra is that we'll offer what we can within the budget
given to us by the Board. When an individual project requests resources,
then (again) we'll do what we can for them. You'll see this in daily
make-work, but also in the provision of "project VMs" where we provision a
VM/resources dedicated to a specific project.

However, we have run into an occurrence where a project's VM ran well past
any/all resources that we could provide within the Infrastructure budget
provided by the Board. As a result, we had to shut it down, or the project
needed to request specific budget from the Board to keep that system
running.

So. We can and will do all that we can. If the request is still pretty
nebulous/unclear, then bring it to users@infra for some early discussion.
Once it gets concrete, then file a ticket. We'll go from there.

Cheers,
Greg Stein
Infrastructure Administrator, ASF

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

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 11:51 PM, Bertrand Delacretaz
 wrote:
> On Fri, Jun 9, 2017 at 7:15 AM, Greg Stein  wrote:
>>... Do no evil...
>
> Of course. As long as everybody agrees on the definition of "evil" ;-)
>
> Hence my proposal to briefly document best practices about how to
> collect user data in a non-evil way.
>
> Maybe adding a few notes to
> https://issues.apache.org/jira/browse/IGNITE-5413 about what infra has
> been doing to fix the current issue is sufficient, so that we can
> point to that later if similar cases arise.

There's also this:
https://issues.apache.org/jira/browse/IGNITE-775?focusedCommentId=14513325=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14513325

which I find very intriguing.

But I've got to say -- we need INFRA (Greg?) to tell us what they are
and what they are NOT
willing to do to enable something like that.

If the default is not much -- I think we have no choice but to say
that since ASF can't
provide the infrastructure to reliable and securely collect user data
project that publish
convenience binaries off of Apache Infra shouldn't do that.

Which basically gets me to the list I was proposing we clean up and
add to the policy:

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

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Bertrand Delacretaz]

On Fri, Jun 9, 2017 at 7:15 AM, Greg Stein  wrote:
>... Do no evil...

Of course. As long as everybody agrees on the definition of "evil" ;-)

Hence my proposal to briefly document best practices about how to
collect user data in a non-evil way.

Maybe adding a few notes to
https://issues.apache.org/jira/browse/IGNITE-5413 about what infra has
been doing to fix the current issue is sufficient, so that we can
point to that later if similar cases arise.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Raphael Bircher]

Hi Roman, Greg, *

Am .06.2017, 07:20 Uhr, schrieb Roman Shaposhnik :


On Thu, Jun 8, 2017 at 10:15 PM, Greg Stein  wrote:
I recall a company that started to list out each of things NOT to do.  
Item
after item after item, to develop a policy. After a few dozen such, one  
guy
piped up, "this is ridiculous" ... It just isn't tractable. So he  
suggested

a simple replacement:

Do no evil.


Should we add that to our release policy? Will VP Legal go along with  
that?


Seriously, on one hand I see folks saying here that clarfiying what is  
and isn't
acceptable is useful. On the other hand, I see your reaction that can  
only

be described as "duh! what policy -- its just common sense".

I actually do not think it is common sense anymore -- I do think it  
needs to be

documented.

However, this won't be the first time when what I feel passionate about  
is
ignored by the "official ASF" -- not a biggie -- you guys are the  
bosses. I just

need to learn to care less.


No we should not care less. We should care more. But adding new policy  
don't means, that this never happened again. I think, more important then  
policy is to have the eyes open. And that's the task of us all.


Regards, Raphael



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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Greg Stein]

Haha... I'm no Director any more. Such policy is above my pay grade :-P

On Jun 8, 2017 22:20, "Roman Shaposhnik"  wrote:

On Thu, Jun 8, 2017 at 10:15 PM, Greg Stein  wrote:
> I recall a company that started to list out each of things NOT to do. Item
> after item after item, to develop a policy. After a few dozen such, one
guy
> piped up, "this is ridiculous" ... It just isn't tractable. So he
suggested
> a simple replacement:
>
> Do no evil.

Should we add that to our release policy? Will VP Legal go along with that?

Seriously, on one hand I see folks saying here that clarfiying what is and
isn't
acceptable is useful. On the other hand, I see your reaction that can only
be described as "duh! what policy -- its just common sense".

I actually do not think it is common sense anymore -- I do think it needs
to be
documented.

However, this won't be the first time when what I feel passionate about is
ignored by the "official ASF" -- not a biggie -- you guys are the bosses. I
just
need to learn to care less.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 10:15 PM, Greg Stein  wrote:
> I recall a company that started to list out each of things NOT to do. Item
> after item after item, to develop a policy. After a few dozen such, one guy
> piped up, "this is ridiculous" ... It just isn't tractable. So he suggested
> a simple replacement:
>
> Do no evil.

Should we add that to our release policy? Will VP Legal go along with that?

Seriously, on one hand I see folks saying here that clarfiying what is and isn't
acceptable is useful. On the other hand, I see your reaction that can only
be described as "duh! what policy -- its just common sense".

I actually do not think it is common sense anymore -- I do think it needs to be
documented.

However, this won't be the first time when what I feel passionate about is
ignored by the "official ASF" -- not a biggie -- you guys are the bosses. I just
need to learn to care less.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Greg Stein]

I recall a company that started to list out each of things NOT to do. Item
after item after item, to develop a policy. After a few dozen such, one guy
piped up, "this is ridiculous" ... It just isn't tractable. So he suggested
a simple replacement:

Do no evil.


On Jun 8, 2017 21:13, "Roman Shaposhnik"  wrote:

> On Thu, Jun 8, 2017 at 12:43 AM, Bertrand Delacretaz
>  wrote:
> > On Wed, Jun 7, 2017 at 5:32 PM, Sean Busbey  wrote:
> >> ...Who owns release policy? I presume it's VP Legal, which would
> suggest legal-discuss...
> >
> > I don't think our release policy is relevant here.
>
> Actually, that's what I'm trying to figure out. My initial thought around
> why
> release policy was relevant here was that THE ONLY reason we reacted
> the way we did is because there was a piece of software associated with
> ASF in two ways:
>1. branding
>2. distribution off of ASF infrastructure
>
> It sounds like you're saying that #1 is actually more important that #2. I
> may
> buy that, but let me ask you a hypothetical first. Suppose releases of
> Ingite
> were only done as source tarballs. Suppose also that the company called
> GridGain built it and made the binary available off of their website with
> the binary (and associated branding) saying Apache Ignite.
>
> Would we still have a problem if that binary did what Ignite's binary did?
>
> > The issue is a project releasing software that a) collects user data
> > without an explicit opt-in, and b) apparently does that in an insecure
> > way.
>
> I'm not concerned about b -- so lets cut it out of the discussion.
>
> > a) is a privacy violation - we have
> > https://www.apache.org/foundation/policies/privacy.html for that, I
> > suggest that we simply expand it with a "collecting user data"
> > section. As Shane mentions
> > https://wiki.openoffice.org/wiki/Update_Service is related.
>
> Well, but what does that policy apply to? A source release? A binary
> release? A binary release off of ASF infrastructure?
>
> Please be specific.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Roman Shaposhnik]

On Thu, Jun 8, 2017 at 12:43 AM, Bertrand Delacretaz
 wrote:
> On Wed, Jun 7, 2017 at 5:32 PM, Sean Busbey  wrote:
>> ...Who owns release policy? I presume it's VP Legal, which would suggest 
>> legal-discuss...
>
> I don't think our release policy is relevant here.

Actually, that's what I'm trying to figure out. My initial thought around why
release policy was relevant here was that THE ONLY reason we reacted
the way we did is because there was a piece of software associated with
ASF in two ways:
   1. branding
   2. distribution off of ASF infrastructure

It sounds like you're saying that #1 is actually more important that #2. I may
buy that, but let me ask you a hypothetical first. Suppose releases of Ingite
were only done as source tarballs. Suppose also that the company called
GridGain built it and made the binary available off of their website with
the binary (and associated branding) saying Apache Ignite.

Would we still have a problem if that binary did what Ignite's binary did?

> The issue is a project releasing software that a) collects user data
> without an explicit opt-in, and b) apparently does that in an insecure
> way.

I'm not concerned about b -- so lets cut it out of the discussion.

> a) is a privacy violation - we have
> https://www.apache.org/foundation/policies/privacy.html for that, I
> suggest that we simply expand it with a "collecting user data"
> section. As Shane mentions
> https://wiki.openoffice.org/wiki/Update_Service is related.

Well, but what does that policy apply to? A source release? A binary
release? A binary release off of ASF infrastructure?

Please be specific.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Myrle Krantz]

Out of curiousity: Do we ever let domains like this expire?

Greets,
Myrle


On Thu, Jun 8, 2017 at 4:55 PM, Chris Mattmann  wrote:
> Makes sense to me.
>
> Cheers,
> Chris
>
>
>
>
> On 6/8/17, 1:42 AM, "Greg Stein"  wrote:
>
> On Thu, Jun 8, 2017 at 3:10 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Thu, Jun 8, 2017 at 10:01 AM, Raphael Bircher
> >  wrote:
> > > Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz
> > > :
> > >> ...Am I missing something?
> > >
> > > Yea, as far as I know it is in a old version who is in the archive,
> > right. I
> > > think this makes some difference...
> >
> > Ah yes you're right, we might want to pull the old binaries from the
> > archive as well, in addition to the changes that I suggested.
> >
>
> In the specific case of Apache Ignite's invocation of that URL and passing
> along certain data ... that is no longer relevant, even for OLD versions,
> as the Foundation currently controls the ignite.run domain (and host). 
> That
> host will no longer resolve, so no HTTP request will be performed, and
> (certainly) no data will be collected from old/new versions of Apache
> Ignite.
>
> Cheers,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Chris Mattmann]

Makes sense to me.

Cheers,
Chris




On 6/8/17, 1:42 AM, "Greg Stein"  wrote:

On Thu, Jun 8, 2017 at 3:10 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Thu, Jun 8, 2017 at 10:01 AM, Raphael Bircher
>  wrote:
> > Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz
> > :
> >> ...Am I missing something?
> >
> > Yea, as far as I know it is in a old version who is in the archive,
> right. I
> > think this makes some difference...
>
> Ah yes you're right, we might want to pull the old binaries from the
> archive as well, in addition to the changes that I suggested.
>

In the specific case of Apache Ignite's invocation of that URL and passing
along certain data ... that is no longer relevant, even for OLD versions,
as the Foundation currently controls the ignite.run domain (and host). That
host will no longer resolve, so no HTTP request will be performed, and
(certainly) no data will be collected from old/new versions of Apache
Ignite.

Cheers,
Greg Stein
Infrastructure Administrator, ASF




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Greg Stein]

On Thu, Jun 8, 2017 at 3:10 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Thu, Jun 8, 2017 at 10:01 AM, Raphael Bircher
>  wrote:
> > Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz
> > :
> >> ...Am I missing something?
> >
> > Yea, as far as I know it is in a old version who is in the archive,
> right. I
> > think this makes some difference...
>
> Ah yes you're right, we might want to pull the old binaries from the
> archive as well, in addition to the changes that I suggested.
>

In the specific case of Apache Ignite's invocation of that URL and passing
along certain data ... that is no longer relevant, even for OLD versions,
as the Foundation currently controls the ignite.run domain (and host). That
host will no longer resolve, so no HTTP request will be performed, and
(certainly) no data will be collected from old/new versions of Apache
Ignite.

Cheers,
Greg Stein
Infrastructure Administrator, ASF

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

[Bertrand Delacretaz]

On Thu, Jun 8, 2017 at 10:01 AM, Raphael Bircher
 wrote:
> Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz
> :
>> ...Am I missing something?
>
> Yea, as far as I know it is in a old version who is in the archive, right. I
> think this makes some difference...

Ah yes you're right, we might want to pull the old binaries from the
archive as well, in addition to the changes that I suggested.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Raphael Bircher]

Hi all,

Am .06.2017, 09:43 Uhr, schrieb Bertrand Delacretaz  
:



On Wed, Jun 7, 2017 at 5:32 PM, Sean Busbey  wrote:
...Who owns release policy? I presume it's VP Legal, which would  
suggest legal-discuss...


I don't think our release policy is relevant here.

The issue is a project releasing software that a) collects user data
without an explicit opt-in, and b) apparently does that in an insecure
way.

a) is a privacy violation - we have
https://www.apache.org/foundation/policies/privacy.html for that, I
suggest that we simply expand it with a "collecting user data"
section. As Shane mentions
https://wiki.openoffice.org/wiki/Update_Service is related.

b) is a general security problem,
http://www.apache.org/security/committers.html applies to that as
usual.

Am I missing something?
Yea, as far as I know it is in a old version who is in the archive, right.  
I think this makes some difference.


Regards Raphael



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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Bertrand Delacretaz]

On Wed, Jun 7, 2017 at 5:32 PM, Sean Busbey  wrote:
> ...Who owns release policy? I presume it's VP Legal, which would suggest 
> legal-discuss...

I don't think our release policy is relevant here.

The issue is a project releasing software that a) collects user data
without an explicit opt-in, and b) apparently does that in an insecure
way.

a) is a privacy violation - we have
https://www.apache.org/foundation/policies/privacy.html for that, I
suggest that we simply expand it with a "collecting user data"
section. As Shane mentions
https://wiki.openoffice.org/wiki/Update_Service is related.

b) is a general security problem,
http://www.apache.org/security/committers.html applies to that as
usual.

Am I missing something?

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[John D. Ament]

On Wed, Jun 7, 2017 at 4:55 PM Ted Dunning  wrote:

> On Wed, Jun 7, 2017 at 10:31 PM, Roman Shaposhnik 
> wrote:
>
> > > legal-discuss@ is the best place to bring any specific requests from
> > > project(s) to change the actual policy itself.  But first it would be
> > > useful to get some rough consensus on some of those specific requests
> > > here from the IPMC or from ComDev.
> >
> > That was my very question: what is the right forum. You could've just
> > answered
> > that. So it is IPMC, ComDev, both?
> >
> > Seriously WHERE do I have to move this thread to?
>
>
> Let's leave it here to get an IPMC opinion.
>

I disagree.  The Ignore PMC released the software with this included.  It
seems like they're the ones having issues with it, the discussion should
happen on their lists to find out what should have been done.



>
> Then take it to legal-discuss with a specific thought in mind.
>

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

[Ted Dunning]

On Wed, Jun 7, 2017 at 10:31 PM, Roman Shaposhnik 
wrote:

> > legal-discuss@ is the best place to bring any specific requests from
> > project(s) to change the actual policy itself.  But first it would be
> > useful to get some rough consensus on some of those specific requests
> > here from the IPMC or from ComDev.
>
> That was my very question: what is the right forum. You could've just
> answered
> that. So it is IPMC, ComDev, both?
>
> Seriously WHERE do I have to move this thread to?


Let's leave it here to get an IPMC opinion.

Then take it to legal-discuss with a specific thought in mind.

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

[Roman Shaposhnik]

On Wed, Jun 7, 2017 at 1:26 PM, Shane Curcuru  wrote:
> Roman Shaposhnik wrote on 6/7/17 4:20 PM:
>> On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas  wrote:
>>> On 07/06/17 17:53, Roman Shaposhnik wrote:
 On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  
> wrote:
>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
>> 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?
>
> Huh?

Because last time BDFL tendencies flared up around ASF Legal it was
painful all around.

>  Only the board and specifically authorized officers can set policy
> like the release policy that all PMCs MUST follow.  So yes, VP Legal is
> the final determiner of release policy updates, not anyone else.
>
> legal-discuss@ is the best place to bring any specific requests from
> project(s) to change the actual policy itself.  But first it would be
> useful to get some rough consensus on some of those specific requests
> here from the IPMC or from ComDev.

That was my very question: what is the right forum. You could've just answered
that. So it is IPMC, ComDev, both?

Seriously WHERE do I have to move this thread to?

> Note that ComDev is a PMC itself, and has no authority to set *policy*
> for other PMCs.  But they do provide a lot of good docs and best
> practices, and dev@community is becoming quite a good cross-project
> discussion area, so it's a good place to get other feedback on a proposal.

Sure. We all know that.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Shane Curcuru]

Roman Shaposhnik wrote on 6/7/17 4:20 PM:
> On Wed, Jun 7, 2017 at 10:56 AM, Mark Thomas  wrote:
>> On 07/06/17 17:53, Roman Shaposhnik wrote:
>>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
 On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
> 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?

Huh?  Only the board and specifically authorized officers can set policy
like the release policy that all PMCs MUST follow.  So yes, VP Legal is
the final determiner of release policy updates, not anyone else.

legal-discuss@ is the best place to bring any specific requests from
project(s) to change the actual policy itself.  But first it would be
useful to get some rough consensus on some of those specific requests
here from the IPMC or from ComDev.  Having specific changes backed up by
actual *needs* from one or more PMCs is the best way to start.

Note that ComDev is a PMC itself, and has no authority to set *policy*
for other PMCs.  But they do provide a lot of good docs and best
practices, and dev@community is becoming quite a good cross-project
discussion area, so it's a good place to get other feedback on a proposal.

> Thanks,
> Roman.

-- 

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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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  wrote:
> On 07/06/17 17:53, Roman Shaposhnik wrote:
>> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
>>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
 On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  
 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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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  wrote:
>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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  wrote:
> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Sean Busbey]

On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote: 
> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Wade Chandler]

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"  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, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
> >  wrote:
> >
> >> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Shane Curcuru]

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, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
>  wrote:
> 
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Bertrand Delacretaz]

On Tue, Jun 6, 2017 at 5:16 AM, Roman Shaposhnik  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Konstantin Boudnik]

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  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 
> wrote:
>
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Alex Harui]

Is the use of Google Analytics also prohibited by #4?

-Alex

On 6/5/17, 8:16 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik"
 wrote:

>On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>

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

[John D. Ament]

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 
wrote:

> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Julian Hyde]

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  wrote:
> 
> On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
> but apparently that never happened.
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Raphael Bircher]

Hi all,

Am .06.2017, 04:47 Uhr, schrieb Roman Shaposhnik :


On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Konstantin Boudnik]

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  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  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] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E <
>> https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%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 
>> 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: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>>
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Roman Shaposhnik]

On Mon, Jun 5, 2017 at 7:34 PM, Julian Hyde  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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14512075
but apparently that never happened.

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Greg Stein]

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  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] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E <
> https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%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 
> 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: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>

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

[Julian Hyde]

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_t...@mail.gmail.com%3E
 


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




> On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik  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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>