[libdvdcss-devel] Please implement the XDG basedir spec

[Rémi Denis-Courmont]

Le jeudi 28 août 2014, 22:24:36 Reimar Döffinger a écrit :
> The proposed patch uses data, not cache, so I think this is besides the
> point, but anyway. Skip it if you don't want to read rants...
> 
> On 27.08.2014, at 21:24, Rémi Denis-Courmont <remi at remlab.net> wrote:
> > Le mercredi 27 août 2014, 11:17:05 Diego Elio Pettenò a écrit :
> >> If you're referring to ~/.dvdcss I think we discussed that before and the
> >> problem was with considering it cache.
> > 
> > It *is* cached data. It is generated from the disc, and can *normally* be
> > fully regenerated. That is pretty much the definition of cache.
> 
> That is one commonly encountered property of a cache, that is can be
> re-filled. And even that one is not properly satisfied here (your examples
> aren't quite the same, since there the authoritative source changed, and
> the cache is intentionally supposed to reflect that)

If you change drive type, the "authoritative source" changed all the same, as 
if my IP address changes and the web content is GeoIP-based.

> Other properties caches often have:
> They can not contain all data

That's not a common property of a cache. My IMAP cache may contain all my 
mails, or it may contain only headers. My web content cache contains entire 
files, or it may contain partially downloaded files.

> They are an exact or
> simplified copy of the base data (not even remotely true here)

It is a presumably exact copy of the decryption key material, indexed by the 
volume identifier or whatever.

> Not to mention simply considering the _purpose_ of having a separate cache
> directory: to allow people to make small, but still complete backups.

Yes. If my hard-drive crashes, I won't need to restore the DVD decryption 
keys; they can be regenerated from the same disc and drive. It is cached data 
and I don't need to back it up (but I can if I want to).

> Putting the keys in the cache does not reduce the backup size in any
> relevant way, so I simply see no _advantage_ to considering it a cache.

That's hardly relevant. And you are assuming that only a small number of discs 
will ever be inserted in a given system. That's not necessarily true (public 
library?).

And I have read complaints about the lack of privacy associated with the 
DVDCSS key cache. Marking its content for backup makes matters worse, rather 
than better.

> Though I grant you that with libdvdcss the situation is not as inane as
> with libaacs, where you ate basically guaranteed to lose access to your
> BluRays if you don't backup your .cache and the only way to get it back is
> to buy a new (but not too new) drive or hope someone publishes a new host
> key...

Device keys are obviously not cache content, and I guess you mean that MKB, 
for practical reasons, should also not be considered as such.

Volume keys are probably cache content though. But that is off-topic.

-- 
Rémi Denis-Courmont
http://www.remlab.net/