https://bugs.kde.org/show_bug.cgi?id=411919
--- Comment #25 from flan_suse <windows2li...@zoho.com> ---
(In reply to Nate Graham from comment #22)
> Flan, Would you be able to submit a merge request to implement your idea?
How and where do I submit a merge request? I'm just an end-user that believes
in practicality and usability. :) I'll do it, just need to know the proper
method.
----------
> Caching thumbnails in $HOME when $HOME is encrypted is reasonable.
This makes a lot of sense, but see below where I will try to break down this
"problem". This is not so much a technical issue (though it requires a
technical solution in the future), but rather this is a practical issue, with
some psychological and use-case elements involved.
----------
>However I'm still
> in favor of one of the original ideas which is to cache the thumbnails
> inside the encrypted volume itself. I think that solves all potential
> problems, if it's technically feasible.
This might not be ideal, and I would argue against it, for four reasons:
1) The user's $HOME is almost always going to be on the faster media (SSD,
NVMe, Optane, etc), whereas an encrypted volume is commonly on a slower media
(secondary HDD, external USB drive, USB stick, etc).
2) The user's $HOME is where we expect cache to be consolidated, and it's the
main "driver" of daily work. I'd assume most users that utilize encrypted
volumes use them nearly exclusively on their *own* system, rather than on
someone else's system. It can complicate things if KDE is an outlier in that it
caches thumbnails on the folder/volume itself (where the media resides), while
other desktop environments continue to use $HOME/.cache consistently.
3) This can be bad for those who use NAS servers or network shares. Not only is
KDE *unaware* of whether or not the photos/videos live on an encrypted volume
("Is the SMB / NFS share residing on an encrypted location on the server? No
idea!"), but if it were to assume it does, it's now storing cache'd thumbnails
on a network share? We're now losing performance and I advise against trying to
write on a network share or NAS server "under-the-hood" like that, especially
for media archives, etc.
4) It's expected that $HOME/.cache will always have read-write access for the
user account. However, offloading the caching of thumbnails to an *external
location* gets even more complicated if it is: write-protected; or mounted
read-only; or does not have write permissions; etc.
I'm not trying to poo-poo any idea nor come off as a pessimist. I'm just trying
to cut off user experience pitfalls *ahead of time*. If it sounds like the
above reasons make it seem like there are too many complexities involved,
that's because there *are*. Once again, pursuing such a workaround might risk
more problems than solutions.
----------
Here is the original problem: "As a user, I want to safeguard against sensitive
photos/videos dumping their thumbnails from an encrypted storage onto a
non-encrypted storage."
This should not be confused with a friend or adversary in possession of the
device. Once it is in their hands, none of this stuff about caching thumbnails
matters.
This should not be confused with using the encrypted device on *someone else's*
computer. Why? Because the friend/stranger could be using *any* OS, distro, or
desktop environment on their own computer.
This really only applies to the *owner's computer* running KDE; in which they
do not want "spillover" of encrypted data onto a non-encrypted volume.
There are three common places where encrypted photos/videos reside that are
under the owner's control: secondary volumes; external drives; network shares
(encrypted on the server).
KDE is only aware of the encryption state of secondary volumes and external
drives. KDE is *not* aware of the encryption state on network shares (on a
server / NAS).
Therefor, to treat this as "How should KDE handle thumbnail caching of
encrypted volumes?" falls short of its *own goal*.
It should be split into *two* approaches:
1) "How should KDE handle thumbnail caching of encrypted volumes?"
2) "How should KDE handle thumbnail caching of network shares / remote
locations?"
In my opinion, you can simplify this by yielding control to the end-user with
*two different toggles*. Plain and simple:
* Cache thumbnail previews for multimedia from encrypted volumes? Yes/No
* Cache thumbnail previews for multimedia from network shares? Yes/No
Simple as that.
Here is the expected behavior, which is very clean and unambiguous, and let's
the user choose:
Cache thumbnail previews for multimedia from encrypted volumes? YES!
- Regardless of the external storage or secondary volume using encryption,
thumbnails will be cache'd to $HOME/.cache/thumbnails
Cache thumbnail previews for multimedia from encrypted volumes? NO!
- Previews will be generated for multimedia from external storage or secondary
volumes that use encryption, but no thumbnails will be cache'd to
$HOME/.cache/thumbnails
Cache thumbnail previews for multimedia from network shares? YES!
- From any network share (SMB, NFS), thumbnails will be cache'd to
$HOME/.cache/thumbnails
Cache thumbnail previews for multimedia from network shares? NO!
- Previews will be generated for multimedia from network shares (SMB, NFS), but
no thumbnails will be cache'd to $HOME/.cache/thumbnails
No need for any special workarounds or clever analysis, or "exceptions" based
on whether or not $HOME lives in an encrypted space. In a sense, this will be
"business as usual", except now the user has two additional toggles that they
may use for enhanced security (if they so desire).
This satisfies nearly *everyone* with the most common scenarios:
* People who have encrypted $HOME. These toggles do not remove nor *force*
anything. They needn't worry about "spillover" either way. These can be toggles
that they "leave alone" or decide to revisit later.
* People who have non-encrypted $HOME. These toggles are a blessing! They can
choose to go the route of "I don't want ANY thumbnails to be cache'd if they
are from encrypted volumes or network shares!" Or they might choose the route
of "I don't care about spillover! I want speed and performance!"
----------
I hope I was able to lay this out as clearly as possible.
I'm not an engineer nor developer. So I view this from the perspective of
someone who uses KDE everyday, from basic tasks to dealing with tons of images
and videos.
--
You are receiving this mail because:
You are watching all bug changes.
