Bug 128255 - No dialog shown, still crashreport uploaded to TDF
Summary: No dialog shown, still crashreport uploaded to TDF
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-19 18:42 UTC by Y
Modified: 2020-06-11 03:54 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Can't reproduce it in LibreOffice 6.3.3.2 (2.99 MB, video/mp4)
2019-11-12 12:33 UTC, Xisco Faulí
Details
I can't reproduce it in LibreOffice 6.4 alpha1 (2.53 MB, video/mp4)
2019-11-12 12:34 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Y 2019-10-19 18:42:59 UTC
Description:
This is a collateral to Bug 128232.  Bug 128232 is open source working at its best, with a fix within less than 24 hours of the bug report.  However, in the process of reporting the bug I learned that LibreOffice called home (crashreport.libreoffice.org).  I understand it is with good intentions.  I am still trying to figure out the details.  I believe that telemetry without consent is not the Right Thing to do.

Please help me understand, and please help me help the Document Foundation / LibreOffice become more respectful of data privacy.


Steps to Reproduce:
1. crash LibreOffice
2. monitor your internet connection

Actual Results:
LibreOffice calls home without warning.

Expected Results:
LibreOffice should ask for user consent, or crash silently.



Reproducible: Always


User Profile Reset: No



Additional Info:
User consent has to be (A) express; (B) informed; (C) meaningful.

(A) Express.  Put a dialogue in front of the user every time consent should be sought.  Consent for telemetry at installation is good.  If consent was granted the first time, repeating the request on significant changes and upgrades as a reminder of the original consent is better.  For the user in a sensitive environment (lawyers, dissident journalist, HR employees, any person that requires confidentiality for whatever reasons) asking to reaffirm consent at every start of the application makes sense.  Ideally, the express consent should be time-limited and revert back to no data leak permitted, with the choices: (a) until the next time the user restarts LibreOffice; (b) until the next LibreOffice upgrade/change; (c) for a fixed (arbitrary) time period of a year; or (d) forever.

(B) informed.  describe in clear words what triggers telemetry, and what kind of information is sent.  To the user, a summary with links to documentation on the Document Foundation's webpage should be sufficient.  From that webpage, link further down into the exact points in the code / repository where the data is collected and where the telemetry is triggered.  When I started researching crashreport.libreoffice.org, I came across https://github.com/mmohrhard/crash -- too much into details for me to understand what is going on.  I also came across conspiracy theories that are even less useful.  The software publisher should fill the void and prevent it from being filled by conspiracy theories.

(C) meaningful.  even after a user has expressly consented, there are circumstances under which refreshing the consent makes sense.  For example, when the data leaked out of the user's control contains information from the documents being edited, the user may need to consider the nature of the document being edited to arrive to a meaningful consent.  A user consenting to telemetry while editing a party invitation can reasonably deny consent when editing a list of employees with salaries and other confidential data.

Please build software that can be trusted.  Thanks for listening.
Comment 1 V Stuart Foote 2019-10-19 21:17:55 UTC
User is prompted on Crash recovery if they explicitly want to submit the Breakpad generated minidump crash report. No personally identifiable details are included beyond the cURL post details of the originating IP.

User has explicit control over "Collect usage data and send it to The Document Foundation"--it is disabled by default on installation. It is only enabled by user action in the Tools -> Options -> LibreOffice General panel, or by setting an environment variable "LO_COLLECT_USAGE" true. There is no personally identifiable information beyond source IP and system network name, otherwise it is just tallys of command/control usage per document per session.

IMHO the user is sufficiently advised, abd providing more complex user notification in the GUI is _visual noise_. IMHO => WF

Otherwise, TDF Project and LibreOffice privacy statements (which admittedly do not address crash reporintg and usage data) are the purview of the TDF Board and their legal advisers. Discussion on appropriate ML no in the BZ --> MOVED

For BoD -- if you take this up could you provide a suitable link to the discussion.
Comment 2 Y 2019-10-21 00:18:14 UTC
That was quick.  Forgive me for being insistent, you, Mr Foote, are wrong on two counts, and while I respect your opinion, I find it to be the opposite of humble.

