Wow, you guys are amazing, thanks a heap!

I would like to test the fix and report back.  HOWEVER reporting this bug revealed something that is of greater concern to me and I will have to fix that first.  Maybe with your help.  Because you as an organization (Document Foundation / LibreOffice) have to understand that there is a deep fault in the way the app collects data, even if it is for a good purpose, and fix data collection accordingly.

Thanks Timur for making me aware of a possible "crash report."  While a crash report can be a good thing, it can also be a data leak.  Bad.

I was not asked for permission before LibreOffice called home at crashreport.libreoffice.org.  There are many good reasons for this kind of telemetry, and I have no doubt that LibreOffice means well.  HOWEVER, there is an overriding reason to ask for user consent first.  I am a lawyer.  I could have been working on highly confidential information,  What if a memory dump is included in the crash report, and that confidential information is in the memory dump?

I will not download a piece of software from https://dev-builds.libreoffice.org/daily/ when I know I cannot trust it to do the Right Thing.

The fact that the competition is worse ("implied" consent buried into Microsoft's licensing terms) is no justification for not doing the Right Thing. 

I am happy to contribute in the form of a bug report; and even a *controlled* dump and backtrace; and even continuing on to using bisecting builds from repository until the faulty commit is identified; and even attempting to contribute a patch.  HOWEVER, I am not willing to compromise on my professional duty of confidentiality.  Nor am I willing to compromise on the right of each user to their own data confidentiality.

Please point me to 
(1) a preference to prevent the collection and transmission of crash reports 
(2) an exact description of how crash reports are generated and what data is gathered and how the data is processed, transmitted, stored, destroyed
(3) instructions how to build LibreOffice from source for my own machine

Y: I understand your point of view, I just think you should submit a new bugtracker (enhancement type).

Michael: thought you might be interested in this one since it concerns legal things.

Thanks, Julien.  I agree with you about a new bugtracker and submitted Bug 128255.  My intention was to submit one when I have enough knowledge of what I write about.  I do not know: WHAT, HOW, WHEN is collected.  All I know is that there was an attempt to call home without me having enough information to consent to it.

But then, I recalled an important principle of successful open source: release early, release frequently.  So I "released" my thinking there.

Thank you also for connecting with Michael / legal.  I am more than willing to volunteer the time necessary to work things out and help make LibreOffice better for the public good.  No intention to take the issue of informed consent to telemetry as a legal battle.  For me personally, the solution if LibreOffice does not do the Right Thing is simple: fork the source code, maintain patches to remove the offending code, roll my own.  But it is preferable to contribute user time and effort upstream.

I can reasonably prove that some fundamental choices made by the IT industry as a whole in the last 10-15 years are bad.  Many of them also cause harm.  Telemetry without informed consent being the one in cause here and now.  I am also of the opinion that the forum to solve this is anti-trust, not product liability.  And I am of the opinion that a software publisher can do the Right Thing from the get go and avoid the whole controversy: no data collection without express and informed user consent.

My request for instructions to build LibreOffice on my own machine still stands.  I had to recently upgrade after my old PC died, and my glorified typewriter now has more CPU power than it needs.  I am almost finish setting it up as "homelab", with my desktop being one of the virtual machines.  Once my setup is robust, up and running, maintaining a VM to build and test such an important app as LibreOffice is something that will cost me little effort and that I will gladly do, as a little token of appreciation, and because sharing is the Right Thing to do.

Thanks for the pointer Julien. Y - we take people's privacy seriously, of course.

> I was not asked for permission before LibreOffice called home at
> crashreport.libreoffice.org.  There are many good reasons for this kind of > telemetry, and I have no doubt that LibreOffice means well.

That is un-expected; I would imagine that you would get a dialog (something like the attached) at the next restart that prompts you to send the crash-report. People tend to have a habit of clicking through those dialogs - if you're at all concerned don't send the report

> HOWEVER, there is an overriding reason to ask for user consent first.
> I am a lawyer.  I could have been working on highly confidential
> information,  What if a memory dump is included in the crash report,
> and that confidential information is in the memory dump?

I would not expect to see any significant document data inside the breakpad / stack.

> The fact that the competition is worse ("implied" consent buried into
> Microsoft's licensing terms) is no justification for not doing the
> Right Thing. 

Agreed. Then again contributing crash reports is extremely helpful for the project.

> (1) a preference to prevent the collection and transmission of
> crash reports 

The setting is:

officecfg/registry/schema/org/openoffice/Office/Common.xcs-      <prop oor:name="CrashReport" oor:type="xs:boolean" oor:nillable="false">

Tools->Options->Advanced->Open Expert search for 'CrashReport'

> (2) an exact description of how crash reports are generated and what
> data is gathered and how the data is processed, transmitted, stored,
> destroyed

I'm afraid you'll have to dig this out yourself, although Markus may have some more details easily to hand.

> (3) instructions how to build LibreOffice from source for my own machine

That's easy - instructions are easy to find from Google - but I'll post them here for you this once: https://wiki.documentfoundation.org/Development/How_to_build

There is a configure option for breakpad support: --enable-breakpad which defaults to off (it seems). Poke at:

./desktop/Library_crashreport.mk
./desktop/source/app/crashreport.cxx

and

git grep -5 ENABLE_BREAKPAD

I hope that helps =)

Created attachment 155155 [details]
a picture

I attach a snapshot of the dialog from glade NB. several strings are shown at once (for ease of translation reasons) that are from later / conditional steps in the flow through the dialog.

Created attachment 155156 [details]
glade dialog picture - note the associated comment.

I attach a snapshot of the dialog from glade NB. several strings are shown at once (for ease of translation reasons) that are from later / conditional steps in the flow through the dialog.

Thanks for your time and explanations, Michael.

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.


> Tools->Options->Advanced->Open Expert search for 'CrashReport'

Empty.  Both Ubuntu and Windows versions.

IMHO important enough to be in ->General, not in ->Advanced.  And with a proper explanation in very close distance (mouseover/link?)


> contributing crash reports is extremely helpful for the project.

Agree.  This is why I try contribute when I can; and this is why I am advocating for making the process a respectful and encouraging one.  Empowerment encourages.  Being told that "we know what is good for you and the rest is visual noise" is discouraging.  Further remarks on Bug 128255.

The key words to *contributing* are KNOWINGLY and VOLUNTARILY.


> I would not expect to see any significant document data inside the breakpad
> / stack.

Happy to rely on your expectations in the general context; however, when client information is in the documents being processed, I need reliable certainty, not "expectations."  Nothing personal.  Better be safe than sorry.


> > (2) an exact description of how crash reports are generated and what
> > data is gathered and how the data is processed, transmitted, stored,
> > destroyed
> 
> I'm afraid you'll have to dig this out yourself, although Markus may have
> some more details easily to hand.

Happy to dig this out myself and to contribute a text for public consumption.  You have given me enough hints where to start.  Not sure when I can fit this into my time planning.  In the meanwhile, I do not have the necessary information to consent to a crash report and  crashreport.libreoffice.org is now blacklisted on my network.  Sometimes, the path of least resistance is the temporary solution that becomes permanent.


> > (3) instructions how to build LibreOffice from source for my own machine
> 
> That's easy - instructions are easy to find from Google - but I'll post them
> here for you this once:
> https://wiki.documentfoundation.org/Development/How_to_build

You are assuming that I am using Google.  A stereotypical example of what has gone wrong in the IT industry.

Anyway, thank you very much for your help.  Much appreciated.

> I never saw the Crash Report Dialog.

Then surely you didn't file the crash report we are talking about. I imagine someone else did. Timur - do you have a link to the crash report in question - it might help clarify things.

Beyond that - if people have genuine legal concerns, bugzilla is not the place to air them - please contact legal@documentfoundation.org and please be aware of the -extraordinary- expense in engineering time it takes to prove a negative. We believe we are doing this right, having concrete, technical evidence that we are not would be extremely helpful - again on that list. 

As for other questions about how we handle bugs - those probably all belong on the QA list or in a QA call, no doubt we can improve our processes: but from my perspective getting bugs closed and keeping the set of things we focus on reasonably small is really important.