Re: [Sugar-devel] [Dextrose] [PATCH sugar 2/2] Send XO serial numbers with anonymous reports

2011-02-04 Thread David Farning
On Fri, Feb 4, 2011 at 9:05 AM, Aleksey Lim wrote: > On Fri, Feb 04, 2011 at 08:35:03AM -0500, Walter Bender wrote: >> It is not clear from this patch if there is a way for a deployment (or >> individual) to disable this feature. It is unprecedented that we have >> this level of auto-association b

Re: [Sugar-devel] [Dextrose] [PATCH sugar 2/2] Send XO serial numbers with anonymous reports

2011-02-04 Thread Bernie Innocenti
On Fri, 2011-02-04 at 08:35 -0500, Walter Bender wrote: > It is not clear from this patch if there is a way for a deployment (or > individual) to disable this feature. It is unprecedented that we have > this level of auto-association between user and some arbitrary > authority -- there should be a

Re: [Sugar-devel] [Dextrose] [PATCH sugar 2/2] Send XO serial numbers with anonymous reports

2011-02-04 Thread Samuel Greenfeld
It's worth noting that a "processor serial number" (along with any other persistent identifier) falls under "personal information" and requires anyone using this code that is either based in the United States or working with children in the United States to obey the Children's Online Privacy Protec

Re: [Sugar-devel] [Dextrose] [PATCH sugar 2/2] Send XO serial numbers with anonymous reports

2011-02-04 Thread Aleksey Lim
On Fri, Feb 04, 2011 at 08:35:03AM -0500, Walter Bender wrote: > It is not clear from this patch if there is a way for a deployment (or > individual) to disable this feature. It is unprecedented that we have > this level of auto-association between user and some arbitrary > authority -- there shoul

Re: [Sugar-devel] [Dextrose] [PATCH sugar 2/2] Send XO serial numbers with anonymous reports

2011-02-04 Thread Walter Bender
It is not clear from this patch if there is a way for a deployment (or individual) to disable this feature. It is unprecedented that we have this level of auto-association between user and some arbitrary authority -- there should be an opt-in policy at the deployment level and an opt-out policy at