Does openSUSE track users?

[nrickert]

@heyjoe

Exactly why I am looking at a situation:

1. The user does net install using a mirror
2. A mirror uses a rogue public key (not that of download.opensuse.org)
3. The mirror has signed packages with the rouge private key matching the rouge public key (so zypper won’t complain)
4. The user continues using some subverted software without even knowing

Is that possible or am I totally wrong in what I understand? The whole question is really: how is the authenticity of the mirrors guaranteed without connecting to download.opensuse.org?

I don’t know for sure. But, as far as I know, the NET installer comes with its own keys and uses those to check what it downloads from the mirror. So I doubt that’s an actual risk.

How you download the NET installer and how you check the integrity of that – this is where to look for problems. I always download the sha256 checksum file. I then verify its “gpg” signature. And then I use the checksum in that file to verify the download.

Could hackers corrupt that? I cannot totally rule it out. Ultimately, it all depends on our own judgment.

[malcolmlewis]

@heyjoe

<snip>
But there is still no info - neither on that mailing list, nor here. I don’t still know how the identifier can be removed or how one can exercise his fundamental (and GDPR) rights in regards to it. Am I missing something?

Hi
Another thread… http://forums.opensuse.org/showthread.php?t=535339

Remove the file /var/lib/zypp/AnonymousUniqueId

See: openSUSE:Statistics - openSUSE Wiki

[suse_rasputin]

…while you are at it: Block at your perimeter firewall (!) all contacts on port 80 to

conncheck.opensuse.org

and start logging (hope they do not switch their “beeping home” to https). Just for the lulz…

But be aware that the domain resolves to an important IP for other opensuse things, such as mailing lists etc. It’s a pain…

[deano_ferrari]

@suse_rasputin

…while you are at it: Block at your perimeter firewall (!) all contacts on port 80 to

conncheck.opensuse.org

and start logging (hope they do not switch their “beeping home” to https). Just for the lulz…

But be aware that the domain resolves to an important IP for other opensuse things, such as mailing lists etc. It’s a pain…

That’s easy to disable - remove (or comment out) the following from /etc/NetworkManager/NetworkManager.conf…

[connectivity]
uri=http://conncheck.opensuse.org

[suse_rasputin]

Maybe, but the next update might bring it back. I had to kill off the IPv6 config of my network interfaces (I use IPv4 only) several times a year after updates on TW. Don’t remember if it’s also for LEAP 15, but iiirc same situation there.

Firewall is safer solution…

[user]

@nrickert

Thanks. I wish there was some document explaining all that.

@malcolmlewis

Thanks! Perhaps sharing that info earlier would have saved a lot of extra talk

So as it seems to never have that UUID without having to use a mirror, one must install with network cable unplugged and run before connecting for first update:

# ln -sf /dev/null /var/lib/zypp/AnonymousUniqueId

I still think all that should be an opt-in (although it may be only for counting).

[hr][/hr]

@suse_rasputin

Firewall is safer solution…

Or use wicked.

[suse_rasputin]

Project Sisyphus - my kind of humor

https://www.golem.de/news/windows-10-die-anatomie-der-telemetrie-1903-140185.html

[dcurtisfra]

@heyjoe

Everything that you listed (in whole or partially) is data which can be used to identify a person indirectly and be used further for profiling (in combination with other data). That is something which requires explicit consent and should be optional, not enforced.

But you can’t say that without having verified how the system processes the data. That’s the whole point of GDPR: that the controller must be transparent regarding all this and that everything that is ‘personal data’ and that the ‘data subject’ is the owner who is in control to say how his data should be processed or not.

For the purposes of this Regulation:‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

Given that,

• A UUID is only unique within a given system, and even then, only if it’s verified against the existing UUID values held within that system.
• The UUID value held in ‘/var/lib/zypp/AnonymousUniqueId’ has been generated either from the output of ‘/proc/sys/kernel/random/uuid’ (or ‘/proc/sys/kernel/random/boot_id’) or, by using system calls which use either ‘/dev/random’ or ‘/dev/urandom’ to generate a UUID, at the initial system installation time.
• During the initial installation of this system and all the subsequent updates, at no point during the installation or update procedure was I asked to provide information in any form whatsoever with respect to my name or, address or, Forums ID or, Credit Card Number or, Bank Account or, Driving Licence or, Passport Number or, Citizen’s ID or, Tax Number or, Telephone Number.

Yes, the system’s approximate location data could be surmised from the Time Zone and the System Language and the (ISP – Router) IP Address.

Maybe openSUSE and SUSE could issue a statement that, during an installation and/or update, the system’s approximate location surmised from the system’s Time Zone, System Language and (ISP – Router) IP Address are not correlated in any possible way to the UUID value held in the file ‘/var/lib/zypp/AnonymousUniqueId’ …

[user]

@dcurtisfra

I am not saying that SUSE does this but it is possible to:

1. have a random UUID and IP address
2. get personal details in conjunction with the same IP address (as I explained)
3. correlate the first two things

Then the UUID is not just some insignificant random string but can be an entry point to various kinds of abuse. Again - I am not saying that SUSE abuses the data. I just don’t agree with what this article says:

There is no way to relate this random string to a user or machine.

Someone may say “What’s the big deal with that?” Well it is not a big deal per se but it can become one:

• the UUID is in a DB on SUSE’ servers
• the rest of your personal data (e.g. Microfocus user account) is in a DB too (same or separate)

Suppose some data breach happens and all this data falls in the hands of criminals. Although SUSE may not correlate the data, someone else will be able to, perhaps with even more data which they have grabbed from other breaches. Then the criminals will know how many machines you have in your office, perhaps when you are at the office or various other things (e.g. based on your forum posts). If there is no UUID they know less and you may not become an interesting target.

Of course I am exaggerating it just to explain an unfortunate possibility. We read about new data breaches and vulnerabilities every week and nothing can guarantee the absolute safety of stored data. So minimization of data collection is good.

[dcurtisfra]

@heyjoe

If there is no UUID they know less and you may not become an interesting target.

Yes, point taken.

For the case of a “community” system such as openSUSE, it is, possibly, reasonable to assume that, the community using that OS wish to be as “unnoticed” as possible.

• We do not pay any licence fees.
• We support the distribution when and as possible – for example, by contributing to this Forum …
• I faintly recall that, at the openSUSE Conference presentation on the subject of collection of usage statistics, a question was asked related to, the usage of a system UUID to avoid “counting twice” …

[HR][/HR]So, does the statistics gathering system used by openSUSE, really need to use a per-system UUID to avoid “double counting” of the distribution’s usage?

• As indicated in the OSC presentation, possibly not – it’s just that, a lot more effort will have to be expended to gather the usage statistics if a per-system UUID is not used.
• Catch-22: If a system is re-installed, without using the existing system information (/var/lib/zypp/AnonymousUniqueId), then, a new system UUID is generated – in other words, the system will be counted twice …

[hcvv]

And there maybe more reason to count system twice (or more).

I e.g. often have partitions labeld System_A, Home_A, System_B and Home_B. The current used system using the _A partitions. A new version is fresh installed on the _B ones, where first Home_B is made equal to Home_A. Installation tested and after that a fresh copy of Home_A to Home_B and booting from then on using the _B partitions. That would count _B as a new system ;).

Yes, I think statistics is a difficult science and you never now how much your data is biased by unexpected behaviour of your human subjects.

[knurpht]

A very brief answer when asked in the Board Meeting:
No, a UUID is not trackable to a person. If one installs on the same machine 5 times in a row one’s /dev/sda# will have different UUID’s.

But, if you want a definite answer on this, please email legal at suse{dot}com, or email the Board directly.

[user]

@Knurpht

But, if you want a definite answer on this, please email legal at suse{dot}com, or email the Board directly.

MAILER-DAEMON said:

<legal@**hidden-by-me-for-the-forum**>: host prv3-mx.novell.com[130.57.1.17] said: 550 No such
    recipient (in reply to RCPT TO command)

