First, I'm no expert on this, so go easy on me. I've been trying to drum up a dialog on this approach for a very long time, so thanks for helping!
You're basically having an SMTP server sign the email... how (exactly) will that prevent someone from spoofing their return address? From your description, all you're doing is using cryptography to ensure that the mail server that's sending the mail is in fact the mail server that's sending the mail... but this is pretty much guaranteed by the TCP protocol, and doesn't address the spoofability of an email address at all.
I suspect my ignorance will show here, but if that were the case, wouldn't e-mails from non-existent domains or domains not associated with the server indicated by the TCP info be the easiest to block?
How does using crypto between servers ensure that an email address isn't spoofed?
How does an e-mail address get resolved? Again, I'm not very well versed in this, but I assume the domain is the starting point.
1. If the sending server doesn't serve the domain, then it's a bogus return address. 2. If the server does handle the domain, but the e-mail address itself isn't recognized, it's a bogus return address. 3. If the address is handled by the server, but the key doesn't match, then it's a bogus e-mail.
So the process should be about the same as resolving the return e-mail address. The trick is that the resolution is used to validate its authenticity.
If your goal is to make sure that a mail server is an authoritative mail server for a domain (which your approach doesn't do - at least not the way you described it)...
I think it does that and more.
Are you suggesting that the mail servers keep a list of keys around indefinitely?
That's the whole point of the process. The sending server does not have to keep keys around. It uses a standard process to create a content key from the contents of the e-mail before it is sent. It uses a private key plus this e-mail key to create the validation key that is sent with the e-mail. The receiving server reconstructs the content key that is sent back to the originating server, along with the embedded validation key. Then the originating server simply uses the content key and its private key to reconstruct the validation key and if they match, the e-mail is valid!
I'm not trying to flame you...
No flame taken. As I mentioned, I am ignorant about most of how this works, but I really think this is the best type of approach, rather than hit-or-miss filters.
By definition filters are hit-and-miss and non-deterministic. I get almost exclusively SPAM with spoofed return addresses. How about this solution:
1. Sending mail server generates a tx content key based on the contents of an e-mail being sent. 2. Sending mail server uses the tx content key with a private key to create a confirmation key. 3. Sending mail server sends the e-mail, along with the confirmation key to the receiving server. 4. Receiving mail server generates a rx content key from the e-mail contents. 5. Receiving mail server sends the rx content key and the confirmation key back to the sending mail server. 6. Sending mail server uses its private key plus the rx content key to re-generate the confirmation key. 7. Sending mail server compares the confirmation keys. 8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox. 9. If the keys don't match, the mail is bounced.
The keys are in place to keep the SPAMmer from tagging along on a valid return address with mail that address didn't send. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
They don't "let" you do crap. For $70 a year, you can view the commercials. Kind of ridiculous to ask you to pay for a commercial asking you to pay for a product.
When phones first appeared, dialing meant talking to an operator who used banana plugs to connect you to the phone of the person you were calling. Then they put electromagnetic switches into place and you could dial yourself. At first this required dialing three digits. But this convenience was very short-lived as phones appeared in more homes and businesses and eventually we spent a number of years dialing five digits. That worked for local calls, but if you wanted to dial the next town, you had to go through the operator again. Then they put the equipment in place and added prefixes. They even gave them names to make them easier to remember. You've all heard of the "KLondike 5" prefix used on old TV and radio shows. The first two letters were for the first two numbers and the 5 was for the third number, which was also the first of the five digits you dialed for local calls mentioned above. (If you look at a phone, you'll see that K and L also stand for 5, so the prefix was 555, a prefix that was not allowed and is still only used for directory assistance, so was a good choice for TV, where no-one wanted to put a real phone number.)
Eventually we had even more phones, so even seven digits wasn't enough, so they created area codes. Now you had to dial ten digits to call the next state. But then more phones were put into place, and they needed ten digits just for the next town, so they added the 1 and you had to dial eleven digits for long distance, and now apparently all the time in NYC.
Now even within more and more towns, they have several "area codes," and there appears no relief in sight. In my local area, we went to ten digits several years ago. When I complained to the local phone company, they claimed that I'd soon be able to take my phone number with me, so the concept of an "area code" wouldn't mean much. Not too bad...if they ever did it. My neighbor moved one mile within the same town but had to change his phone number. I'm moving to a neighboring town and will have to do the same. But I still have to dial ten digits. What a load of crap!
But I think I have a (perhaps radical and too late) solution:
1. Celular phones should have separate area codes. An area code doesn't make sense for mobile phones, so give them their own. Besides, then you could at least keep your cel phone number if you moved (and not be long distance from your new home). When you call the phone, you get a message if it's a long distance call and you can decide then if you want to pay the toll.
2. All pagers must have consolidated phone numbers. There is no reason that each pager needs its own phone number. Most pagers are not used much at all, especially compared to your typical voice number. A phone number plus a 4-digit code would free up tons of phone numbers for regular use.
3. Restore the "area codes" to areas, and get rid of "overlays." Who's the rocket scientist that figured out overlays? There is no real benefit, and the drawbacks are ridiculous. Almost without exception, the only reason we're outgrowing area codes is because of cel phones. The density of ground lines is pretty limited, so with 1 above, area code issues go away.
4. With area codes restored, allow you to dial just the end of a phone number in your same area code/prefix plus the pound (#) key. I really should have patented this idea and charged the phone company $$$ for it. But the idea is simple.
Just think: For my next door neighbor, I'd only have to dial four digits and the #! A local business, maybe seven digits.
As I understand it, Microsoft's CODECs are heavily based on MPEG4. Aren't they voilating the patents already at this point?
As for MPEG-LA and the rest of the "standards comittee." There should be absolutely no charge for "standards" that are issued by a "standard comittee," unless that "standard comittee" actually provides something (software, hardware, etc.). Otherwise, the whole thing is a thinly veiled process to come up with ideas and then profit from someone else's actual work.
At the point where you label it "standard" and push everyone to adopt it for "compatibility," you should lose the right to charge for the idea.
I wish I remembered who said it, but I agree that "the best science fiction puts ordinary people into extraordinary circumstances." And it never hurts if the "ordinary people" show just a little human frailty, but overcome it with the human dignity and determination that we really want to identify with and see in ourselves.
I think this works in the long term better than whitelists:
1. Sending mail server generates a tx content key based on the contents of an e-mail being sent. 2. Sending mail server uses the tx content key with a private key to create a confirmation key. 3. Sending mail server sends the e-mail, along with the confirmation key to the receiving server. 4. Receiving mail server generates a rx content key from the e-mail contents. 5. Receiving mail server sends the rx content key and the confirmation key back to the sending mail server. 6. Sending mail server uses its private key plus the rx content key to re-generate the confirmation key. 7. Sending mail server compares the confirmation keys. 8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox. 9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
If they were truly more reliable, then the drives wouldn't break, meaning that a longer warranty would not cost the manufacturers anything, and in fact would be a selling point. The change actually is a sure indication of exactly the opposite: the drives are failing more often, and they don't want to pay for it.
Does Phoenix have a smaller footprint than Mozilla? I only have 128MB, and Mozilla makes me spend loads of time swapping if I run anything else. Netscape, Opera, and Internet Exploiter don't do this. It's my last complaint about Mozilla.
As someone in the computer/electronics industry, where we are squeezed for every penny, and where we have to add features each year just to keep the same (barely profitable) price, it is extremely frustrating to see the two industries that seem totally unaffected by competition:
the phone companies and
cable/satellite companies. Sure, I can switch phone companies. But I lose my phone number (still, even though they make me dial 10 digits to call my nextdoor neighbor, which was supposed to be so I could keep my phone number). But wait, for a bit more, you can block your phone number. And for a bit more, you can block people who block their phone number. But in either case, the phone company will sell your phone number to telemarketers to ensure that you do get calls that you will want to block...thus ensuring that you buy caller ID. Oh, and now they'll raise the price for caller ID, thank you very much. And if your state creates a no-call list, you'll have to pay for that too. Oh, but wait, some companies can get a state license to ignore the list you paid for and call you anyway. But you can pay for caller ID....
The phone and cable companies introduced high-speed internet, and the prices go up while the bandwidth goes down. This year's fastest processors cost the same as last year's that were slower. This year's hard drives are bigger and faster for about the same as last year's. You can have more memory cheaper than last year. But they want to you upgrade to DSL or cable-modems by paying more. But if you actually use the bandwidth, they'll adjust the prices so you have to pay more, or you get less bandwidth...not much more than dialup in the end. Oh yeah, and the basic phone bill will go up too, to cover the cost of the digital services they are now offering. And they don't even offer any package deals with an actual discount (they just put all the same chareges on one bill).
And don't get me started on cable/satellite. They raised my cable rates a few years back to pay for "improving the infrastructure" so they could "upgrade to digital cable." So now they have digital cable, but I still have to pay extra for it?I want my money back then (I guess we aren't demaning it back because we have a short memory)! And then they raise the price of basic cable again, and again, and just for good measure, again...because you know electronics equipment prices just keep skyrocketing and the number of subscribers keeps going down...oh wait.... And then have the nerve to ask why I don't want to pay more for digital cable. Besides, then I can pay even more by ordering pay-per-view!
What I wish is that I could take this offer I got for free satellite equipment and installation and then programming at $21.99/mo and the cable company would meet it (you know, the way BestBuy does with a special at Circuit City?), instead of charging me $36.99/mo for fewer analog channels. I want the convenience of analog so I don't have to have a box (and the requisite fees) for all four TVs and both VCRs, and so I can use the picture-in-picture I paid for (we already went through this box-per-TV/VCR crap with cable tuners). Plus, I don't want to look at the over-filtered, over-compressed digital crap they send to the satellites. It may be digital, but it's garbage. I'd rather look at a bit of analog noise than golf greens with no details because they were completely filtered out and the halos and distortions of too-low bitrates.
And I also wish that one of the phone companies would offer me the following package:
local phone at as significant discount with FREE features (caller ID/call waiting/call blocking)
long distance w/no fee at a low minute rate
cel phone with decent minutes for a cheap monthly rate
television for
high-speed internet for
Xesdeeni
It just turns the CD into a dongle
on
CD Copy Stopper
·
· Score: 1
I used to hate dongles. But I have come to believe that I just have hated every implementation detail up until now, including this one.
The problem is the need to search and locate the dongle itself, whether a CD or something that plugs into an I/O port (serial, mouse, USB, etc.), in order to use the product. It makes legitimate use of the product a severe pain, even if it legitimately protects the product.
I think your assumption is invalid. I think adding an entry next to each e-mail address on the CDs they hawk that contains an address known to be on your whitelist will become the norm, if a significant number of people adopts your idea. Heck, half the e-mail I get now says it's from me! And a significant group of other e-mail is copied to other people I know.
I think your idea only works so long as few others adopt it.
I'm trying to put forth an idea that will work for everyone, and should (with the help of people to actually peck away at the implementation details) be robust for a while.
So I have this big database on my machine based on my own e-mail? If my machine crashes, I have to start all over? And when the SPAMmers figure out they can send an innocent-looking e-mail with embedded SPAM images, then where are we?
So I'll make my suggestion to eliminate spoofed-address SPAM again:
1. Sending mail server generates a content key based on the contents of an e-mail being sent. 2. Sending mail server uses this key with a private key to create a public key. 3. Sending mail server sends the e-mail, along with the public key to the receiving server. 4. Receiving mail server generates a content key from the e-mail contents. 5. Receiving mail server sends the content key and the public key back to the sending mail server. 6. Sending mail server uses its private key plus the content key to re-generate the public key. 7. Sending mail server compares the public key to the one sent by the receiving mail server. 8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox. 9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
But aren't there a lot of legitimate e-mail addresses that send out mass mailings? Mailing lists, opt-in advertising, etc.? Won't those people have to set up automated confirmation e-mails? And can't SPAMmers just use those addresses as well? And in fact, can't they just add any necessary e-mail origin that is known to be on the e-mail recipient's white list to the CD full of e-mail addresses they sell?
Part of my idea is to actually validate the e-mail itself. That way they can't even hijack the same e-mail, much less create another one that looks like it's from and to addresses are the same as a previous one.
I keep trying to sell this idea...free...to at least eliminate spoofed address SPAM:
1. Sending mail server generates a content key based on the contents of an e-mail being sent. 2. Sending mail server uses this key with a private key to create a public key. 3. Sending mail server sends the e-mail, along with the public key to the receiving server. 4. Receiving mail server generates a content key from the e-mail contents. 5. Receiving mail server sends the content key and the public key back to the sending mail server. 6. Sending mail server uses its private key plus the content key to re-generate the public key. 7. Sending mail server compares the public key to the one sent by the receiving mail server. 8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox. 9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
Forget the law, I think we can eliminate most SPAM very simply with as small change to current technology I've outlined before:
"I can't figure out who to open a discussion with about this, but I have this simple idea that should at least eliminate the anonymous/spoofed spam, which is all I get.
You simply modify the mail servers to query the sending server whether a received mail actually came from that server. The query is a key based on the contents of the message and a key included with the message, which is itself based on the same contents and a private key of the sending server. If the sending server has been upgraded with this feature, it can validate, or not, the message. If it's not validated, the message is bounced. For backwards compatibility, if the sending server hasn't been upgraded, the message always goes through. [Here's the beauty of the idea:] But as more servers are upgraded, fewer and fewer servers will be able to be used as scapegoats for spoofed spam, and pressure will mount to upgrade these servers as well.
Eventually, the only spam you will get will be from a valid return address, which can be handled more effectively in more conventional ways. In fact, adding manual bouncing at this stage might be helpful as well, since now it really will bounce back to the sender.
I realize I've glossed over some details here, and someone much more experienced in mail servers will have to massage this approach to make it practical, but I think the germ of a very simple but effective idea is here."
Even for those of use without PHDs in Math, it is still inherently obvious that you can't compress completely random data losslessly at all.
If I have 4 bits, then I have 16 (2^4) combinations. If I want to compress this to 3 bits, then I can only have 8 (2^3) codes, so I have to use some of the codes for more than one combination. Obviously, I can't tell the difference between the multiple combinations from just the code, when I try to reverse the process.
Pretty obvious really, but then again this type of crap comes up every year or so. I suppose it makes some unscrupulous individuals enough investment money for them to run off to Burmuda.
That's the beauty of it. If they don't upgrade, they become one of the ever-decreasing number of servers that can be spoofed. They would be increasingly swamped with bounced mail, e-mail to abuse@, or even black-listed completely. It's kind of net peer pressure.
I can't figure out who to open a discussion with about this, but I have this simple idea that should at least eliminate the anonymous/spoofed spam, which is all I get.
You simply modify the mail servers to query the sending server whether a received mail actually came from that server. The query is a key based on the contents of the message and a key included with the message, which is itself based on the same contents and a private key of the sending server. If the sending server has been upgraded with this feature, it can validate, or not, the message. If it's not validated, the message is bounced. For backwards compatibility, if the sending server hasn't been upgraded, the message always goes through. But as more servers are upgraded, fewer and fewer servers will be able to be used as scapegoats for spoofed spam, and pressure will mount to upgrade these servers as well.
Eventually, the only spam you will get will be from a valid return address, which can be handled more effectively in more conventional ways. In fact, adding manual bouncing at this stage might be helpful as well, since now it really will bounce back to the sender.
I realize I've glossed over some details here, and someone much more experienced in mail servers will have to massage this approach to make it practical, but I think the germ of a very simple but effective idea is here.
The U.S. Government was absolutely right. It was a bad idea to break M$ into two companies....it should have been broken up into FIVE: Desktop O/S, Server O/S, Portable O/S, Applications, and Services.
We've already seen them use their dominance in almost every one of these sections to force use of another. This is yet another example of using the Services to force use of desktop O/S and applications.
If the Fair Use doctrine says I can use content for my own purposes (e.g. school reports, viewing DVD content in places where only VCRs are available (the back seat of my mini-van to entertain my kids on a long drive), etc.), and the industry puts something in place which prohibits me from doing this, and further makes it illegal for me to circumvent this protection, even for Fair Use...doesn't that imply that the industry is now responsible for providing me a method around this protection?
I.E. they would have to provide the snippets I need for a school report, or a video tape copy for my road trip? Otherwise I can't exercise my right to Fair Use.
Perhaps we could begin making such requests to the content producers and innundate them. They, of course, would say no, and then THEY would be the "bad guy" when they were the defendent in our class-action suit to claim our Fair Use right.
Doesn't the GPL stand on the same ground as all the ridiculous new EULAs floating around? I mean, I bought a pieces of software that said I have to a) register to use (or it expires in 7 days), and b) that I can't sell or even give away when I don't want it any more! Apart from the obvious (What happens if the company goes out of business and I have to re-install the damn thing?), if they can actually enforce that kind of garbage, then I don't see how anyone can legally voilate the GPL either. I'm sure Vidomi has a nice EULA of their own. It seems like Open Source wins if GPL triumphs, and if not, then consumers can tear up their EULAs!
Xesdeeni
As I understand it, the FCC made a last-minute allowance for television stations to allow them to transmit any DTV format, not just HDTV. Now, if I were a television station owner, and you gave me a choice between replacing all of my equipment (cameras, monitors, mixing boards, tape decks, etc.) in order to transmit one HDTV signal, or adding just an A/D and being able to transmit 6 or 7 channels down the same pipe (including using all of my old archived footage), I'm going to choose the advertising revenue I can generate from 6 or 7 sets of eyeballs over 1 set. What was the FCC's justification for sinking HDTV in this manner?
Slashdot Mirror
First, I'm no expert on this, so go easy on me. I've been trying to drum up a dialog on this approach for a very long time, so thanks for helping!
You're basically having an SMTP server sign the email... how (exactly) will that prevent someone from spoofing their return address? From your description, all you're doing is using cryptography to ensure that the mail server that's sending the mail is in fact the mail server that's sending the mail... but this is pretty much guaranteed by the TCP protocol, and doesn't address the spoofability of an email address at all.
I suspect my ignorance will show here, but if that were the case, wouldn't e-mails from non-existent domains or domains not associated with the server indicated by the TCP info be the easiest to block?
How does using crypto between servers ensure that an email address isn't spoofed?
How does an e-mail address get resolved? Again, I'm not very well versed in this, but I assume the domain is the starting point.
1. If the sending server doesn't serve the domain, then it's a bogus return address.
2. If the server does handle the domain, but the e-mail address itself isn't recognized, it's a bogus return address.
3. If the address is handled by the server, but the key doesn't match, then it's a bogus e-mail.
So the process should be about the same as resolving the return e-mail address. The trick is that the resolution is used to validate its authenticity.
If your goal is to make sure that a mail server is an authoritative mail server for a domain (which your approach doesn't do - at least not the way you described it)...
I think it does that and more.
Are you suggesting that the mail servers keep a list of keys around indefinitely?
That's the whole point of the process. The sending server does not have to keep keys around. It uses a standard process to create a content key from the contents of the e-mail before it is sent. It uses a private key plus this e-mail key to create the validation key that is sent with the e-mail. The receiving server reconstructs the content key that is sent back to the originating server, along with the embedded validation key. Then the originating server simply uses the content key and its private key to reconstruct the validation key and if they match, the e-mail is valid!
I'm not trying to flame you...
No flame taken. As I mentioned, I am ignorant about most of how this works, but I really think this is the best type of approach, rather than hit-or-miss filters.
Xesdeeni
By definition filters are hit-and-miss and non-deterministic. I get almost exclusively SPAM with spoofed return addresses. How about this solution:
1. Sending mail server generates a tx content key based on the contents of an e-mail being sent.
2. Sending mail server uses the tx content key with a private key to create a confirmation key.
3. Sending mail server sends the e-mail, along with the confirmation key to the receiving server.
4. Receiving mail server generates a rx content key from the e-mail contents.
5. Receiving mail server sends the rx content key and the confirmation key back to the sending mail server.
6. Sending mail server uses its private key plus the rx content key to re-generate the confirmation key.
7. Sending mail server compares the confirmation keys.
8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox.
9. If the keys don't match, the mail is bounced.
The keys are in place to keep the SPAMmer from tagging along on a valid return address with mail that address didn't send. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
Xesdeeni
They don't "let" you do crap. For $70 a year, you can view the commercials. Kind of ridiculous to ask you to pay for a commercial asking you to pay for a product.
Xesdeeni
When phones first appeared, dialing meant talking to an operator who used banana plugs to connect you to the phone of the person you were calling. Then they put electromagnetic switches into place and you could dial yourself. At first this required dialing three digits. But this convenience was very short-lived as phones appeared in more homes and businesses and eventually we spent a number of years dialing five digits. That worked for local calls, but if you wanted to dial the next town, you had to go through the operator again. Then they put the equipment in place and added prefixes. They even gave them names to make them easier to remember. You've all heard of the "KLondike 5" prefix used on old TV and radio shows. The first two letters were for the first two numbers and the 5 was for the third number, which was also the first of the five digits you dialed for local calls mentioned above. (If you look at a phone, you'll see that K and L also stand for 5, so the prefix was 555, a prefix that was not allowed and is still only used for directory assistance, so was a good choice for TV, where no-one wanted to put a real phone number.)
Eventually we had even more phones, so even seven digits wasn't enough, so they created area codes. Now you had to dial ten digits to call the next state. But then more phones were put into place, and they needed ten digits just for the next town, so they added the 1 and you had to dial eleven digits for long distance, and now apparently all the time in NYC.
Now even within more and more towns, they have several "area codes," and there appears no relief in sight. In my local area, we went to ten digits several years ago. When I complained to the local phone company, they claimed that I'd soon be able to take my phone number with me, so the concept of an "area code" wouldn't mean much. Not too bad...if they ever did it. My neighbor moved one mile within the same town but had to change his phone number. I'm moving to a neighboring town and will have to do the same. But I still have to dial ten digits. What a load of crap!
But I think I have a (perhaps radical and too late) solution:
1. Celular phones should have separate area codes. An area code doesn't make sense for mobile phones, so give them their own. Besides, then you could at least keep your cel phone number if you moved (and not be long distance from your new home). When you call the phone, you get a message if it's a long distance call and you can decide then if you want to pay the toll.
2. All pagers must have consolidated phone numbers. There is no reason that each pager needs its own phone number. Most pagers are not used much at all, especially compared to your typical voice number. A phone number plus a 4-digit code would free up tons of phone numbers for regular use.
3. Restore the "area codes" to areas, and get rid of "overlays." Who's the rocket scientist that figured out overlays? There is no real benefit, and the drawbacks are ridiculous. Almost without exception, the only reason we're outgrowing area codes is because of cel phones. The density of ground lines is pretty limited, so
with 1 above, area code issues go away.
4. With area codes restored, allow you to dial just the end of a phone number in your same area code/prefix plus the pound (#) key. I really should have patented this idea and charged the phone company $$$ for it. But the idea is simple.
Just think: For my next door neighbor, I'd only have to dial four digits and the #! A local business, maybe seven digits.
Back to the Good Old Days!
Xesdeeni
As I understand it, Microsoft's CODECs are heavily based on MPEG4. Aren't they voilating the patents already at this point?
As for MPEG-LA and the rest of the "standards comittee." There should be absolutely no charge for "standards" that are issued by a "standard comittee," unless that "standard comittee" actually provides something (software, hardware, etc.). Otherwise, the whole thing is a thinly veiled process to come up with ideas and then profit from someone else's actual work.
At the point where you label it "standard" and push everyone to adopt it for "compatibility," you should lose the right to charge for the idea.
Xesdeeni
I wish I remembered who said it, but I agree that "the best science fiction puts ordinary people into extraordinary circumstances." And it never hurts if the "ordinary people" show just a little human frailty, but overcome it with the human dignity and determination that we really want to identify with and see in ourselves.
Xesdeeni
I think this works in the long term better than whitelists:
1. Sending mail server generates a tx content key based on the contents of an e-mail being sent.
2. Sending mail server uses the tx content key with a private key to create a confirmation key.
3. Sending mail server sends the e-mail, along with the confirmation key to the receiving server.
4. Receiving mail server generates a rx content key from the e-mail contents.
5. Receiving mail server sends the rx content key and the confirmation key back to the sending mail server.
6. Sending mail server uses its private key plus the rx content key to re-generate the confirmation key.
7. Sending mail server compares the confirmation keys.
8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox.
9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
Xesdeeni
First, shouldn't the telcos be paying for me to be on the list, since they profit from selling my phone # in the first place?
But second, now I'm getting calls from "licensees" of the state. So now the states are playing the same game as the the telcos.
Xesdeeni
If they were truly more reliable, then the drives wouldn't break, meaning that a longer warranty would not cost the manufacturers anything, and in fact would be a selling point. The change actually is a sure indication of exactly the opposite: the drives are failing more often, and they don't want to pay for it.
Xesdeeni
Does Phoenix have a smaller footprint than Mozilla? I only have 128MB, and Mozilla makes me spend loads of time swapping if I run anything else. Netscape, Opera, and Internet Exploiter don't do this. It's my last complaint about Mozilla.
Xesdeeni
the phone companies and
cable/satellite companies.
Sure, I can switch phone companies. But I lose my phone number (still, even though they make me dial 10 digits to call my nextdoor neighbor, which was supposed to be so I could keep my phone number). But wait, for a bit more, you can block your phone number. And for a bit more, you can block people who block their phone number. But in either case, the phone company will sell your phone number to telemarketers to ensure that you do get calls that you will want to block...thus ensuring that you buy caller ID. Oh, and now they'll raise the price for caller ID, thank you very much. And if your state creates a no-call list, you'll have to pay for that too. Oh, but wait, some companies can get a state license to ignore the list you paid for and call you anyway. But you can pay for caller ID....
The phone and cable companies introduced high-speed internet, and the prices go up while the bandwidth goes down. This year's fastest processors cost the same as last year's that were slower. This year's hard drives are bigger and faster for about the same as last year's. You can have more memory cheaper than last year. But they want to you upgrade to DSL or cable-modems by paying more. But if you actually use the bandwidth, they'll adjust the prices so you have to pay more, or you get less bandwidth...not much more than dialup in the end. Oh yeah, and the basic phone bill will go up too, to cover the cost of the digital services they are now offering. And they don't even offer any package deals with an actual discount (they just put all the same chareges on one bill).
And don't get me started on cable/satellite. They raised my cable rates a few years back to pay for "improving the infrastructure" so they could "upgrade to digital cable." So now they have digital cable, but I still have to pay extra for it? I want my money back then (I guess we aren't demaning it back because we have a short memory)! And then they raise the price of basic cable again, and again, and just for good measure, again...because you know electronics equipment prices just keep skyrocketing and the number of subscribers keeps going down...oh wait.... And then have the nerve to ask why I don't want to pay more for digital cable. Besides, then I can pay even more by ordering pay-per-view!
What I wish is that I could take this offer I got for free satellite equipment and installation and then programming at $21.99/mo and the cable company would meet it (you know, the way BestBuy does with a special at Circuit City?), instead of charging me $36.99/mo for fewer analog channels. I want the convenience of analog so I don't have to have a box (and the requisite fees) for all four TVs and both VCRs, and so I can use the picture-in-picture I paid for (we already went through this box-per-TV/VCR crap with cable tuners). Plus, I don't want to look at the over-filtered, over-compressed digital crap they send to the satellites. It may be digital, but it's garbage. I'd rather look at a bit of analog noise than golf greens with no details because they were completely filtered out and the halos and distortions of too-low bitrates.
And I also wish that one of the phone companies would offer me the following package:
local phone at as significant discount with FREE features (caller ID/call waiting/call blocking)
long distance w/no fee at a low minute rate
cel phone with decent minutes for a cheap monthly rate
television for
high-speed internet for
Xesdeeni
I used to hate dongles. But I have come to believe that I just have hated every implementation detail up until now, including this one.
The problem is the need to search and locate the dongle itself, whether a CD or something that plugs into an I/O port (serial, mouse, USB, etc.), in order to use the product. It makes legitimate use of the product a severe pain, even if it legitimately protects the product.
Xesdeeni
I think your assumption is invalid. I think adding an entry next to each e-mail address on the CDs they hawk that contains an address known to be on your whitelist will become the norm, if a significant number of people adopts your idea. Heck, half the e-mail I get now says it's from me! And a significant group of other e-mail is copied to other people I know.
I think your idea only works so long as few others adopt it.
I'm trying to put forth an idea that will work for everyone, and should (with the help of people to actually peck away at the implementation details) be robust for a while.
Xesdeeni
So I have this big database on my machine based on my own e-mail? If my machine crashes, I have to start all over? And when the SPAMmers figure out they can send an innocent-looking e-mail with embedded SPAM images, then where are we?
So I'll make my suggestion to eliminate spoofed-address SPAM again:
1. Sending mail server generates a content key based on the contents of an e-mail being sent.
2. Sending mail server uses this key with a private key to create a public key.
3. Sending mail server sends the e-mail, along with the public key to the receiving server.
4. Receiving mail server generates a content key from the e-mail contents.
5. Receiving mail server sends the content key and the public key back to the sending mail server.
6. Sending mail server uses its private key plus the content key to re-generate the public key.
7. Sending mail server compares the public key to the one sent by the receiving mail server.
8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox.
9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
Xesdeeni
But aren't there a lot of legitimate e-mail addresses that send out mass mailings? Mailing lists, opt-in advertising, etc.? Won't those people have to set up automated confirmation e-mails? And can't SPAMmers just use those addresses as well? And in fact, can't they just add any necessary e-mail origin that is known to be on the e-mail recipient's white list to the CD full of e-mail addresses they sell?
Part of my idea is to actually validate the e-mail itself. That way they can't even hijack the same e-mail, much less create another one that looks like it's from and to addresses are the same as a previous one.
Xesdeeni
I keep trying to sell this idea...free...to at least eliminate spoofed address SPAM:
1. Sending mail server generates a content key based on the contents of an e-mail being sent.
2. Sending mail server uses this key with a private key to create a public key.
3. Sending mail server sends the e-mail, along with the public key to the receiving server.
4. Receiving mail server generates a content key from the e-mail contents.
5. Receiving mail server sends the content key and the public key back to the sending mail server.
6. Sending mail server uses its private key plus the content key to re-generate the public key.
7. Sending mail server compares the public key to the one sent by the receiving mail server.
8. If the keys match, the receiving mail server allows the mail to enter the recipient's mailbox.
9. If the keys don't match, the mail is bounced.
This should eliminate spoofed e-mail, which is the only type I get. This technique also keeps the second transaction to a minimum exchange of keys. The keys add traffic, but the eliminated SPAM traffic more than makes up for the penalty. As more and more mail servers are updated with this feature, spoofing is all but eliminated. The remaining "spoofable" domains can be explicitly severed from the net or blocked.
Xesdeeni
Won't this also affect Babel Fish, when it frames a page after it translates it so you can click on a link and have it translated too?
Xesdeeni
Forget the law, I think we can eliminate most SPAM very simply with as small change to current technology I've outlined before:
"I can't figure out who to open a discussion with about this, but I have this simple idea that should at least eliminate the anonymous/spoofed spam, which is all I get.
You simply modify the mail servers to query the sending server whether a received mail actually came from that server. The query is a key based on the contents of the message and a key included with the message, which is itself based on the same contents and a private key of the sending server. If the sending server has been upgraded with this feature, it can validate, or not, the message. If it's not validated, the message is bounced. For backwards compatibility, if the sending server hasn't been upgraded, the message always goes through. [Here's the beauty of the idea:] But as more servers are upgraded, fewer and fewer servers will be able to be used as scapegoats for spoofed spam, and pressure will mount to upgrade these servers as well.
Eventually, the only spam you will get will be from a valid return address, which can be handled more effectively in more conventional ways. In fact, adding manual bouncing at this stage might be helpful as well, since now it really will bounce back to the sender.
I realize I've glossed over some details here, and someone much more experienced in mail servers will have to massage this approach to make it practical, but I think the germ of a very simple but effective idea is here."
Xesdeeni
Even for those of use without PHDs in Math, it is still inherently obvious that you can't compress completely random data losslessly at all.
If I have 4 bits, then I have 16 (2^4) combinations. If I want to compress this to 3 bits, then I can only have 8 (2^3) codes, so I have to use some of the codes for more than one combination. Obviously, I can't tell the difference between the multiple combinations from just the code, when I try to reverse the process.
Pretty obvious really, but then again this type of crap comes up every year or so. I suppose it makes some unscrupulous individuals enough investment money for them to run off to Burmuda.
Xesdeeni
That's the beauty of it. If they don't upgrade, they become one of the ever-decreasing number of servers that can be spoofed. They would be increasingly swamped with bounced mail, e-mail to abuse@, or even black-listed completely. It's kind of net peer pressure.
Xesdeeni
I can't figure out who to open a discussion with about this, but I have this simple idea that should at least eliminate the anonymous/spoofed spam, which is all I get.
You simply modify the mail servers to query the sending server whether a received mail actually came from that server. The query is a key based on the contents of the message and a key included with the message, which is itself based on the same contents and a private key of the sending server. If the sending server has been upgraded with this feature, it can validate, or not, the message. If it's not validated, the message is bounced. For backwards compatibility, if the sending server hasn't been upgraded, the message always goes through. But as more servers are upgraded, fewer and fewer servers will be able to be used as scapegoats for spoofed spam, and pressure will mount to upgrade these servers as well.
Eventually, the only spam you will get will be from a valid return address, which can be handled more effectively in more conventional ways. In fact, adding manual bouncing at this stage might be helpful as well, since now it really will bounce back to the sender.
I realize I've glossed over some details here, and someone much more experienced in mail servers will have to massage this approach to make it practical, but I think the germ of a very simple but effective idea is here.
Xesdeeni
The U.S. Government was absolutely right. It was a bad idea to break M$ into two companies....it should have been broken up into FIVE: Desktop O/S, Server O/S, Portable O/S, Applications, and Services.
We've already seen them use their dominance in almost every one of these sections to force use of another. This is yet another example of using the Services to force use of desktop O/S and applications.
Hey DoJ! Here's a quarter. Go buy a clue!
Xesdeeni
If the Fair Use doctrine says I can use content for my own purposes (e.g. school reports, viewing DVD content in places where only VCRs are available (the back seat of my mini-van to entertain my kids on a long drive), etc.), and the industry puts something in place which prohibits me from doing this, and further makes it illegal for me to circumvent this protection, even for Fair Use...doesn't that imply that the industry is now responsible for providing me a method around this protection?
I.E. they would have to provide the snippets I need for a school report, or a video tape copy for my road trip? Otherwise I can't exercise my right to Fair Use.
Perhaps we could begin making such requests to the content producers and innundate them. They, of course, would say no, and then THEY would be the "bad guy" when they were the defendent in our class-action suit to claim our Fair Use right.
Xesdeeni
Doesn't the GPL stand on the same ground as all the ridiculous new EULAs floating around? I mean, I bought a pieces of software that said I have to a) register to use (or it expires in 7 days), and b) that I can't sell or even give away when I don't want it any more! Apart from the obvious (What happens if the company goes out of business and I have to re-install the damn thing?), if they can actually enforce that kind of garbage, then I don't see how anyone can legally voilate the GPL either. I'm sure Vidomi has a nice EULA of their own. It seems like Open Source wins if GPL triumphs, and if not, then consumers can tear up their EULAs! Xesdeeni
As I understand it, the FCC made a last-minute allowance for television stations to allow them to transmit any DTV format, not just HDTV. Now, if I were a television station owner, and you gave me a choice between replacing all of my equipment (cameras, monitors, mixing boards, tape decks, etc.) in order to transmit one HDTV signal, or adding just an A/D and being able to transmit 6 or 7 channels down the same pipe (including using all of my old archived footage), I'm going to choose the advertising revenue I can generate from 6 or 7 sets of eyeballs over 1 set. What was the FCC's justification for sinking HDTV in this manner?