How would Java evolve without Sun to "guide" it. What would Sun certifications mean without Sun there to back it up?...
If Sun does go out of business, Java may become fragmented and start losing the solid base it has around it.
#1: you're on dope. #2: you're on crack!
I pray that Apple, IBM, or anybody who knows anything about OO programming would buy/take/steal Java from SUN, who have failed Java like only SUN could. Hell, if M$ bought Java from SUN, we'd probably end up with better APIs. If WINE can reproduce win32, why not Java...
I blame SUN squarely for the failure that Java is today. Any by that, I mean everything from AJAX to php eating what should have been Java's lunch.
In the Linux world the software UI can be vastly different across all applications. There is no standard interface, and so the user gains much by experimenting with all portions of the software. Even then there are some similarities, such as command line switches. Teaching a user to read the documentation (hopefully it has been well written) will do them a better service then giving them the answer. If the documentation is poorly written (I have seen poorly written documentation in both Windows and Linux) it may be necessary for the user to ask for assistance. In that case (and only in that case) please try to be hospitable.
This is 3 crocks and 4 excuses. If you run a disty, all the software you ship had better be uniform. If it isn't, your disty sucks. If a user can't figure out 90% of what they want to do without even going to the help, your disty probably sucks. If a user can't figure out the remaining 10% of what they want to do inside the docs, your disty certainly sucks. If a user has to use the commandline at all, your disty sucks.
Your notion of the "user gaining greater experience" is an excuse. The user should not have to gain much of any experience with the OS - their experience should be with their business. If the system doesn't install and let the user log in and have clear and obvious access to Email, Web, and Office Suite, your disty sucks. If they don't have subtle access to system tools/config, your disty sucks.
I installed Ubuntu the other day. I had to edit the x11org.conf file by hand just ot get the monitor working. By that, I mean that when I started the computer, I was greeted with a black screen. I had to edit/etc/fstab by hand to get the 2nd drive to mount after reboots. In my book, Ubuntu has been added to the sucks list.
"Done" in the sense that if you want to copy all your image files, you're done. Not done in the sense that if you just want to point iPhoto at a firewire drive with more gigs of images than you have space and work with the images there, you can't do it (easily).
iPhoto was amazing when it was first released. It was free, easy, and better than anything else. It continues to do what it does VERY VERY well. But I want more from my tools, now. (I wanted more back then, and suffered with the program from Cannon because it let me organize my own photos).
I am being pedantic because DRM is all about being pedantic.
My coffee did come with the restriction that I not assault someone with it... to that same extent there are restrictions on everything we do.
I bet your coffee came with no restrictions at all. I'm pretty sure that all the restrictions on how you interact with your coffee, and how the two of you interact with society at large are driven by society - not the coffee, nor the coffee vendor. This is substantially different from the interaction between you and non public domain media that is sold (or given) to you. Media tends to come with a lot more restrictions.
And here's my take-home point: DRM is an attempt to enfoce the restrictions media vendors have placed on you. There is nothing wrong with DRM. You may not like some of the media restrictions already present in the system. You may not like some implementations of DRM (I sure don't). But DRM is just an attempt to enforce the rules that we're already (theoretically) playing by.
Living in a civil society means we have to learn to play nice together... my point was more that I refuse to play with those that don't want to play nice with me.
The coffee I bought at Starbucks this morning didn't come with usage restrictions, and neither will any media I consume or use.
Well, that's one perspective. But it is a false one, or you just don't count.
The software you're using comes with restrictions unless it's public domain. It may not count as media, and it may not be usage restrictions.
The website you're accessing is media, and it does come with usage restrictions.
Virtually all music you purchase comes with usage restrictions. Certainly any music from a "big label" does. Most free music you gain access to comes with usage restrictions, too.
Same goes for video.
Same goes for text.
Finally, any music/video/text that you gain access to for free, and legally, and which is public domian, just doesn't matter in the context of the article. If you don't pay for it, it doesn't have anything to do with DRM. Even stuff you purchase which is public domain doesn't have anything to do with DRM.
To some extent I'm just picking nits. But on the other hand "The coffee I bought at Starbucks this morning didn't come with usage restrictions, and neither will any media I consume or use." just isn't true - or if so, is not important.
Finally, I'm all for "I won't purchase media that limits the way I use it, keeping in mind I will comply with the intent of copyright law."
For me it turns out that iTunes work just fine for me in that respect, and that many DVDs do not - though a decent hacked DVD that will allow me to FF whenever *I* want would fix most of that issue.
People pay for songs on iTunes because they want to feel like they are helping the artists (They're not BTW)
How do you figure? CDBaby pays out about 90% to their musicians (http://cdbaby.net/).
or they're scared enough to think that they actually might get caught for sharing music on p2p. People certainly don't use it for the "experience" or quality.
I use iTunes because it is convenient, legal, 128Kbit is good enough for me, and becaues musicians who have not screwwed themselves certainly do get money out of it.
'Rampant piracy' doesn't significantly impact sales. Over 1,000,000 sales on iTunes agrees with this (the same tunes are _all_ readily available from p2p at the same or better quality)
It's 1B sales, not 1M. And I don't think you can argue that because people buy songs on iTunes, that they would not buy more if there there were end-to-end DRM.
However, DRM also does NOT make the slightest difference to piracy, rampant or otherwise.
Sure it does. It means that Bobby can't just email the latest track by Who Done It to his friend Ted. It means that you can't casually share music in a way that is illegal, and qualifies as piracy. Good or bad, it's a true statement. DRM limits piracy to people who purposely pirate music.
Not that people who break DRM are not necessarily pirates.
The only people even the slightest bit bothered by CD copy-protection and DRM on digital music files are the legitimate music purchasers. Seeders know how to bypass it. P2P downloaders never even see it.
Why would someone waste their time downloading a 128kbps file? Most of the illegal stuff is MUCH better quality than that. The songs on BT and other p2p networks usually come from CDs, putting DRM on the ITMS files isn't stopping them from spreading because they're already being shared in mp3 format ripped from CDs.
DRM does not stop or slow anything.
1,000,000,000+ song purchases (at Apple alone) say you're wrong.
Of course you CAN listen to it on whichever device you want. It just requires a few extra steps and a loss in quality (that I certainly wouldn't notice, but I'm a head banger).
But your point is well taken.
I don't think that the music industry will abandon DRM, however. As much as it keeps users from doing whatever they want, it also slows down rampant piracy. Yes, I did say SLOWS DOWN and RAMPANT.
Apple has sold more than a billion songs, and they're all DRM'd (at least I think all of them are). If they didn't DRM them, I heartily believe that some visible percentage of them would be pirated. And 1% of a billion is still 10,000,000. If they kept only 1% of sales from being pirated to another customer, that's 10M in sales. That's a pretty big incentive to keep using DRM. And vendor lockin is something of a non-issue to the music industry while they're 'backed' by a vendor that has 80% or more of the market.
... Not that I would want my ETrade sessions to go in the clear, but, if they were to go in the clear, what would happen... traffic leaves my computer, goes straight into the backbone of my major ISP (where interception and analysis would require quite a lot of behind-the-scenes treachery), bounces around amongst other backbone routers (similar situation), and then plonks off into the ETrade server where, hopefully, they're fastidious about security.
This was the telnet attitude for decades. And then people realised it was folly, and trivial, and started using ssh (with self signed keys). The problem of people sniffing telnet passwords/information went away.
The "behind the scenes analysis" requried for password collection amounts to a perl script that looks for http POSTs that include the key "PASSWORD". The payoff is all the passwords for all the etrade accounts. That's a pretty good arguement for encryption.
traceroute to etrade.com (12.153.224.22), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 1.205 ms 0.367 ms 0.207 ms
2 adsl-64-170-199-97.dsl.snfc21.pacbell.net (64.170.199.97) 15.531 ms 7.585 ms 7.620 ms
3 dist1-vlan50.snfc21.pbi.net (206.171.134.130) 11.203 ms 7.290 ms 10.637 ms
4 bb1-10g2-0.snfcca.sbcglobal.net (216.102.176.224) 9.620 ms 7.684 ms 7.539 ms
5 core1-p14-1.crsfca.sbcglobal.net (151.164.242.65) 8.117 ms 7.966 ms 7.592 ms
6 bb1-p8-0.crsfca.sbcglobal.net (151.164.243.2) 7.842 ms 7.942 ms 7.819 ms
7 ex1-p3-0.eqsjca.sbcglobal.net (151.164.41.101) 8.889 ms 8.642 ms 8.600 ms
8 ge-6-11.car4.sanjose1.level3.net (151.164.250.29) 8.888 ms 8.616 ms 8.810 ms
9 ae-2-52.bbr2.sanjose1.level3.net (4.68.123.33) 9.326 ms 9.651 ms ae-2-54.bbr2.sanjose1.level3.net (4.68.123.97) 9.557 ms 10 as-1-0.bbr1.atlanta1.level3.net (209.247.9.101) 75.981 ms ae-0-0.bbr2.atlanta1.level3.net (64.159.1.46) 76.257 ms 76.531 ms 11 ge-10-1.hsa1.atlanta1.level3.net (4.68.103.68) 76.305 ms ge-11-1.hsa1.atlanta1.level3.net (4.68.103.100) 76.306 ms ge-10-2.hsa1.atlanta1.level3.net (4.68.103.132) 76.977 ms 12 p0-0.etrade5.bbnplanet.net (4.24.186.6) 79.235 ms 77.394 ms 78.604 ms...
So that's at least 5 domains and a dozen hosts to sniff at. I'm glad my ETrade traffic is ssl'd.
Using a net cafe would be a totally different situation as I'm relying on some $7/hr admin to not sniff traffic and install keystroke loggers.. but I would never online bank from such a spot anyways.
I do all the time - from my laptop. (you're also trusting the admin secured the NAT box against crackers - a much bigger concern, IMHO).
Flame away, but I worry less about my VOIP traffic being encrypted than I do about the material on my USB keychain, my laptop, my system being encrypted. Most of you probably have $20 door locks protecting your home machines and files.
We've avoided flammage pretty well, so far. The truth is: your voip traffic includes no passwords or security information, or anything interesting to much of anyone, really. Just like your email traffic (which is often cleartext).
The only thing that unauthenticated encryption can really prevent is accidental evesdropping. You could accomplish that by just ROT13'ing the message. I don't know about you, but if I encrypt something it's because I don't want anyone listening in -- particularly if they're listening in on purpose. The only way to ensure that is to be sure of who I'm communicating with before I start giving away my secrets. Fingerprint authentication "is way better than nothing - it eliminates an entire (trivial) form of attack." Without it no amount of encryption will protect against an intentional evesdropper.
I know people who have lost passwords because they used IMAP, not IMAPS. IMAPR13 would be very little better. SSL with any reasonable keysize is essentially uncrackable, and eliminates the eavesdropper. And I think that's an important distinction. Eavesdropping is trivial on the internet - anyone can do it without breaking any laws. Compromising a host (whether by impersonation, rooting and repalcing sshd, or whatever) is (IAMAL, but I believe) illegal. At the very least, encryption requires illegal activity to get at someone's keys.
... untrusted systems in the communications path could be intercepting and forwarding the connection...
Yup. Got it.
The point of a lock is just as much authentication as it is protection. Encryption without authentication is like a strong lock that accepts any key: you don't have to break the lock to get inside. Similarly, encryption is useless for secure communication in the absence of correspondingly strong authentication.
And here is where I totally disagree. Having a good lock is no better than your key security. That's true in computers as it is in real life. Encryption without "strong authentication" means that people can't just take your stuff off the curb. They have to at least compromise your door - whether they replace it with one that logs keys and mails them off, or walk around it and in the back door and steal your stuff, or disguise your neighbor's house as yours.
I agree that there's no point in waiting for "perfect" security -- there is no such thing. All encryption can be broken; all authentication can be forged. The point is to make doing so as difficult as possible.
So far so good.
Relying on the false sense of security that unauthenticated encryption provides is ultimately worse than not using any sort of encryption in the first place.
Nope. You just equated leaving your stuff in your house (we can argue about whether the door is locked or not - doesn't much matter) with leaving your stuff on the curb. Encryption is way better than nothing - it eliminates an entire (trivial) form of attack.
If everyone used IMAPS/POPS instead of IMAP/POP, nobody would have keys stolen just because someone listened to IP traffic. That's a pretty tremendous statement.
Exactly the response I was looking for. This is not testing, and I never said it was. I was basically saying that even though I know what fingerprints are, I ignore them. The way I use ssh is clearly "not total security", and it would be easy to prove that. But you can never really prove security, can you - you can only say that you believe something is secure, and that it hasn't been stolen, yet. In the case of binary data, you can't really even say that, can you - because someone could have just made a copy and walked off with the copy. The point is that nobody but a vanishingly small number of people check their ssh fingerprints. The truth is that many, if not most people, don't understand the purpose or point of fingerprints, and don't know what it means when the fingerprints change.
Which means that fingerprints represent security to the security minded, but to the masses they generally just represent a pain and maybe an OK button to continue. Which means they are worse than not having them for the general population (at least as far as security theory goes).
Even if I did check the fingerprints, it is entirely possible that the remote system was compromised and sshd was replaced with a logging sshd. And that is the point.
I forgot to lock my front door the other day. When I returned home everything was still there. Therefore I shall never lock my front door in future. It's just too much effort and people probably aren't going to break in while I'm away.
Which is entirely true. They probably won't. And locking your door provides almost zero security - anyone who really wanted in would get in.
Encrypting traffic without verifying the endpoints is at least as good as closing your front door - versus leaving your stuff on the curb and hoping someone doesn't take it. I'd argue it is at least as good as locking your front door.
Leaving your stuff in your house is way better than on the curb. Locking your door is somewhat better than closing your door. I'd argue that encryption is somewhere around locking your door. It is not total security, but it's way better than no encryption.
I believe it is exactly because the 'security community' (I'll call them "them/they") insist on total security before saying something is worthwhile that we have so little security now. Security is a sliding scale, and encryption with unverified endpoints is better than no encryption at all - and it isway easier.
Encryption means you don't trust the machines between you and your destination. Virtually all protocols should use it. Fingerprinting means you are worried that your destination may be swapped out; it is a lot more work, and a lot harder to understand. It would be nice to use it, but I just don't think it's likely for "the masses."
That's because you skipped the hardest step - the out-of-band communication necessary to establish key authenticity. The first time you connect to a host via ssh, it displays a fingerprint and asks you if it should be trusted. Most people don't value encryption enough to even bother installing the relevant software, what makes you think that they value encryption enough to figure out a way of validating the fingerprint securely?
At the risk of summoning the ire of cryptographers everywhere: So what.
Skip the whole fingerprint validity thing - I do all the time. I never call the sysadmins of machines I'm using to make sure their self-signed certs are really them (mail, https, ssh, whatever). It has bit me 0 times. As far as I'm concerned, that answer is just an excuse to dismiss a trivially simple 90% solution. As a matter of fact, my system uses secure SMTP (what's the right acronym?) in it's MTA. Nobody validates SMTP's keys for sending - they just trust the message is going to the right machine and sends it encrypted. Folley! But it works fine.
But partial security is worse than no security!
BS. There is no total security. Someone can always root that machine and get your password.
In the meantime we have VNC in the clear, because "encryption is hard to do".
Total security is virtually impossible. Encryption is pretty easy, and we'd all be better off using more of it.
No, encryption isn't hard. OK, it is hard, but that's what libraries, encapsulation, etc, are for.
Wanna encrypt VNC?
ssh -L 5900:localhost:5900 somehost.org vnc to localhost:5900
Was that hard? No. Why isn't that built into VNC? Because it's hard? No. Most of the reasons are probably legacy export concerns. But I don't think all of it is.
Note that openssh.org is hosted in the netherlands. I don't think that's entirely coincidental.
Securing a socket in cocoa seems to be a single method call on NSStream.
So the reason it hasn't been done is that it wasn't done - and it used to involve legal issues. The reason it isn't done is that coders are lazy.
Like I said, supplying web hosting for people is something anyone should reasonably expect to be able to do with a unix machine. OS X has lots of local root exploits which make it impossible to safely provide web hosting for people (serving up only static files is not webhosting anyone will pay for). Pretending local root exploits don't matter because "people shouldn't have shell access" is rediculous. There's legitimate reasons to have local users. And besides that, local root exploit + remote non-priviledged exploit = remote root.
I agree with almost everything you're saying.
OS X has lots of local root exploits
If "a lot" means "more than 0", then I agree with you. And certainly that's what "a lot" should mean - but just saying "OSX has local root exploits" is just as true, and less inflamatory. Really, it is unclear what happened on the server in question, except that a file was modified. We don't know who owned the file, or how it was modified. We don't know from the article if the 'cracker' even rooted the box.
serving up only static files is not webhosting anyone will pay for
That's nearly true (there are plenty of domain parkers that charge for static content), but it is certainly not true that dynamic content requires clients be able to install their own scripts - see also myspace.com, etc.
If doubling nukes would only narrowly reduce emmisions, adding electrical cars probably wouldn't help much, either. As evil as burning petrol is, I suspect it's a lot more efficient than running on batteries - and if the number of electric cars increased greatly, it'd just mean more non-nuclear plants would be needed. I'm thinking that by the time the non nukes are pushing your wheels, you may actually be BEHIND in terms of pollution/mile.
I would love for someone more informed (which is to say, AT ALL) to tell me I'm wrong, and that conventional power plants are more pollution/mile efficient when paired with electric cars...
No, you just don't understand the topic at hand. If you give someone access to run cgi scripts or any other form of dynamic content, then they can do anything and everything they can do with a shell.
No, you don't understand how CGI access works. Nor do you understand about jails. Nor do you understand about running previously approved/audited/secure CGI vs. letting users install their own. Nor do you understand about running httpd (or whatever) as a chrooted user who only has read/write access to a very limited (and secure) space.
Either way you have access to execute code on the server as a non-priviledged user, and can exploit local vulnerabilities to get root. This crazy notion that setting users shells to nologin makes you "secure" is one of the most annoying linux noob misconceptions out there.
Not sure where you got the whole nologin idea from. Not sure why you're talking about linux misconceptions. The "subject at hand" was an OSX server where they allowed ssh, which is certainly a whole lot more access than CGI on a jailed or chrooted suid nobody http account - even with CGI access.
If a machine gives CGI access (install whatever you like) on it's http server, and that server is configured to chroot non priveledged accounts, and that machine gets hacked, then there IS a problem with either the OS (chroot), or the http server (overflow/whatever), or the configuration (chrooting somewhere not safe).
(note that I'm assuming that CGI is well configured to disable exec, etc)
Like I said: there are thousands of OSX machines on the net right now. Acting as servers. One of them vended ssh access and got hacked. The other thousands are doing just fine.
You are saying that providing web hosting means you should expect to be rooted all the time? People need to have unpriviledged user accounts. That should never mean they can root the system. OSX is insecure, and cannot be used as a server because of this. Its nothing at all like physical access, which gives you the ability to bypass the OS altogether.
You are mixing up "server" with "shell server". There are thousands of OSX servers on the net right now. One of those servers chose to give out shell access and got hacked. The other thousands are doing just fine.
This is just a case of the OS being broken, plain and simple.
I'm inclined to argue that because some of the tools or parts of the system are broken, it does not follow that the OS is broken. But that's getting pedantic about what really constitutes the OS.
How is the WoW scenario any different from the cleaning person scenario? How is it different than *any* task that a person *could* do for themselves, but simply doesn't enjoy, and doesn't feel is an effective use of their time, so they hire someone else?
You're absolutely right - but only partly...
If you want to pay someone to do something in game, you should make the money in game. It is destructive to the gaming environment to use "real money" to buy things in game. You are facilitating farmers, which alter the economy of the game in ways that were absolutely not intended (and are explicitly forbidden).
Yeah, as long as you don't mind your application only being usable by about 4% of computer users, Cocoa is a perfect API to develop to.
You're absolutely right. The thing that is most depressing to me is that even though *step/Cocoa has been around for nearly 20 years, nothing has managed to copy it (see below) - even though everything else seems to [me to] suck.
If you want to write something that can be used by the majority of Linux, BSD, and Windows users, on the other hand, it starts to have certain very obvious disadvantages.
While this statement is true, I could also qualify it by adding "can [but won't] be used by...". It's been my experience (some time ago, admittedly) that developing cross platform Java GUI apps is 2nd worse example of "write once, test everywhere"; the worst being HTML with css, javascript, or anything interesting in it at all.
You also fail to mention that GNUstep is cross platform for the various *nix platforms. So if all I cared about was OSX & them, I could probably mostly develop to Cocoa. Note that I have not tried porting a cocoa app to GNUstep, so I don't know how bumpy the ride is.
It may well have been less than 2 years each (certainly it seems so from your numbers); I try to be generous even when I'm pissed at the manufacturer. I'm thinking the firmware shouldn't much matter - both failed entirely - could not replace the firmware, reset, or anything (makes me think it was a blown capacitor or somesuch).
I'm CERTAIN that the 2nd one that failed had the latest firmware as of the end of last year. It blew out not long after I upgraded it (though it did run for a while).
Slashdot Mirror
How would Java evolve without Sun to "guide" it. What would Sun certifications mean without Sun there to back it up? ...
If Sun does go out of business, Java may become fragmented and start losing the solid base it has around it.
#1: you're on dope.
#2: you're on crack!
I pray that Apple, IBM, or anybody who knows anything about OO programming would buy/take/steal Java from SUN, who have failed Java like only SUN could. Hell, if M$ bought Java from SUN, we'd probably end up with better APIs. If WINE can reproduce win32, why not Java...
I blame SUN squarely for the failure that Java is today. Any by that, I mean everything from AJAX to php eating what should have been Java's lunch.
In the Linux world the software UI can be vastly different across all applications. There is no standard interface, and so the user gains much by experimenting with all portions of the software. Even then there are some similarities, such as command line switches. Teaching a user to read the documentation (hopefully it has been well written) will do them a better service then giving them the answer. If the documentation is poorly written (I have seen poorly written documentation in both Windows and Linux) it may be necessary for the user to ask for assistance. In that case (and only in that case) please try to be hospitable.
/etc/fstab by hand to get the 2nd drive to mount after reboots. In my book, Ubuntu has been added to the sucks list.
This is 3 crocks and 4 excuses.
If you run a disty, all the software you ship had better be uniform. If it isn't, your disty sucks.
If a user can't figure out 90% of what they want to do without even going to the help, your disty probably sucks.
If a user can't figure out the remaining 10% of what they want to do inside the docs, your disty certainly sucks.
If a user has to use the commandline at all, your disty sucks.
Your notion of the "user gaining greater experience" is an excuse. The user should not have to gain much of any experience with the OS - their experience should be with their business. If the system doesn't install and let the user log in and have clear and obvious access to Email, Web, and Office Suite, your disty sucks. If they don't have subtle access to system tools/config, your disty sucks.
I installed Ubuntu the other day. I had to edit the x11org.conf file by hand just ot get the monitor working. By that, I mean that when I started the computer, I was greeted with a black screen. I had to edit
"Done" in the sense that if you want to copy all your image files, you're done. Not done in the sense that if you just want to point iPhoto at a firewire drive with more gigs of images than you have space and work with the images there, you can't do it (easily).
iPhoto was amazing when it was first released. It was free, easy, and better than anything else. It continues to do what it does VERY VERY well. But I want more from my tools, now. (I wanted more back then, and suffered with the program from Cannon because it let me organize my own photos).
I'm a Mac user and I have Picasa envy.
I am being pedantic because DRM is all about being pedantic.
... to that same extent there are restrictions on everything we do.
... my point was more that I refuse to play with those that don't want to play nice with me.
My coffee did come with the restriction that I not assault someone with it
I bet your coffee came with no restrictions at all. I'm pretty sure that all the restrictions on how you interact with your coffee, and how the two of you interact with society at large are driven by society - not the coffee, nor the coffee vendor. This is substantially different from the interaction between you and non public domain media that is sold (or given) to you. Media tends to come with a lot more restrictions.
And here's my take-home point: DRM is an attempt to enfoce the restrictions media vendors have placed on you. There is nothing wrong with DRM. You may not like some of the media restrictions already present in the system. You may not like some implementations of DRM (I sure don't). But DRM is just an attempt to enforce the rules that we're already (theoretically) playing by.
Living in a civil society means we have to learn to play nice together
Amen to that.
The coffee I bought at Starbucks this morning didn't come with usage restrictions, and neither will any media I consume or use.
Well, that's one perspective. But it is a false one, or you just don't count.
The software you're using comes with restrictions unless it's public domain. It may not count as media, and it may not be usage restrictions.
The website you're accessing is media, and it does come with usage restrictions.
Virtually all music you purchase comes with usage restrictions. Certainly any music from a "big label" does. Most free music you gain access to comes with usage restrictions, too.
Same goes for video.
Same goes for text.
Finally, any music/video/text that you gain access to for free, and legally, and which is public domian, just doesn't matter in the context of the article. If you don't pay for it, it doesn't have anything to do with DRM. Even stuff you purchase which is public domain doesn't have anything to do with DRM.
To some extent I'm just picking nits. But on the other hand "The coffee I bought at Starbucks this morning didn't come with usage restrictions, and neither will any media I consume or use." just isn't true - or if so, is not important.
Finally, I'm all for "I won't purchase media that limits the way I use it, keeping in mind I will comply with the intent of copyright law."
For me it turns out that iTunes work just fine for me in that respect, and that many DVDs do not - though a decent hacked DVD that will allow me to FF whenever *I* want would fix most of that issue.
People pay for songs on iTunes because they want to feel like they are helping the artists (They're not BTW)
How do you figure? CDBaby pays out about 90% to their musicians (http://cdbaby.net/).
or they're scared enough to think that they actually might get caught for sharing music on p2p. People certainly don't use it for the "experience" or quality.
I use iTunes because it is convenient, legal, 128Kbit is good enough for me, and becaues musicians who have not screwwed themselves certainly do get money out of it.
'Rampant piracy' doesn't significantly impact sales. Over 1,000,000 sales on iTunes agrees with this (the same tunes are _all_ readily available from p2p at the same or better quality)
It's 1B sales, not 1M. And I don't think you can argue that because people buy songs on iTunes, that they would not buy more if there there were end-to-end DRM.
However, DRM also does NOT make the slightest difference to piracy, rampant or otherwise.
Sure it does. It means that Bobby can't just email the latest track by Who Done It to his friend Ted. It means that you can't casually share music in a way that is illegal, and qualifies as piracy. Good or bad, it's a true statement. DRM limits piracy to people who purposely pirate music.
Not that people who break DRM are not necessarily pirates.
The only people even the slightest bit bothered by CD copy-protection and DRM on digital music files are the legitimate music purchasers. Seeders know how to bypass it. P2P downloaders never even see it.
Sure. So what.
Why would someone waste their time downloading a 128kbps file? Most of the illegal stuff is MUCH better quality than that. The songs on BT and other p2p networks usually come from CDs, putting DRM on the ITMS files isn't stopping them from spreading because they're already being shared in mp3 format ripped from CDs.
DRM does not stop or slow anything.
1,000,000,000+ song purchases (at Apple alone) say you're wrong.
Of course you CAN listen to it on whichever device you want. It just requires a few extra steps and a loss in quality (that I certainly wouldn't notice, but I'm a head banger).
But your point is well taken.
I don't think that the music industry will abandon DRM, however. As much as it keeps users from doing whatever they want, it also slows down rampant piracy. Yes, I did say SLOWS DOWN and RAMPANT.
Apple has sold more than a billion songs, and they're all DRM'd (at least I think all of them are). If they didn't DRM them, I heartily believe that some visible percentage of them would be pirated. And 1% of a billion is still 10,000,000. If they kept only 1% of sales from being pirated to another customer, that's 10M in sales. That's a pretty big incentive to keep using DRM. And vendor lockin is something of a non-issue to the music industry while they're 'backed' by a vendor that has 80% or more of the market.
... Not that I would want my ETrade sessions to go in the clear, but, if they were to go in the clear, what would happen... traffic leaves my computer, goes straight into the backbone of my major ISP (where interception and analysis would require quite a lot of behind-the-scenes treachery), bounces around amongst other backbone routers (similar situation), and then plonks off into the ETrade server where, hopefully, they're fastidious about security.
...
t ;"><b>User ID:</b>
...
This was the telnet attitude for decades. And then people realised it was folly, and trivial, and started using ssh (with self signed keys). The problem of people sniffing telnet passwords/information went away.
Etrade's login page
<div class="HPWidG" style="float:left;margin-right:2px;text-align:lef
<br/>
<input TYPE="text" SIZE="7" NAME="USER" STYLE="width:70px;" >
</div>
<div class="HPWidG" style="float:left; text-align:left;"><b>Password:</b>
<br/>
<input TYPE="password" SIZE="9" NAME="PASSWORD" STYLE="width:85px;" >
</div>
The "behind the scenes analysis" requried for password collection amounts to a perl script that looks for http POSTs that include the key "PASSWORD". The payoff is all the passwords for all the etrade accounts. That's a pretty good arguement for encryption.
traceroute to etrade.com (12.153.224.22), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 1.205 ms 0.367 ms 0.207 ms
2 adsl-64-170-199-97.dsl.snfc21.pacbell.net (64.170.199.97) 15.531 ms 7.585 ms 7.620 ms
3 dist1-vlan50.snfc21.pbi.net (206.171.134.130) 11.203 ms 7.290 ms 10.637 ms
4 bb1-10g2-0.snfcca.sbcglobal.net (216.102.176.224) 9.620 ms 7.684 ms 7.539 ms
5 core1-p14-1.crsfca.sbcglobal.net (151.164.242.65) 8.117 ms 7.966 ms 7.592 ms
6 bb1-p8-0.crsfca.sbcglobal.net (151.164.243.2) 7.842 ms 7.942 ms 7.819 ms
7 ex1-p3-0.eqsjca.sbcglobal.net (151.164.41.101) 8.889 ms 8.642 ms 8.600 ms
8 ge-6-11.car4.sanjose1.level3.net (151.164.250.29) 8.888 ms 8.616 ms 8.810 ms
9 ae-2-52.bbr2.sanjose1.level3.net (4.68.123.33) 9.326 ms 9.651 ms ae-2-54.bbr2.sanjose1.level3.net (4.68.123.97) 9.557 ms
10 as-1-0.bbr1.atlanta1.level3.net (209.247.9.101) 75.981 ms ae-0-0.bbr2.atlanta1.level3.net (64.159.1.46) 76.257 ms 76.531 ms
11 ge-10-1.hsa1.atlanta1.level3.net (4.68.103.68) 76.305 ms ge-11-1.hsa1.atlanta1.level3.net (4.68.103.100) 76.306 ms ge-10-2.hsa1.atlanta1.level3.net (4.68.103.132) 76.977 ms
12 p0-0.etrade5.bbnplanet.net (4.24.186.6) 79.235 ms 77.394 ms 78.604 ms
So that's at least 5 domains and a dozen hosts to sniff at. I'm glad my ETrade traffic is ssl'd.
Using a net cafe would be a totally different situation as I'm relying on some $7/hr admin to not sniff traffic and install keystroke loggers.. but I would never online bank from such a spot anyways.
I do all the time - from my laptop. (you're also trusting the admin secured the NAT box against crackers - a much bigger concern, IMHO).
Flame away, but I worry less about my VOIP traffic being encrypted than I do about the material on my USB keychain, my laptop, my system being encrypted. Most of you probably have $20 door locks protecting your home machines and files.
We've avoided flammage pretty well, so far. The truth is: your voip traffic includes no passwords or security information, or anything interesting to much of anyone, really. Just like your email traffic (which is often cleartext).
The only thing that unauthenticated encryption can really prevent is accidental evesdropping. You could accomplish that by just ROT13'ing the message. I don't know about you, but if I encrypt something it's because I don't want anyone listening in -- particularly if they're listening in on purpose. The only way to ensure that is to be sure of who I'm communicating with before I start giving away my secrets. Fingerprint authentication "is way better than nothing - it eliminates an entire (trivial) form of attack." Without it no amount of encryption will protect against an intentional evesdropper.
I know people who have lost passwords because they used IMAP, not IMAPS. IMAPR13 would be very little better. SSL with any reasonable keysize is essentially uncrackable, and eliminates the eavesdropper. And I think that's an important distinction. Eavesdropping is trivial on the internet - anyone can do it without breaking any laws. Compromising a host (whether by impersonation, rooting and repalcing sshd, or whatever) is (IAMAL, but I believe) illegal. At the very least, encryption requires illegal activity to get at someone's keys.
... untrusted systems in the communications path could be intercepting and forwarding the connection...
Yup. Got it.
The point of a lock is just as much authentication as it is protection. Encryption without authentication is like a strong lock that accepts any key: you don't have to break the lock to get inside. Similarly, encryption is useless for secure communication in the absence of correspondingly strong authentication.
And here is where I totally disagree. Having a good lock is no better than your key security. That's true in computers as it is in real life. Encryption without "strong authentication" means that people can't just take your stuff off the curb. They have to at least compromise your door - whether they replace it with one that logs keys and mails them off, or walk around it and in the back door and steal your stuff, or disguise your neighbor's house as yours.
I agree that there's no point in waiting for "perfect" security -- there is no such thing. All encryption can be broken; all authentication can be forged. The point is to make doing so as difficult as possible.
So far so good.
Relying on the false sense of security that unauthenticated encryption provides is ultimately worse than not using any sort of encryption in the first place.
Nope. You just equated leaving your stuff in your house (we can argue about whether the door is locked or not - doesn't much matter) with leaving your stuff on the curb. Encryption is way better than nothing - it eliminates an entire (trivial) form of attack.
If everyone used IMAPS/POPS instead of IMAP/POP, nobody would have keys stolen just because someone listened to IP traffic. That's a pretty tremendous statement.
Woohoo! Monte-carlo testing!
Exactly the response I was looking for. This is not testing, and I never said it was. I was basically saying that even though I know what fingerprints are, I ignore them. The way I use ssh is clearly "not total security", and it would be easy to prove that. But you can never really prove security, can you - you can only say that you believe something is secure, and that it hasn't been stolen, yet. In the case of binary data, you can't really even say that, can you - because someone could have just made a copy and walked off with the copy. The point is that nobody but a vanishingly small number of people check their ssh fingerprints. The truth is that many, if not most people, don't understand the purpose or point of fingerprints, and don't know what it means when the fingerprints change.
Which means that fingerprints represent security to the security minded, but to the masses they generally just represent a pain and maybe an OK button to continue. Which means they are worse than not having them for the general population (at least as far as security theory goes).
Even if I did check the fingerprints, it is entirely possible that the remote system was compromised and sshd was replaced with a logging sshd. And that is the point.
I forgot to lock my front door the other day. When I returned home everything was still there. Therefore I shall never lock my front door in future. It's just too much effort and people probably aren't going to break in while I'm away.
Which is entirely true. They probably won't. And locking your door provides almost zero security - anyone who really wanted in would get in.
Encrypting traffic without verifying the endpoints is at least as good as closing your front door - versus leaving your stuff on the curb and hoping someone doesn't take it. I'd argue it is at least as good as locking your front door.
Leaving your stuff in your house is way better than on the curb. Locking your door is somewhat better than closing your door. I'd argue that encryption is somewhere around locking your door. It is not total security, but it's way better than no encryption.
I believe it is exactly because the 'security community' (I'll call them "them/they") insist on total security before saying something is worthwhile that we have so little security now. Security is a sliding scale, and encryption with unverified endpoints is better than no encryption at all - and it is way easier.
Encryption means you don't trust the machines between you and your destination. Virtually all protocols should use it. Fingerprinting means you are worried that your destination may be swapped out; it is a lot more work, and a lot harder to understand. It would be nice to use it, but I just don't think it's likely for "the masses."
That's because you skipped the hardest step - the out-of-band communication necessary to establish key authenticity. The first time you connect to a host via ssh, it displays a fingerprint and asks you if it should be trusted. Most people don't value encryption enough to even bother installing the relevant software, what makes you think that they value encryption enough to figure out a way of validating the fingerprint securely?
At the risk of summoning the ire of cryptographers everywhere:
So what.
Skip the whole fingerprint validity thing - I do all the time. I never call the sysadmins of machines I'm using to make sure their self-signed certs are really them (mail, https, ssh, whatever). It has bit me 0 times. As far as I'm concerned, that answer is just an excuse to dismiss a trivially simple 90% solution. As a matter of fact, my system uses secure SMTP (what's the right acronym?) in it's MTA. Nobody validates SMTP's keys for sending - they just trust the message is going to the right machine and sends it encrypted. Folley! But it works fine.
But partial security is worse than no security!
BS. There is no total security. Someone can always root that machine and get your password.
In the meantime we have VNC in the clear, because "encryption is hard to do".
Total security is virtually impossible. Encryption is pretty easy, and we'd all be better off using more of it.
No, encryption isn't hard. OK, it is hard, but that's what libraries, encapsulation, etc, are for.
Wanna encrypt VNC?
ssh -L 5900:localhost:5900 somehost.org
vnc to localhost:5900
Was that hard? No.
Why isn't that built into VNC? Because it's hard? No. Most of the reasons are probably legacy export concerns. But I don't think all of it is.
Note that openssh.org is hosted in the netherlands. I don't think that's entirely coincidental.
Securing a socket in cocoa seems to be a single method call on NSStream.
So the reason it hasn't been done is that it wasn't done - and it used to involve legal issues. The reason it isn't done is that coders are lazy.
And I can't buy a Jaguar from Chevy, or a Apple PowerBook from eMachines either. I mean, what's up with that?
Actually, pay them enough and I think you can. I mean - I don't see why not.
I'm not sure if that is true or not of the music industry. Music copyright is a mysterious thing.
That's great information. Thanks for an informative followup.
Like I said, supplying web hosting for people is something anyone should reasonably expect to be able to do with a unix machine. OS X has lots of local root exploits which make it impossible to safely provide web hosting for people (serving up only static files is not webhosting anyone will pay for). Pretending local root exploits don't matter because "people shouldn't have shell access" is rediculous. There's legitimate reasons to have local users. And besides that, local root exploit + remote non-priviledged exploit = remote root.
I agree with almost everything you're saying.
OS X has lots of local root exploits
If "a lot" means "more than 0", then I agree with you. And certainly that's what "a lot" should mean - but just saying "OSX has local root exploits" is just as true, and less inflamatory. Really, it is unclear what happened on the server in question, except that a file was modified. We don't know who owned the file, or how it was modified. We don't know from the article if the 'cracker' even rooted the box.
serving up only static files is not webhosting anyone will pay for
That's nearly true (there are plenty of domain parkers that charge for static content), but it is certainly not true that dynamic content requires clients be able to install their own scripts - see also myspace.com, etc.
If doubling nukes would only narrowly reduce emmisions, adding electrical cars probably wouldn't help much, either. As evil as burning petrol is, I suspect it's a lot more efficient than running on batteries - and if the number of electric cars increased greatly, it'd just mean more non-nuclear plants would be needed. I'm thinking that by the time the non nukes are pushing your wheels, you may actually be BEHIND in terms of pollution/mile.
I would love for someone more informed (which is to say, AT ALL) to tell me I'm wrong, and that conventional power plants are more pollution/mile efficient when paired with electric cars...
No, you just don't understand the topic at hand. If you give someone access to run cgi scripts or any other form of dynamic content, then they can do anything and everything they can do with a shell.
No, you don't understand how CGI access works. Nor do you understand about jails. Nor do you understand about running previously approved/audited/secure CGI vs. letting users install their own. Nor do you understand about running httpd (or whatever) as a chrooted user who only has read/write access to a very limited (and secure) space.
Either way you have access to execute code on the server as a non-priviledged user, and can exploit local vulnerabilities to get root. This crazy notion that setting users shells to nologin makes you "secure" is one of the most annoying linux noob misconceptions out there.
Not sure where you got the whole nologin idea from. Not sure why you're talking about linux misconceptions. The "subject at hand" was an OSX server where they allowed ssh, which is certainly a whole lot more access than CGI on a jailed or chrooted suid nobody http account - even with CGI access.
If a machine gives CGI access (install whatever you like) on it's http server, and that server is configured to chroot non priveledged accounts, and that machine gets hacked, then there IS a problem with either the OS (chroot), or the http server (overflow/whatever), or the configuration (chrooting somewhere not safe).
(note that I'm assuming that CGI is well configured to disable exec, etc)
Like I said: there are thousands of OSX machines on the net right now. Acting as servers. One of them vended ssh access and got hacked. The other thousands are doing just fine.
You are saying that providing web hosting means you should expect to be rooted all the time? People need to have unpriviledged user accounts. That should never mean they can root the system. OSX is insecure, and cannot be used as a server because of this. Its nothing at all like physical access, which gives you the ability to bypass the OS altogether.
You are mixing up "server" with "shell server". There are thousands of OSX servers on the net right now. One of those servers chose to give out shell access and got hacked. The other thousands are doing just fine.
This is just a case of the OS being broken, plain and simple.
I'm inclined to argue that because some of the tools or parts of the system are broken, it does not follow that the OS is broken. But that's getting pedantic about what really constitutes the OS.
How is the WoW scenario any different from the cleaning person scenario? How is it different than *any* task that a person *could* do for themselves, but simply doesn't enjoy, and doesn't feel is an effective use of their time, so they hire someone else?
You're absolutely right - but only partly...
If you want to pay someone to do something in game, you should make the money in game. It is destructive to the gaming environment to use "real money" to buy things in game. You are facilitating farmers, which alter the economy of the game in ways that were absolutely not intended (and are explicitly forbidden).
Yeah, as long as you don't mind your application only being usable by about 4% of computer users, Cocoa is a perfect API to develop to.
You're absolutely right. The thing that is most depressing to me is that even though *step/Cocoa has been around for nearly 20 years, nothing has managed to copy it (see below) - even though everything else seems to [me to] suck.
If you want to write something that can be used by the majority of Linux, BSD, and Windows users, on the other hand, it starts to have certain very obvious disadvantages.
While this statement is true, I could also qualify it by adding "can [but won't] be used by...". It's been my experience (some time ago, admittedly) that developing cross platform Java GUI apps is 2nd worse example of "write once, test everywhere"; the worst being HTML with css, javascript, or anything interesting in it at all.
You also fail to mention that GNUstep is cross platform for the various *nix platforms. So if all I cared about was OSX & them, I could probably mostly develop to Cocoa. Note that I have not tried porting a cocoa app to GNUstep, so I don't know how bumpy the ride is.
Each tool kit offers advantages and disadvantages that make selecting one more appropriate, given your needs and intended audience.
Having used them, I'm pretty sure that each just has a different set of disadvantages.
Spoiled after 15+ years of [NeXT|Open|GNU]Step/Cocoa, I guess.
It may well have been less than 2 years each (certainly it seems so from your numbers); I try to be generous even when I'm pissed at the manufacturer. I'm thinking the firmware shouldn't much matter - both failed entirely - could not replace the firmware, reset, or anything (makes me think it was a blown capacitor or somesuch).
I'm CERTAIN that the 2nd one that failed had the latest firmware as of the end of last year. It blew out not long after I upgraded it (though it did run for a while).