[knurpht]

@heyjoe

MAILER-DAEMON said:

<legal@**hidden-by-me-for-the-forum**>: host prv3-mx.novell.com[130.57.1.17] said: 550 No such
    recipient (in reply to RCPT TO command)

My mistake. It should be
privacy at suse{dot}com

[user]

Thank you.

[nlsthzn]

@Knurpht

But, if you want a definite answer on this, please email legal at suse{dot}com, or email the Board directly.

Phew, what a read this thread turned out to be. I would have thought the easiest and best answer would have been to differ it to an expert in these matters to start with

[dcurtisfra]

@nlsthzn

I would have thought the easiest and best answer would have been to differ it to an expert in these matters to start with

IMHO, unfortunately, most of the “General Data Protection” experts are lawyers and, at least for Europeans, exactly those who formulated the rules which are now part of European law …

Which begs the question, how does an Open Source community deal with such issues?

• I suspect, only by discussions such as the one being discussed in this thread …

[HR][/HR]BTW, governments such as the Bavarian State, have provided documentation for their citizens to help them deal with the complexities of European Data Protection – at the level of Clubs and small businesses – in language a “normal” citizen can understand …

[nlsthzn]

@dcurtisfra

IMHO, unfortunately, most of the “General Data Protection” experts are lawyers and, at least for Europeans, exactly those who formulated the rules which are now part of European law …

Which begs the question, how does an Open Source community deal with such issues?

• I suspect, only by discussions such as the one being discussed in this thread …

[HR][/HR]BTW, governments such as the Bavarian State, have provided documentation for their citizens to help them deal with the complexities of European Data Protection – at the level of Clubs and small businesses – in language a “normal” citizen can understand …

In the case of the question(s) at hand in regards to openSUSE the best suited to answer would be the legal team of SUSE. Sure, the thread has up to now been a very interesting discussion, but it doesn’t matter what concensus or understanding is generated within if it finally becomes known to be wrong.

That off course doesn’t mean that it can’t be debated and all doing so is free to continue and enjoy (if this your cup of tea) ;).

[user]

As this discussion also touched on other aspects of personal data handling (e.g. through SUSE’s sites) I will allow myself to share an update on the progress of this whole situation:

1. I have filed a bug report about microfocus.com requiring too much personal information and the sharing of data with 3rd parties without the actual need for it.

2. It got closed as “RESOLVED DUPLICATE” of another bug which itself had been closed earlier. I reopened it and asked for further attention on the matter.

3. I have also contacted all email addresses found on the terms and policies pages of SUSE and Microfocus asking them to pay attention to the reopened bug report. I explained to them that there are no tools for one to control one’s personal data, there is no granularity on agreements, no unified privacy policy but multiple ones, personal data is shared with 3rd parties without that being necessary. Additionally I asked for personal data erasure as per Article 17 of GDPR. I have sent this to:

• privacy at suse.com

No reply so far

• stefan.eigler at i-sec.tuv.com

No reply so far

• legal at suse.com

As it was clarified earlier this was a non-existing mailbox.

• compliance at microfocus.com

3 days after my message I received a reply:

We at Micro Focus have received your request to have your personal information erased from our systems, and we are actively working to fulfil your request in the manner and time period prescribed by law.

We may ask you to provide us additional information if it is necessary for us to fully comply with your request and would appreciate your cooperation if that is the case.

Please note that since 1 March 2019 that SUSE is no longer part of the Micro Focus group of companies, and any queries concerning SUSE should be addressed directly to that company.

Please feel free to contact me directly if you have any questions or concerns.

I explained in my reply that their intention to ask for additional information contradicts GDPR Recital (57) because they already can identify me as I am sending through the email address which they already have on record. I didn’t receive any further reply.

• admin at opensuse.org

Contacting this email address resulted in opening a ticket on the issue tracker. One of the people who replied in the ticket has an email address which is not @suse.com or @opensuse.org or @microfocus.com which implies my request and the personal data in it were also shared with yet another 3rd party - of course without anyone asking me for that. In a further comment another one replied:

