You're exactly right. A quick glance at the actual FTC regulations show that it applies to financial institutions and creditors -- in other words, banks and credit card companies.
And it's not some mysterious "Do Not Sell" list. It just requires those companies to create and implement a plan to prevent, detect and mitigate identity theft. Which is something they *should* all be doing anyway.
Talk about a distorted summary of what this really is. Not to mention that the FTC regs were issued in October of last year, so it's not really new either.
When I can buy a movie from one computer and have the download start *on another machine*, it's pretty obvious that the software has to be in contact with their servers. Given the large number of internet users with unroutable IPs, having a service that just listens on a port isn't really feasible either.
Whether you think its a good thing or not, this shouldn't really be a surprise to anybody who thought about the software for more than a minute or two.
Buffer overflows are a software problem and have nothing to do with the CPU. The PowerPC would have been just as vulnerable, when running identical code.
That's not entirely true. Buffer overflows are exploited at the assembly level, not at the source code level. So the point is that, even if a PPC is running the same source code, it's not running the same assembly, since it uses a different ISA.
More to the point, the simplest and most common buffer overflow attacks rely on the fact that the user stack traditionally grows down. Since buffers are addressed upwards, writing of the end of a buffer can overwrite a previous stack frame and return address. If the user stack were to grow upwards instead, this wouldn't be nearly the problem it is, since writing past the end of a buffer would result in corruption of other user variables or some unused memory, instead of changing the return address of a function.
Even though stacks growing down is really just a convention which could be changed by the compiler, the x86 instruction set supports and almost enforces that convention. The x86 push and pop instructions that are used to handle stack frames expect that the stack grows down and wouldn't work for a stack growing upward. I don't know PPC assembly, so I can't say if it does the same thing.
Put simply, it is possible to create and instruction set architecture that is less vulnerable to buffer overflows than x86 is. Whether PPC is that ISA, I don't know, but it would be possible to create one.
Slashdot Mirror
You're exactly right. A quick glance at the actual FTC regulations show that it applies to financial institutions and creditors -- in other words, banks and credit card companies.
And it's not some mysterious "Do Not Sell" list. It just requires those companies to create and implement a plan to prevent, detect and mitigate identity theft. Which is something they *should* all be doing anyway.
Talk about a distorted summary of what this really is. Not to mention that the FTC regs were issued in October of last year, so it's not really new either.
When I can buy a movie from one computer and have the download start *on another machine*, it's pretty obvious that the software has to be in contact with their servers. Given the large number of internet users with unroutable IPs, having a service that just listens on a port isn't really feasible either.
Whether you think its a good thing or not, this shouldn't really be a surprise to anybody who thought about the software for more than a minute or two.
Unbox is implemented with .Net 2.0. Mono is your best bet if you want to run it on linux.
Buffer overflows are a software problem and have nothing to do with the CPU. The PowerPC would have been just as vulnerable, when running identical code.
That's not entirely true. Buffer overflows are exploited at the assembly level, not at the source code level. So the point is that, even if a PPC is running the same source code, it's not running the same assembly, since it uses a different ISA.
More to the point, the simplest and most common buffer overflow attacks rely on the fact that the user stack traditionally grows down. Since buffers are addressed upwards, writing of the end of a buffer can overwrite a previous stack frame and return address. If the user stack were to grow upwards instead, this wouldn't be nearly the problem it is, since writing past the end of a buffer would result in corruption of other user variables or some unused memory, instead of changing the return address of a function.
Even though stacks growing down is really just a convention which could be changed by the compiler, the x86 instruction set supports and almost enforces that convention. The x86 push and pop instructions that are used to handle stack frames expect that the stack grows down and wouldn't work for a stack growing upward. I don't know PPC assembly, so I can't say if it does the same thing.
Put simply, it is possible to create and instruction set architecture that is less vulnerable to buffer overflows than x86 is. Whether PPC is that ISA, I don't know, but it would be possible to create one.