LWN: Comments on "Okular, Debian, and copy restrictions"

tar, ext4, root

ChrisDolan — Sat, 04 Jul 2009 18:25:08 +0000

While we're at it, can we remove file permissions from the tar file format? When I untar a file with -r--r--r-- permissions, that violates my freedom.

And that ext4 filesystem, man! It always says "Permission denied" when I try to "rm -r /". We gotta rip that antifeature out of Linux.

And the root account? What's up with that? All accounts should be created equal! Root is the Man. Debian should eliminate the root account, or at least disable the limitations of all other accounts by default. Why do they make "sudo chmod -R 777 /" so obscure?

Okular, Debian, and copy restrictions

ggw — Wed, 01 Jul 2009 03:10:40 +0000

What have you been smoking Superstoned? Here is the last sentence of the
third paragraph.

"There is a configuration option which disables this behavior, but the
default setting is to enforce the copy restriction flag."

Okular is doing the right thing. NOT.

Baylink — Tue, 23 Jun 2009 12:51:15 +0000

Precisely. The point is to make it necessary for you to testify that you turned the protection off in order to copy the data.

I, personally, am on the side of the developer straight down the line here, and I think that the people whining about this need to go take a cold shower.

It'd be real interesting to hear rms's opinion on this: do you violate the spec in the name of "freedom!!!", or do you respect the spec? I'm sure he'd say violate it... but I think that knocks just a little chink in his armor, myself.

We *need* people like rms, don't get me wrong.

Just like we need lawyers.

But that doesn't mean we should do everything either of them say to.

I know of no major DRM implementation that has not been quickly cracked - have you actually looked?

khim — Wed, 17 Jun 2009 07:05:35 +0000

I know of no major DRM implementation that has not been quickly cracked, and I strongly believe that the reason for this is that the concept of DRM is technically flawed.

Have you actually tried to find such an implementation or are you living in your own phantasy world? The very first DRM implementation designed with help of cryptoanalysts - Cell - was successfully used for working DRM protestion of PS3 titles. The solution is on the market for 2.5 years, there are ove 20 millions players and 100 millions disks, yet DRM is holding? Will it work forever? Probably not - but then it has no need to: 20-30 years from now disks will deteriorate and the fact that DRM will be broken will have no practical significance...

The point is not so subtle and it's pointless to discuss it

khim — Wed, 17 Jun 2009 06:35:08 +0000

Yes, because the flags for said usage restrictions are part of the spec and the program is implementing the spec as designed.

Such behaiour is form of sabotage. It's called Italian strike. Recently Microsoft employed it and was rightfully condemned for it. I see no reason to applaud in this case too.

Specs are not objects of worshipment. Specs are just tools. The end goal is usefullness of software. When specs damage this goal - they should be ignored and/or fixed. Here is such a case.

The programmers should be commended for such thoroughness.

Are you masochist? Why will you commend someone for strike against you?

Okular, Debian, and copy restrictions

zenaan — Tue, 16 Jun 2009 14:54:53 +0000

My right to do as I choose with my computer in my house (not talking about publishing to the Internet here at the moment), is absolute!

This is an "information-age right". It appears there are some humans who believe this right either does not exist, or ought be restricted by some heavy hand of law or government or community. I find that strange, but c'est la vie.

In this case of Okular, this absolute-right-over-my-computer is 'functionally' acknowledged with the badly named and mildly obfuscated "DRM" preference option.

My datapoint: The current default for this option in Debian does not match my understanding of the Debian Social Contract nor my expectations for the Debian GNU/Linux distribution.
The "provide dialog option to disable, on first occurrence" is acceptable to me.
I actually like to know about the expectations and/ or license of a document producer/ document, and would appreciate having some GUI feature(s) which makes this information readily available to me.

My position is: either:
a) the Debian Social Contract must change,
b) the default for Okular "DRM" option in Debian must change, or
c) Okular must be 'enhanced' to provide opt-out on first hit, and/ or other GUI enhancements.

If the Okular devs/ Debian packagers are trying to make a point, they're not doing it in the most elegant way at the moment, emphasizing the utility of this article by Corbet - highlighting that there is in fact an issue.

I heartily agree.

Community introspection is a very important thing. Also highlights that we are indeed a community! Happy joy...

Circumvention

zenaan — Tue, 16 Jun 2009 13:52:34 +0000

Well well well. My, what a cool nic you have ...

Okular, Debian, and copy restrictions

zenaan — Tue, 16 Jun 2009 13:43:43 +0000

