copyright straw

I was just reading about Ted Nelson, who still believes he is locked in an epic struggle with the web. Is it possible to be locked in an epic struggle if your opponent doesn't even notice?

Anyway, I came to this site after reading my favorite philosophy-disguised-as-humor site, and I thought that some other people should see these things juxtaposed.

Mr. Nelson: (whose work I am citing in a manner I am sure he would not approve of)

Most people don't understand the copyright law and how much it restricts re-use of content. No other system allows such re-use and is legal.

Others are trying to break the law, hoping that copyright will become permanently unenforceable. Ethical issues aside, this is probably a mistake. They do not recognize the determination and resources of the publishing and film industries. The large fines and occasional imprisonment of violators are likely to be only the beginning.

Still others are trying to change the copyright law, which is now the same in most countries (the Berne convention). Good luck, but change is not likely.

We work within the law. With the transcopyright system we offer the only legal, honest, daylight method of making on-line content reusable in new ways. Transcopyright is a permission system (or license) which lawyers agree is probably legal in all countries.


Mr. Holkins:

Digital delivery, man. It just freaks these people out.

Imagine that you had to go to a well every time you wanted water. Then, somebody figured out a way to get the water to come out right inside your house! I don't blame them for being scared. Progress is a bitch.


Plumbing can only remain a crime for so long while people still get thirsty.

A More Focused Proposal

As AMK has recently proposed, I think that the Python team should be focusing more on the standard library. However, I refrain from posting on python-dev to this effect any more because all I've had to contribute to the discussion is directionless whining. I consider it a given, however, that the standard library has reached a near-toxic level of bit-rot, although I rarely examine that assumption, although nits periodically come up that reinforce this impression, I hadn't ever thought of a nice "poster child", an issue with the stdlib that reflects the nature of the systematic problem.

The other day, when trying to hunt down a bug in my own code, I found a perfect example of this, though, and I think it should be a point of reflection for the Python team. Let me dress up this next point a bit, for emphasis:

The standard library does not provide a functioning debugger.


But what about pdb.py, you might ask? Well, pdb:
  1. occasionally blows past breakpoints due to .pyc/.py/sys.path disagreements about pathnames
  2. has no way of saving a set of breakpoints across invocations from within the debugger
  3. integration with Emacs support does not work with python packages
  4. doesn't allow you to view the stack when breaking inside a generator
  5. provides no support for remote debugging or IDEs


There are probably even more issues than this, but I generally use a set of hacks included with Twisted and Twisted's Emacs support to work around these deficiencies.

These are also problems with basic functionality. There are other things I think a Python debugger should be able to do, for example, "fix and continue", which even environments working with a far less flexible language (for example, Microsoft Visual C++) manage to do.

So, I will focus on this point, for future discussion of Python development, to avoid unproductive discussion of differences of style and taste. I think we should all be able to agree that the Python debugger should not be broken in basic ways, such as missing breakpoints, and should work with all aspects of the language, including generators and list comprehensions.

Does this mean I can sue the MPAA?

Apparently the MPAA is harassing Linux Australia on my behalf, without my permission.

I guess this just goes to show that they have no respect for copyright law. Bunch of bloody anarchists, they are, those MPAA guys. Stealing the hard labor of innocent copyright creators of content, rapacity on the high seas, etc etc.

Meta

One LJ to another: apparently Doc Searls found my commentary worth linking to. He says "Read the whole thing.". I'm flattered - apparently my impressions of others' experiences in corporate IT were at least somewhat accurate.

I have started using Straw today in earnest, thanks to the ability to aggregate my LJ friends list. I particularly like Straw's UI. I don't think it's using Twisted - although it should be, since it's in python - but it behaves like it does. It is nice and responsive. News aggregators are cool. I'm even aggregating aggregators, most notably Planet Twisted, which if you aren't reading, you should be. It's a Planet thing.

Who Is You? Not Them, That's Who

I started out here by writing a reply to href="http://garage.docsearls.com/node/view/453">r0ml's recent post on href="http://garage.docsearls.com/">Doc Searls' IT Garage. For some
reason, though, reading this article started me thinking about security. and so
its scope has expanded.





Based on my second- and third-hand knowledge, in previous office information
technology revolutions, security domains were well separated, or at least gave
a convincing illusion of being so. At first, things which ran on the mainframe
were the responsibility of the IT department, things which ran on the
workstations were the responsibility of the "rocket scientists", be they devs
or quants. Anything IT talked to that wasn't actually running on the mainframe
was suspect.



As IT subsumed the TCP/IP infrastructure, the professionals ran to IPX and
various transports for SMB: anything IT talked to on a Netware or NT share was
suspect. Now that IPX has gone the way of the dodo and CIFS is exclusively a
TCP/IP beast, there is a new problem: assuming the end-users are equally
sophisticated as your IT staff (unlikely) but less concerned with security
(very likely), if they attach a machine to "the network", meaning the
IT-maintained, TCP intranet, then there is no protection against the outside
world besides the firewall. There is no domain that IT can look at and
automatically say "ah-hah - data coming from there is suspicious, and sensitive
data should not go there".



