[Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/

[Dan Armbrust]

> Kevin Krammer
> Weird, I seem to have backed up my email and browser form completion data
> without actually knowing where these programs store them.
> But maybe Okular's data is so different that I would escape the same backup
> procedure that work for other programs. Time will tell.

Go ahead.  I challenge you.  Fill out a random PDF form using Okular.
Make a backup of said filled out form.  Now, lets see you open that
backup copy with the data fields in tact, on another computer.  Maybe
better yet.  Task your mother or father with this if they are
available.  Lets see how they do.

As far as other programs documentation... hmm, let see.  This list
took about 20 seconds to find:
https://support.google.com/chrome/bin/answer.py?hl=en&answer=142893
http://support.mozilla.org/en-US/kb/Form-autocomplete
http://windows.microsoft.com/en-US/windows7/Fill-in-website-forms-and-passwords-automatically-in-Internet-Explorer-9

Show me where Okular has documented this.  (good luck)

> If you say so. My experience suggests that people do quite well understand
> that anything not explicitly saved does not alter an opened document.
> I believe that some people even rely on that, e.g. temporarily changing
> something (e.g. for printing) and then closing the program to ensure a kind of
> complete "undo".

Umm... which is your argument?  That it is saved, or that it isn't?
Because if the user didn't click save, Okular shouldn't store the data
anywhere.  But it does.  And if the user were to use the "save as"
button, they would expect that to save their data, when in fact, it
doesn't.  And your notion of having a complete "undo" doesn't work
with Okular either.  Because if you open a form, there is no
"temporarily" changing anything.  As soon as you change a field, it
saves those changes to disk.  There is no "undo" via closing the form
without clicking save the way any normal user would expect it to work.
 That is my biggest concern with how the feature works now.

User opens up a PDF file from their flash drive on a computer.  Fills
in some fields.  Prints it.  Closes the PDF without ever clicking
save.  The user would expect that the data that they typed in should
not be saved anywhere.  Yet, Okular just stored it away on that
computer.

And X days later, when someone else shows up with a PDF file that has
the same name, Okular will just dump the previous persons data
directly into their form.

>> That was why I suggested just shutting it off.  Or redirecting it to
>> /dev/null.
>
> That second suggestion makes little sense now, does it?

Actually, it still makes perfect sense.  If you don't like that
suggestion, there are others that are just as easy:

Add a simple question (remember your answers for these fields yes/no?),
Move the file storing location to be the folder that contains the form
being opened... (and oh, by the way, if that location happens to be
the system temp folder, disable the feature),

They should default to the most secure, least surprising behavior
unless the user requests otherwise.  The principal of least surprises,
as it were.

Because I was sure as hell surprised when I found my tax return
information magically re-filling a blank form I had just downloaded,
when I _knew_ that my filled out tax form was stored in an encrypted
volume that wasn't even mounted at the time.

The "feature" is a disservice to the users of Okular as the
maintainers have no notion of handling users data safely and properly.
 And given the type of data that is frequently entered into PDF forms,
that it just unacceptable.

>> But the maintainers of Okular refuse to even talk about
>> it.
>
> Hence the suggestion of trying a less confrontational approach. Obviously
> approach used in the past didn't work out so well.

About 5 other people have reported the issue in less "confrontational"
ways in the past 2 years.  They were all ignored.  And I'd hardly call
my approach confrontational.  More, shear amazement that they don't
seem to be able to grasp that their design of this feature was so bad.

After I got over my initial shock, I've posted several followups with
reasonable, low work suggestions which could alleviate the issue.  But
they are too busy feigning "insult" to want to do anything about it.

I appreciate that you are willing to talk about the issue.  I think
you even agree that its not a good way to handle users data.  I was
hoping that someone from KDE would recognize a security issue when
they saw one, and ask the okular maintainers to spend the 15 minutes
it would take them to put in something, anything, to address the
issue.  Its not a question of developer resources.  Many of the
potential fixes are dead-simple trivial.

An end user like me just shouldn't have to work this hard to report a
security / data privacy issue.  The handling by the Okular developers
has been like a 2 year old with a temper tantrum from the beginning.

This bug, for example:  https://bugs.kde.org/show_bug.cgi?id=267350
has had no involvement by me.  3 different people have nicely noticed
and reported the issue.  And a maintainer won't even comment.  Much
less think about addressing the issue.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.