Sure, simple for me and you, but way harder if you're an elected official entrenched in the current system with an active interest in making it harder for third parties.;-)
(IRV is what I would choose if someone asked me to pick a new method now and didn't let me do further research.)
Unfortunately, a method which is "the best" does not seem to lend itself immediately.
If you impose a couple quite reasonable desiderata on how the election should behave, if you have at least three candidates not only is it unclear how to do it, but it is actually impossible.
In this particular case, those desiderata are: * No single voter decides the election. * Every possible set of votes results in a winner. (E.g. you can't tie. In addition, if the same set of votes is presented again, it must give the same result.) * If the system prefers candidate A to B, adding a candidate C cannot reverse the rankings of A and B. (Look at multiple elections in recent US history for an example of this not occuring, in particular 1996 and 2000. If there were an election between Bush and Gore only, Gore almost certainly would have won without much controversy. Adding in Nader changed the rankings of Bush and Gore so that Bush won. In 1996, Dole probably did the same thing for the opposite party.) * If all votes prefer candidate A to candidate B, then so will the ranking as a whole.
(There is an alternate formulation (actually the original one) that replaces the final item with two other things; see the Wikipedia article linked above.)
Notice how Mccain actually voted against this thing, even though his party voted for it. Does it represent his views regardless of his vote? No, as he said he supports telecom immunity.
According to the roll call, McCain didn't vote at all.
If everyone did that we might no longer have a two-party system.
Even if this is true, I'm not convinced what we'd have is better though. We really need to fix the one-person-one-vote thing to have viable third parties.
There's an interesting bit of economic theory which I think I remember from my game theory class. Imagine you have a beach, represented simply by a stretch of land. (i.e. it doesn't go all the way around a lake or something like that.) There are two competing snack stands that stake out the beach. Suppose they start 25% and 75% of the way across the beach, respectively. Assume a uniform (or at least symmetric about the midpoint) distribution of visitors on the beach, and that everyone goes to the nearest snack stand for food.
What will happen is that each snack stand owner will keep nudging closer to the center of the beach in an effort to get more of the visitors. Eventually they will reach a stable position with both in the exact center.
What's interesting about this is that if a third snack stand enters the picture, there is no stable solution. It will always be in someone's best interest to move.
The parallels to elections I think is pretty clear, even if the model is extremely simple even for the beach world, let alone an election where you have rich political views that don't just fall on a single axis. (Even the thing you'll see with some online tests that rate you on, say, economic and social axes are really simple.)
But I really think that if magically we were to arrive at the situation where there were three parties and a third of the country identified with each, after a few election cycles we'd be back where we are, at least for presidental and probably Senate elections. You need something more, like proportional representation (which doesn't work for the president and not really for the Senate) or a different vote counting system.
The code for yacc was certainly not originally written in c - c didn't exist at that time.
Then why are you using C code to illustrate the behavior of code that wouldn't have been in C?
By 1975, either Yacc was written in C or it wasn't. If it wasn't, then your example is irrelevant anyway. If it was in C, then you'll note that =+ was changed to += in 1976, but this bug was in the 1975 version. Ergo, the bug was in the (preliminary) version of C that Yacc was using.
The "archaic behaviour" was never part of that standard - it was a mistake in early implementations while they were still "working out the details" of the language, well before K & R, as Ritchie says:
That's fine. But Yacc was still written in that early version.
His summation is correct, all recipients of GPL code have the freedoms granted by the GPL.
Which is not the freedom "to do what they want"; thus his summation is NOT correct, because the recipient can NOT do what he wants.
However, the reverse is also not true, for the reason you give.
If I had to give a quick summary like that, I would say the following: - BSD ensures *direct recipients* have the freedom to do what they want (just about) - GPL ensures *all eventual recipients* have the fundamental freedoms to view and modify the source
I tend to say that the BSD license is more free than the GPL, but the GPL ensures that your code stays free.
For instance, the following program compiled with Visual Studio 2008 under release mode performs an illegal operation (I don't really understand why it does, but it does)
Figured it out.
Even under release builds, VS will by default do range checks on []. (This *is* allowed by the C++ standard, even if it's a little outside of the spirit.)
Adding the following to the top of the file:
#define _SECURE_SCL 0
(see here) will cause it to run to completion, with "5" as the output.
Actually, the [] operator of an STL vector doesn't throw any exceptions, and will happily allow you to reference an index which is out of bounds.
It's entirely possible that your STL implementation IS doing bounds checking on [] when doing debug releases, which means that if you do testing under a debug build, you're more likely to find problems even if you use [], so you're still in better shape than if you had used arrays.
For instance, the following program compiled with Visual Studio 2008 under release mode performs an illegal operation (I don't really understand why it does, but it does), but under debug build fails an assertion that says "vector subscript out of range".
#include <iostream> #include <vector>
using namespace std;
int main() {
vector<int> v;
v.reserve(10);
v[0] = 5;
cout << v[0] << endl; }
GCC doesn't seem to do this, but I only tried under Cygwin and could be mistaken.
(I also tend to think that the bounds checking properties of [] and at() should be reversed, but that's just me. I think that 95% of the time you should include checking, and [] is easier to read, more natural, and fits better with templates than at().)
I have been under the impression that Reiser was German, and this case has been taking place in Germany, pretty much since the beginning, and I've never gone to verify this. How on Earth did I get under that misconception?!
I image it and start a dictionary attack to get the rest of the info.
That'll only work if you're using a weak password. This may be the common case, but I doubt it's the common case among people paranoid enough to set up TrueCrypt hidden volumes. For instance, you can't dictionary attack a 12 character, randomly-generated password drawn from a 95-character alphabet (alphanumeric + 33 symbols; ascii 32-126), maybe unless you run a big botnet or work at the NSA.
You don't mind exposing your secrets to a machine you don't have control over (and thus should not trust)? I don't recommend it.
I'm not the OP, but this is being sillily unreasonable.
For instance, I don't have admin rights on the computer in my office. So maybe I don't want to trust this computer entirely. But if I'm walking back and forth with my USB key most days, the major threat is me leaving the key sitting on the bus seat or something like that, not information being stolen while I'm on the work computer.
It's not like just because you don't control a computer you don't trust it at all, or that just because something is in a TrueCrypt volume it's extremely sensitive.
Why's "gay" on that list? It shouldn't be viewed at a source of shame. It also wasn't directly the cause of the suicide; attempts to make him NOT gay were.
Because otherwise he wouldn't have showed them the location of the body.
Right or not, most places that act is viewed as giving closure to the family, and a lighter sentence is fairly often given in exchange for that closure.
In a way, I admire that. In another way, I like watching "Mythbusters."
If it really is just Mythbusters you miss, you can probably get a season of it on DVD for less money ($30) than a month of the level of cable where you get Discovery (maybe 40-50?).
You have to wait, and if there's a *lot* of stuff you'd watch it may not be the right decision. But it may well be reasonable for many.
Yeah, that's the case. I don't think the CC companies make any money for PIN-based transactions, though I could be wrong. And they charge something like 3% or so (again, could be wrong) for CC transactions, both on debit and real credit cards.
So the 1% off or whatever makes sense from their perspective. The grocery store I do my big shopping trips at (because they have the cheapest prices) don't accept credit cards at all; I suspect this is why.
Retinal scanning would fail if someone was in an accident or had surgery or something.
I don't think this is a good reason to reject it. If the accident/surgery just changes the authentication token, the person can just go to the bank and update it. If it makes it so they won't be able to authenticate, it can just be set up to not require that particular token. The system will have to take them into account, but it's not exactly hard to deal with, and the exceptions will only happen rarely. The other issues (e.g. you can't change your tokens if someone else gets them) are much much better reasons to reject this.
If you get a cut on your thumb you won't be able to get cash out of the ATM until it heals. A cataract could lock you out of your account forever. Etc.
Actually I'm just running into this on my laptop. I log in using a fingerprint scan because it's quicker and easier than a password. (And besides, I have the scanner, might as well use it. Also, I used my middle finger, so every time I log on I can say I'm giving Windows the finger.) But I'm also doing a lot of (gym) rock climbing, and the texture of the hand holds often means that I get little tiny scrapes on my hands. My most recent session seems to have done this in a way that makes it way way harder to log on, to the point where I'm going to be using my password for a few days.
(BTW, presumably if you had some permanent change like the cataract you would just go into your bank and get a new scan, or have them disable the authentication, so saying you would be locked out forever is being alarmist.)
Any Debit Card with a Visa or MC logo carries fraud protection. They both require that funds be put back into your account within 5 business days, and many banks do it same-day, mine included.
This is true only if you use your debit card like a credit card, rather than a debit card, right? (I.e. you give the cashier your signature rather than PIN.)
You're right overall, but I just wanted to clarify that point (both for me, since I'm not positive, and others).
However: If Alice talks to a legitimate merchant, and no one has hacked anything, then the conversation between her and the other end is very difficult to break into, moreso than her computer, I might add. Which is the same advantage you would have had with self-signed certificates. The ONLY time you're safe is when you've not been hacked. To say that because ONE hack has been deterred -- the MITM attack -- the user should feel safe... I'm not buying it.
Okay fine. What would you suggest?
A CA-provided cert is better than a self-signed cert, period. How much better depends on your trust of the CA. I would tend to say quite a bit better.
Sure, there are other attack vectors. But let's take your argument the other way. SSL in the first place. Why bother with it? After all, if my computer is rooted, or if the legitimate merchant's computer has been rooted, then the information has already been lost and encryption doesn't help. To say that one hack has been deterred -- the evesdropping attack -- the user should feel safe... I'm not buying it. How does that sound?
(1) Plain HTTP gets you no security. (2) SSL with self-signed certs gets you protection against evesdropping. If you can establish the certificate out-of-band, it gets you protection against MITM. If you can save the cert, it substantially narrows the band where you are vulnerable to MITM, to when you first get the cert. (3) SSL with CA-signed certs gets you protection against MITM at all times, to the extent you trust the CA. (Note that all of the options for additional verification present in (2) are also present here.)
(3) is strictly better than (2) which is strictly better than (1). What are the relative weights? The jump from (1) to (2) is substantially more than the jump (2) to (3) I would say. But you still get help going from (2) to (3).
As many others have said, do you verify the HTML of the page you load when you load an unencrypted login page?
If you don't, how do you know that a MITM didn't modify it to redirect that form input? How do you know a MITM didn't modify it to insert javascript to forward everything you enter in that form to him?
An unencrypted login page is only as secure as an encrypted login page if you open view source and look.
If my bank did that, I would only use the web interface in an absolute emergency. And then I would get a different bank.
while a trusted CA-signed cert is not, that's not true, provided you verify the certificate once (for example, the site could post the fingerprint on many public sites to make it well known), and then tell your browser to trust that certificate for that site
It helps, but it's still far from a particularly good solution. Assuming your browser will store things indefinitely, the window where you're vulnerable to a MITM is substantially shortened -- they have to be there for the initial visit.
But if they are -- bye-bye security. Are you really going to go around and look at those many public sites to verify the fingerprint? Even I wouldn't do that unless there was no alternative. I'd find some other place to do what I wanted before that. If the security matters enough I care if other people are reading what I'm saying (as a matter of practice and not an "encrypt everything" ideology I'm somewhat partial to) and the target can't be bothered to get a "real" cert, I'm probably going elsewhere.
You can only say that CA-signed certs don't help against MITM if, at the point you are receiving the self-signed certs, you trust your network as much or more than you trust the CA. Frankly, for me, that would never be the case right now.
I don't think he's talking about subversion. He's talking about the fact that anyone with $900 can buy a cert from verisign regardless of their evil intentions.
But they can't buy one for my bank, or for Amazon, or for Paypal.
His point was that since any malware site or someone who just intends to steal your credit card on a legit looking site could in theory buy a legal cert, that rolling your own is just as trust worthy.
But it isn't. Roll-your-own SSL cert doesn't provide protection against man-in-the-middle attacks (unless you have previously visited the site and stored the self-signed cert); a Verisign-signed cert does (to the extent you trust Verisign).
Just because self-signed certs don't always help with phishing doesn't mean there aren't other threats they DO help against.
IF you can spoof mybank.com.au's DNS then you can apply for a certificate to that domain yourself... Most certificate authorities just send you an email to confirm, and if you control the DNS you can control the MX records to ensure you receive that mail.
Not really. If I can spoof your DNS server to you, I can redirect your requests to me and do a man-in-the-middle attack on you (modulo encryption). If I set up a wifi hotspot, I can run my own DNS server that redirects stuff from you to me.
If I want to spoof someone so that I get the email that Verisign sends out, I have to spoof *Verisign's* DNS. And really, if I were Verisign, I would try a number of different DNS servers to make sure they all agree, so I would have to spoof all of them. (At least assuming this is possible; I don't know enough about IP to know if DNS entries can legitimately vary like that.)
And today, we have script languages like this. Just shows things never change, they just go quiet before returning to fashion. To be fair, the non-type-checking of old C compilers (or new C compilers if you do something wrong and don't follow good conventions) is an entirely different animal than the non-type-checking of today's Python or Perl.
In the former, the function you're calling expects certain types in particular register and/or memory locations, and runs as if they are there. If it's wrong, and the caller didn't set up the stack right, you'll have fun times debugging what the hell is going on.
In the latter, the function you're calling expects certain types in particular register and/or memory locations, and verifies at runtime that they are there. If the wrong type or wrong number of arguments is provided, a predictable result will occur.
There's a big difference between untyped (which is what C is at the linker, and what K&R C is at the compiler) and dynamically-typed (which is what the scripting languages you refer to are).
Slashdot Mirror
Sure, simple for me and you, but way harder if you're an elected official entrenched in the current system with an active interest in making it harder for third parties. ;-)
(IRV is what I would choose if someone asked me to pick a new method now and didn't let me do further research.)
Unfortunately, a method which is "the best" does not seem to lend itself immediately.
If you impose a couple quite reasonable desiderata on how the election should behave, if you have at least three candidates not only is it unclear how to do it, but it is actually impossible.
In this particular case, those desiderata are:
* No single voter decides the election.
* Every possible set of votes results in a winner. (E.g. you can't tie. In addition, if the same set of votes is presented again, it must give the same result.)
* If the system prefers candidate A to B, adding a candidate C cannot reverse the rankings of A and B. (Look at multiple elections in recent US history for an example of this not occuring, in particular 1996 and 2000. If there were an election between Bush and Gore only, Gore almost certainly would have won without much controversy. Adding in Nader changed the rankings of Bush and Gore so that Bush won. In 1996, Dole probably did the same thing for the opposite party.)
* If all votes prefer candidate A to candidate B, then so will the ranking as a whole.
(There is an alternate formulation (actually the original one) that replaces the final item with two other things; see the Wikipedia article linked above.)
Notice how Mccain actually voted against this thing, even though his party voted for it. Does it represent his views regardless of his vote? No, as he said he supports telecom immunity.
According to the roll call, McCain didn't vote at all.
If everyone did that we might no longer have a two-party system.
Even if this is true, I'm not convinced what we'd have is better though. We really need to fix the one-person-one-vote thing to have viable third parties.
There's an interesting bit of economic theory which I think I remember from my game theory class. Imagine you have a beach, represented simply by a stretch of land. (i.e. it doesn't go all the way around a lake or something like that.) There are two competing snack stands that stake out the beach. Suppose they start 25% and 75% of the way across the beach, respectively. Assume a uniform (or at least symmetric about the midpoint) distribution of visitors on the beach, and that everyone goes to the nearest snack stand for food.
What will happen is that each snack stand owner will keep nudging closer to the center of the beach in an effort to get more of the visitors. Eventually they will reach a stable position with both in the exact center.
What's interesting about this is that if a third snack stand enters the picture, there is no stable solution. It will always be in someone's best interest to move.
The parallels to elections I think is pretty clear, even if the model is extremely simple even for the beach world, let alone an election where you have rich political views that don't just fall on a single axis. (Even the thing you'll see with some online tests that rate you on, say, economic and social axes are really simple.)
But I really think that if magically we were to arrive at the situation where there were three parties and a third of the country identified with each, after a few election cycles we'd be back where we are, at least for presidental and probably Senate elections. You need something more, like proportional representation (which doesn't work for the president and not really for the Senate) or a different vote counting system.
It's possible that I'm wrong of course.
The code for yacc was certainly not originally written in c - c didn't exist at that time.
Then why are you using C code to illustrate the behavior of code that wouldn't have been in C?
By 1975, either Yacc was written in C or it wasn't. If it wasn't, then your example is irrelevant anyway. If it was in C, then you'll note that =+ was changed to += in 1976, but this bug was in the 1975 version. Ergo, the bug was in the (preliminary) version of C that Yacc was using.
The "archaic behaviour" was never part of that standard - it was a mistake in early implementations while they were still "working out the details" of the language, well before K & R, as Ritchie says:
That's fine. But Yacc was still written in that early version.
His summation is correct, all recipients of GPL code have the freedoms granted by the GPL.
Which is not the freedom "to do what they want"; thus his summation is NOT correct, because the recipient can NOT do what he wants.
However, the reverse is also not true, for the reason you give.
If I had to give a quick summary like that, I would say the following:
- BSD ensures *direct recipients* have the freedom to do what they want (just about)
- GPL ensures *all eventual recipients* have the fundamental freedoms to view and modify the source
I tend to say that the BSD license is more free than the GPL, but the GPL ensures that your code stays free.
For instance, the following program compiled with Visual Studio 2008 under release mode performs an illegal operation (I don't really understand why it does, but it does)
Figured it out.
Even under release builds, VS will by default do range checks on []. (This *is* allowed by the C++ standard, even if it's a little outside of the spirit.)
Adding the following to the top of the file:
(see here) will cause it to run to completion, with "5" as the output.
Actually, the [] operator of an STL vector doesn't throw any exceptions, and will happily allow you to reference an index which is out of bounds.
It's entirely possible that your STL implementation IS doing bounds checking on [] when doing debug releases, which means that if you do testing under a debug build, you're more likely to find problems even if you use [], so you're still in better shape than if you had used arrays.
For instance, the following program compiled with Visual Studio 2008 under release mode performs an illegal operation (I don't really understand why it does, but it does), but under debug build fails an assertion that says "vector subscript out of range".
GCC doesn't seem to do this, but I only tried under Cygwin and could be mistaken.
(I also tend to think that the bounds checking properties of [] and at() should be reversed, but that's just me. I think that 95% of the time you should include checking, and [] is easier to read, more natural, and fits better with templates than at().)
.... okay, I am officially an idiot.
I have been under the impression that Reiser was German, and this case has been taking place in Germany, pretty much since the beginning, and I've never gone to verify this. How on Earth did I get under that misconception?!
I image it and start a dictionary attack to get the rest of the info.
That'll only work if you're using a weak password. This may be the common case, but I doubt it's the common case among people paranoid enough to set up TrueCrypt hidden volumes. For instance, you can't dictionary attack a 12 character, randomly-generated password drawn from a 95-character alphabet (alphanumeric + 33 symbols; ascii 32-126), maybe unless you run a big botnet or work at the NSA.
You don't mind exposing your secrets to a machine you don't have control over (and thus should not trust)? I don't recommend it.
I'm not the OP, but this is being sillily unreasonable.
For instance, I don't have admin rights on the computer in my office. So maybe I don't want to trust this computer entirely. But if I'm walking back and forth with my USB key most days, the major threat is me leaving the key sitting on the bus seat or something like that, not information being stolen while I'm on the work computer.
It's not like just because you don't control a computer you don't trust it at all, or that just because something is in a TrueCrypt volume it's extremely sensitive.
Alan Turing - gay, suicide
Why's "gay" on that list? It shouldn't be viewed at a source of shame. It also wasn't directly the cause of the suicide; attempts to make him NOT gay were.
Because otherwise he wouldn't have showed them the location of the body.
Right or not, most places that act is viewed as giving closure to the family, and a lighter sentence is fairly often given in exchange for that closure.
I didn't realize the German government recognized the 5th amendment as applicable in court proceedings there.
In a way, I admire that. In another way, I like watching "Mythbusters."
If it really is just Mythbusters you miss, you can probably get a season of it on DVD for less money ($30) than a month of the level of cable where you get Discovery (maybe 40-50?).
You have to wait, and if there's a *lot* of stuff you'd watch it may not be the right decision. But it may well be reasonable for many.
Yeah, that's the case. I don't think the CC companies make any money for PIN-based transactions, though I could be wrong. And they charge something like 3% or so (again, could be wrong) for CC transactions, both on debit and real credit cards.
So the 1% off or whatever makes sense from their perspective. The grocery store I do my big shopping trips at (because they have the cheapest prices) don't accept credit cards at all; I suspect this is why.
Retinal scanning would fail if someone was in an accident or had surgery or something.
I don't think this is a good reason to reject it. If the accident/surgery just changes the authentication token, the person can just go to the bank and update it. If it makes it so they won't be able to authenticate, it can just be set up to not require that particular token. The system will have to take them into account, but it's not exactly hard to deal with, and the exceptions will only happen rarely. The other issues (e.g. you can't change your tokens if someone else gets them) are much much better reasons to reject this.
If you get a cut on your thumb you won't be able to get cash out of the ATM until it heals. A cataract could lock you out of your account forever. Etc.
Actually I'm just running into this on my laptop. I log in using a fingerprint scan because it's quicker and easier than a password. (And besides, I have the scanner, might as well use it. Also, I used my middle finger, so every time I log on I can say I'm giving Windows the finger.) But I'm also doing a lot of (gym) rock climbing, and the texture of the hand holds often means that I get little tiny scrapes on my hands. My most recent session seems to have done this in a way that makes it way way harder to log on, to the point where I'm going to be using my password for a few days.
(BTW, presumably if you had some permanent change like the cataract you would just go into your bank and get a new scan, or have them disable the authentication, so saying you would be locked out forever is being alarmist.)
Any Debit Card with a Visa or MC logo carries fraud protection. They both require that funds be put back into your account within 5 business days, and many banks do it same-day, mine included.
This is true only if you use your debit card like a credit card, rather than a debit card, right? (I.e. you give the cashier your signature rather than PIN.)
You're right overall, but I just wanted to clarify that point (both for me, since I'm not positive, and others).
However: If Alice talks to a legitimate merchant, and no one has hacked anything, then the conversation between her and the other end is very difficult to break into, moreso than her computer, I might add. Which is the same advantage you would have had with self-signed certificates. The ONLY time you're safe is when you've not been hacked. To say that because ONE hack has been deterred -- the MITM attack -- the user should feel safe... I'm not buying it.
Okay fine. What would you suggest?
A CA-provided cert is better than a self-signed cert, period. How much better depends on your trust of the CA. I would tend to say quite a bit better.
Sure, there are other attack vectors. But let's take your argument the other way. SSL in the first place. Why bother with it? After all, if my computer is rooted, or if the legitimate merchant's computer has been rooted, then the information has already been lost and encryption doesn't help. To say that one hack has been deterred -- the evesdropping attack -- the user should feel safe... I'm not buying it. How does that sound?
(1) Plain HTTP gets you no security.
(2) SSL with self-signed certs gets you protection against evesdropping. If you can establish the certificate out-of-band, it gets you protection against MITM. If you can save the cert, it substantially narrows the band where you are vulnerable to MITM, to when you first get the cert.
(3) SSL with CA-signed certs gets you protection against MITM at all times, to the extent you trust the CA. (Note that all of the options for additional verification present in (2) are also present here.)
(3) is strictly better than (2) which is strictly better than (1). What are the relative weights? The jump from (1) to (2) is substantially more than the jump (2) to (3) I would say. But you still get help going from (2) to (3).
As many others have said, do you verify the HTML of the page you load when you load an unencrypted login page?
If you don't, how do you know that a MITM didn't modify it to redirect that form input? How do you know a MITM didn't modify it to insert javascript to forward everything you enter in that form to him?
An unencrypted login page is only as secure as an encrypted login page if you open view source and look.
If my bank did that, I would only use the web interface in an absolute emergency. And then I would get a different bank.
while a trusted CA-signed cert is not, that's not true, provided you verify the certificate once (for example, the site could post the fingerprint on many public sites to make it well known), and then tell your browser to trust that certificate for that site
It helps, but it's still far from a particularly good solution. Assuming your browser will store things indefinitely, the window where you're vulnerable to a MITM is substantially shortened -- they have to be there for the initial visit.
But if they are -- bye-bye security. Are you really going to go around and look at those many public sites to verify the fingerprint? Even I wouldn't do that unless there was no alternative. I'd find some other place to do what I wanted before that. If the security matters enough I care if other people are reading what I'm saying (as a matter of practice and not an "encrypt everything" ideology I'm somewhat partial to) and the target can't be bothered to get a "real" cert, I'm probably going elsewhere.
You can only say that CA-signed certs don't help against MITM if, at the point you are receiving the self-signed certs, you trust your network as much or more than you trust the CA. Frankly, for me, that would never be the case right now.
I don't think he's talking about subversion. He's talking about the fact that anyone with $900 can buy a cert from verisign regardless of their evil intentions.
But they can't buy one for my bank, or for Amazon, or for Paypal.
His point was that since any malware site or someone who just intends to steal your credit card on a legit looking site could in theory buy a legal cert, that rolling your own is just as trust worthy.
But it isn't. Roll-your-own SSL cert doesn't provide protection against man-in-the-middle attacks (unless you have previously visited the site and stored the self-signed cert); a Verisign-signed cert does (to the extent you trust Verisign).
Just because self-signed certs don't always help with phishing doesn't mean there aren't other threats they DO help against.
IF you can spoof mybank.com.au's DNS then you can apply for a certificate to that domain yourself... Most certificate authorities just send you an email to confirm, and if you control the DNS you can control the MX records to ensure you receive that mail.
Not really. If I can spoof your DNS server to you, I can redirect your requests to me and do a man-in-the-middle attack on you (modulo encryption). If I set up a wifi hotspot, I can run my own DNS server that redirects stuff from you to me.
If I want to spoof someone so that I get the email that Verisign sends out, I have to spoof *Verisign's* DNS. And really, if I were Verisign, I would try a number of different DNS servers to make sure they all agree, so I would have to spoof all of them. (At least assuming this is possible; I don't know enough about IP to know if DNS entries can legitimately vary like that.)
And today, we have script languages like this. Just shows things never change, they just go quiet before returning to fashion.
To be fair, the non-type-checking of old C compilers (or new C compilers if you do something wrong and don't follow good conventions) is an entirely different animal than the non-type-checking of today's Python or Perl.
In the former, the function you're calling expects certain types in particular register and/or memory locations, and runs as if they are there. If it's wrong, and the caller didn't set up the stack right, you'll have fun times debugging what the hell is going on.
In the latter, the function you're calling expects certain types in particular register and/or memory locations, and verifies at runtime that they are there. If the wrong type or wrong number of arguments is provided, a predictable result will occur.
There's a big difference between untyped (which is what C is at the linker, and what K&R C is at the compiler) and dynamically-typed (which is what the scripting languages you refer to are).