IDE's don't allow you to write software using "mostly mouse clicks". If you think so then you haven't used a decent IDE
In fact, most of the functionality of an IDE should work pretty much independent of whatever libraries and clicky widgets you'd be using. To whit, taking care of CVS, taking care of builds, navigating packages/modules, setting breakpoints and doing the step-through thing while debugging, context-highlighting (oh noes, vim does that, that's evil), predictive input/listboxes that let you pick methods/variables that actually exist/are in scope preventing you from making typos all the time, refactoring, pretty-printing, etc. But for the last 3 features, these things have existed since ye olde times of Turbo Pascal 4 or thereabouts.
You can have a project that compiles just fine using only stock tools from text source files, but use an IDE to make developing a bit (a lot) nicer. Vim and emacs are nice, sure, but they're general purpose text editors. Kinda of like painting the mona lisa with house paint and 2 inch brushes. It can be done, but why would you bother, given that there are specialized tools?
Second, you have to do it in the right order, at about the same time. If you update the server, then clients who schedule appointments will be off until they update.
Huh? How does that happen, assuming you're a good boy and using timestamps in UTC in the first place? You know, the ones that look like "Sat, 3 Mar 2007 08:06:08 -0800 (PST)", the ones you find in e-mail headers for example?
If Outlook can't cope with that, how can it cope with people in different offices with different timezones? Or people with laptops?
.. doesnt somebody actually create a distributed brute force on Windows activation. How many windows machinès in the world? That adds up to some pretty powerful attack.
Except that you need an activation code for every machine. So adding machines doesn't only add to the processing power by 1, but also increases the workload by 1. This is of course assuming people who don't need to get a copy of windows activated won't feel the urge to join, which seems fairly likely.
Brute force is always the last resort, and not really attractive. What was interesting about this hack is that apparently the windows activation scheme didn't limit the amount of tries (per second).
Holy crap. You should be able to pull up that information right from the device manager, really. Bad microsoft for not making it as accesible as, say UnknownDevices does. Why that KnowledgeBase article doesn't just point you to the freeware tool is any one's guess.
With all these performance-improving things, shouldn't performance actually, you know, be improved?
Of course not. That's why they're called SuperFetch, ReadyBoost, ReadyBoot, and ReadyDrive.
My motherboard for example, comes with: BuzzFree, LifePro, PowerPro, SpeedStar, and ActiveArmor. I'm pretty sure all that means is that it, by now, obsolete.
If these features were of any use besides being marketing snakeoil and/or painfully obvious, they'd be called "the hvuk__k() tweak" or "deloop_64" or "-O3" or something.
They're a resellers as in: they are not themselves an ICANN accredited registrar. (There are a lot of eNom resellers; back in the day, eNom was handing out reseller contracts like candy, with massive discounts on volume.) Stuff like hosting etc. is bound not to happen through eNom, but perhaps some subset is shared amongst resellers (like the private registrations; these are part of the eNom XML API interface. Something called 'Name-My-Phone' is too, but namecheap doesn't seem to bother with it).
I had a domain name registered at godaddy for a while, but I left, exactly because of the horror stories from their (alleged?) "we'll pull any site that generates complaints without investigating one bit" policy. I don't host anything controversial (in fact, I use my domainnames almost exclusively for e-mail), but all it takes is someone deciding to (fake) some spam advertising your domainname, and you can kiss it goodbye.
Something godaddy pulled on me was that when it came time to renew, the registration rates offered to me were higher than for new customers - and no discount for 10 year registrations.
So, after some forum reading, and weeding out suspiciously cheap registrars, I decided on namecheap. As the name implies, they're cheap, $8.88 per domain per year. At the time they were slightly more expensive than godaddy, now they're slightly cheaper.
They're an eNom reseller, so they probably offer the exact same services as any other eNom reseller, but they're cheap.
"Will ISPs still be able to throttle WorldWideWeb traffic now that a significant proportion of it is legit?.. Do they want to irritate their BitTorrent-using contingent, or let WorldWideWeb flow unhindered at the risk degrading the experience of those who use e-mail and telnet only?'"
When people are designing cryptographic protocols, they always assume a perfect cipher, a perfect hash, etc. hmm, i think only and idiot would do that
Cryptographers (even some who aren't idiots) disagree.
Note the distinction between designing a protocol, and designing the cipher itself.
All decently designed ciphers contain (sometimes huge) safety margins. After all, you should be able to keep something secret for at least the rest of your life, if not your kids' lives, to save embarassement if nothing else.
That's why, when "breaks" are announced, you'll often notice the words "reduced rounds" - in fact, most breaks are of deliberately weakened algorithms, because studying the fullblown algorithm is too complicated. The full-rounds version often holds up against breaks that work on reduced rounds.
It's not like cryptographers were born yesterday, exactly.
However, when you're designing a protocol (such as TLS) the last thing you want to do, is design it around a cipher/hash, especially if you know it to be broken. When designing a protocol, you're best off not even specifying the exact ciphers/hashes to be used - just take a state-of-the-art, well-designed and peer-reviewed cipher off the shelve.
The alternative would be for example to say "ok, this protocol MUST use MD5, but we know MD5 to be weak in some circumstances, so we'll reject input that has too many zeroes". That sort of thing can only weaken your protocol. And you'll end up with 100 versions of your protocol.
If a cipher/hash needs a randomly generated number, only used once, it should be part of the cipher/hash specification. If it doesn't work too well on certain inputs, it should be fixed before it's considered to be used in a protocol.
That's why you'll see e.g. TLS (and SSH) accepts all sorts of ciphers and key-lengths. If some of the ciphers or hashes turn out to be crap, fine, you can just disable them.
You want low latency in your game traffic? How about smooth VoIP conversations?
The ISP only effectively controls the last mile. There's no consensus about how to do QoS upstream, anyway.
Guess what, my dinky router is perfectly capable of controlling that last mile, too. It has a firewall built in. ISPs don't need to be able to filter ports, since the routers the public already has does that pretty well already. Why should the ISPs be in control of QoS?
They shouldn't, it should be a user setting.
Net neutrality legislation won't prevent me from adding QoS labels to my outgoing traffic either. Just so long as no one who owns pipes alters the QoS data (either interpret it correctly, or ignore it) there's no harm, no foul.
User hardware/software is perfectly capable of making QoS happen. The ISP should stay out of the whole affair.
Hashes will always have collisions, if (and only if) the input space is larger than the output space, sure.
Are you sure and the "only if" part? Couldn't there be a hash function which maps several inputs to the same output even if are less inputs than outputs?
Hashes with an input space equal to or smaller than the output space will not always have collisions. I could've stated that more clearly.
Obviously a badly designed "hash"-function that always outputs 0xDEADBEEF has collisions.
I'm not expecting 144-bits security in the scenario you paint. I'm expecting that, if one hash turns out to be fundamentally flawed, it will offer 0 bits security for all practical purposes, and at least you have the other hash to rely on. So if you'd use SHA1 and MD5 together (which you shouldn't, since they're both known to have vulnerabilities) I'd expect SHA1 to be the upper bound.
It was pointed out in the questions that another reason for concatenating hashes is not to try to increase the theoretical security, but for practical considerations in case one of them gets broken. This is probably why SSL, for example, used MD5 along with SHA1. That is still a valid reason.
Note expecially that Joux's results pertain to iterative hashes, which is pretty much all of them. If you would have been using a fundamentally different hash alongside SHA1/MD5, etc., that second hash could well have turned out not to be vulnerable to Joux's attack.
Honestly, using SHA-512 is probably more secure than using a bunch of hashes concatenated together.
Including length seems like common sense though. I'm not quite convinced it's a bad idea to use multiple hashes, as long as they are all state-of-the-art AND fundamentally different, not just re-hashes of the same concept. E.g. SHA-512 AND whirlpool.
It's only a matter of time before other hashes "fall" really - you're taking a large vector space, and mapping to a smaller one. You're in a "state of mathematical sin" relying on that for validation:-)
Hashes will always have collisions, if (and only if) the input space is larger than the output space, sure.
Nevertheless, if a hash were perfect, there would be no more efficient way to find a collision than brute force.
When people are designing cryptographic protocols, they always assume a perfect cipher, a perfect hash, etc.
Typically, what these attacks mean, is that some one found a short cut, so that actually forging a signature or deciphering text would take less than brute force. How much of a big deal this is, depends on how much the difference is, and also on whether it exposes any weaknesses (e.g. 'if your input starts with 123, you'll always get the same hash, whatever comes next').
sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color
Ironically, it's much easier to establish an individual's identity (many databases that you can look in and merge, require multiple forms of ID, etc.) than the fact whether an individual is actually a proper agent of some huge megacorporation.
I don't know specifically which bit in the certificate makes the address bar green, but the idea of these certificates is that the CA took extra super care to make sure they weren't issued to some bum, but to the people the certificate says it was issued to.
The example in the article immediately points out a failure of this idea. Go to entrust.com and your address bar turns green. And who is the CA that has verified that this site is really operated by entrust? "Entrust or an independent local registration authority has verified that Entrust Inc is an existing business and owns or operates the domain name www.entrust.com".. Yeah. So, this is basically a self-signed certificate, but it turns up green, because you're supposed to trust entrust, because you're supposed to trust entrust, because you're supposed to trust internet explorer.
Meanwhile, their 'extra validation' CPS states that they offer no warranties or guarantees, nor any detail about what they DO do to make extra super sure they don't issue certificates to some random Joe.
I think we all understand the desire for QoS application tagging, to support high bandwidth low latency streams. I think net neutrality folks would be willing to accept a compromise which allowed for a public QoS standard. The real issue is transparency and censorship.
I'm for Net Neutrality, and I have no issue with QoS whatsoever.
For example; say I can login to my ISPs website, and edit my QoS settings. By default, no QoS, but I choose to prioritize VOIP. Maybe even the ISPs own VOIP service. Maybe I want to prioritize bittorrent. Now say that my ISP actually respects those settings. Hey, perhaps even the backbones do.
No harm, no foul. Yes, even if I choose to prioritize the ISP's own services. The point is, they're not being given the opportunity to degrade other's services. Unless I'm OK with that. If I'm not, I change my settings. Simple.
This is entirely the same as being able to run your own firewall, or spamfilter. If I choose to blackhole vonage.com, fine. If my ISP choses to do so - not fine.
The whole Akamai argument is a great argument for a non-neutral except for the minor point that Akamai doesn't in any way violate net neutrality.
That's not the point of the Akamai argument. The point is that Akamai is cool, and if you would allow for non-net-neutrality, you could have more cool just like Akamia, but at the next lower level of the internet.
Akamai isn't the only system of this kind. DNS is distributed and cacheing. Reaching DNS rootservers works by routing your packets to the closest server, even though they have the same IP number. IRC sends chat data between servers, and then from each server to multiple clients, so you don't have n*n connections, kinda like multicast. Then there's your transparant proxies, loadbalancers, mirrors, etc. Usenet distributes and caches content. E-mail is delivered to your ISP even when your computer is switched off (this was a big deal in the day). You can choose for an ISP that deploys MPLS for you, or one with better usenet servers. None of that has to violate net neutrality in any way, shape or form.
Akamai, or any of those other things is cool. Your ISP artificially degrading your access to its competitors, and giving his own services priority, isn't cool.
This is much like sex is cool (yay!) but incest isn't.
I don't know what this guy is pretending to be, a lawyer or a geek, but his arguments are all extremely uninformed.
1) "The number of possible connections has gone up quadratically with the number of total users; so the Internet has become much more complex."
So? Is this a technological problem that is in any way related to the issue of Net-Neutrality? We seem to be handling this just fine at the moment, and if we run into problems we switch to IPv6, don't we?
2) People use different applications with different QoS needs. Providers should be allowed to provide priority to certain types of traffic.
Again, entirely unrelated to the issue of Net-Neutrality. You can get all sorts of QoS deals from ISPs, e.g. MPLS. The issue with Net-Neutrality is the ISP giving priority to their own traffic, so they gain an unnatural advantage over competing services not owned by the ISP - a vertical monopoly.
3) TCP/IP is obsolete, and companies should be allowed to experiment with protocols.
TCP/IP is not only working just fine, but it's adapted all the time. It's up to version 4, and IPv6 can be implemented by any one who chooses to. There are many protocols that use UDP over IP, and even many protocols that use IP, but neither TCP nor UDP. The past few years there have been many quiet revolutions in protocols; from dialling in using SLIP to PPP, to getting cable (docsis 1.0) to getting ADSL, then ADSL2+, p2p protocols like bittorrent emerging and chanching just about daily, people using VOIP, companies deploying VOIP on an enterprise scale (right down to global telecommunications giants switching to, egads no!, an all-IP backbone for voice).
Again, this has nothing to do with preventing vertical monopolies.
Then there are some things that just paint him as someone who has no idea what he's talking about..
How to achieve QoS? He points out that TCP (the obsolete protocol, mind you) has a Type of Service field! How ironic. Wasn't he argueing we need new protocols? Like, oh, I don't know, MPLS, which he seems to be unaware of? But then, he also seems to be under the impression that you can't choose between ISPs that offer different levels of QoS, which is patently untrue. (Nor would they not be allowed to exist if we had Net Neutrality. They just would be forced to be fair)
Then he goes on to say Akamai (not an internet service provider, not engaging much in vertical monopolies) is "an entirely different architecture". No it's not, they use DNS and obsolete TCP just like anybody else. There is nothing at all new about this architecture, mind you - in fact, it's pretty much what usenet does. We used to call sites with content closer to you "mirrors". The only nifty thing akamai adds is redirecting you to the nearest host on the DNS level. Oh, in fact, DNS root servers do the same thing on a BGP level even. And they also cache their zones. Still neutral, though.
"deep packet inspections... would allow a degree of non-neutrality" - there again, confusing anti-QoS with anti-vertical-monopoly (Net Neutrality); in fact, using "non-neutrality" as a synonym for QoS. It's not.
Oh, and the question about neutrality? Who controls the QoS, in his grand vision? He doesn't even answer it.
If you want to be anti-Net-Neutrality, fine, argue that vertical monopolies are good, or that vertical monopolies won't happen, or that Net-Neutrality laws wouldn't be effective. Don't bring up straw man arguments.
It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.
Strangely enough, the parent post mentions something along the lines of ( in addition to the use of a "Smart Card" plugged into the machine to gain access ).
The best scheme is to have a smart card (preferably with an attached input device) that unlocks its public key authentication mechanism based on the entry of a password or PIN. A PIN should really suffice, as a smart card can simply lock out any repeated attempts at guessing after the first 3 tries. (It should still be fairly tamper resistant, but a smart card is in itself much better than, say, an easily copied magnetic stripe card).
One of the reasons to use smartcards in the first place is that the card can protect itself to some degree - which means you can make do with a PIN rather than a huge, complex password, which people WILL write down.
IANAL but wouldn't it be convenient for the RIAA to have a judge declare allofmp3.com illegal, so they can subpoena credit card company records of allofmp3 purchasers (AKA people who actually paid, albeit little, and in a different country, for music AKA more customers to sue)?
Slashdot Mirror
IDE's don't allow you to write software using "mostly mouse clicks". If you think so then you haven't used a decent IDE
In fact, most of the functionality of an IDE should work pretty much independent of whatever libraries and clicky widgets you'd be using. To whit, taking care of CVS, taking care of builds, navigating packages/modules, setting breakpoints and doing the step-through thing while debugging, context-highlighting (oh noes, vim does that, that's evil), predictive input/listboxes that let you pick methods/variables that actually exist/are in scope preventing you from making typos all the time, refactoring, pretty-printing, etc. But for the last 3 features, these things have existed since ye olde times of Turbo Pascal 4 or thereabouts.
You can have a project that compiles just fine using only stock tools from text source files, but use an IDE to make developing a bit (a lot) nicer. Vim and emacs are nice, sure, but they're general purpose text editors. Kinda of like painting the mona lisa with house paint and 2 inch brushes. It can be done, but why would you bother, given that there are specialized tools?
Second, you have to do it in the right order, at about the same time. If you update the server, then clients who schedule appointments will be off until they update.
Huh? How does that happen, assuming you're a good boy and using timestamps in UTC in the first place? You know, the ones that look like "Sat, 3 Mar 2007 08:06:08 -0800 (PST)", the ones you find in e-mail headers for example?
If Outlook can't cope with that, how can it cope with people in different offices with different timezones? Or people with laptops?
.. doesnt somebody actually create a distributed brute force on Windows activation. How many windows machinès in the world? That adds up to some pretty powerful attack.
Except that you need an activation code for every machine. So adding machines doesn't only add to the processing power by 1, but also increases the workload by 1. This is of course assuming people who don't need to get a copy of windows activated won't feel the urge to join, which seems fairly likely.
Brute force is always the last resort, and not really attractive. What was interesting about this hack is that apparently the windows activation scheme didn't limit the amount of tries (per second).
You can find out by following the instructions at
http://support.microsoft.com/kb/298837
Holy crap. You should be able to pull up that information right from the device manager, really. Bad microsoft for not making it as accesible as, say UnknownDevices does. Why that KnowledgeBase article doesn't just point you to the freeware tool is any one's guess.
With all these performance-improving things, shouldn't performance actually, you know, be improved?
Of course not. That's why they're called SuperFetch, ReadyBoost, ReadyBoot, and ReadyDrive.
My motherboard for example, comes with: BuzzFree, LifePro, PowerPro, SpeedStar, and ActiveArmor. I'm pretty sure all that means is that it, by now, obsolete.
If these features were of any use besides being marketing snakeoil and/or painfully obvious, they'd be called "the hvuk__k() tweak" or "deloop_64" or "-O3" or something.
They're a resellers as in: they are not themselves an ICANN accredited registrar.
(There are a lot of eNom resellers; back in the day, eNom was handing out reseller contracts like candy, with massive discounts on volume.)
Stuff like hosting etc. is bound not to happen through eNom, but perhaps some subset is shared amongst resellers (like the private registrations; these are part of the eNom XML API interface. Something called 'Name-My-Phone' is too, but namecheap doesn't seem to bother with it).
A quick google turns up a lot of registrars.
I had a domain name registered at godaddy for a while, but I left, exactly because of the horror stories from their (alleged?) "we'll pull any site that generates complaints without investigating one bit" policy. I don't host anything controversial (in fact, I use my domainnames almost exclusively for e-mail), but all it takes is someone deciding to (fake) some spam advertising your domainname, and you can kiss it goodbye.
Something godaddy pulled on me was that when it came time to renew, the registration rates offered to me were higher than for new customers - and no discount for 10 year registrations.
So, after some forum reading, and weeding out suspiciously cheap registrars, I decided on namecheap. As the name implies, they're cheap, $8.88 per domain per year. At the time they were slightly more expensive than godaddy, now they're slightly cheaper.
They're an eNom reseller, so they probably offer the exact same services as any other eNom reseller, but they're cheap.
"Will ISPs still be able to throttle WorldWideWeb traffic now that a significant proportion of it is legit? .. Do they want to irritate their BitTorrent-using contingent, or let WorldWideWeb flow unhindered at the risk degrading the experience of those who use e-mail and telnet only?'"
Cryptographers (even some who aren't idiots) disagree.
Note the distinction between designing a protocol, and designing the cipher itself.
All decently designed ciphers contain (sometimes huge) safety margins. After all, you should be able to keep something secret for at least the rest of your life, if not your kids' lives, to save embarassement if nothing else.
That's why, when "breaks" are announced, you'll often notice the words "reduced rounds" - in fact, most breaks are of deliberately weakened algorithms, because studying the fullblown algorithm is too complicated. The full-rounds version often holds up against breaks that work on reduced rounds.
It's not like cryptographers were born yesterday, exactly.
However, when you're designing a protocol (such as TLS) the last thing you want to do, is design it around a cipher/hash, especially if you know it to be broken. When designing a protocol, you're best off not even specifying the exact ciphers/hashes to be used - just take a state-of-the-art, well-designed and peer-reviewed cipher off the shelve.
The alternative would be for example to say "ok, this protocol MUST use MD5, but we know MD5 to be weak in some circumstances, so we'll reject input that has too many zeroes". That sort of thing can only weaken your protocol. And you'll end up with 100 versions of your protocol.
If a cipher/hash needs a randomly generated number, only used once, it should be part of the cipher/hash specification. If it doesn't work too well on certain inputs, it should be fixed before it's considered to be used in a protocol.
That's why you'll see e.g. TLS (and SSH) accepts all sorts of ciphers and key-lengths. If some of the ciphers or hashes turn out to be crap, fine, you can just disable them.
The ISP only effectively controls the last mile. There's no consensus about how to do QoS upstream, anyway.
Guess what, my dinky router is perfectly capable of controlling that last mile, too. It has a firewall built in. ISPs don't need to be able to filter ports, since the routers the public already has does that pretty well already. Why should the ISPs be in control of QoS?
They shouldn't, it should be a user setting.
Net neutrality legislation won't prevent me from adding QoS labels to my outgoing traffic either. Just so long as no one who owns pipes alters the QoS data (either interpret it correctly, or ignore it) there's no harm, no foul.
User hardware/software is perfectly capable of making QoS happen. The ISP should stay out of the whole affair.
Hashes with an input space equal to or smaller than the output space will not always have collisions.
I could've stated that more clearly.
Obviously a badly designed "hash"-function that always outputs 0xDEADBEEF has collisions.
Or, another way to put it, from The Cryptography Mailing List:
Note expecially that Joux's results pertain to iterative hashes, which is pretty much all of them. If you would have been using a fundamentally different hash alongside SHA1/MD5, etc., that second hash could well have turned out not to be vulnerable to Joux's attack.
Including length seems like common sense though.
I'm not quite convinced it's a bad idea to use multiple hashes, as long as they are all state-of-the-art AND fundamentally different, not just re-hashes of the same concept. E.g. SHA-512 AND whirlpool.
Hashes will always have collisions, if (and only if) the input space is larger than the output space, sure.
Nevertheless, if a hash were perfect, there would be no more efficient way to find a collision than brute force.
When people are designing cryptographic protocols, they always assume a perfect cipher, a perfect hash, etc.
Typically, what these attacks mean, is that some one found a short cut, so that actually forging a signature or deciphering text would take less than brute force. How much of a big deal this is, depends on how much the difference is, and also on whether it exposes any weaknesses (e.g. 'if your input starts with 123, you'll always get the same hash, whatever comes next').
Wireless transfer of energy through a magnetic field, is SO 1998.
No, really, my toothbrush does it.
Of course, back in the old days we used to call them 'keywords'.
sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color
Ironically, it's much easier to establish an individual's identity (many databases that you can look in and merge, require multiple forms of ID, etc.) than the fact whether an individual is actually a proper agent of some huge megacorporation.
I don't know specifically which bit in the certificate makes the address bar green, but the idea of these certificates is that the CA took extra super care to make sure they weren't issued to some bum, but to the people the certificate says it was issued to.
The example in the article immediately points out a failure of this idea. Go to entrust.com and your address bar turns green. And who is the CA that has verified that this site is really operated by entrust? "Entrust or an independent local registration authority has verified that Entrust Inc is an existing business and owns or operates the domain name www.entrust.com".. Yeah. So, this is basically a self-signed certificate, but it turns up green, because you're supposed to trust entrust, because you're supposed to trust entrust, because you're supposed to trust internet explorer.
Meanwhile, their 'extra validation' CPS states that they offer no warranties or guarantees, nor any detail about what they DO do to make extra super sure they don't issue certificates to some random Joe.
Who cares about TLDs, what I want to know is who controls the IPs?
It's one of the IANA functions contracted out to ICANN, but it's implemented by the RIRs.
I think we all understand the desire for QoS application tagging, to support high bandwidth low latency streams. I think net neutrality folks would be willing to accept a compromise which allowed for a public QoS standard. The real issue is transparency and censorship.
I'm for Net Neutrality, and I have no issue with QoS whatsoever.
For example; say I can login to my ISPs website, and edit my QoS settings. By default, no QoS, but I choose to prioritize VOIP. Maybe even the ISPs own VOIP service. Maybe I want to prioritize bittorrent. Now say that my ISP actually respects those settings. Hey, perhaps even the backbones do.
No harm, no foul. Yes, even if I choose to prioritize the ISP's own services. The point is, they're not being given the opportunity to degrade other's services. Unless I'm OK with that. If I'm not, I change my settings. Simple.
This is entirely the same as being able to run your own firewall, or spamfilter. If I choose to blackhole vonage.com, fine. If my ISP choses to do so - not fine.
The whole Akamai argument is a great argument for a non-neutral except for the minor point that Akamai doesn't in any way violate net neutrality.
That's not the point of the Akamai argument. The point is that Akamai is cool, and if you would allow for non-net-neutrality, you could have more cool just like Akamia, but at the next lower level of the internet.
Akamai isn't the only system of this kind. DNS is distributed and cacheing. Reaching DNS rootservers works by routing your packets to the closest server, even though they have the same IP number. IRC sends chat data between servers, and then from each server to multiple clients, so you don't have n*n connections, kinda like multicast. Then there's your transparant proxies, loadbalancers, mirrors, etc. Usenet distributes and caches content. E-mail is delivered to your ISP even when your computer is switched off (this was a big deal in the day). You can choose for an ISP that deploys MPLS for you, or one with better usenet servers. None of that has to violate net neutrality in any way, shape or form.
Akamai, or any of those other things is cool.
Your ISP artificially degrading your access to its competitors, and giving his own services priority, isn't cool.
This is much like sex is cool (yay!) but incest isn't.
I don't know what this guy is pretending to be, a lawyer or a geek, but his arguments are all extremely uninformed.
... would allow a degree of non-neutrality" - there again, confusing anti-QoS with anti-vertical-monopoly (Net Neutrality); in fact, using "non-neutrality" as a synonym for QoS. It's not.
1) "The number of possible connections has gone up quadratically with the number of total users; so the Internet has become much more complex."
So? Is this a technological problem that is in any way related to the issue of Net-Neutrality? We seem to be handling this just fine at the moment, and if we run into problems we switch to IPv6, don't we?
2) People use different applications with different QoS needs. Providers should be allowed to provide priority to certain types of traffic.
Again, entirely unrelated to the issue of Net-Neutrality. You can get all sorts of QoS deals from ISPs, e.g. MPLS. The issue with Net-Neutrality is the ISP giving priority to their own traffic, so they gain an unnatural advantage over competing services not owned by the ISP - a vertical monopoly.
3) TCP/IP is obsolete, and companies should be allowed to experiment with protocols.
TCP/IP is not only working just fine, but it's adapted all the time. It's up to version 4, and IPv6 can be implemented by any one who chooses to. There are many protocols that use UDP over IP, and even many protocols that use IP, but neither TCP nor UDP. The past few years there have been many quiet revolutions in protocols; from dialling in using SLIP to PPP, to getting cable (docsis 1.0) to getting ADSL, then ADSL2+, p2p protocols like bittorrent emerging and chanching just about daily, people using VOIP, companies deploying VOIP on an enterprise scale (right down to global telecommunications giants switching to, egads no!, an all-IP backbone for voice).
Again, this has nothing to do with preventing vertical monopolies.
Then there are some things that just paint him as someone who has no idea what he's talking about..
How to achieve QoS? He points out that TCP (the obsolete protocol, mind you) has a Type of Service field! How ironic. Wasn't he argueing we need new protocols? Like, oh, I don't know, MPLS, which he seems to be unaware of? But then, he also seems to be under the impression that you can't choose between ISPs that offer different levels of QoS, which is patently untrue. (Nor would they not be allowed to exist if we had Net Neutrality. They just would be forced to be fair)
Then he goes on to say Akamai (not an internet service provider, not engaging much in vertical monopolies) is "an entirely different architecture". No it's not, they use DNS and obsolete TCP just like anybody else. There is nothing at all new about this architecture, mind you - in fact, it's pretty much what usenet does. We used to call sites with content closer to you "mirrors". The only nifty thing akamai adds is redirecting you to the nearest host on the DNS level. Oh, in fact, DNS root servers do the same thing on a BGP level even. And they also cache their zones. Still neutral, though.
"deep packet inspections
Oh, and the question about neutrality? Who controls the QoS, in his grand vision? He doesn't even answer it.
If you want to be anti-Net-Neutrality, fine, argue that vertical monopolies are good, or that vertical monopolies won't happen, or that Net-Neutrality laws wouldn't be effective. Don't bring up straw man arguments.
Can I hire someone in China to go through the refund process for me for a fraction of the refund amount?
No, but our operators in Nigeria are standing by..
It's actually more secure to have an essentially random password that people secure on a laminated card in their wallet (appropriately obfuscated of course) than have passwords that people can easily remember. When you think about it, people are actually very good at securing their wallet independently of their laptops.
Strangely enough, the parent post mentions something along the lines of ( in addition to the use of a "Smart Card" plugged into the machine to gain access ).
The best scheme is to have a smart card (preferably with an attached input device) that unlocks its public key authentication mechanism based on the entry of a password or PIN. A PIN should really suffice, as a smart card can simply lock out any repeated attempts at guessing after the first 3 tries. (It should still be fairly tamper resistant, but a smart card is in itself much better than, say, an easily copied magnetic stripe card).
One of the reasons to use smartcards in the first place is that the card can protect itself to some degree - which means you can make do with a PIN rather than a huge, complex password, which people WILL write down.
IANAL but wouldn't it be convenient for the RIAA to have a judge declare allofmp3.com illegal, so they can subpoena credit card company records of allofmp3 purchasers (AKA people who actually paid, albeit little, and in a different country, for music AKA more customers to sue)?