With a new Outlook virus every two weeks, allowing users to download and run
things off the web puts corporate IT into an almost tragic position. An
industrial spy who writes a trojan that uses visual basic can act as if they
were actually a user, willy-nilly attaching any file on the user's hard drive
with the word "budget" in it to an email in outlook and mailing it to servers
in russia. When users inevitably fall prey to these problems, it becomes IT's
responsibility. Even - and perhaps especially - the machines sitting on the
users' own desks are part of the IT infrastructure.



They also must remain part of that infrastructure until there is some other
way to deal with assigning responsibility for security problems. If the CTO is
going to get the axe for poor security practices, you bet he's going to scream
bloody murder every time an IT staffer lets a user install a .scr file
somewhere.



This all creates a problem of in the mercurial worlds of legislation and
accounting, but I think the next IT revolution might put power back in the
hands of the users if these alternate universes come back into tune with
reality. The fact is, IT in the large is doing a pretty bad job with
security. Firewalls that block everything but port 80 and leave email in the
DMZ a good example of the sort of cargo-cult paranoia that drives modern
security design. Who is it out there that really believes that attackers can't
tunnel their outgoing information through HTTP or email?



What about incoming attacks? Outlook is always easy to pick on, but it is
hardly the only problem. Let me preface what I am about to say: I don't have
any connections in the white-hat or black-hat security communities. I do know
a few programmers though, and most of them work with the web. Every so often,
one of my colleagues will hit a website, look at a peculiar URL, say
"Hmm... that's funny" and try passing some obviously invalid data as a
parameter. On several occasions, this has resulted in me getting an IM or an
IRC connection saying something like "Hey, look at this:
http://...?PROGRAM=/bin/cat%00/etc/passwd". Or maybe,
http://.../query?sql=SELECT%20custname%20FROM%20customers%20LIMIT%2010.
These simple attacks, performed through the public web-sites made available by
the companies themselves, result in password files being exposed, or even
customer information being inadvertently granted to outsiders. In every case,
the problems have been promptly reported to the proper authorities within the
companies with the problem (and in at least one case, where the company was
unresponsive, to the police).



Aside to the viewers at home: before you ask, no, I will
not tell you who discovered the problems, or where the problems were
discovered
. Most especially, I will not "teach you to hack", and if
you asked, you are href="http://www.catb.org/~esr/faqs/hacker-howto.html#I_want_to_crack_and_Im_an_idiot">sub-human
scum
. I thought long and hard about posting this part of the
entry, and if any discussion about this breaks out, I will immediately
remove public access to it.



I've never heard two reports from the same person, or at the same company;
these are not hardened criminals breaking into sites, or one company whose
security is abysmally bad. Security on the internet really is so bad that a
casual observer with no security training and only a smattering of knowledge
about the potential configuration of a website is often able to accidentally
break into it. It's a quiet epidemic in the technology industry, one that goes
to the roots of the unexpected success of the internet and the hyper-speed at
which programmers have been forced to produce code and be the first to market.
This epidemic will become a harsh reality for consumers soon, as computational
trust issues have now taken on clear
and present political consequences
.



Back to the issue at hand, though. In "Do It Yourself" IT, who is
"Yourself"? The implied "Me" shifts back and forth between IT companies and
vendors, but the "You", the "real people" who need to do their work with
computers, are hamstrung by mistakes "We" have made. It seems to me that the
most serious among these mistakes, the really limiting ones, are related to
security. The limiting factor isn't one particular aspect, but both problems
and solutions, both perceptions and misconceptions about security and real
security issues.




Business technologists need to get serious about security, and start
considering attacks against their software in a real way. That means getting
security where it counts: in the applications and in the operating system. IT
management needs to take drastic action and hold vendors responsible for even
potential security problems. There is a tendency to whitewash these things or
to put them on the back burner, since when security is not an emergency, it's
not a visible problem at all.



Until that climate changes, the user's computer will be a prisoner of IT's
fear that it will cause security problems. I don't have any illusions that
suddenly everyone will start getting better at security auditing, but the
fundamental technologies underlying our infrastructure need to be cleaned up
significantly. I'll call out a few by name by way of example - Perl, PHP, and
ASP. Every compromised site I've ever seen was using one of those three
technologies, and it was a problem at that level or a very bad, but very common
idiom that made the sorts of mistakes I've seen easy to make for
developers.



I know I plug high level languages a lot, but I don't want to end on a glum
note of "and that's how things are". You can improve your code's foundation
today, if you just pay attention to security. If you're starting a
new project, Lisp, Smalltalk and Python may not be perfect, but applications
written with them (and with an eye to security) can set you free, to be You, or
Me, and let you define who Yourself is.