Personal data in the BugTracker

[lelldorin]

Based on the discussion about the possibility of personal, security-relevant, data in the output files of the system programs / scripts (ifconfig, listdev, listimage, listusb, sysinfo, syslog, dmidecode ...) the question arises:

How secure is this information on the BugTracker server?

The developers are advised to place these output files in the bug report in order to be able to process the error better.

As a result, various attachments on the BugTracker server, which may contain personal, security-related information about the user, can now be viewed by every logged-in (also unregistered?) User.

What can be done to ensure that this data is secure?

Can you create a script instead of the various output options that only contains the data that are not personal, security-relevant?

The ordinary user must be made aware of this risk. For example, through the info before uploading, that you should make sure that no personal or security-related data is included (This will deter many people from doing it at all, but it would be the right way).

References: ​https://discuss.haiku-os.org/t/boot-screen-stuck-at-the-rocket/9273/29 ​https://discuss.haiku-os.org/t/besly-project/1389/46

For this reason I removed my project "BeSly System Analysis Tool" from the internet.

German Original:

Persönliche Daten im BugTracker Basierend auf der Diskussion über die Möglichkeit von persönlichen, sicherheitsrelevanten, Daten in den Ausgabedateien der System Programme/Scripte (ifconfig, listdev, listimage, listusb, sysinfo, syslog, dmidecode…) stellt sich mir die Frage: Wie sicher sind diese Informationen auf dem BugTracker Server? Von den Entwicklern wird angeraten diese Ausgabedateien mit in den Bug Report zu platzieren um den Fehler besser bearbeiten zu können. Dadurch sind jetzt diverse Anhänge auf dem BugTracker Server die eventuell persönlichen, sicherheitsrelevanten Informationen über den Nutzer beinhalten, für jeden angemeldeten (unangemeldet auch?) Nutzer einsehbar. Was kann getan werden damit diese Daten sicher sind? Kann man an statt der diversen Ausgabemöglichkeiten ein Script erstellen welches nur die Daten enthält die nicht persönliche, sicherheitsrelevant sind? Der gewöhnliche Benutzer muss auf dieses Risiko aufmerksam gemacht werden. Zum Beispiel durch die Info bevor hochgeladen wird, das man sichergehen soll, das keine persönlichen oder sicherheitsrelevanten Daten enthalten sind (Dadurch werden viele abgeschreckt es überhaupt zu tun, aber es wäre der richtige Weg).

Verweise: ​https://discuss.haiku-os.org/t/boot-screen-stuck-at-the-rocket/9273/29 ​https://discuss.haiku-os.org/t/besly-project/1389/46

Aus diesem Grund habe ich mein eh Projekt "BeSly System Analysis Tool" aus dem Internet entfernt.

[waddlesplash]

How secure is this information on the BugTracker server?

It is "rate limited" so you cannot download too much at once. But anyone can download any file, yes.

output files of the system programs / scripts (ifconfig, listdev, listimage, listusb, sysinfo, c, dmidecode ...) the question arises:

So, the "personal data" that may be in here is:

• ifconfig: MAC address, network name. Your MAC address will usually identify what kind of device and maybe even when it was manufactured (however that info we usually include in the ticket), and once someone knows it, they can "find" you if you ever happen to connect (or, in some circumstances scan for) a network in their vicinity.

• listdev: Lists PCI IDs. Unless you have some sort of "secret" PCI hardware, this usually will be the same as a listing from the manufacturer's website, so not that interesting.

• listimage: This will show what programs and drivers you have loaded; what programs may be slightly revealing of your habits, but usually we ask people to include a "grep" portion on this line as its output is often unmanageably large otherwise.

• listusb: Lists what USB devices you have attached; I think that is obvious...

• sysinfo: Will contain most of the same information as "ifconfig" if you are connected to a network, as well as listdev, listusb, and what kernel drivers you have loaded. It may (under very rare circumstances) have more information than that, I think, but I can't remember specifics.

• dmidecode: This one does include serial numbers for your hardware, usually, which may be more revealing than the MAC address. However, I don't know where we have asked users to provide it?

It is worth noting that the FAQ pages detail some of this, at least for syslogs; and Linux and other distributions ask for "dmesg" when diagnosing problems, which includes all the information our syslog does (including MAC address, etc.) So, I think this is OK; users who particularly care can "anonymize" their information (and indeed some have when submitting syslogs) by deleting the network name and MAC address from them.

For example, through the info before uploading, that you should make sure that no personal or security-related data is included

The MAC address, local network name, and local (NOT external) IP address are the most "personal" this data gets; however, I don't know if this is even considered "personal" data (rather "identifying" data.) At most your username might appear there, but one's username appears when submitting tickets, too...

Security related data is not placed into any of these files under normal circumstances; if it does, usually something has gone wrong.

Can you create a script instead of the various output options that only contains the data that are not personal, security-relevant?

It may be possible to craft a script that deletes MAC addresses from the syslog. However, if these are the only issue, then I don't know if it is really an issue at all worth adding to the general guides. Some (not even most, I think) of the same concerns of sharing your "dmesg" from Linux apply to Haiku.

For this reason I removed my project "BeSly System Analysis Tool" from the internet.

I think this case was fundamentally different, as extrowerk wrote in his initial complaint:

So the program:

• collects unnecessary information
• doesn’t warn the user about this
• and it doesn’t try to remove any of this in any kind of automated way

Extra point: you publishing the collected data on the internet

Submissions to the Haiku bugtracker are manual, never automated (there is a ticket about writing an automated crash reporter, Firefox-style; i.e. with user consent each time, but that is not yet implemented), and we always request certain things that the user collects manually (like the syslog.)

We do not (and cannot) collect any of that automatically; if users do not want to provide it, then they do not have to; and the users of course in uploading it know that they are uploading it "to the internet."

[pulkomandy]

There is a difference between your tool, which collects this information automatically without the user knowing what exactly will be collected and where it will be sent, and this bugtracker, where we ask user to manually run some command and send us the output.

This is an important difference. I think it makes this bugtracker compliant to the GDPR, by collecting information that is relevant to the work being done, and collecting it only if the user agrees to do so (by attaching specific files to their tickets). We keep the data forever, because an history of bugs we fixed is an important reference for us.

We will comply to requests from people who want their data deleted, should this happen. It's easy to identify who sent what (because attachments are associated to an user account) and to delete specific files from the bugtracker. And of course, we comply with the right for users to access and even delete their own data, which is easily doable with a few clicks in Trac.

[miqlas]

FYI: some programs dumps plenty information in syslog, for example Transmission, which dumps all the active torrent name in syslog at start.

Is there any plan to modernize the logging facility in Haiku? Per application log would be nice to have with a GUI program to show/filter/export just like the Console application in Mac.

[pulkomandy]

One can use BeDC (Be Developer Console) for BMessage based logging, but it is not currently wired to the syslog() API. And it would need an x86_64 version and it's a closed source app.

I'm not sure Transmission for Haiku should log to the syslog at all. What's the point? That's good when you run it on a Linux server, but on your desktop machine?

[miqlas]

I run Transmission demonized, maybe that's why it pushes its log into syslog.

[lelldorin]

Replying to pulkomandy:

There is a difference between your tool, which collects this information automatically without the user knowing what exactly will be collected and where it will be sent, and this bugtracker, where we ask user to manually run some command and send us the output.

This is not true, we get the systeminfos when you start the app and Display it. It only stored then user save them lokal. And them the user will send it to us to add to the Hardware data list he need to do this using email. There is no automatically upload and the user can look in any file.

I know that the bug tracker is to help the user, but it is not really a diffent way, because private data is private data.if here or there else.

Our project started to be a help for haiku devs to create drivers, better bug reports and i add many informations to collect by tips of our devs. And on the other side to create a useable hardware database for haiku in the future.

But i see that many people does not understand this right and does not take a look in the program.

[pulkomandy]

Our project started to be a help for haiku devs to create drivers, better bug reports and i add many informations to collect by tips of our devs. And on the other side to create a useable hardware database for haiku in the future.

But i see that many people does not understand this right and does not take a look in the program.

The GDPR requires to collect only the data that's appropriate, and not more. That's what we do here, by asking people reporting bugs to attach just the info we need. An automated tool is of no help here.

As for the hardware database, you keep saying that, and it is a nice project, yet you still have done nothing to build the said database. So, if you are collecting data without having an use for it, it is in violation of the GDPR. Only when you build such a tool, you can know what information exactly would be needed, and you can define the best way to collect it and why it is useful. Then you can explain that to the users and they can decide if they agree or not.

I appreciate your efforts for this, but I think that by collecting the data first without having the tools to use it, you are working the problem backwards.

[pulkomandy]

I added a note on the https://dev.haiku-os.org/wiki/ReportingBugs page about this. I think that's enough to let people know what they are doing when sharing information here.