The light gun for the NES worked a bit differently, since it didn't really have the processing power to use this method (at least without some specialized hardware on the cartridge).
When the light gun fired, the game software blanked the entire screen, except for a white box. The light sensor could only differentiate between a bright and dim area. The game cycled through all the hittable objects on screen, one per frame, displaying the white box in each object's place. It timed the light sensor hit with the current object being shown.
This method is limited in that you couldn't get an absolute screen position for each shot. But it didn't require calibration before playing, didn't require extra hardware or precision timing on the nes, and the gun itself was cheaper to make. It didn't work on projection televisions because they weren't bright enough for the light gun sensor. It also wouldn't work on any display that might have latency of a single frame or more, at least without the software knowing what that latency is.
It's typical marketer hubris - they all think that their shit doesn't stink. Each telemarketer wishes that all the other telemarketers would stop harassing people so the noise doesn't drown out their own pitch. Any marketer smart enough to realise that do-not-call listees are fed up with the calls is not in the telemarketing business. They are all looking for new marketing mediums to hit first before they're strip-mined.
If the only spam on the internet came from a Microsoft IP address, it would make a spam block list really easy to maintain. The DMA, MS, or any other corp. can push all the spam legislation they want, but it will not change the fact that people hate spam.
You're absolutely right about them trying to push laws with exceptions just for them. My theory is that they think if they can get rid of all the pr0n, herbal v1a6ra, pen1s enlarger, mortgage spam, it will give them enough control to try and legitimize email marketing. I'm not so optimistic. There would have to be a lengthy moratorium on all email marketing before it could ever be considered socially acceptable. Even then, many would still hate it, myself included.
And if that spam legislation includes anything forbidding spam block lists or filters, that's the day I stop using email.
Sounds like we completely agree with each other, except, of course, for my somewhat abstract and non-traditional use of the terms "scripting" and "programming" in that post. That's OK, because I was elaborating from the context of the parent post. I was referring to interfacing, which is something that "scripting" in your sense handles nicely.
Sounds good, but I'd break it down more specifically: Scripting is interfacing, tying things together on a higher level. Programming is functionality, algorithms and such. This still has nothing to do with language choice, as many languages can handle both to a degree.
Do you really think someone running securities scams is going to check his fax-blasting (already illegal) list against an opt-in list? The guy that faxes you is already a criminal in several ways. The opt-out number is for some other purpose, probably verification of human receipt.
I don't think there's any reason to store the 3 digit number in a database. It's only used during transaction approval. I can see why merchants store accounts numbers, to keep records of transactions and such (though it's just lazy and insecure the way they manage that data sometimes). There really is no need to add a field in their dastabases for the extra 3 digits, since the account number already serves its purpose, and is guaranteed to be unique.
Of course, then the problem is not every merchant verifies the 3 digit code, so a theif doesn't even need it for some transactions. It is in the merchants' best interests to use the code, however, since the merchants foot the bill in fraud claims.
It's still not the greatest system, but it has some potential to curb fraud. Needs refining, but it's better than nothing.
OK, twice you have accused me of trying to dictate what your ISPs terms with you should be. I'm not doing this. Period. That's your business and I am external to it, and can't affect it in anyway. Maybe it was bad wording on my part. My statement was meant to be general.
That statement is: An ISP that cares about its customers' needs AND preventing abuse CAN use port 25 blocking as one way to prevent abuse yet simultaneously provide a way for people to run their own mail servers. This is a completely technical problem with a technical solution.
Do you care if your ISP doesn't do everything to prevent abuse? Maybe you do, maybe you don't, but it's your decision to make. I happen to care about my own providers' abuse control, and make that one of the terms of the ISP relationship that I define.
The reason I care is because eventually my traffic has to travel to someone else's network. What they allow into their networks is entirely up to them. I can't demand that they carry my traffic any more than I can demand that your ISP start blocking port 25. These days, networks that get a reputation for abuse end up getting shitlisted. So, I host my email with an abuse intolerant provider that gives me services I need.
Your hosting situation looks like something I wouldn't want. I could see a situation where you get a new IP address one day that is widely blocklisted because it was previously leased to a widely exploited open proxy. You may not be so lucky defining the terms of your relationship with each and every mail server to which your server connects. Maybe this doesn't bug you so much, or even effect you at all, but it would bug me.
Well, this story's fallen off the main page now and you'll probably be the only one reading this. Good luck with your mail server, and, should your ISP one day decide to block outbound port 25, you're not totally screwed. If they do care about letting customers run mail servers, they will work with you to set up something. Hopefully something abuse proof, for the good of the internet.
If you need to run your own mail server you need to find out about that when you sign up for service.
I did, and it's allowed. And I don't need to run my own mail server. I want to run my own mail server. And I want to run my own mail server because TMDA is the most effective spam blocker that I've tried. It's a *ton* easier to use with your own domain and mailserver.
Cool beans dude, go for it. Any egress blocking won't affect your inbox, as long as others aren't using source port 25 to connect to your port 25. That would be a broken way of doing things, indeed. As far as outgoing mail, you can relay through the ISPs SMTP servers or beg them to lift any blocking on port 25 for your special case. None of this should be a problem for an ISP that cares about providing customers services they want and preventing abuse.
Are you saying that since some of these dynamic IPs can be used by spammers, that all should dynamic IP's should be considered bad?
In practice, they are considered bad. Browsing through my own spam, I see the majority to be open proxy and open relay abuse. I check the IPs in the top-most Received: header (the only one I can really trust) and find DSL and cable modem IPs connecting. Result: that space gets shitlisted as a spam source, in my own filters and public blocklists. If the ISP cared at all about preventing abuse, solving the open proxy/relay problem on their network would be a good start. Block outgoing port 25 connections first, then handle the customers that have special needs (you) later. That is, if they even care about that minority in their customer base.
My service uses dynamic IP address only because static IPv4 addresses are in too high of demand.
I'm curious how you handle DNS issues with a dynamic IP. My first instinct here would be a problem propogating changes when your ISP gives you a new IP. Is there a service for people who need domain name to dynamic IP resolution I haven't heard of? Links....
The terms of service of my cable modem allow for running a mail server. That is a term that is between them and me. Stop trying to interfere with it, please...
Dude, I can't do a damn thing about what your ISP allows on the net. If someone doesn't like it, they won't accept traffic. What I'm saying is that an ISP should be able to let you run your server and block port 25 from everyone who isn't so we can all stop getting spam delivered from personal firewall software. Whatever solution they use to get your email out should be easily monitored for abuse. If the terms of your provider allow you to spam the shit out of the internet, expect it in a blocklist. If they allow responsible users to run servers, and stop abuse from the rest of the network, all is well.
Port 25 egress blocking is a good start to the spam problem for two reasons: First, it prevents a spammer from signing up and just doing direct-to-MX spam from that throwaway account. Not many spammers do this anymore, because its easily tracead and bigger ISPs kick those accounts fastest. Second, it limits a spammer's ability to abuse open proxies and relays on a network. Say clueless users are running a WinGate open proxy or an open sendmail relay on an older default Linux/BSD install on their cable or DSL line. A spammer could try to relay spam through it, but the egress block would stop it.
I see alot of complaints here about how such a block prevents you from running a mail server on your broadband line. People, this is residential service you are getting here. If you need to run your own mail server you need to find out about that when you sign up for service. A typical residential user never needs to connect to any SMTP relay except the ones the ISP provides. These users are also more likely to cluelessly leave their computers open to abuse. If you're responsible enough to run a mail server, and you really NEED one, get a real account.
Another option is to relay your mail over a non-standard port through a third-party email provider, if you really loathe your ISPs relays. This is my situation, and I use Lux Scientiae. They run a SMTP AUTH relay on a secondary non-standard port. It's locked down to prevent abuse, and SMTP AUTH lets them track down any of their users that abuse it. They don't accept incoming mail on that non-standard port, only relay for users, so it's not like they're re-defining SMTP to use a different port.
Of course, there will always be those ISPs that really don't care about preventing abuse. This is why blocklists even exist, to allow users to shut out the bad neighborhoods on the net. It would be nice if all those residential broadband users' computers couldn't be hijacked by spammers. As it stands, they are, so one way or another port 25 traffic is blocked.
I would like nothing more than for a software companies to justify their actions by saying "That's correct, we don't trust users." Maybe AMI is more of a middleman and is only giving software companies tools to restrict end users. But, he was presented with this issue in the interview and the response was not clear.
Bottom line: software companies do not trust you. I know it, you know it, but when they try to dance around the issue when confronted, it is just insulting.
Which is why I asked for a follow up. It may have been unintentional on your part, but the issue I addressed in my follow up was only addressed indirectly in the interview. We all *know* how vendors feel about us end users, they just won't say it to our faces. Attempts to obscure one's true intentions bug me alot more than those intentions themselves.
So, roblimo says this guy reads Slahsdot, maybe he will answer follow-up questions here...
Please clarify, in 50 words or less, wether or not the trust model that TCPA implements will ever allow software to consider the owner and operator of a TCPA-enabled computer "not trusted."
If you can, with extra effort, go from "reading any trace data would be very near impossible" to "reading any trace data is mathematically proven to be impossible," that extra effort may be justified.
Consider that 20 years from now, HD technololgy will most likely have increased, and today's monster drives will look old. Who knows what technology will be available.
So the question is then: "For how long do you want your data to be unrecoverable?" For some the answer may be "Long enough," but for many, the answer is "As long as evil exists."
Several passes of/dev/random is certainly more secure. Writing a predictable pattern, such as/dev/zero (which, given HD encoding schemes does not actually mean all zero bits on the disk) only gives an attacker a pattern to subtract from the signal on the disk and recover the original data. Writing zero over a one looks different than writing a zero over a zero when you look at the disk on a low-level.
In the article, it wasn't so much that the Chicago PD simply didn't want to help out, it's that they wouldn't be able to do so in the time frame the author would've hoped for. It was the FBI and Secret Service that wouldn't touch the case, and referred him to local authorities. Yeah, he had information already gathered, but the cops have to do their own investigation as well. Chicago is a big city with all the crime problems that come with big cities, and maybe they do need to hire more investigators to improve response time. But they did not all together refuse to investigate, according to the article.
Shopping at Best Buy for a new television, the sales monkey tells me that the expected life of a television is about four years. I'm not too sure what he meant by that, or what kind of research Best Buy corporate goons do to reach that conclusion (and then train the monkeys to quote it), but the TV sitting in my living room that I eventually decided NOT to replace was made in 1982.
Funny thin is they're still pushing you to upgrade to a digital-ready TV because analog will no longer be broadcasted in about.... four years.
Moral of the story: don't listen to sales monkeys.
Isn't there some sort of judge that looks beyond the length of his nose, into the background of the company?
That's not the judge's job. That's the defence's job. They then present the facts to the judge, maybe a jury if one is requested, to take into consideration.
All the court has to go on when agreeing to hear the case is 1) PanIP has a patent on a process. 2) Someone has implemented the patented process without the permission of the patent holder. 3) The law says PanIP can petition the court for a redress of this specific greivance.
The claim that 1) never should've happened will be decided in court. The opinion that the last thing PanIP wants is to go to court is suggested by the pattern they have chosen in filing their lawsuits.
Since a buffer overflow attack overwrites with data memory addresses filled with instructions, why not designing an operative system that isolates the executable memory from the data memory?
The x86 is what we call a Von Neumann (maybe not spelled that way) architecture machine, meaning memory is memory and you can put whatever you want there. A Harvard architecure machine separates program and data memory. There are tradeoffs and advantages to each architecture.
The operating system you suggest running on a Von Neumann machine would essentially emulate a Harvard machine on hardware not designed to do that. To avoid buffer overflows, just use a Harvard machine with an OS designed for it. But you lose the advantages of a Von Neumann machine, like self-modifying code, simpler executable formats, simpler memory management.
In simple terms, all your questions could be answered with "It's a hardware thing."
That was the first time that PanIP filed some lawsuits. They have filed more, 10 defendants at a time, most recently on Oct. 4. This is an ongoing issue, so you can expect to see it posted on Slashdot a few more times.
Slashdot Mirror
If they write proper HTML, the alt-tag should describe the image; ie the number...
...which would defeat the purpose of having the number in an image at all, which is to make it hard to machine-parse but still human-readable.
The light gun for the NES worked a bit differently, since it didn't really have the processing power to use this method (at least without some specialized hardware on the cartridge).
When the light gun fired, the game software blanked the entire screen, except for a white box. The light sensor could only differentiate between a bright and dim area. The game cycled through all the hittable objects on screen, one per frame, displaying the white box in each object's place. It timed the light sensor hit with the current object being shown.
This method is limited in that you couldn't get an absolute screen position for each shot. But it didn't require calibration before playing, didn't require extra hardware or precision timing on the nes, and the gun itself was cheaper to make. It didn't work on projection televisions because they weren't bright enough for the light gun sensor. It also wouldn't work on any display that might have latency of a single frame or more, at least without the software knowing what that latency is.
It's typical marketer hubris - they all think that their shit doesn't stink. Each telemarketer wishes that all the other telemarketers would stop harassing people so the noise doesn't drown out their own pitch. Any marketer smart enough to realise that do-not-call listees are fed up with the calls is not in the telemarketing business. They are all looking for new marketing mediums to hit first before they're strip-mined.
If the only spam on the internet came from a Microsoft IP address, it would make a spam block list really easy to maintain. The DMA, MS, or any other corp. can push all the spam legislation they want, but it will not change the fact that people hate spam.
You're absolutely right about them trying to push laws with exceptions just for them. My theory is that they think if they can get rid of all the pr0n, herbal v1a6ra, pen1s enlarger, mortgage spam, it will give them enough control to try and legitimize email marketing. I'm not so optimistic. There would have to be a lengthy moratorium on all email marketing before it could ever be considered socially acceptable. Even then, many would still hate it, myself included.
And if that spam legislation includes anything forbidding spam block lists or filters, that's the day I stop using email.
Sounds like we completely agree with each other, except, of course, for my somewhat abstract and non-traditional use of the terms "scripting" and "programming" in that post. That's OK, because I was elaborating from the context of the parent post. I was referring to interfacing, which is something that "scripting" in your sense handles nicely.
Sounds good, but I'd break it down more specifically: Scripting is interfacing, tying things together on a higher level. Programming is functionality, algorithms and such. This still has nothing to do with language choice, as many languages can handle both to a degree.
How about SDL, developed primarily by Loki? Pretty decent so far, from what I've used of it.
Isn't some big fax company under indictment for this?
It is Fax.com.
Do you really think someone running securities scams is going to check his fax-blasting (already illegal) list against an opt-in list? The guy that faxes you is already a criminal in several ways. The opt-out number is for some other purpose, probably verification of human receipt.
I don't think there's any reason to store the 3 digit number in a database. It's only used during transaction approval. I can see why merchants store accounts numbers, to keep records of transactions and such (though it's just lazy and insecure the way they manage that data sometimes). There really is no need to add a field in their dastabases for the extra 3 digits, since the account number already serves its purpose, and is guaranteed to be unique.
Of course, then the problem is not every merchant verifies the 3 digit code, so a theif doesn't even need it for some transactions. It is in the merchants' best interests to use the code, however, since the merchants foot the bill in fraud claims.
It's still not the greatest system, but it has some potential to curb fraud. Needs refining, but it's better than nothing.
OK, twice you have accused me of trying to dictate what your ISPs terms with you should be. I'm not doing this. Period. That's your business and I am external to it, and can't affect it in anyway. Maybe it was bad wording on my part. My statement was meant to be general.
That statement is: An ISP that cares about its customers' needs AND preventing abuse CAN use port 25 blocking as one way to prevent abuse yet simultaneously provide a way for people to run their own mail servers. This is a completely technical problem with a technical solution.
Do you care if your ISP doesn't do everything to prevent abuse? Maybe you do, maybe you don't, but it's your decision to make. I happen to care about my own providers' abuse control, and make that one of the terms of the ISP relationship that I define.
The reason I care is because eventually my traffic has to travel to someone else's network. What they allow into their networks is entirely up to them. I can't demand that they carry my traffic any more than I can demand that your ISP start blocking port 25. These days, networks that get a reputation for abuse end up getting shitlisted. So, I host my email with an abuse intolerant provider that gives me services I need.
Your hosting situation looks like something I wouldn't want. I could see a situation where you get a new IP address one day that is widely blocklisted because it was previously leased to a widely exploited open proxy. You may not be so lucky defining the terms of your relationship with each and every mail server to which your server connects. Maybe this doesn't bug you so much, or even effect you at all, but it would bug me.
Well, this story's fallen off the main page now and you'll probably be the only one reading this. Good luck with your mail server, and, should your ISP one day decide to block outbound port 25, you're not totally screwed. If they do care about letting customers run mail servers, they will work with you to set up something. Hopefully something abuse proof, for the good of the internet.
I did, and it's allowed. And I don't need to run my own mail server. I want to run my own mail server. And I want to run my own mail server because TMDA is the most effective spam blocker that I've tried. It's a *ton* easier to use with your own domain and mailserver.
Cool beans dude, go for it. Any egress blocking won't affect your inbox, as long as others aren't using source port 25 to connect to your port 25. That would be a broken way of doing things, indeed. As far as outgoing mail, you can relay through the ISPs SMTP servers or beg them to lift any blocking on port 25 for your special case. None of this should be a problem for an ISP that cares about providing customers services they want and preventing abuse.
Are you saying that since some of these dynamic IPs can be used by spammers, that all should dynamic IP's should be considered bad?
In practice, they are considered bad. Browsing through my own spam, I see the majority to be open proxy and open relay abuse. I check the IPs in the top-most Received: header (the only one I can really trust) and find DSL and cable modem IPs connecting. Result: that space gets shitlisted as a spam source, in my own filters and public blocklists. If the ISP cared at all about preventing abuse, solving the open proxy/relay problem on their network would be a good start. Block outgoing port 25 connections first, then handle the customers that have special needs (you) later. That is, if they even care about that minority in their customer base.
My service uses dynamic IP address only because static IPv4 addresses are in too high of demand.
I'm curious how you handle DNS issues with a dynamic IP. My first instinct here would be a problem propogating changes when your ISP gives you a new IP. Is there a service for people who need domain name to dynamic IP resolution I haven't heard of? Links....
The terms of service of my cable modem allow for running a mail server. That is a term that is between them and me. Stop trying to interfere with it, please...
Dude, I can't do a damn thing about what your ISP allows on the net. If someone doesn't like it, they won't accept traffic. What I'm saying is that an ISP should be able to let you run your server and block port 25 from everyone who isn't so we can all stop getting spam delivered from personal firewall software. Whatever solution they use to get your email out should be easily monitored for abuse. If the terms of your provider allow you to spam the shit out of the internet, expect it in a blocklist. If they allow responsible users to run servers, and stop abuse from the rest of the network, all is well.
Port 25 egress blocking is a good start to the spam problem for two reasons: First, it prevents a spammer from signing up and just doing direct-to-MX spam from that throwaway account. Not many spammers do this anymore, because its easily tracead and bigger ISPs kick those accounts fastest. Second, it limits a spammer's ability to abuse open proxies and relays on a network. Say clueless users are running a WinGate open proxy or an open sendmail relay on an older default Linux/BSD install on their cable or DSL line. A spammer could try to relay spam through it, but the egress block would stop it.
I see alot of complaints here about how such a block prevents you from running a mail server on your broadband line. People, this is residential service you are getting here. If you need to run your own mail server you need to find out about that when you sign up for service. A typical residential user never needs to connect to any SMTP relay except the ones the ISP provides. These users are also more likely to cluelessly leave their computers open to abuse. If you're responsible enough to run a mail server, and you really NEED one, get a real account.
Another option is to relay your mail over a non-standard port through a third-party email provider, if you really loathe your ISPs relays. This is my situation, and I use Lux Scientiae. They run a SMTP AUTH relay on a secondary non-standard port. It's locked down to prevent abuse, and SMTP AUTH lets them track down any of their users that abuse it. They don't accept incoming mail on that non-standard port, only relay for users, so it's not like they're re-defining SMTP to use a different port.
Of course, there will always be those ISPs that really don't care about preventing abuse. This is why blocklists even exist, to allow users to shut out the bad neighborhoods on the net. It would be nice if all those residential broadband users' computers couldn't be hijacked by spammers. As it stands, they are, so one way or another port 25 traffic is blocked.
Bottom line: software companies do not trust you.
I would like nothing more than for a software companies to justify their actions by saying "That's correct, we don't trust users." Maybe AMI is more of a middleman and is only giving software companies tools to restrict end users. But, he was presented with this issue in the interview and the response was not clear.
Bottom line: software companies do not trust you. I know it, you know it, but when they try to dance around the issue when confronted, it is just insulting.
Now, who wants to see me hit a few dingers!!!
Perhaps I should have said that in the interview.
Which is why I asked for a follow up. It may have been unintentional on your part, but the issue I addressed in my follow up was only addressed indirectly in the interview. We all *know* how vendors feel about us end users, they just won't say it to our faces. Attempts to obscure one's true intentions bug me alot more than those intentions themselves.
So, roblimo says this guy reads Slahsdot, maybe he will answer follow-up questions here...
Please clarify, in 50 words or less, wether or not the trust model that TCPA implements will ever allow software to consider the owner and operator of a TCPA-enabled computer "not trusted."
If you can, with extra effort, go from "reading any trace data would be very near impossible" to "reading any trace data is mathematically proven to be impossible," that extra effort may be justified.
Consider that 20 years from now, HD technololgy will most likely have increased, and today's monster drives will look old. Who knows what technology will be available.
So the question is then: "For how long do you want your data to be unrecoverable?" For some the answer may be "Long enough," but for many, the answer is "As long as evil exists."
Several passes of /dev/random is certainly more secure. Writing a predictable pattern, such as /dev/zero (which, given HD encoding schemes does not actually mean all zero bits on the disk) only gives an attacker a pattern to subtract from the signal on the disk and recover the original data. Writing zero over a one looks different than writing a zero over a zero when you look at the disk on a low-level.
In the article, it wasn't so much that the Chicago PD simply didn't want to help out, it's that they wouldn't be able to do so in the time frame the author would've hoped for. It was the FBI and Secret Service that wouldn't touch the case, and referred him to local authorities. Yeah, he had information already gathered, but the cops have to do their own investigation as well. Chicago is a big city with all the crime problems that come with big cities, and maybe they do need to hire more investigators to improve response time. But they did not all together refuse to investigate, according to the article.
Shopping at Best Buy for a new television, the sales monkey tells me that the expected life of a television is about four years. I'm not too sure what he meant by that, or what kind of research Best Buy corporate goons do to reach that conclusion (and then train the monkeys to quote it), but the TV sitting in my living room that I eventually decided NOT to replace was made in 1982.
Funny thin is they're still pushing you to upgrade to a digital-ready TV because analog will no longer be broadcasted in about .... four years.
Moral of the story: don't listen to sales monkeys.
For reference, I believe the correct term is "dittohead."
Apparently, it was a big deal on May 11, 2002, the date the Register published that article.
Isn't there some sort of judge that looks beyond the length of his nose, into the background of the company?
That's not the judge's job. That's the defence's job. They then present the facts to the judge, maybe a jury if one is requested, to take into consideration.
All the court has to go on when agreeing to hear the case is 1) PanIP has a patent on a process. 2) Someone has implemented the patented process without the permission of the patent holder. 3) The law says PanIP can petition the court for a redress of this specific greivance.
The claim that 1) never should've happened will be decided in court. The opinion that the last thing PanIP wants is to go to court is suggested by the pattern they have chosen in filing their lawsuits.
Since a buffer overflow attack overwrites with data memory addresses filled with instructions, why not designing an operative system that isolates the executable memory from the data memory?
The x86 is what we call a Von Neumann (maybe not spelled that way) architecture machine, meaning memory is memory and you can put whatever you want there. A Harvard architecure machine separates program and data memory. There are tradeoffs and advantages to each architecture.
The operating system you suggest running on a Von Neumann machine would essentially emulate a Harvard machine on hardware not designed to do that. To avoid buffer overflows, just use a Harvard machine with an OS designed for it. But you lose the advantages of a Von Neumann machine, like self-modifying code, simpler executable formats, simpler memory management.
In simple terms, all your questions could be answered with "It's a hardware thing."
That was the first time that PanIP filed some lawsuits. They have filed more, 10 defendants at a time, most recently on Oct. 4. This is an ongoing issue, so you can expect to see it posted on Slashdot a few more times.