We should do our best to honour our obligations under those rights, and the policy goes into some details about the steps we might take and further discussions that would be initiated if exceptions exist.

This sounds good but to have the overall picture paid attention to, I also I explained further that the current terms and tools are simply not GDPR compliant because:

[list]

• The privacy policy is misleading. It says:

The legal basis for this processing of your data is Article 6(1)(f) of the GDPR, which allows the processing of data to ensure e.g. a functioning and usable online services such as forums.

However what Article 6(1)(f) actually says is:

1. Processing shall be lawful only if and to the extent that at least one of the following applies:

(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

IOW: the “legitimate interest” cannot overpower the fundamental the right to data protection which says it must be processed fairly and on the basis of consent, i.e. not forced. GDPR Article 6(1)(a) says the same. So Article 6(1)(f) which is mentioned as a ‘basis’ is really just used partially, for the convenience and the interest of the data controller, thus justifying a “legitimate interest” by completely ignoring what the rest of it and the whole GDPR stands for.

• The principle of data minimisation is not followed which contradicts Article 5(c) of the GDPR.

There is absolutely no technical reason to:
[list]

• collect name, physical address, phone, job, etc.
• share this data with 3rd party (e.g. Microfocus)
• share IP address, HTTP user agent, referrer and give the possibility for 3rd party cookies with Google Analytics or other third parties (all listed in the policy)

in order to post in the forums or file a bug report.

Although it may be of valid legitimate interest of the controller to process as much data as possible under a catch-all agreement GDPR Recital 43 says:

Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.

So one is not only deprived of the possibility for separate consent for non-essential personal data processing but is even forced to accept the policies of multiple legal entities. I wonder where is the privacy in this privacy policy.

1. One of the people who fixed a bug which I reported some time ago has shared my personal details in the form of credit (assuming that this is public data and obviously with good intentions but without asking me). Unfortunately through kernel.org now my name and email address are on thousands of pages, copied/mirrored on multiple websites, crawled, indexed, combined with other data and used in who knows what context now or in future. To that I got the suggestion to try to contact each domain which has a copy of the data (and I don’t even know which are those domains). Even if it was possible, not every domain has contact email published. Even if they have and if they reply - they can argue that their system is automatic and they have not done anything deliberately. In best case I would get a shrug. I do appreciate that the developer is sorry for doing it but unfortunately that doesn’t help at all.

One of people who replied in my admin@ case said:

This was merged into the Linux master branch, so there is no chance to fully remove it from the world.
Merge tag 'firewire-fixes-6.8-rc7' of git://git.kernel.org/pub/scm/li… · torvalds/linux@04b8076 · GitHub…]

I do not think, immutable git history was considered in GDPR design.

however according to GitHub’s terms:

3. Conduct Restrictions

While using GitHub, you agree that you will not under any circumstances:

…]

• violate the privacy of any third party, such as by posting another person’s personal information without consent.

After commenting on all these issues in the ticket I got a reply in it:

So your inclusion of that information just adds noise to the discussion from the point of view of the volunteers who will be taking care of the parts of this request they can deal with.

I don’t blame you, but would discourage you from adding too much noise to this request - in order to fulfil you’re request many volunteers are going to have to spend non-insignificant amounts of their limited spare time to take care that your data is removed. If they’re distracted by additional irrelevant information, that will not help the timely processing of your request.

I don’t know why the info which I added to explain that the policies and tools need fixing is considered irrelevant but as it seems the main accent is on the request for erasure, not on fixing things and making them long term good for everyone.
[/list]
[/list]
I am so baffled that I have no words to explain what I am thinking right now.

[hendersj]

On Fri, 05 Apr 2019 13:46:04 +0000, heyjoe wrote:

> I am so baffled that I have no words to explain what I am thinking right
> now.

I would recommend contacting the board for answers to your questions.
IIRC, it’s board{at}o.o.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C