ncm: YOU ROCK!

My god it's good to be involved with the gang at LWN!

Made my day. Nothin like a regular dose of rationality. With class.

And Jon - excellent article! Clearly a timely raising of these issues.

Over the top

nix — Mon, 15 Jun 2009 08:44:26 +0000

Well, given that 'direspect the users' is unlikely to be written into
Debian Policy anytime soon, and that Debian is basically a mass of chaotic
independent arguing maintainers except inasmuch as constrained by Policy,
I'd say your fear of a (ha!) corporate-controlled Debian is needless.

Over the top

Arker — Mon, 15 Jun 2009 05:12:17 +0000

What I am arguing is that we should, if we want to have some role for Open Source in society's future other than supporting locked-down systems, respect other folks rights as we would have them respect ours.

I dont think anyone disagrees with that. I also dont think it is at all on point. No one has any right to take control of my computer from me, period, end of story.

Many people clearly believe they have such a right but they are mistaken. This is not a conflict between my rights and their rights, it's a conflict between my rights and their desires. My rights win.

The Okular maintainers are not violating my rights - they are in no way forcing me to use their software, and they have the right to make it however they think right. Although their choice in this situation makes it clear they are dangerous lunatics, that is their right.

The same can be said for the Debian maintainers, although it is much more disturbing given the long commitment from Debian to respecting users rights. But in the end, we dont have to use Debian either.

But really, if this becomes more than an isolated incident but a harbinger of how Debian looks to move forward, then Debian will die, or morph into some sort of corporate controlled fifth column. I dont want to see either of these things happen.

Never reported upstream?

k8to — Fri, 12 Jun 2009 06:41:04 +0000

> You know, normal people don't feel the need to "evaluate" the
> community before installing an application, especially not
> "including the bug reports". That alone marks you as Not a Normal
> User, but someone who can be expected to be a little more flexible
> and knowledgeable.

I recognize that you are not trying to be insulting by insisting that people such as me who do this are abnormal. However, you are being insulting.

There's nothing wrong with researching something you're going to invest in. It is a matter of thoroughness, care, attention to detail, and of course interest and available time, rather than normality or the lack thereof.

Okular, Debian, and copy restrictions

oblio — Thu, 11 Jun 2009 12:17:43 +0000

Maybe this (together with various other issues) is what's holding Konqueror back. Check out Linux Hater's blog for the KDE 4 rant ;)

Okular, Debian, and copy restrictions

Janne — Thu, 11 Jun 2009 10:42:02 +0000

If there's one thing that's cle<r from this discussion, it's this:

If free software-folks stopped nitpicking and complaining about minor
licensing-issues and related topics, free software would utterly dominate
the world by now.

But no, what happens is that time and energy gets wasted on pointless
arguments. Software gets forked and unforked, resources get wasted and
developers have to waste their time listening to users who whine "But I
don't want to invest 10 seconds of my life to changing that setting, I want
you do to it for me!".

And there's one thing that amazes me: Basically this discussion has been
about "I should be able to do whatever I please with the content,
regardless of the wishes of the creator!". Now, assume the person saying
that comment was Steve Ballmer, and the content he was referring to, was
GPL'ed software, everyone would be up in arms. But now that it's US who is
making that claim, everything is apparently a-OK....

Is Okular doing the right thing?

huaz — Thu, 11 Jun 2009 06:13:05 +0000

> "Implementing the spec as designed" is not an excuse for putative bad
> behavior here.

And who are you to decide which behavior is bad?

Come on, there is a standard and the code implemented it.

There is an option for you to turn it off if you care.

So spend five seconds clicking it off and stop whining!

Never reported upstream?

halla — Tue, 09 Jun 2009 13:08:46 +0000

You know, normal people don't feel the need to "evaluate" the community before installing an application, especially not "including the bug reports". That alone marks you as Not a Normal User, but someone who can be expected to be a little more flexible and knowledgeable. And no, that is not an insult either. (And if Okular crashes on startup, you also get a nice window that helps you file a bug report.)

If you really had wanted to make a suggestion instead of scoring a silly little point at the tail of a silly discussion on a news website, you could have, like, contacted the Okular team directly. There is quite a prominent link on their website to http://okular.kde.org/contact.php, which gives you plenty of ways to contact them and ask them to add a link to bugs.kde.org.

So, you could, very easily, have made just this little suggestion of yours, without resorting to phrases like:

" Oddly, neither the Okular user web page, nor the Okular KDE web page seem to have any links to any sort of bug tracker. So I can't tell what the upstream developers may have said about it."

