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 Tuesday, 2012-01-17, Duncan wrote:
> Kevin Krammer posted on Sun, 15 Jan 2012 18:08:31 +0100 as excerpted:
> > 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?
> I don't know about asking, but it's a preferences setting.
I was mainly puzzled by the fact that there are obviously applications asking
for it versus just being a switchable preference.
Would be interesting to see how that question looks like.
> There's also
> the "private browsing" or whatever the app decides to call it, mode,
> where everything (cookies, form completion, browsing history, etc) is
> forgotten, tho that normally has to be specifically toggled on.
Indeed, hence the suggestion to pursue a form completion data handling similar
to those examples.
> >> 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.
> Actually, I wonder if this idea could get a bit more traction in view of
> the new ksecrets thing?
Unlikely, this is just a new implementation of already existing functionality.
The currently proposed KSecret API is also still a bit weird ;-)
> That's where I'd try to take it at this point, since ksecrets IS new and
> shiny and fascinating! =:^)
Not from an application developer's point of view, sorry :-)
> >> > 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.
> It seems he's using "virus" not in the technically narrow "virus" sense,
> but in the broader "malware" sense, inclusive of trojans, etc.
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.
> okular really can't be considered a virus in the technically narrow sense
> (as you pointed out), certainly, the argument here is that it's behaving
> like a trojan, so if one accepts an extremely fuzzy definition of virus
> that really means something more like malware in general.
I' am still not convinced. How does Okular behave like a trojan? What is the
function it is pretending to do in order to hide the function it was designed
to do and which function would that be?
> >> > 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.
> Same here, particularly with the new ksecrets angle to explore. If I
> were an okular dev I think I might jump on this one just for the
> opportunity to play with that! =:^)
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.
> BTW, Kevin, any wild guess or informed opinion on how long kde4 will
> continue with the semi-annual feature updates, given kde5 in the wings?
My guess is at least 4.10 but I find even 4.11 likely.
An important fact here is that while during "KDE4" times the split of names or
terminology around KDE products was mostly cosmetic, "KDE5" will very likely
make actual use of the new disambiguation.
The current work on KDE frameworks is not only a matter of making KDE
libraries less interdependent, it also serves as a starting point for
separation of development cycles.
I.e. it is almost certain that there will be a release of KDE frameworks
before any of the KDE application products are rebased onto them.
Some application developers will of course starting to port earlier, e.g. when
technolog preview releases become available, but that will largely depend on
specifiy API usages of those apps (applications using fewer APIs or only very
core APIs can expect fewer changes between a TP release and the final one).
> Of course as others have said, I expect kde5 to be a rather minor deal
> compared to kde4, and that it'll be handled rather better.
An extremely important difference IMHO is that while there will be some changes
in implementation (e.g. due to functionality previously only available through
KDE libs moving into Qt), we have to remember that communication channels will
remain compatible this time.
KDE software has for a long time been designed with collaboration between
programs as a center piece, e.g. using services for common problems,
delegating certain functionality to other programs.
At the 3 -> 4 transition the transition from DCOP to D-Bus created and
unbridgable gap between old and new, thus requiring new services to be running
for new applications to use.
The next transition doesn't have this problem since the communication
framework is the same, e.g. a frameworks 5 based application wanting to
inhibit the screensaver will be able to do so on a kdelibs4 based workspace as
well as on a frameworks 5 one.
> Does that sound reasonable, or are there bad assumptions there, such that
> we're likely to see a 4.11 and 4.12 at the current schedule, or OTOH,
> won't get to 4.10?
Sounds reasonalble, though I am kind of expecting at least 4.11 to happen as
> Any guess on wayland support? Maybe not for 4.x but for 5.x? If so, do
> you think it'll make 5.0?
Not for 4.x since this requires support in Qt and it is unlikely that
something as major as a new rendering/windowing system will be introduced into
Qt4 at this point.
However, this is one of the instances where talking about KDE as a single
product does not make sense in combination with a version number.
I.e. it could very well be that wayland support is not available yet when
KDE's library product(s) are released for the first time but could be available
when KDE's workspace product(s) are.
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]