On Thu, Jul 18, 2024 at 09:48:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> a long time ago I wanted to propose a more formal policy for privacy
> behaviours and I wrote this draft [1]. My idea was that we'd first
> create and approve such a policy, and then add the conformance to this
> policy
On Mon, Jul 08, 2024 at 02:28:09PM -0500, Michael Catanzaro wrote:
> timestamps. But we do need to audit and make sure that if timestamps
> are stored anywhere else, we must reduce their granularity to
> prevent them from being matched up with timestamps from other
> records. It's probably more tha
On Thu, Jul 18, 2024 at 11:01:37AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 18, 2024 at 09:48:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Jul 17, 2024 at 02:13:12PM -0500, Michel Lind wrote:
> > > On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote:
> > > > On Sun, J
On Thu, Jul 18, 2024 at 09:48:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 17, 2024 at 02:13:12PM -0500, Michel Lind wrote:
> > On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote:
> > > On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote:
> > > > That
On Wed, Jul 17, 2024 at 02:13:12PM -0500, Michel Lind wrote:
> On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote:
> > On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote:
> > > That said, it is not sufficient to reject adding Fedora downstream
> > > spyware.
> > >
On Wed, Jul 17, 2024 at 02:45:31PM -0400, Matthew Miller wrote:
> On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote:
> > That said, it is not sufficient to reject adding Fedora downstream spyware.
> > Fedora also needs a policy that upstream "telemetry" spyware is not allowed
On Sun, Jul 14, 2024 at 04:14:03AM +0200, Kevin Kofler via devel wrote:
> That said, it is not sufficient to reject adding Fedora downstream spyware.
> Fedora also needs a policy that upstream "telemetry" spyware is not allowed
> and needs to be disabled at compile time or patched out. We have se
Kevin Kofler via devel wrote:
> That said, it is not sufficient to reject adding Fedora downstream
> spyware. Fedora also needs a policy that upstream "telemetry" spyware is
> not allowed and needs to be disabled at compile time or patched out. We
> have several packaged applications wanting to "ph
Michael Catanzaro wrote:
> We don't have proposed wording yet. We should of course be reasonable
> and not write something misleading, but I think the question should be
> something along the lines of "help improve Fedora" (e.g. "Help improve
> Fedora by sending anonymous usage data" plus maybe "Fe
Mattia Verga via devel wrote:
> BTW, it's not really different on how the kde-sig managed to drop x11
> support - they wanted to do so and they have not stopped until they got
> what they want, addressing most of the concerns raised by the community.
But the main concern was that the community doe
On Mon, Jul 8 2024 at 08:51:58 PM +00:00:00, Zbigniew
Jędrzejewski-Szmek wrote:
Does the table store counts or separate entries? I would guess that if
it just stores disaggregated values, then the values repeat often, and
it's natural to store the count in the table. And then the order
doesn'
On Mon, Jul 8 2024 at 02:28:09 PM -05:00:00, Michael Catanzaro
wrote:
Good question! I *think* timestamps are no longer a problem. It does
store precise timestamps alongside a hash of the full submission, but
it doesn't actually store the full submission itself anymore, and the
first few table
On Monday 8 July 2024 19:51:07 CEST Przemek Klosowski via devel wrote:
> I haven't heard WHY is the existence of this data dangerous.
Data can be miss managed (not implying intention here)
Data can be miss used ( somebody who is not here now can gain access in the
future and not have the same...
On Monday 8 July 2024 21:30:07 CEST Przemek Klosowski via devel wrote:
> This is an established practice on pretty much
> all the websites I've encountered, so apparently it satisfies world-wide
> legal requirements too.
We are not concerned about the law (well, a bit).
what is legal != what is
On Mon, Jul 08, 2024 at 02:28:09PM -0500, Michael Catanzaro wrote:
> On Mon, Jul 8 2024 at 01:51:07 PM -04:00:00, Przemek Klosowski via devel
> wrote:
> > At the same time, I ask the proponents to confirm that there will be no
> > way to re-aggregate the data by any means (timestamps, Fedora accou
On Mon, Jul 8 2024 at 01:51:07 PM -04:00:00, Przemek Klosowski via
devel wrote:
At the same time, I ask the proponents to confirm that there will be
no
way to re-aggregate the data by any means (timestamps, Fedora account
cookies, load factor on the server, etc).
Good question! I *think* time
On Mon, Jul 8 2024 at 11:31:20 AM -05:00:00, Michel Lind
wrote:
Do the metrics really need to be kept separate?
I think so. Fedora Workstation is a completely different product from
Fedora KDE Plasma Desktop. We surely don't want to consider other
Fedora variants when making decisions that a
On 7/8/24 14:37, Vitaly Zaitsev via devel wrote:
Most GNU/Linux users are privacy conscious. This was the main reason
for choosing this OS. All this data belongs to them,
Good point, I agree personally, e.g. I whack-a-mole cookie privacy
dialogs to 'off', even while having occasional doubts w
On 08/07/2024 19:51, Przemek Klosowski via devel wrote:
So, I ask the questioners what is the exact scenario they are
contesting? why is the data on distribution of memory sizes
privacy-relevant?
Most GNU/Linux users are privacy conscious. This was the main reason for
choosing this OS. All th
On 7/7/24 16:49, Marc Deop i Argemí wrote:
With that statement you are showing that many here do not understand the
concern: nobody (I daresay) believes the proponents of this want to spy on
Fedora users or sell the data.
The concern is that the data is available at all!
I haven't heard WHY is
On Mon, Jul 08, 2024 at 08:20:05AM -0500, Michael Catanzaro wrote:
> On Mon, Jul 8 2024 at 09:03:50 AM -04:00:00, Neal Gompa
> wrote:
> > My biggest issue with this is that it's only useful for Fedora
> > Workstation. As it is currently designed, nobody else can benefit from
> > it. I would have p
Michael Catanzaro wrote:
> It's starting out as a Workstation-only proposal for simplicity, but I
> think nothing should stop other Fedora variants from adopting the
> Endless metrics system if they want to, *except* we'd need to somehow
> keep metrics separate on a per-variant basis as we surel
On Mon, Jul 08, 2024 at 12:50:52PM +, Tim Landscheidt wrote:
> Developers might not want to work for a project any longer
> that engages in behaviour that is perceived as being at odds
> with why they chose to work for that project in the first
> place.
Well... yeah?
That sounds like a self
On Mon, Jul 8 2024 at 09:03:50 AM -04:00:00, Neal Gompa
wrote:
My biggest issue with this is that it's only useful for Fedora
Workstation. As it is currently designed, nobody else can benefit from
it. I would have preferred a design that allows all Fedora variants to
be able to offer this so tha
On Mon, Jul 8, 2024 at 8:52 AM Tim Landscheidt wrote:
>
> Solomon Peachy wrote:
>
> >> But with that knowledge comes the ability to work for a va-
> >> riety of organizations who will spend many resources on
> >> nudging their users to behave in a way that is not necessar-
> >> ily in their best i
Solomon Peachy wrote:
>> But with that knowledge comes the ability to work for a va-
>> riety of organizations who will spend many resources on
>> nudging their users to behave in a way that is not necessar-
>> ily in their best interests.
> What does "a developer's ability to choose who they wor
On Mon, Jul 08, 2024 at 11:03:53AM +, Tim Landscheidt wrote:
> But with that knowledge comes the ability to work for a va-
> riety of organizations who will spend many resources on
> nudging their users to behave in a way that is not necessar-
> ily in their best interests.
What does "a devel
Mattia Verga wrote:
> […]
> If the change is approved, if you not believe in who proposed the
> metrics good faith, if you don't want to send your metrics, if you don't
> believe that setting a simple switch to OFF will make you safe, well,
> goodbye. There are plenty of other linux distributions
Il 07/07/24 20:44, Ralf Corsépius ha scritto:
>
> Am 07.07.24 um 8:25 PM schrieb Mattia Verga via devel:
>> So, again, I ask to stop implying malicious intentions where there's
>> none. Folks behind this proposal need this data to improve Fedora
> That's simply not true. It's a blatant lie.
>
> Ral
On Sun, Jul 7 2024 at 10:49:36 PM +02:00:00, Marc Deop i Argemí
wrote:
Let's say "possibly" instead of "probably". Regardless, that is a
very weak
argument. The fact that some information might be leaked while
browsing the
web has absolutely no weight on whether I would like to see even
*more*
On Sunday 7 July 2024 20:25:27 CEST Mattia Verga via devel wrote:
> It is not scary, it's how the things get done - find solutions for
> concerns raised by the community about the proposal and propose
> corrections.
In principle that is correct. Things are not black or white though.
One could sa
On Sunday 7 July 2024 20:21:07 CEST Leon Fauster via devel wrote:
> What I noticed in such discussions is, that there is the assumption that
> person-A's intention, is what person-B's finds scary. But there is the
> possibility that the both "target/assumptions" are _not_ the same
> (independent ho
Am 07.07.24 um 8:25 PM schrieb Mattia Verga via devel:
So, again, I ask to stop implying malicious intentions where there's
none. Folks behind this proposal need this data to improve Fedora
That's simply not true. It's a blatant lie.
Ralf
--
___
d
Il 07/07/24 18:29, Marc Deop i Argemí ha scritto:
> On Sunday 7 July 2024 17:14:44 CEST Michael Catanzaro wrote:
>> The design of the question will be
>> critical because if the acceptance rate is too low, then the project
>> will fail and we're just going to be back here in a couple years
>> debat
Am 07.07.24 um 18:29 schrieb Marc Deop i Argemí:
On Sunday 7 July 2024 17:14:44 CEST Michael Catanzaro wrote:
The design of the question will be
critical because if the acceptance rate is too low, then the project
will fail and we're just going to be back here in a couple years
debating once aga
On Sunday 7 July 2024 17:14:44 CEST Michael Catanzaro wrote:
> The design of the question will be
> critical because if the acceptance rate is too low, then the project
> will fail and we're just going to be back here in a couple years
> debating once again whether to make the metrics opt-out to in
On Sun, Jul 7 2024 at 03:43:15 AM +00:00:00, Gary Buhrmaster
wrote:
Do you have a proposed wording for the
question that does not, itself, exhibit any
bias?
We don't have proposed wording yet. We should of course be reasonable
and not write something misleading, but I think the question shoul
On Sat, Jul 6, 2024 at 7:03 PM Marc Deop i Argemí
wrote:
> Most users will just click on "Yes" without really comprehending what they
> are doing. And you _know_ this.
With no default provided, the most likely
response may very well depend on the
exact phrasing of the prompt (as few
would be ex
Thank you! The ability for members of the community to request the SIG for
copies of the database really helps put my mind at ease about this, as anything
going wrong with data collection that a community member catches could be
something we could alert you to and improve this process thereby, a
On Monday 1 July 2024 21:47:35 CEST Aoife Moloney wrote:
> As a result of this feedback, we have changed the proposal: we now
> propose that initial setup will show an explicit yes/no prompt which
> has no default value.
This is still absolutely _unnacceptable_.
It _must_ be *OFF* by default.
Mo
On Wed, Jul 03, 2024 at 06:50:02PM +0800, Jens-Ulrik Petersen wrote:
> >
> > > Country where device is physically located (this will need discussion)
>
>
> I think I would be more interested in locale info than country.
Yeah, I think locale info would be quite relevant. We have translations
into
Hi, please see:
https://fedoraproject.org/wiki/Changes/Metrics#Who_will_have_access_to_metrics_data
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
If the data is as anonymous as you say, why not just make it available to the
public? If it truly is, it would be nice to be able to verify that and there
would be no downside I could see to making it available given the use-cases you
outline for it.
--
_
On Wed, Jul 3 2024 at 09:32:45 AM +02:00:00, Vitaly Zaitsev via devel
wrote:
The apps should dlopen() it and if this library is not installed they
will be able to disable all telemetry functionality.
dlopen is the best option for this.
It's possible, but that's annoying. There is really no
On Wed, Jul 3, 2024 at 7:30 AM Richard W.M. Jones wrote:
>
> On Wed, Jul 03, 2024 at 06:39:04AM -0400, Neal Gompa wrote:
> > On Wed, Jul 3, 2024 at 4:53 AM Richard W.M. Jones wrote:
> > >
> > > On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote:
> > > >
> > > >
> > > > Am 02.07.24 um
On Wed, Jul 03, 2024 at 06:39:04AM -0400, Neal Gompa wrote:
> On Wed, Jul 3, 2024 at 4:53 AM Richard W.M. Jones wrote:
> >
> > On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote:
> > >
> > >
> > > Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro:
> > > >On Tue, Jul 2 2024 at 04:05:11 P
>
> > Country where device is physically located (this will need discussion)
I think I would be more interested in locale info than country.
Jens
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@li
On Wed, Jul 3, 2024 at 4:53 AM Richard W.M. Jones wrote:
>
> On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote:
> >
> >
> > Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro:
> > >On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius
> > > wrote:
> > >>Is this the same cheat as w
On Tue, Jul 02, 2024 at 06:32:17PM +0200, Ralf Corsépius wrote:
>
>
> Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro:
> >On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius
> > wrote:
> >>Is this the same cheat as with Fedora's "installation ids" and Firefox's
> >>"phone home" features?
On 02/07/2024 20:21, Michael Catanzaro wrote:
But it's a library that applications will link to, so this won't work.
The apps should dlopen() it and if this library is not installed they
will be able to disable all telemetry functionality.
dlopen is the best option for this.
--
Sincerely,
On Tue, Jul 2 2024 at 07:14:46 PM +02:00:00, Vitaly Zaitsev via devel
wrote:
Please use a weak dependency on eos-metrics to allow its removal too.
But it's a library that applications will link to, so this won't work.
See my answer on Discourse:
https://discussion.fedoraproject.org/t/f42-ch
On 01/07/2024 21:47, Aoife Moloney wrote:
Packages wanting to collect metrics data will need to depend on
eos-metrics. For example, to collect statistics about Settings usage,
the gnome-control-center package would need to depend on eos-metrics
in order to send a metric to eos-event-recorder-daem
Am 02.07.24 um 4:44 PM schrieb Michael Catanzaro:
On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius
wrote:
Is this the same cheat as with Fedora's "installation ids" and Firefox's
"phone home" features?
This stuff is activated by default, which means at the point a user
deactivates
Added links:
https://fedoraproject.org/wiki/Changes/Metrics#Metrics_system_components
One more thing: the eos-metrics-instrumentation project is going to
need a lot of work. The change proposal envisions only collecting
metrics that are approved by Fedora, and many of those metrics probably
won
On Tue, Jul 2 2024 at 11:04:25 AM -04:00:00, Stephen Smoogen
wrote:
I don't see where this open source code is mentioned in the proposal
or the FAQ or the other notes. The wording of the documents led me to
believe the code was going to be written in the future. Could that be
added so people
On Tue, 2 Jul 2024 at 10:59, Michael Catanzaro wrote:
>
>
> Well the entire metrics system is open source, so I'd encourage
> interested developers to study how it works. The database is just not
> structured to associate unrelated data points together. We are not
> interested in doing that.
>
I
Well the entire metrics system is open source, so I'd encourage
interested developers to study how it works. The database is just not
structured to associate unrelated data points together. We are not
interested in doing that.
There are some things we need to fix before deployment, though. E
On Tue, Jul 2 2024 at 04:05:11 PM +02:00:00, Ralf Corsépius
wrote:
Is this the same cheat as with Fedora's "installation ids" and
Firefox's
"phone home" features?
This stuff is activated by default, which means at the point a user
deactivates them, he already is "collected".
This metrics sys
On Tue, 2 Jul 2024 at 07:00, Michael Catanzaro wrote:
>
> On Tue, Jul 2 2024 at 12:04:48 PM +02:00:00, Vitaly Zaitsev via devel
> wrote:
> > Because Red Hat is based in the US. It can be used against users from
> > countries and regions that the US does not like (e.g. sanctions,
> > export
> > po
Am 02.07.24 um 10:53 AM schrieb Neal Gompa:
On Tue, Jul 2, 2024 at 3:27 AM Vitaly Zaitsev via devel
wrote:
On 01/07/2024 21:47, Aoife Moloney wrote:
As a result of this feedback, we have changed the proposal: we now
propose that initial setup will show an explicit yes/no prompt which
has no
On Tue, Jul 2, 2024 at 7:14 AM Vitaly Zaitsev via devel
wrote:
>
> On 02/07/2024 12:52, Michael Catanzaro wrote:
> > Please remember the data collected will be anonymous and the data points
> > will not be aggregated together with other data points.
>
> The government can ask "How many users are t
On Tue, Jul 2, 2024, 07:14 Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 02/07/2024 12:52, Michael Catanzaro wrote:
> > Please remember the data collected will be anonymous and the data points
> > will not be aggregated together with other data points.
>
> The government ca
On 02/07/2024 12:52, Michael Catanzaro wrote:
Please remember the data collected will be anonymous and the data points
will not be aggregated together with other data points.
The government can ask "How many users are there from the
$country_name", and if the number is greater than N, they can
On Tue, Jul 2 2024 at 12:04:48 PM +02:00:00, Vitaly Zaitsev via devel
wrote:
Because Red Hat is based in the US. It can be used against users from
countries and regions that the US does not like (e.g. sanctions,
export
policies, etc.).
Please remember the data collected will be anonymous and
On Tue, 2 Jul 2024 at 12:05, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 02/07/2024 10:53, Neal Gompa wrote:
> > Why? It can be useful for determining where to boost investment in
> > l10n and i18n efforts.
>
> Because Red Hat is based in the US. It can be used against us
On 02/07/2024 10:53, Neal Gompa wrote:
Why? It can be useful for determining where to boost investment in
l10n and i18n efforts.
Because Red Hat is based in the US. It can be used against users from
countries and regions that the US does not like (e.g. sanctions, export
policies, etc.).
--
On Tue, 2 Jul 2024 at 09:55, Neal Gompa wrote:
> On Tue, Jul 2, 2024 at 3:27 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 01/07/2024 21:47, Aoife Moloney wrote:
> > > As a result of this feedback, we have changed the proposal: we now
> > > propose that initial setup will show an explicit yes/
On Tue, Jul 2, 2024 at 3:27 AM Vitaly Zaitsev via devel
wrote:
>
> On 01/07/2024 21:47, Aoife Moloney wrote:
> > As a result of this feedback, we have changed the proposal: we now
> > propose that initial setup will show an explicit yes/no prompt which
> > has no default value.
>
> What about exis
On 01/07/2024 21:47, Aoife Moloney wrote:
As a result of this feedback, we have changed the proposal: we now
propose that initial setup will show an explicit yes/no prompt which
has no default value.
What about existing systems?
Which metrics will be collected
Country where device is physical
69 matches
Mail list logo