Because it isn't odd -- it's just an oversight, most KDE applications don't have a link to the bug database because that's in the application menu. It is seldom needed. But it didn't make it impossible for you to figure out what the upstrream developers might have said about, because a) there have been links to their opinion as expressed in blogs and b) you could easily have reached them because the means to do so are prominently displayed on the okular website.

Never reported upstream?

kevinbsmith — Tue, 09 Jun 2009 12:35:21 +0000

Perhaps I would like to evaluate the Okular community (including bug reports) before deciding to install the application. Perhaps the bug I want to report is that the app won't even start up. There really are valid reasons for the project web site to link to the bug tracker.

As for thinking to look on kde.org: I was curious about Okular, not KDE (I assume is possible to run one without the other, as with other KDE apps). It honestly didn't occur to me to look on the KDE site. Apparently I'm more ignorant than I thought

And sure, I don't really matter because I'm not (yet) an Okular user. Clearly the best response to my suggestion for how to improve the site, as well as my suggestion for a possible way to resolve the frustration of many users while also fixing a public relations problem, is to insult me. Ok. If that's how the Okular/KDE communities wish to be represented, so be it.

Never reported upstream?

halla — Tue, 09 Jun 2009 07:43:49 +0000

Yes, of course. If you are a normal user, you use the menu to report a bug. You don't go traipsing
all over the internet in search of a bug tracker, since you don't know what a bug tracker is.

You, Kevin, are not an ordinary user. You are posting comments on lwn.net, you know what a bug
tracker is, you know that Okular belongs to KDE. Of course you are not really so ignorant that you
cannot think of going to http://www.kde.org and see find the link that is clearly marked "Bug
Database".

Never reported upstream?

kevinbsmith — Mon, 08 Jun 2009 22:51:09 +0000

"Of course". Sigh. As if everyone in the world knows that. I'm neither a KDE nor an Okular user, but perhaps someone could suggest that they update their web sites to have links to their bug tracker.

I checked bugs.kde.org and couldn't find any bug report for this issue. Perhaps I missed it somehow. If not, hopefully someone will create one. Seems like that should have been the first step when the Debian maintainers marked the issue as wontfix.

Compromise

halla — Mon, 08 Jun 2009 21:23:21 +0000

But the Okular application _has_. Help->Report Bug.

And, of course, it's bugs.kde.org, which is the place where all KDE
applications track their bugs.

Compromise

kevinbsmith — Mon, 08 Jun 2009 20:39:43 +0000

I'm disappointed at how many folks here have either taken the absolutist stance "It must be removed or disabled by default" while many others take the opposite absolutist position of "No change needed or desired." Where is the compromise? (Kudos to the several people who have advocated some middle ground).

I read (much of) the bug thread, and see that JohnG (the original bug reporter) did agree to the compromise of having an advisory dialog with instructions for how to disable the feature. The KDE maintainer (Ana) said no, and actually explained why doing this would be somewhat difficult technically, at the package maintainer level.

So in my mind this compromise clearly should be pushed upstream. Oddly, neither the Okular user web page, nor the Okular KDE web page seem to have any links to any sort of bug tracker. So I can't tell what the upstream developers may have said about it.

If a reasonable effort has been made to persuade upstream to compromise, then I guess I would favor Debian taking action. The most reasonable technical action seems to be disabling the option by default. However, the maintainers disagree with that. I'm no Debian expert, but that seems to leave two options: Live with it, or create an alternative package with new maintainers.

It's frustrating when an issue like this is painted in stark black and white, when in reality there seems to be a very reasonable compromise available...and when some folks on each side seem uninterested in being reasonable.

Okular, Debian, and copy restrictions

Hawke — Sat, 06 Jun 2009 19:31:02 +0000

Konqueror does, in my experience.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

BrucePerens — Sat, 06 Jun 2009 16:23:10 +0000

Well, this is very nice for existing discs, but my understanding was that Blu-Ray had multiple keys, and that they had planned for updates.

There is also the prospect of HDMI 2.0. So, I hope we're as lucky in the future.

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Kamilion — Sat, 06 Jun 2009 09:24:14 +0000

Blu-Ray's AACS key has been compromised since May of 2007.
http://www.bmeink.com/A70529/high/bmepb529722.jpg

HDMI's been compromised by the HDFury2.
http://preview.tinyurl.com/hdfury2

