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

Kevin Krammer kevin.krammer at gmx.at
Mon Jan 23 17:55:11 GMT 2012


On Monday, 2012-01-23, Dan Armbrust wrote:
> > If storing data to prefill form fields would be considered malware,
> > people would have a hard time browsing the Internet since malware
> > removal tools would have deinstalled all incarnations of browsers
> > already.
> 
> One minor point.  A PDF viewer is not web browser.  Its much more like
> a document editor.  That is how users expect it to behave - like other
> document editors.

I disagree. A PDF viewer is primarily a viewer (might be a reason that's part 
of the name). Due to all the interactivity added to the web IMHO even more so 
than browsers.

Even Adobe has a different product for editing PDFs. Their viewer is called 
"Adobe Reader" for a reason.

> Don't you suppose folks would find it a little unsettling if
> LibreOffice just silently saved anything you typed into it, without
> asking, in a hidden location, every time you even opened a document
> with it?
> 
> Because that is exactly what Okular does.

And what every browser and other programs with form like fields do.
E.g. my email program saves recently used email addresses, I heard other email 
programs to that as well.

> I only brought the webbrowsers into the conversation to point out that
> other software that stores user data for auto-form filling always
> gives the user control over said data.

And I brought web browsers into the converstation to point out that form 
completion is a widely accepted feature inspite of it requiring storing user 
input detached from the actual document.

And I believe I wrote several times that their implementation of said feature 
should be considered a role model, i.e. allowing to clear cached input and/or 
allowing to deactivate.

> >My take is that asking for a more secure implementation of a feature,
> >especially since there are role models for how that works, has magnitudes
> >more chances of being considered worth while than asking for removable of
> >a feature that is considered useful by others inspite of not ideal
> >implementation.
> 
> And another point.  Nobody has stepped forward to defend the current
> "feature".

And why would that be neccessary?

> Because the "feature", in its current form is almost
> completely useless.  The only possible thing I can think of that it
> does is not lose your work if you close Okular, go out to lunch, then
> come back and continue working.  But storing your work - aka - filled
> form data for any significant amount of time?  No.  Its useless. 

Interesting. As I said I've not used Okular to fill forms but I find that 
feature to generally very useful when filling web forms.

I am actually pretty certain I would find it useful for PDF forms as well. I 
have such a form for reimbursement request for certain expenses last time I 
had to use it Okular couldn't fill forms yet. I would certainly find it an 
improvement not to have to retype name and account details all the time.

But I can see this being of limited use if you only ever fill forms only once 
in your life time.

> You don't even know where it stored it.

Where does your browser store its completion data?
How well documented is that location

> You can't back it up.

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.

> It doesn't even _tell_ you that it didn't actually put the data into
> the form.  You won't find out until you send the document to a
> coworker, and they tell you it is blank.  The only thing this feature
> will lead to is a horrible user experience.

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".

> That was why I suggested just shutting it off.  Or redirecting it to
> /dev/null.

That second suggestion makes little sense now, does it?

> 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.

> So,  here we are, 2 years later, with it still behaving in the
> same brain-dead way.

From what I gathered it is behaving quite ok. Sure, it could do better on the 
security/privacy front by incorporating features found in browsers' 
implementations but it seems to do its purpose of putting text into empty 
fields based on previous user input to said fields.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20120123/c4181d1e/attachment.sig>
-------------- next part --------------
___________________________________________________
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.


More information about the kde mailing list