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

[Kevin Krammer]

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.

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

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

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/8c63cc2a/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.