Neat little hack, that. They used a laptop TMDS display transmitter chip's
HDMI input paired 3cm from a TMDS receiver chip with a VGA/component
output.

Fully HDMI 1.3 compliant with embedded HDCP keys and CEA861 EDID extension
block! Heh!

Perfect match for the Ambarella A2 chip in Hauppauge's HD PVR to capture
crisp 720p or 1080i straight to h264. Ambarella's A3 chip extends that to
1080p60, or our friendly neighborhood PC resolution of 1920x1080@60hz.

(Can you tell I'm a hardware geek?)

Whta's the difference between this and robots.txt?

euske — Sat, 06 Jun 2009 05:34:43 +0000

But even in those cases, we don't publicly tout that we can infringe it, right? Going back to the PDF case, what a developer could do at best (in favor of infringement) in this case is to give an ability to do so in a somewhat obscure way, and I guess that's what the Okular people did. Blaming them publicly that they didn't make it conspicuous enough is obviously too much one-sided. This is a complex real-world problem and there's no single perfect answer, either technically or socially.

Is Okular doing the right thing?

pjm — Sat, 06 Jun 2009 01:24:08 +0000

The word "enforce" is in general somewhat ambiguous about to what extent the object is absolutely obtained (see the variation in meanings given by a dictionary), but the post to which JoeF replies already makes clear (in more than one paragraph) that its author is aware that the software does not absolutely prevent copying.

(So the answer to the question how ... does that enforce ... is: it urges or causes (to quote one dictionary) that result both by informing the user that an author of the document has requested that the text not be copied or printed, and by requiring the user to go to extra effort to copy or print the document.)

The question under discussion is not whether copying is absolutely prevented (that question has already been answered both in the original article and in the post to which JoeF replies), but whether the software is effective in reducing costly mistakes, and whether there are any practical steps we can take to improve the tradeoff of preventing rare but costly mistakes against the cost of making it less convenient to copy when it is appropriate to copy.

(In this case, without yet having read the discussion in the bug report, I'd suggest that the dialog box could be improved by changing the text to An author of the document has requested not to copy text from this document., and going on to inform the user how they can nevertheless copy from the document. Adding a button to the dialog box would be something to consider, though the trade-off is that users don't then get much chance to think about the reason for the request. Again, I haven't read the discussion in the bug report.)

And more generally under discussion is how one might handle other cases where there is some desire to hinder some user actions ("limit freedom") to prevent harm or achieve some other desirable result.

Whta's the difference between this and robots.txt?

foom — Fri, 05 Jun 2009 15:45:44 +0000

Think about it: Most people respect a "private" sign in the real world when there's no physical obstacle, so we don't have to spend huge money on security.

Taking that analogy further:

If you know you have the permission to enter the property marked "Private", you don't have to wait for the owner to come over and take the sign down before doing so. You can just do it.

If you are crossing into the land for innocent purposes (e.g. it's a shortcut to where you're going and the land is unused, so what's the harm?) you might make the decision to enter despite it being marked private. And often that'll be fine, because likely nobody will know, and nobody was harmed.

Think about it. Even when there's a chain-link-fence around some unused land (one step up from a sign on the border), how often have you seen holes in it for people to walk through? At least around here that's quite common.

Both externally-granted permission and innocent infringement are quite common with software, as "in the real world". I've certainly run into both situations personally with copy-inhibited PDFs.

Whta's the difference between this and robots.txt?

euske — Fri, 05 Jun 2009 10:34:48 +0000

No, copy-and-paste is a form of automation too. You could always type the written characters by yourself when extraction is prohibited, although it sounds stupid. Basically, both features grant access to the contents in a basic way. They just prohibit a certain kind of use of its information. Technically, of course, it doesn't make much sense, because it's easily circumventable. But it's an okay solution as long as most people follow the restriction and to follow these restriction is considered decency.

Think about it: Most people respect a "private" sign in the real world when there's no physical obstacle, so we don't have to spend huge money on security. If everyone starts ignoring these "soft" restrictions by their own discretion, the world would become much worse. Originally Adobe created this because their customers want it. But I'm pretty sure companies like Adobe might be eventually going to impose much more strict, heavy and technically ill-formed DRM scheme when the content providers demand, no matter how ridiculous or broken the idea is.

My only gripe is that the whole mechanism was made and spread by a single company without much consideration or democratic discussion, and nowadays it gets so important. But sadly, that's how most of today's format standards were created.

Over the top

liljencrantz — Fri, 05 Jun 2009 07:50:20 +0000

The decryption keys are stored somewhere on every HDMI device. Way harder than to sniff out the key from a software player, but definitely doable. Don't know enough about TPM to know how secure it is, though.

Okular, Debian, and copy restrictions

liljencrantz — Fri, 05 Jun 2009 07:44:46 +0000

This seems completely backwards to me. The very, very small number of organizations with specific reasons to limit their users freedom can update the system defaults to enforce these limitations, and let the other 99.9 % of humanity, including all sane corporations, to get on with their lives. Why on earth should the default value cater to a microscopic subgroup instead of the broad masses, when that subgroup can actually change the default for themselves?

Over the top

nix — Thu, 04 Jun 2009 20:18:20 +0000

DRM *implemented in software* is fundamentally flawed. I just hope nobody
starts really using the TPM and things like HDMI that move decryption into
the display/sound hardware :(

Whta's the difference between this and robots.txt?

ncm — Thu, 04 Jun 2009 20:00:26 +0000

What does "had to" mean, here? Corporate directive, or misplaced feeling of obligation?

The difference is that copying and pasting from a pdf is done by an individual, who can be presumed to be equipped to make the decision whether the flags reasonably apply in each case. robots.txt is read by automated programs, and is obeyed mainly because crawlers wouldn't work if they ignored it.

Grumpy

madcoder — Thu, 04 Jun 2009 19:48:37 +0000

fair enough, this time that was really a mistake :)

Grumpy

ncm — Thu, 04 Jun 2009 19:45:32 +0000

Jon's not angry, just grumpy. With every reason to be.

Over the top

timschmidt — Thu, 04 Jun 2009 16:21:53 +0000

One need not know what DRM is to be prevented from viewing content by it.

Many of my friends and co-workers have used iTunes in the past. Several of them stopped after catastrophic software failure or other calamity in which iTunes DRM keys were lost - preventing access to the hundreds of dollars of music they'd 'purchased'. Of course, when such things happen, these folks come to their friendly local computer guy, and we tend to show them the easiest way to replace all those music files - already bought and paid for - Arrrrr!

And that's how DRM fails - even for normal people.

Okular is doing the right thing. NOT.

sepreece — Thu, 04 Jun 2009 14:28:16 +0000

Agreed, and that's clear in other comments I have made in this strand - it disables the ability to take snips out of the document without overriding the restriction.

The point (from my perspective) is just to make sure the user knows he's breaking the author's rules.

Whta's the difference between this and robots.txt?

euske — Thu, 04 Jun 2009 12:49:30 +0000

As a developer of text extraction tool from PDF, I'm pretty concerned of this sort of bashing. Think about the difference of this type of copy protection and robots.txt. Both are shady standards but used for some time. Do people complain about major search engines not ignoring robots.txt? Sure, this kind of features can be abused by some people. But both are easily circumvented if anyone has demand. Any "decent" search engine or crawler program are supposed to respect this, and departure from the expected behavior is considered rude. You can be rude anytime at your own risk, but please don't complain when people don't provide a tool for it.

BTW, I'm personally against the idea of this "extraction protection" bit because this poses a serious information barrier for users who are visually impaired and access to PDF documents via voice synthesis (later Adobe added an "exception for blind people" bit, but it's far from perfect). Still, I had to implement this dreadful thing when I published the software. Am I missing something?

up-side

jospoortvliet — Thu, 04 Jun 2009 11:57:38 +0000

Point is that preventing copying like this works just fine in most cases. Especially if you know (like in the example I gave) that you're not allowed to try to circumvent it. This is like a 'soft DRM' function. Pretty easy to circumvent, but that's no problem. Inconvenient is good enough here.

Anyway, you think the functionality is useless. I think it has it's usecases. You should ask Adobe why they wrote it, and the companies using it why they do that, not me.

Okular, Debian, and copy restrictions

nye — Thu, 04 Jun 2009 10:37:47 +0000

The thing is, I don't know of any browser that does so by default. By default they all just accept it, unless you change a configuration option. This sounds familiar to me...

Over the top

nye — Thu, 04 Jun 2009 10:33:44 +0000

Okay, sorry. I'm just saying that I don't think it's realistic *at all* to expect content and its producers to 'fade into obscurity' simply for wanting to use DRM. The number of us who even know what that means may well be less than a percent of the general population, and the other guys just think we're wierd for caring about such things.

FAIL

nye — Thu, 04 Jun 2009 10:30:43 +0000

And after I spent all that time coming up with a politely factual remark, rather than making the original emotional response I felt like.

Tch.