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

[Kevin Krammer]

On Sunday, 2012-01-15, Dan Armbrust wrote:
> > Hmm. Most software with autocompletion support does that. E.g. browsers,
> > email programs.
> 
> They also ask your permission first.

Interesting. Neither Konqueror, Firefox, KMail or Thunderbird have asked me 
whether I wanted to store form data.
Can you attach a screenshot of an application asking that?

> And they have an off switch.
> And, they definitely don't autocomplete fields which are know to
> contain private info - aka - passwords.  Unless you go through another
> dialog telling it to remember the password.  And they give you a menu
> option to clear it.  And, most browsers now have a "don't remember
> anything" mode.  Okular has none of those.

Right, hence the recommendation for lobby for an implementation doing that.

> > However I don't see any facts supporting the claim of "virus like
> > behavior".
> 
> Hiding users data without permission and without the users knowledge
> certainly is virus like behavior.

No, virus behavior is attaching itself with the purpose of distribution and 
spreading.
I don't think Okular is doing either.

> If they didn't click save, you
> shouldn't save.  Its pretty simple.

Well, even some document creation applications are moving to an autosafe 
approach. I am not aware of any application with autocompletion fields which 
asked whether to save the autocompletion data.
But again my own experience is limited to the applications I use, which KDE 
and Mozilla programs.

> > I would recommend lobbying for secure storage of form completion data
> > like other form completing programs do.
> 
> I doubt it would help.

I wouldn't be so sure. Securely storing form completion data is what lots of 
other programs do, so find it likely that moving from a plain text storage to 
an encrypted storage would find support especially among users of that 
features, while asking for removal will not.

> The feature is so mis-conceived from the get-go that it serves almost no 
purpose.

Hmm. I haven't used Okular's implementation yet but generally I find form 
completion support to be rather useful. I used it all the times when filling in 
web forms or completing email addresses.

> There is almost no point in
> storing form data for Form A in randomly named File B.

Right, hence the suggestion to ask for an implementation using standard form 
completion storage solutions, e.g. on KDE that would be KWallet.

> If you even
> rename file A, Okular gets confused and can no longer associate the
> data from File B with Form A.

Right, using URIs works better for web sites. File A's SHA1 hash might be 
sufficiently unique though.

> Don't even think about trying to sent
> Form A to another person... it doesn't work.  The only way it could be
> properly implemented is to store the data in the actual PDF file,
> where it belongs.  But that is hard.  So it seems unlikely that it
> will ever be implemented in the near future.

Right, I would consider that an additional feature.
Treating the current document more as a template for creating a new document.
Such a feature should probably deploy explicit saving since it changes the 
document at hand.

> The only sane thing to do is to turn the feature off.  At least by
> default.  At least give the user some control over it.  Which I
> suggested 2 years ago.  And here we _still_ are.

My guess is that asking for deactivation or removal of a feature cherished by 
other users and found in other form displaying programs will always be met 
with more resistance than asking for an improved implementation, e.g. how 
browsers do it.

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/20120115/0f4c0440/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.