I've noticed a scary trend in "de facto" internet law: Sites are shut down, projects stopped, and ideas silenced because of scary notices from lawyers. Lots of the time, these cease and desist letters don't actually have much to stand on, but they're so cheap to send, and so effective, that any business with a site it doesn't like and a lawyer on salary would be crazy not to do it. The effect of these letters is chilling (so to speak): sites that are probably legal are shut down without the benefit of a trial, and the "precedent" affects the way other laymen interpret the law. I've seen numerous mostly-serious posts on slashdot proclaiming "Wouldn't this be a violation of the DMCA?" when referring to any sort of activity the MPAA or RIAA, etc. wouldn't like. (Speaking of the DMCA -- it has built-in provisions for making precisely this kind of judge-free takedown by an ISP!) This trend seems to be a serious breakdown of the legal system, and I don't like it.
My question is: In your opinion, what can be done to change the way the system operates so that spurious legal threats aren't so economical? What can someone like me do, besides donating to the EFF or going to law school?
You might look into a "Faraday Cage," which I hear improves reception tremendously.
FWIW, my little linksys base station gives me solid coverage all over my house, and even outside. Maybe it's the base station or card?
Re:Where are you getting this? Read the DMCA!
on
Copyright Rumblings
·
· Score: 1
> So, exactly as I said: If two pieces are protected by the same DRM scheme, and one of them passes into public domain, it is > still prohibited to "traffic" in any device that circumvented the DRM to access it.
Where do you find this in the law? Though they may be protected by the same DRM scheme, the scheme is only a "technological measure" when it controls access to a work that is protected under title 17, ie, is still in copyright. If the device is not primarily designed to circumvent DRM-protected copyrighted works (in other words, if there are plenty of public domain works protected by that DRM scheme), then it's in the clear.
> There are no exemptions in the DMCA for access to public domain works behind DRM schemes -- at least, not behind ones that > happen to also be used on protected materials. If you can find it, I'd be much happier. But I am not going to hold my breath.
There are no explicit exemptions because the DMCA only applies to copyrighted works. That is why the things you're saying don't fly! It says "... work protected under this title" everywhere!
>> Well, if the technology can be used to decode a significant amount of public domain content, then it is probably not >> "primarily designed" for work protected under title 17. > > This is of course nonsense. The technology could have been developed to protect works while under copyright, but -- for now, > at least -- copyright does expire. The eventual passing into public domain of some works does not retroactively change the > fact that the DRM was primarily -- indeed, explicitly -- designed to protect covered works.
You misunderstood what I was talking about. The technology in question is the "circumvention device", not the DRM scheme. (I don't call it that because all "circumvention devices" are prohibited by the DMCA -- the point is that the device in question doesn't meet the definition.) Rephrased: Because the device decodes a significant amount of public domain content, then it is not "primarily designed" to circumvent technological measures as defined in 17 USC 1201.
Where are you getting this? Read the DMCA!
on
Copyright Rumblings
·
· Score: 2, Informative
I think you guys should read the law carefully. (http://www4.law.cornell.edu/uscode/17/1201.html)
There are two main things that the DMCA bans. One is the actual act of circumvention: "No person shall circumvent a technological measure that effectively controls access to a work protected under this title." Certainly, when a work has passed into the public domain it is not protected under title 17! (They are not talking about a "brand" of technology here, but a specific instance of it.)
The other thing that the DMCA bans is the distribution of circumvention devices: "No person shall... traffic in any technology..." At first, this seems to support your argument that any device that could decrypt copyrighted content would be banned. But a technology is only banned if it...
- "... is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title"
Well, if the technology can be used to decode a significant amount of public domain content, then it is probably not "primarily designed" for work protected under title 17.
- "... has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or"
Accessing public domain works is certainly commercially significant.
- "... is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title."
As long as you don't market it as a circumvention device for copyrighted works, you're fine.
So where do you get the idea that the DMCA prohibits work on breaking any DRM scheme?
Finally, your argument is simply impractical. Even clearly illegal circumvention tools are available easily on the internet, and once someone has anonymously done the dirty work of unshackling a public domain work, content industries would have no way to stop its distribution. Given that they barely have any impact on movie and music trading that is clearly illegal, it's not very likely that they'd be able to prevent the distribution of stuff they don't even have any legal claim to.
I wish people on slashdot would stop asserting misinformation with authority. Please at least reveal your sources and your reasoning with regard to the actual law! (as I have done..)
Well, you're right about limitations being in the eye of the beholder. I just wanted to make the point that it is not simply a matter of giving the user all of the possible features, even questionable ones (unsafe casts), and letting him pick which ones to use -- a key feature of safe language is that they prevent such questionable access, enabling the user to make more precise restrictions on how his code is used. I've found this has made a huge difference in my ability to write large scale software.
> That is... memory related issues is not the top bug I find myself worrying over in my carreer, so I'm not willing to give up > much in the way of performance, etc., for a magic solution.
Yeah, memory safety is a pretty minor one, although if you don't have memory safety than you can never really be sure about any other properties. SML achieves, I think, better control over data structures than java with its sophisticated type system, and that I think is a bigger win as far as real world interface specification (that is checked by the compiler).
> I tend to think the practical languages will always look messy to purists.
This is true, but nonetheless SML is practical (most implementations even have unsafe features like the ability to interface to C code -- the difference is that you sure as hell know when you're using these!) and a lot more palatable to us purists.;)
> C and C++'s limitation: you have to learn what you are doing, which is in general good advice!
You have to learn the language *and* the implementation in order to really understand C or C++. A good example is the address-of operator; in order to understand why you can't return the address of a . There's no question that understanding compilers and architecture and operating systems is useful and helpful when programming, but somehow I don't think of it as a fair prerequisite for being able to program on a platform.
Well, let me first say that Java is not the language I'd advocate first over C or C++, though if you want to program in an Object Oriented style, maybe it is the most appropriate. I would consider a language like SML or O'Caml or Haskell to be "radically modern" in the sense that, unlike Java, they don't feel that they need to present the user with familiar paridigms (OO) and syntax and buzzwords just to gain industry acceptance. My favorite is SML, so if you're interested, that would be a good one to try.
> In fact, all the "pure" languages ever tried (like Pascal) limit you in some way that C/C++ > refuses to. This is a power of C++.
I'd be interested in knowing what sort of ways you believe "pure" languages limit you; this seems to be a common fear. Especially I'd like to know which ones are important for programming network applications. It's true that most "pure" languages would be inappropriate for writing OS kernels (at least certain parts of the kernel), and it's true that some kinds of allocation strategies are not possible in a garbage collection environment (but it's not clear what examples you have in mind and why those are important for general applications). In my experience, I'm never troubled writing real world applications in SML (or even Java) because I feel like the languages limit me as compared to what I can do in C++. Basically, the things that I can do in C but can't do in these languages are things I don't want to do, or shouldn't be doing (unsafe casts?). So, what do you have in mind?
To tell you the truth, whenever I have to program in C or C++ I find that I have an opposite problem: C and C++ limit my ability to control access to my data structures because of the lack of safety in the language. In SML (or even Java) I can write an interface to my module that specifies precisely how others can use my code. If the code malfunctions, I know that the error is mine. There is no mechanism by which a programmer can deviously (or accidentally) mess with its internals. This is of course essential for having a modular program, and invaluable for debugging, since it makes faults easier to isolate. No matter how hard I try in C or C++, though, a user can still cast my data structure, or even accidentally corrupt it by writing outside the bounds of an array, or double-freeing some memory. That sucks! It can't happen in SML (and to a lesser extent, Java), and I consider that a feature. In fact, you sort of allude to this in your post with respect to the "ownership" of an object in C++.
Of course, there are many other features of SML (higher order functions, polymorphism, type inference, parameterized modules, nested modules, exceptions, datatypes, pattern matching, first-class continuations, tuples, etc.) that are missing or typically badly designed/implemented in C or C++, and I miss those, too! Some of those are only possible or practical because the language has safety and garbage collection. Safety alone is enough to sell me on modern languages if I care about security, but all of the new-fangled features are awfully nice to have, too.
> The point is, it will always, always, without exception, rely upon the developer not fucking up. > If you remove the capacity for pointers, they'll find some other way to exploit the system. There is no such thing as > security.
This is a pretty extreme position to take, and I think it's impractical. Using more safe languages can make our programs more reliable and more secure, by limiting the ways that programmers can make exploitable bugs. Of course, a language that doesn't allow the developer to make any holes at all, even if he's trying, is not very useful (in a sense ssh itself is a 'hole' that grants access to someone who 'exploits' it with a password). I am not claiming that we should program in these languages, if in fact they exist. But there is a rich middle ground between such a useless language and a language like C that makes it so easy and dangerous to make mistakes. These languages absolutely do make a very popular class of errors (that occur even among the world's best programmers) vanish instantly, and that to me is obviously a step in the right direction.
> I think languages that claim to do it all for you and protect you from logic errors (I guess you start from a truth and only > divide, truth truth truth all around) are the ones that encourage bad program design.
Well, I used to love C too, so maybe the only way to change one's mind is to try a radically modern language for a while and see. For me, I hated it at first and now I don't want to go back. No language claims to "do it all" for you, of course. The specific thing I'm talking about is automatic safety, which is easy to achieve in one of these languages and essentially impossible in C. For people who care about security (I thought slashdot programmers did? Or do we just love the 70s?) this seems like an obvious choice!
> Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU > time doing diffs, that is, text processing--something that C is notoriously awful at.) > > It might be difficult to code for beginners, but what text processing languages like perl are written in lower-level > languages like C. Its plenty fast.
Well, I didn't really have perl in mind -- perl is pretty slow. (Though, since the language is built for string manipulation, it is pretty convenient!) My main point is borne out by the existence of perl, though: since C's facilities for string handling are so rudimentary, people found it necessary to invent new languages on top of C just to make it tractable.
> There are not enough daemons written in other languages to determine if security exploits would be present in them.
That's true. I think there are good reasons to believe that security would be better, but we have seen with scripting languages (which are "safe" in the sense I'm using here) that easy access to the shell and behind-the-scenes globbing can be just as dangerous. However, we can say for sure that using compiled safe languages does remove the largest class of unix security vulnerabilities: buffer overflows, format string attacks, heap corruption, and integer overflow. So, for sure something gets better, but maybe (not likely) something else gets worse. Sounds good to me!
> But you are wrong about SSH, go to CERT [cert.org] and search for SSH. The first 5 (that's all I checked) were implementation > problems _NOT_ buffer overflow problems.
I meant OpenSSH, sorry. I just checked openssh.org/security.html, and the newest vulnerabilities are:
- Remote challenge vulnerability (integer overflow -- impossible)
- Overflow in AFS/Kerberos (buffer overflow -- impossible)
- Off-by-one error in the channel code (array overflow -- impossible)
In other words, I would have avoided having to do emergency upgrades of my sshd the last two times had it been written in a modern safe language.
There are a few before that that were language-neutral (probably), and several other buffer overflows. The overflow attacks were the most serious, because they often affected the default configuration. Many of the other vulnerabilities were relatively theoretical or difficult attacks that could not be carried out by script kiddies in an automated, large-scale way. Also, I think I am being generous by choosing ssh, since the algorithmic issues in crypto login software are much more difficult than those in, say, ftp or named.
> I'm curious, but do you actually know C? I mean really know it. Know the caveats of realloc? If so, I'd find it odd that you > think C is bad by design.
Yes, absolutely. At the beginning of college I was a total C cowboy, but I have grown out of that. Now I am studying programming languages for my PhD so I have more refined tastes.;) But unlike a lot of programming language researchers, I really do a lot of practical programming. I don't think C was designed to be bad, but I do think that it is no longer an appropriate design for application languages.
> We call them "Denial of Service" attacks, or DoS. I'm surprised you haven't heard of them.
What makes you think that I haven't heard of them?
Essentially nothing can protect me from Denial of Service attacks. If an enterprising script kiddie wants to make my network connection unusable, he can, no matter what software I run. Though it's bad if he can crash my servers with little effort, I can notice that kind of behavior and patch them -- unless I'm running a service for someone else, that's no big deal. (Being compromised is much worse, though, because even the home user who hardly cares if his cvs pserver works cares if his computer is controlled by someone else.)
> While this does seem true, it also seems to me that it's mostly a result of various deprecated libraries still being used.
Although beginners still make the old strcpy mistakes, most of those bugs are gone from the high profile software. That's because it's fairly easy to automatically look for problematic library calls and audit them. For the last few years format string attacks were pretty popular, but now we've figured out how to audit against those, too. Recently, the bugs I've been seeing on bugtraq have been rather insidious. Heap corruption (through double-frees) and integer overflow seem to be pretty popular, and those are quite difficult (AFAIK) to find automatically. The C rules for memory management work most of the time -- the problem is, a single bug is disastrous. My impression is that many of these problems come from error conditions, which is further exacerbated by the fact that C has completely primitive error recovery features. (ie, no exception support outside of setjmp).
Finally, C is indeed a useful gun, but there are plenty of other guns that are just as useful (if not more so!) but have better safety features. If security is critical (and I think most people on slashdot think it is), why do we settle for C?
> The SSH exploits could exist regardless of what language.
This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.
My response to the rest of your post can be summed up as: C behaving as it is designed is no consolation if the design is bad, and the design is bad as far as security is concerned. It's true that it's possible (to a certain extent) to grin and bear it, but why would you want to do that??
> It really is not so hard to never use an unbounded function (snprintf instead of sprintf) or to count malloc() and frees() > and if you do your code well structured, than it works. If you test your code with code that will cause buffer overflows > everywhere, you will find them. If you do your math correctly, you will find them. If you don't, it's human error.
I think you must have never written any big software, because it's not as simple as you think. Look at the complexity of the recent SSH bugs, for instance. Human error is universal, even if you are trying hard, and even if you are an excellent programmer (see the list in my previous post). And it is extremely dangerous. Regardless of whether this is C's "fault" (can a tool really be at "fault"?) or the programmer's "fault" for choosing a tool that is so dangerous, it is clear to me that C is a bad language for writing security-critical software.
Now, if we always go to so much trouble to look for bugs, and always use functions that check bounds, then why not simply have the language (compiler) do this work for us? This can free us to spend more time doing things that are not totally mechanical (looking for other kinds of security holes) or useful (looking for ways to make the program better). What is wrong with my reasoning?
> Anything external will usually be less reliable and robust than something built-in to the language specifications. But, I > would trust the authors of gcc more than you, no offense mate.
I think you missed my point: The authors of *gcc*, which is THE quintessential C program (in a strong sense), have found it so difficult to manage memory manually that they've resorted to using a garbage collector, despite its deficiencies. If anything is a testament to the inappropriateness of C, that is.
Many "functional" languages (like SML and O'Caml) have imperative features for exactly this reason, just as C has (sort of) the ability to pass around functions. It's true that Haskell (purely functional) is not a great language to write I/O intensive software in (though Haskell has its own ways to do IO, and Haskell fans have written many I/O intensive, interactive applications, including network daemons). However, Haskell would be far from the worst language, because at least you'd have a better chance of ending up with a program that works correctly (doesn't provide remote root access to anyone).
I maintain that SML and O'Caml ("functional" languages) are utterly practical (and in fact superior to C and C++ in terms of correctness and ease of use) for network software. I've written a full-featured ftp server in SML to replace my buggy wu_ftpd, so I have some evidence to back this up.
> Again, the problem is not the language, it's the coder.... Don't blame a language for operating exactly as it's designed to.
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
Quake I, II, and III Linux Kernel, OpenBSD Kernel, FreeBSD Kernel SSH perl Half-Life X11 BIND dhcpd ap ache mozilla, internet explorer, netscape navigator, konqueror, opera etc. etc. etc. etc.
(Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!)
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
This post is severely uninformed, like most others that defend C for network applications. Here's why.
- "Java would probably crash with some sort of exception instead of happily running in an invalid state... but do you really
want anyone to remotely crash the server daemon either?"
No, of course not, but that's about ten million times better than giving the attacker remote root access. Script kiddies don't get much out of crashing servers, but they do out of compromising a computer. And it is much much harder to detect and clean up afterwards.
- "C is absolutely, bar none, the fastest language for slinging raw bytes around (err... ignoring assembly, but it's close) -
and that's pretty much what a CVS server (or FTP, or HTTP, or...) does."
Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU time doing diffs, that is, text processing--something that C is notoriously awful at.) Most users wouldn't notice if their CVS server used 20 times more CPU. C is no more than 2x faster than modern safe languages like O'Caml and SML (http://www.bagley.org/~doug/shootout/craps.shtml) . For well optimized code, that number can easily be within 20%. Of course, writing in a high level language gives you more time to work on better algorithms, which as any good programmer knows, is what *really* matters in its performance.
I'm not just bullshitting, either: Last summer after another wu_ftpd remote hole I rewrote the damn thing in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/to m7misc/net/mlftpd/). It took me only about a weekend and the result was about 10% the length of the C program. It also saturates my 100mbit link without using more than a few percent of my crappy 400mhz CPU. (It transfers data using basically the same mechanisms that C uses, so C doesn't have any advantage in that part.) Most importantly, I sleep tighter at night knowing that my server is 100% buffer overflow, double-free, and integer overflow free.
- "... the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug."
Unfortunately, C encourages such bad program design, and then makes bugs deadly. How else can you explain so many buffer overflows, double-frees, and integer overflows? Don't tell me it's the programmers, because almost all of the most revered C software, written by the most talented programmers I know, has had such bugs. (Quake III, ssh, linux kernel, wu_ftpd, apache, perl, etc., etc., etc.)
The GPL applies to things you copyright (code), not file formats. I didn't look at the page, but unless they patented the algorithm (unlikely) then it's hardly more IP-entangled than LZW or GIFs. You can always re-implement a piece of GPL software if you don't want to be bound by the terms of the license.
It's true that I was being cynical, but I don't think I'm that far off the mark. It just doesn't make sense to me that the same person who uses MAME (to probably play pirate ROMs -- illegal) and records shows off TV (legal) also refuses to download pirate MP3s or CSS/Macrovision/Region Coded DVDs.
I'll be the first to claim that MP3s have legitimate legal uses (I have hundreds that I've made myself and granted people to distribute). MAME and DVDs less so, but they do. P2P apps, sure. However, most people do NOT use these technologies legally. (I think that's good for the world, actually, because it reminds people that sharing isn't the same as stealing.)
The basis of my question is: Why care about "free" or "open" software to play closed/proprietary/illegal media? What's the point?
(Someone posted a good response having to do with the ability to modify the software. That's true. In this case I get the feeling that the poster of the question was only interested in having an "open" system because that was cool, like linux is cool, not because there's some actual philosophical or practical reason for it.)
To me, the idea of an open entertainment system that you describe doesn't seem to mesh.
Why does it matter that you're running on a free platform when you're playing non-free movies using illegal technology, pirated video game ROMs and MP3s?
In order for this to be real, we'd also need a collection of free movies and video games to add to the admittedly significant cache of free music. (There are also plenty of free video games, but since you are talking about MAME I don't think this is what you had in mind.) Otherwise, why does it matter if your media center uses pirated software, too?
Don't get me wrong -- I love the idea of disconnecting ourselves from the corporation-controlled content and software, but I don't think it helps us much if we develop a lot of free software in order to continue to consume the proprietary stuff.
On the other hand, I'm not saying that using pirated everything is all bad -- maybe a generation kids who grew up sharing things on Napster and clones will result in a less conservative congress, where things like the Copyright Term Extension Act won't be so common. (Which is what has me feeling so cynical right now...)
Well, his article is crap, too, so that's why I didn't read it.;)
It may be true for writing, but it's definitely not true for music: for several years I've been having a great time downloading self-published music from mp3.com. Believe me, there's no sewage filter here, but that doesn't mean I'm not able to find stuff that I like fairly easily. It's great that these are real people, doing it for the love of it, and that you can have discussions and collaborations with them. Really refreshing. (It also feels a lot better than buying from the RIAA!) Of course, making my own music is a good way to have music that I like, and that some other people might by chance like, too. Seriously, if it meant the end of commercial radio and professional "artists," hell, sign me up.
This whole thing reminds me eerily of the academic publishing industry's claim that we as researchers need them in order to survive. (So sign over those copyrights!) Of course, with the internet we no longer need journals and conference proceedings to get access to papers, and with the recent academic scandals involving forged results, it's not clear that the peer review system is working particularly well, either.
Demos may be the pinnacle of a certain kind of programming (making graphics and music with really small amounts of code), but I don't think that's the only kind of programming, nor even the hardest kind of programming. In fact, in some ways it's pretty easy, since the project is usually so small that you can pull some really dirty tricks without losing the manageability of the code. Do demo programmers find compiler-writing trivial? Algorithm design? Concurrent programming? Of course not.
Anyway -- writing stupid little assembly demos was how I began programming. The stuff I was doing had been done before (for the most part) and better, but I still enjoyed doing it. If his question is, "I want to get into the demo scene because I have some really sweet ideas and I think I could win some of those competitions," then you might be right. If it's, "Wow, demos are really cool and they have really excited me about programming and now I want to try," (which I think it is), then I think starting with Demos is a completely reasonable idea.
Well, it sounds like we may be getting through to them -- consumers who understand the issues won't stand for it. Why would anyone want "features" that reduce the usefulness of a computer by giving more control to bit content-owning corporations? Send your comments to marketing@ami.com (address on the initial press release web page). Here are mine:
Just to clarify my earlier comments: It is in fact TCPA, and not just Palladium, that upsets me. Computers are just fine as they are, and you and I both know that operating systems can already implement the kinds of features ("virus protection") that TCPA claims will benefit consumers. The only use of TCPA preventing a computer user from modifying his *own* system in order to bypass "digital rights management," the software that intends to make it impossible for consumers to exercise their fair use privileges and other freedoms that we currently enjoy. I do not want to be enslaved by content owners!
Therefore, I will always buy from the last manufacturer to sell general-purpose, non-TCP-enabled computers, and I think any consumer who understands the issues will, too. I really hope this turns out to be the marketing disaster that it deserves to be.
Spinmeister Brian Richardson wrote: "I am a bit concerned that the information you provided misled your readers into thinking AMI was promoting Palladium or taking some sort of anti-open-source stance. This might be due to the fact that TCPA was mistakenly equated to Palladium, or questioning how Linux would run on a TCPA-enabled system... or by the horde of angry Slashdot readers telling us they would never buy an AMI product because we were forcing standards on them."
Slashdot Mirror
I've noticed a scary trend in "de facto" internet law: Sites are shut down, projects stopped, and ideas silenced because of scary notices from lawyers. Lots of the time, these cease and desist letters don't actually have much to stand on, but they're so cheap to send, and so effective, that any business with a site it doesn't like and a lawyer on salary would be crazy not to do it. The effect of these letters is chilling (so to speak): sites that are probably legal are shut down without the benefit of a trial, and the "precedent" affects the way other laymen interpret the law. I've seen numerous mostly-serious posts on slashdot proclaiming "Wouldn't this be a violation of the DMCA?" when referring to any sort of activity the MPAA or RIAA, etc. wouldn't like. (Speaking of the DMCA -- it has built-in provisions for making precisely this kind of judge-free takedown by an ISP!) This trend seems to be a serious breakdown of the legal system, and I don't like it.
My question is: In your opinion, what can be done to change the way the system operates so that spurious legal threats aren't so economical? What can someone like me do, besides donating to the EFF or going to law school?
I've warned them before about tampering with "dark side matter." This is bad news.
Dude, hydrogen peroxide is like 79 cents at the drug store on my street.
You might look into a "Faraday Cage," which I hear improves reception tremendously.
FWIW, my little linksys base station gives me solid coverage all over my house, and even outside. Maybe it's the base station or card?
> So, exactly as I said: If two pieces are protected by the same DRM scheme, and one of them passes into public domain, it is
> still prohibited to "traffic" in any device that circumvented the DRM to access it.
Where do you find this in the law? Though they may be protected by the same DRM scheme, the scheme is only a "technological measure" when it controls access to a work that is protected under title 17, ie, is still in copyright. If the device is not primarily designed to circumvent DRM-protected copyrighted works (in other words, if there are plenty of public domain works protected by that DRM scheme), then it's in the clear.
> There are no exemptions in the DMCA for access to public domain works behind DRM schemes -- at least, not behind ones that
> happen to also be used on protected materials. If you can find it, I'd be much happier. But I am not going to hold my breath.
There are no explicit exemptions because the DMCA only applies to copyrighted works. That is why the things you're saying don't fly! It says "... work protected under this title" everywhere!
>> Well, if the technology can be used to decode a significant amount of public domain content, then it is probably not
>> "primarily designed" for work protected under title 17.
>
> This is of course nonsense. The technology could have been developed to protect works while under copyright, but -- for now,
> at least -- copyright does expire. The eventual passing into public domain of some works does not retroactively change the
> fact that the DRM was primarily -- indeed, explicitly -- designed to protect covered works.
You misunderstood what I was talking about. The technology in question is the "circumvention device", not the DRM scheme. (I don't call it that because all "circumvention devices" are prohibited by the DMCA -- the point is that the device in question doesn't meet the definition.) Rephrased: Because the device decodes a significant amount of public domain content, then it is not "primarily designed" to circumvent technological measures as defined in 17 USC 1201.
I think you guys should read the law carefully. (http://www4.law.cornell.edu/uscode/17/1201.html)
... traffic in any technology ..." At first, this seems to support your argument that any device that could decrypt copyrighted content would be banned. But a technology is only banned if it ...
There are two main things that the DMCA bans. One is the actual act of circumvention: "No person shall circumvent a technological measure that effectively controls access to a work protected under this title." Certainly, when a work has passed into the public domain it is not protected under title 17! (They are not talking about a "brand" of technology here, but a specific instance of it.)
The other thing that the DMCA bans is the distribution of circumvention devices: "No person shall
- "... is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title"
Well, if the technology can be used to decode a significant amount of public domain content, then it is probably not "primarily designed" for work protected under title 17.
- "... has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or"
Accessing public domain works is certainly commercially significant.
- "... is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title."
As long as you don't market it as a circumvention device for copyrighted works, you're fine.
So where do you get the idea that the DMCA prohibits work on breaking any DRM scheme?
Finally, your argument is simply impractical. Even clearly illegal circumvention tools are available easily on the internet, and once someone has anonymously done the dirty work of unshackling a public domain work, content industries would have no way to stop its distribution. Given that they barely have any impact on movie and music trading that is clearly illegal, it's not very likely that they'd be able to prevent the distribution of stuff they don't even have any legal claim to.
I wish people on slashdot would stop asserting misinformation with authority. Please at least reveal your sources and your reasoning with regard to the actual law! (as I have done..)
Well, you're right about limitations being in the eye of the beholder. I just wanted to make the point that it is not simply a matter of giving the user all of the possible features, even questionable ones (unsafe casts), and letting him pick which ones to use -- a key feature of safe language is that they prevent such questionable access, enabling the user to make more precise restrictions on how his code is used. I've found this has made a huge difference in my ability to write large scale software.
> That is... memory related issues is not the top bug I find myself worrying over in my carreer, so I'm not willing to give up
> much in the way of performance, etc., for a magic solution.
Yeah, memory safety is a pretty minor one, although if you don't have memory safety than you can never really be sure about any other properties. SML achieves, I think, better control over data structures than java with its sophisticated type system, and that I think is a bigger win as far as real world interface specification (that is checked by the compiler).
> I tend to think the practical languages will always look messy to purists.
This is true, but nonetheless SML is practical (most implementations even have unsafe features like the ability to interface to C code -- the difference is that you sure as hell know when you're using these!) and a lot more palatable to us purists.
> C and C++'s limitation: you have to learn what you are doing, which is in general good advice!
You have to learn the language *and* the implementation in order to really understand C or C++. A good example is the address-of operator; in order to understand why you can't return the address of a . There's no question that understanding compilers and architecture and operating systems is useful and helpful when programming, but somehow I don't think of it as a fair prerequisite for being able to program on a platform.
Well, let me first say that Java is not the language I'd advocate first over C or C++, though if you want to program in an Object Oriented style, maybe it is the most appropriate. I would consider a language like SML or O'Caml or Haskell to be "radically modern" in the sense that, unlike Java, they don't feel that they need to present the user with familiar paridigms (OO) and syntax and buzzwords just to gain industry acceptance. My favorite is SML, so if you're interested, that would be a good one to try.
> In fact, all the "pure" languages ever tried (like Pascal) limit you in some way that C/C++
> refuses to. This is a power of C++.
I'd be interested in knowing what sort of ways you believe "pure" languages limit you; this seems to be a common fear. Especially I'd like to know which ones are important for programming network applications. It's true that most "pure" languages would be inappropriate for writing OS kernels (at least certain parts of the kernel), and it's true that some kinds of allocation strategies are not possible in a garbage collection environment (but it's not clear what examples you have in mind and why those are important for general applications). In my experience, I'm never troubled writing real world applications in SML (or even Java) because I feel like the languages limit me as compared to what I can do in C++. Basically, the things that I can do in C but can't do in these languages are things I don't want to do, or shouldn't be doing (unsafe casts?). So, what do you have in mind?
To tell you the truth, whenever I have to program in C or C++ I find that I have an opposite problem: C and C++ limit my ability to control access to my data structures because of the lack of safety in the language. In SML (or even Java) I can write an interface to my module that specifies precisely how others can use my code. If the code malfunctions, I know that the error is mine. There is no mechanism by which a programmer can deviously (or accidentally) mess with its internals. This is of course essential for having a modular program, and invaluable for debugging, since it makes faults easier to isolate. No matter how hard I try in C or C++, though, a user can still cast my data structure, or even accidentally corrupt it by writing outside the bounds of an array, or double-freeing some memory. That sucks! It can't happen in SML (and to a lesser extent, Java), and I consider that a feature. In fact, you sort of allude to this in your post with respect to the "ownership" of an object in C++.
Of course, there are many other features of SML (higher order functions, polymorphism, type inference, parameterized modules, nested modules, exceptions, datatypes, pattern matching, first-class continuations, tuples, etc.) that are missing or typically badly designed/implemented in C or C++, and I miss those, too! Some of those are only possible or practical because the language has safety and garbage collection. Safety alone is enough to sell me on modern languages if I care about security, but all of the new-fangled features are awfully nice to have, too.
> The point is, it will always, always, without exception, rely upon the developer not fucking up.
> If you remove the capacity for pointers, they'll find some other way to exploit the system. There is no such thing as
> security.
This is a pretty extreme position to take, and I think it's impractical. Using more safe languages can make our programs more reliable and more secure, by limiting the ways that programmers can make exploitable bugs. Of course, a language that doesn't allow the developer to make any holes at all, even if he's trying, is not very useful (in a sense ssh itself is a 'hole' that grants access to someone who 'exploits' it with a password). I am not claiming that we should program in these languages, if in fact they exist. But there is a rich middle ground between such a useless language and a language like C that makes it so easy and dangerous to make mistakes. These languages absolutely do make a very popular class of errors (that occur even among the world's best programmers) vanish instantly, and that to me is obviously a step in the right direction.
> I think languages that claim to do it all for you and protect you from logic errors (I guess you start from a truth and only
> divide, truth truth truth all around) are the ones that encourage bad program design.
Well, I used to love C too, so maybe the only way to change one's mind is to try a radically modern language for a while and see. For me, I hated it at first and now I don't want to go back. No language claims to "do it all" for you, of course. The specific thing I'm talking about is automatic safety, which is easy to achieve in one of these languages and essentially impossible in C. For people who care about security (I thought slashdot programmers did? Or do we just love the 70s?) this seems like an obvious choice!
An AC writes,
> Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU
> time doing diffs, that is, text processing--something that C is notoriously awful at.)
>
> It might be difficult to code for beginners, but what text processing languages like perl are written in lower-level
> languages like C. Its plenty fast.
Well, I didn't really have perl in mind -- perl is pretty slow. (Though, since the language is built for string manipulation, it is pretty convenient!) My main point is borne out by the existence of perl, though: since C's facilities for string handling are so rudimentary, people found it necessary to invent new languages on top of C just to make it tractable.
> There are not enough daemons written in other languages to determine if security exploits would be present in them.
That's true. I think there are good reasons to believe that security would be better, but we have seen with scripting languages (which are "safe" in the sense I'm using here) that easy access to the shell and behind-the-scenes globbing can be just as dangerous. However, we can say for sure that using compiled safe languages does remove the largest class of unix security vulnerabilities: buffer overflows, format string attacks, heap corruption, and integer overflow. So, for sure something gets better, but maybe (not likely) something else gets worse. Sounds good to me!
> But you are wrong about SSH, go to CERT [cert.org] and search for SSH. The first 5 (that's all I checked) were implementation
> problems _NOT_ buffer overflow problems.
I meant OpenSSH, sorry. I just checked openssh.org/security.html, and the newest vulnerabilities are:
- Remote challenge vulnerability (integer overflow -- impossible)
- Overflow in AFS/Kerberos (buffer overflow -- impossible)
- Off-by-one error in the channel code (array overflow -- impossible)
In other words, I would have avoided having to do emergency upgrades of my sshd the last two times had it been written in a modern safe language.
There are a few before that that were language-neutral (probably), and several other buffer overflows. The overflow attacks were the most serious, because they often affected the default configuration. Many of the other vulnerabilities were relatively theoretical or difficult attacks that could not be carried out by script kiddies in an automated, large-scale way. Also, I think I am being generous by choosing ssh, since the algorithmic issues in crypto login software are much more difficult than those in, say, ftp or named.
> I'm curious, but do you actually know C? I mean really know it. Know the caveats of realloc? If so, I'd find it odd that you
> think C is bad by design.
Yes, absolutely. At the beginning of college I was a total C cowboy, but I have grown out of that. Now I am studying programming languages for my PhD so I have more refined tastes.
> We call them "Denial of Service" attacks, or DoS. I'm surprised you haven't heard of them.
What makes you think that I haven't heard of them?
Essentially nothing can protect me from Denial of Service attacks. If an enterprising script kiddie wants to make my network connection unusable, he can, no matter what software I run. Though it's bad if he can crash my servers with little effort, I can notice that kind of behavior and patch them -- unless I'm running a service for someone else, that's no big deal. (Being compromised is much worse, though, because even the home user who hardly cares if his cvs pserver works cares if his computer is controlled by someone else.)
> While this does seem true, it also seems to me that it's mostly a result of various deprecated libraries still being used.
Although beginners still make the old strcpy mistakes, most of those bugs are gone from the high profile software. That's because it's fairly easy to automatically look for problematic library calls and audit them. For the last few years format string attacks were pretty popular, but now we've figured out how to audit against those, too. Recently, the bugs I've been seeing on bugtraq have been rather insidious. Heap corruption (through double-frees) and integer overflow seem to be pretty popular, and those are quite difficult (AFAIK) to find automatically. The C rules for memory management work most of the time -- the problem is, a single bug is disastrous. My impression is that many of these problems come from error conditions, which is further exacerbated by the fact that C has completely primitive error recovery features. (ie, no exception support outside of setjmp).
Finally, C is indeed a useful gun, but there are plenty of other guns that are just as useful (if not more so!) but have better safety features. If security is critical (and I think most people on slashdot think it is), why do we settle for C?
> The SSH exploits could exist regardless of what language.
This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.
My response to the rest of your post can be summed up as: C behaving as it is designed is no consolation if the design is bad, and the design is bad as far as security is concerned. It's true that it's possible (to a certain extent) to grin and bear it, but why would you want to do that??
> It really is not so hard to never use an unbounded function (snprintf instead of sprintf) or to count malloc() and frees()
> and if you do your code well structured, than it works. If you test your code with code that will cause buffer overflows
> everywhere, you will find them. If you do your math correctly, you will find them. If you don't, it's human error.
I think you must have never written any big software, because it's not as simple as you think. Look at the complexity of the recent SSH bugs, for instance. Human error is universal, even if you are trying hard, and even if you are an excellent programmer (see the list in my previous post). And it is extremely dangerous. Regardless of whether this is C's "fault" (can a tool really be at "fault"?) or the programmer's "fault" for choosing a tool that is so dangerous, it is clear to me that C is a bad language for writing security-critical software.
Now, if we always go to so much trouble to look for bugs, and always use functions that check bounds, then why not simply have the language (compiler) do this work for us? This can free us to spend more time doing things that are not totally mechanical (looking for other kinds of security holes) or useful (looking for ways to make the program better). What is wrong with my reasoning?
> Anything external will usually be less reliable and robust than something built-in to the language specifications. But, I
> would trust the authors of gcc more than you, no offense mate.
I think you missed my point: The authors of *gcc*, which is THE quintessential C program (in a strong sense), have found it so difficult to manage memory manually that they've resorted to using a garbage collector, despite its deficiencies. If anything is a testament to the inappropriateness of C, that is.
Many "functional" languages (like SML and O'Caml) have imperative features for exactly this reason, just as C has (sort of) the ability to pass around functions. It's true that Haskell (purely functional) is not a great language to write I/O intensive software in (though Haskell has its own ways to do IO, and Haskell fans have written many I/O intensive, interactive applications, including network daemons). However, Haskell would be far from the worst language, because at least you'd have a better chance of ending up with a program that works correctly (doesn't provide remote root access to anyone).
I maintain that SML and O'Caml ("functional" languages) are utterly practical (and in fact superior to C and C++ in terms of correctness and ease of use) for network software. I've written a full-featured ftp server in SML to replace my buggy wu_ftpd, so I have some evidence to back this up.
> Again, the problem is not the language, it's the coder. ... Don't blame a language for operating exactly as it's designed to.
p ache
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
Quake I, II, and III
Linux Kernel, OpenBSD Kernel, FreeBSD Kernel
SSH
perl
Half-Life
X11
BIND
dhcpd
a
mozilla, internet explorer, netscape navigator, konqueror, opera
etc.
etc.
etc.
etc.
(Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!)
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
This post is severely uninformed, like most others that defend C for network applications. Here's why.
...) does."
) . For well optimized code, that number can easily be within 20%. Of course, writing in a high level language gives you more time to work on better algorithms, which as any good programmer knows, is what *really* matters in its performance.
o m7misc/net/mlftpd/). It took me only about a weekend and the result was about 10% the length of the C program. It also saturates my 100mbit link without using more than a few percent of my crappy 400mhz CPU. (It transfers data using basically the same mechanisms that C uses, so C doesn't have any advantage in that part.) Most importantly, I sleep tighter at night knowing that my server is 100% buffer overflow, double-free, and integer overflow free.
- "Java would probably crash with some sort of exception instead of happily running in an invalid state... but do you really
want anyone to remotely crash the server daemon either?"
No, of course not, but that's about ten million times better than giving the attacker remote root access. Script kiddies don't get much out of crashing servers, but they do out of compromising a computer. And it is much much harder to detect and clean up afterwards.
- "C is absolutely, bar none, the fastest language for slinging raw bytes around (err... ignoring assembly, but it's close) -
and that's pretty much what a CVS server (or FTP, or HTTP, or
Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU time doing diffs, that is, text processing--something that C is notoriously awful at.) Most users wouldn't notice if their CVS server used 20 times more CPU. C is no more than 2x faster than modern safe languages like O'Caml and SML (http://www.bagley.org/~doug/shootout/craps.shtml
I'm not just bullshitting, either: Last summer after another wu_ftpd remote hole I rewrote the damn thing in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/t
- "... the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug."
Unfortunately, C encourages such bad program design, and then makes bugs deadly. How else can you explain so many buffer overflows, double-frees, and integer overflows? Don't tell me it's the programmers, because almost all of the most revered C software, written by the most talented programmers I know, has had such bugs. (Quake III, ssh, linux kernel, wu_ftpd, apache, perl, etc., etc., etc.)
The GPL applies to things you copyright (code), not file formats. I didn't look at the page, but unless they patented the algorithm (unlikely) then it's hardly more IP-entangled than LZW or GIFs. You can always re-implement a piece of GPL software if you don't want to be bound by the terms of the license.
It's true that I was being cynical, but I don't think I'm that far off the mark. It just doesn't make sense to me that the same person who uses MAME (to probably play pirate ROMs -- illegal) and records shows off TV (legal) also refuses to download pirate MP3s or CSS/Macrovision/Region Coded DVDs.
I'll be the first to claim that MP3s have legitimate legal uses (I have hundreds that I've made myself and granted people to distribute). MAME and DVDs less so, but they do. P2P apps, sure. However, most people do NOT use these technologies legally. (I think that's good for the world, actually, because it reminds people that sharing isn't the same as stealing.)
The basis of my question is: Why care about "free" or "open" software to play closed/proprietary/illegal media? What's the point?
(Someone posted a good response having to do with the ability to modify the software. That's true. In this case I get the feeling that the poster of the question was only interested in having an "open" system because that was cool, like linux is cool, not because there's some actual philosophical or practical reason for it.)
To me, the idea of an open entertainment system that you describe doesn't seem to mesh.
Why does it matter that you're running on a free platform when you're playing non-free movies using illegal technology, pirated video game ROMs and MP3s?
In order for this to be real, we'd also need a collection of free movies and video games to add to the admittedly significant cache of free music. (There are also plenty of free video games, but since you are talking about MAME I don't think this is what you had in mind.) Otherwise, why does it matter if your media center uses pirated software, too?
Don't get me wrong -- I love the idea of disconnecting ourselves from the corporation-controlled content and software, but I don't think it helps us much if we develop a lot of free software in order to continue to consume the proprietary stuff.
On the other hand, I'm not saying that using pirated everything is all bad -- maybe a generation kids who grew up sharing things on Napster and clones will result in a less conservative congress, where things like the Copyright Term Extension Act won't be so common. (Which is what has me feeling so cynical right now...)
Well, his article is crap, too, so that's why I didn't read it. ;)
It may be true for writing, but it's definitely not true for music: for several years I've been having a great time downloading self-published music from mp3.com. Believe me, there's no sewage filter here, but that doesn't mean I'm not able to find stuff that I like fairly easily. It's great that these are real people, doing it for the love of it, and that you can have discussions and collaborations with them. Really refreshing. (It also feels a lot better than buying from the RIAA!) Of course, making my own music is a good way to have music that I like, and that some other people might by chance like, too. Seriously, if it meant the end of commercial radio and professional "artists," hell, sign me up.
This whole thing reminds me eerily of the academic publishing industry's claim that we as researchers need them in order to survive. (So sign over those copyrights!) Of course, with the internet we no longer need journals and conference proceedings to get access to papers, and with the recent academic scandals involving forged results, it's not clear that the peer review system is working particularly well, either.
Demos may be the pinnacle of a certain kind of programming (making graphics and music with really small amounts of code), but I don't think that's the only kind of programming, nor even the hardest kind of programming. In fact, in some ways it's pretty easy, since the project is usually so small that you can pull some really dirty tricks without losing the manageability of the code. Do demo programmers find compiler-writing trivial? Algorithm design? Concurrent programming? Of course not.
Anyway -- writing stupid little assembly demos was how I began programming. The stuff I was doing had been done before (for the most part) and better, but I still enjoyed doing it. If his question is, "I want to get into the demo scene because I have some really sweet ideas and I think I could win some of those competitions," then you might be right. If it's, "Wow, demos are really cool and they have really excited me about programming and now I want to try," (which I think it is), then I think starting with Demos is a completely reasonable idea.
Hehe. 'Viree' is the funniest mispluralization of 'virus' I've ever seen. =)
Well, it sounds like we may be getting through to them -- consumers who understand the issues won't stand for it. Why would anyone want "features" that reduce the usefulness of a computer by giving more control to bit content-owning corporations? Send your comments to marketing@ami.com (address on the initial press release web page). Here are mine:
... or by the horde of angry Slashdot readers telling us they would never buy an AMI product because we were forcing standards on them."
Just to clarify my earlier comments: It is in fact TCPA, and not just Palladium, that upsets me. Computers are just fine as they are, and you and I both know that operating systems can already implement the kinds of features ("virus protection") that TCPA claims will benefit consumers. The only use of TCPA preventing a computer user from modifying his *own* system in order to bypass "digital rights management," the software that intends to make it impossible for consumers to exercise their fair use privileges and other freedoms that we currently enjoy. I do not want to be enslaved by content owners!
Therefore, I will always buy from the last manufacturer to sell general-purpose, non-TCP-enabled computers, and I think any consumer who understands the issues will, too. I really hope this turns out to be the marketing disaster that it deserves to be.
Spinmeister Brian Richardson wrote:
"I am a bit concerned that the information you provided misled your readers into thinking AMI was promoting Palladium or taking some sort of anti-open-source stance. This might be due to the fact that TCPA was mistakenly equated to Palladium, or questioning how Linux would run on a TCPA-enabled system