Re: [Okular-devel] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
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.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
Description: This is a digitally signed message part.
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
[Red Hat Install]
[GIMP for Windows]
[Red Hat Development]