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
Attachment:
signature.asc
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. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