(In reply to V Stuart Foote from comment #1)
> User is prompted on Crash recovery if they explicitly want to submit the
> Breakpad generated minidump crash report.

I never saw the Crash Report Dialog.

To compare, I fired up a Windows VM, installed LO's from the LO website (6.3.2.2) and triggered the bug.  No such dialog there either.


> No personally identifiable details
> are included beyond the cURL post details of the originating IP.

(_1_) Too narrow definition of data collection.

The starting point to any discussion about data collection is: the user owns the data.  You are not at liberty to collect it.  Whether it contains personally identifiable details or not is irrelevant.

Even if personally identifiable details were the issue:

(_2_) Too narrow consideration of what are "personally identifiable details" and where they are found. 

Real life examples:
(a) LO crash while I write a letter to police requiring disclosure of an accident report that implicates my client
(b) LO crash while I am editing a standard template with no client information.

I want to contribute to LO.  In (b) I am happy to file a bug report (see Bug 128232) and contribute forensic/statistic data while in (a) I do not want to see a single bit leaving my LAN, or even my PC.

I understand the importance of crash reports and of usage statistics.  I am all in favour of contributing them.  The key words is *contributing*.  KNOWINGLY and VOLUNTARILY.


> User has explicit control over "Collect usage data and send it to The
> Document Foundation"--it is disabled by default on installation. It is only
> enabled by user action in the Tools -> Options -> LibreOffice General panel,
> or by setting an environment variable "LO_COLLECT_USAGE" true.

Sensible defaults.  However, this control is as "explicit" as putting a green and a red pill in front of the user and telling them that one is "good for them."  This is a disenfranchising approach, typical of the bitten fruit.  Please make an effort to explain the control, and while it may be "visual noise" for you personally like the pill's information sheets are "visual noise" for a trained chemist, please understand that not all users are as smart and knowledgeable and enlightened as the rocket scientist you seem to be.


> just tallys of command/control usage per document per session.

Not what was told to me in the case of a crash report.


> IMHO the user is sufficiently advised, abd providing more complex user
> notification in the GUI is _visual noise_. IMHO => WF

Even without knowing what WF stands for.  There is a lot of visual noise.  Providing the user with a reasonable explanation of what a control does is not visual noise.  Popping up a request for a donation on startup of a version update is visual noise.  Showing off that a developer can program a computer to write Today and "Yesterday instead of 2019-10-20 and 2019-10-19 is visual noise.

In Bug 128232 Michael Meeks expressed the opinion that "contributing crash reports is extremely helpful for the project."  In this bug, I am showing the project that there is at least one shortcoming in how crash reports are collected that disenfranchises the user.  The questions to the project is:
* do you want to elicit more user feedback? or less? 
* And do you want the project to be better than the proprietary competition that buries consent to data collection in the general licensing terms?  Or do you want user to consider the project as adversarial as any modern day proprietary piece of software and run it sandbox and cut off the internet to prevent leaks?

Last but not least: a call for symmetry on the bug tracker.  When a user enters a bug, it stays UNCONFIRMED until a second user CONFIRMS it.  Why is it that a developer, arguably just another user as well, can close a bug without a second user confirming the closing?

Happy Monday!
Comment 3 V Stuart Foote 2019-10-21 03:14:49 UTC
(In reply to Y from comment #2)
Bombarding users with it in the GUI would be an obnoxious and counter productive exercise in political correctness. I don't _need_ to see it, nor do I _want_ to.

From a UX advise and development perspective I advise a strong Wont Fix (WF) for doing _anything_ along these lines in the GUI. 

But there is an EU statutory requirement for the LibreOffice project and TDF Board of Directors to provide suitable advisory as to the specifics of any data collected and its uses. They have not yet done so, and you have raised that issue.

Thank you.

IMHO any such notification should be correctly handled via privacy and usage policy statement(s)--but that is not my nor your choice to make. That is a responsibility of the TDF BoD as advised by counsel, and implemented by the project's ESC.

Resolved => Moved _is_ the correct disposition for this BZ issue.

It is then up to one of the TDF BoD members added to CC to annotate where the discussion occurs.
Comment 4 Thorsten Behrens (allotropia) 2019-10-21 03:49:26 UTC
Narrowing down the scope of this bug report, to be solely about the problem with the crash report.
Comment 5 Thorsten Behrens (allotropia) 2019-10-21 03:50:48 UTC
(the LO_COLLECT_USAGE aspect is not forgotten, digging out the details currently)
Comment 6 Xisco Faulí 2019-11-12 12:33:34 UTC
Created attachment 155737 [details]
Can't reproduce it in LibreOffice 6.3.3.2

I can't reproduce it in

Versión: 6.3.3.2 (x86)
Id. de compilación: a64200df03143b798afd1ec74a12ab50359878ed
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

see how wireshark doesn't log anything...
Comment 7 Xisco Faulí 2019-11-12 12:34:56 UTC
Created attachment 155738 [details]
I can't reproduce it in LibreOffice 6.4 alpha1

I can't reproduce it in

Versión: 6.4.0.0.alpha1 (x86)
Id. de compilación: cc57df8f942f239d29cb575ea5a7cb01405db787
Subprocs. CPU: 1; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

see how wireshart doesn't log anything
Comment 8 Xisco Faulí 2019-11-12 12:36:24 UTC
For the record, I used attachment 152193 [details] from bug 124738
Comment 9 Xisco Faulí 2019-11-12 12:37:14 UTC
Y,
Could you please paste the info from Help - about LibreOffice ?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' once the information has been provided
Comment 10 V Stuart Foote 2019-11-12 14:31:36 UTC
@Xisco, I think you have pretty much quashed this non issue. 

Per OPs comment 2 "I never saw the Crash Report Dialog", meaning the OP never established they'd actually submitted a crash report, or that a Breakpad minidump was even generated on their system for submission. A lingering aspect of reporting for resolved bug 128232

They could of course now run the the crash inducing STR from bug 124738, while Wireshark or similar is running, then parse and provide results as you've done, to replicate your finding.

But point is there is no cURL upload of the minidump without express user release from their system--which is the correct and expected behavior.

Personally I am still interested in the BOD response to adjusting the Privacy notice(s) to cover this, but as Thorsten had adjusted the scope of this issue to be just the upload without notification, this should now be closed either 'Invalid', or 'Insufficient Data'.

Stuart
Comment 11 QA Administrators 2020-05-11 03:45:48 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2020-06-11 03:54:14 UTC
Dear Y,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp