Ahh, word-mincing. Cleverly worded that. The only thing RMS is saying is that copyright was not a "natural right".
To quote what you were quoting:
The founders of our country adopted a different premise, that copyright is not a natural right of authors, but an artificial concession made to them for the sake of progress.
Of course it's not a natural right! An artificial concession was made granting protection, granted. But what did this concession grant them? Legal rights! Artificial rights if you mind you, rights that are revokable, so to speak.
Basically, we agree in principle, but my point is that, whether you like it or not, copyright owners do have legal rights under the system, and as such, until the law changes, calling DRM for Digital Rights Management is entirely fair, even though it is a case of euphemistic marketing-speak.
That doesn't stop anti-DRM people from calling it "Digital Restrictions Management" though. It's pretty clever, using their own acronym against them that way.
Where on earth did you get that strange definition of "right"?
The law can very well give a certain person or group a "right" to do something. I think you're confusing the issue with the issue of inalienable and human rights with the more basic definition of the word right (pay special attention to definition 7 under 'noun'.)
You forgot the http:/// in front. Without that, your web browser is going to treat the hostname you mentioned as a relative link, which probably isn't want you want.
This needs to be stressed. The biggest threat to computer security is not insecurity in the underlying operating system. It's users not knowing what they're doing.
In this sense, having operating systems hide operation details from you is a Very Bad Thing.
Also, it's naïve to think that the pure virtue of Linux and Mac OS X running everything as an unpriviledged user as standard is going to stop virus writers. You don't need to take over a computer completely to screw with it. You can install nice little keyloggers or remove user data just fine without having to become root.
You can't use tin foil. That's implanted with secret government RFID equipment they implanted in the tin ore making tin foil actually AMPLIFY the signal.
You need to use aluminum foil. They haven't figured out how to taint Bauxite quite yet.
He explains that he got the same results using the rawmedia interface. It was just a bitch to do the aligned writes in perl.
Where? I found no reference to rawmedia in the linked article. If it was in another article I'm not aware of, please tell me. If I write something incorrect in one article, but I have 10 other articles where I'm correct, does that make a person wrong for pointing out a mistake in any of the articles somebody has written?
Fsync on linux happens to issue the underlying raw flush command.
Who mentioned Linux? I certainly only mentioned it as one of the sources I pulled man pages for, for a standard library function available on pretty much all operating systems today. If you want to go platform-specific, fine. That's not what I was doing. The only place he mentions any specific operating system is in his later clarification in the top of his post.
The issue is NOT that fsync isn't guaranteed to do a physical flush to media! The issue is that even though on linux it happens to issue that command, the underlying physical media controller lies about having done so.
I understood this after he wrote his clarification. The thing is, I didn't intend to criticise the person or his knowledge. I can't do that. I was discussing the content of the article, where he specifies that the fsync() call IS guaranteed to flush to disk (without specifying which operating system) and then blames hard drive manufacturers for fsync() not delivering the guarantees it's specifically documented not to guarantee.
You owe him a public apology. I doubt you'll have the balls to do it, though.
I'm willing to admit, publically, that he knows his shit, and that if I somehow doubted it, it's because he wrote a misleading article. I won't apologise for criticising a poorly written article though. I'm not a mind reader, I can't assess knowledge that's in somebody's head, but not in writing.
He does have a point -- enabling write caching on high-end drives by default is brain dead. If that were the point he was making, I'd agree. Instead, he went on about drives not obeying fsync(). Without knowing what operating system's fsync() he was talking about, I had no choice but to refer to as much as the library standard says.
For full disclosure, I did reply to his reply to me (he probably sent the same reply to many people) acknowledging that I'm somewhat happy with the way his article reads now that he's added his clarification at the top.
Either way, I don't think there's anything left to discuss here. The author of the article has already updated his blog with the relevant information, and I have no beef with him, and I hope he has no beef with me.
For full disclosure: a copy of the followup he sent and my final reply is now up at my web space.
There. I had the balls to admit he knows his shit after all. Now, the ball's* in your court. Unless you have the balls to identify yourself when you reply, don't bother replying at all. I have nothing more to say to an Anonymous Coward.
pv2b
* Man. That was a bad pun. Please hit me in the head with a large anti-pun readjustion device or whatever.
Right. And the author is implementing a program that sends raw commands to ATA drives... in perl. Right. He does no such thing, at least not what I can see, by glancing at the source code of the perl script. Granted, I'm not fluent in perl, but it doesn't seem to do anything else than to do an fsync() equivalent. Please do correct me if I'm wrong.
The truth is that he doesn't know wtf he's talking about. I decide to cut him some slack though, because the FreeBSD 4 man pages at least are very misleading, and I don't know what man pages he did read.
By the way, I sent him an e-mail. It's available on my web space. I'm not posting it in full here, because it's a little long and it would be redundant, since a lot of the surrounding posts discuss pretty much the same thing as I said.
Why, after all, it rules the waves in Saturn's belt. Britannia rule the waves. Get it?
Besides, what more fitting tribute to the decline of the British Empire than naming an insignificant 7 kilometer wide hunk of rock(or whatever it's made of) after it.:-)
A ATTworldnet user complains about spam. ATT complains to the owner of the email server the spam came from. THey say 'piss off'. ATT then updates it's list of 'bad' email servers. That list is sent out to other email servers as they connect to deliver mail. Kinda like the Fidonet of old, or Usenet of today.
I think we're talking about different things here. I'm talking about the huge amounts of spam coming from compromised home machines, which is what got Telewest in trouble. You're talking about spammers sending e-mail directly to their recipients from their servers connected to leased lines or in colo facilities. These are two entirely different problems.
When it comes to blocking e-mail from spammers sending directly to recipients, you already have blackhole servers which solve that particular problem. You ignore complaints, you're added to blacklists of all servers filtering based on specific blackholes. What you're trying to suggest is that the entire follow the same blacklist. Not only is it arrogant to think that one group can somehow get all the world's mail administrators to agree to let them decide who to receive mail from, it's also undesirable and open for wide abuse. I think the current system of blackholing works great, since the filters are applied selectively by the recipients, and if you're not happy with the policy a certain RBL uses, you can always as a recipient choose another RBL. So in essence, this problem is already solved, and in a better way than you suggest. Some ISP:s housing these kind of spammers can even be (and have been) blocked wholesale. There is collateral damage of course, but if the ISP is uncooperative, the legitimate customers will just switch ISP:s.
When it comes to blocking e-mail sent through zombies, that's a completely different problem, that I have outlined in my previous posts. The reason I want a limit on outgoing e-mails sent through *broadband* connections, is to stop the spam from being sent in the first place. It doesn't matter if the ISP responds timely to complaints, by the time the complaints are received, the e-mails are already away and the damage has been done, and by the time the zombie responsible is shut down, the spammers have already found new zombies to replace it. Blackholing zombies is futile in the long term, and the best RBLs can hope to achieve by doing it, is to encourage broadband ISPs to take better preventative measures, like the one I'm suggesting.
In short, the Internet isn't one big happy familiy that can be controlled from above. At best, you can get groups of disgruntled sysadmins together cooperating on blacklists, which is what's happening already. This will stop a lot of spam sent through business lines, but in practice does nothing to the problem of spam through zombied broadband machines.
You say my plan is similar to the way it is done now with IPs. Well, FINE. Let's quit arguing and get the more important second part of my plan, the Email Death Penalty part set up. The First part is just to make sure of who the target is, to avoid mistakes. But if the needed information already exists, let's skip that part and get on with the EDPs already.
All right. We agree that the problem is not technical -- the tools to do what you propose already exists without requiring certificate technology, but administrative. Now we can move on from *how* an EDP is possible to whether it's a good idea.
First of all, who do you propose should decide who gets EDP:ed and who not? You? A consortium of large ISPs? A group of random roaming anti-spam vigilantes? And who is to watch that the group doesn't overstep it's boundaries and not block an ISP for completely arbitrary reasons?
A system similar to the one you propose already exists. There exist blacklists that individual mail administrators can use on an individual and voluntary basis. They don't block all e-mail on the Internet, but they block enough e-mail for ISP:s to be concerned when they get blocked. These people who run these anti-spam lists are hot-headed enough already, I sure as hell wouldn't want them controlling *all* the e-mail on the Internet.
The problem with these systems is that they only harm the ISP and its customers, all because some of their customers don't know how to properly secure their Windows machines. They don't need to be hurt more than they already are to get the message. The spammers themselves aren't hurt. They just move on to zombies on another as-yet-unblocked ISP.
So, basically, you're proposing to build another bigger and better black hole to encompass all traffic -- in order to reduce collateral damage?! This doesn't make sense. If you want to reduce collateral damage, you make your blocking less aggressive, not more aggressive.
Apparently, the blackhole systems that already exist are doing their job by blocking enough e-mail to be a major inconvenience and cause the ISP to be more proactive in shutting down spam zombies. Don't be fooled though. This isn't a system to fight spam. This is a system to force ISP:s to fight spam, and it's working.
The root of the problem is that there's only so much an ISP can do to combat the spam problem. Whacking individual zombies is never going to solve the core problem of shutting down spammers.
What I suggest instead, to combat zombies, is to block port 25 outwards for dynamic IP users and force them to send e-mail through a central SMTP server. This SMTP server would then be set only to permit a certain number of e-mails per day from a single user. Say, 100. This would be enough for any normal user, but would make individual zombies so much less valuable and raise the cost of spamming considerably.
Now, what about businesses that need to send out bulk e-mail? The ISP can provide them with the option of turning this limit off. No questions asked, except that they'll shut them down if they receive valid spam complaints. This would stop an ISP from having to play whack-a-mole with individual client machines, but would still allow bulk e-mail through for a small number of users who are easier to handle if something does go wrong.
The sentence may have been long. Doesn't mean it's coherent. How can a cost be profitable?
At the risk of putting words into your mouth I'm assuming you meant that even though the cost of pressing CD:s is and has always negligible, it's still lower than 15 years ago.
The fact that a negligible cost has lowered will have a negligible effect on the price of the final product. Which is entirely in line with what has happened.:-)
Of course, this is irrelevant. The music industry isn't in the business of manufacturing shiny discs. They're in the business of financing music production and profiting on music distribution. And because they, because of copyright restrictions, have their own little mini-monopoly on every CD they publish. (There can't be several competing music publishers selling the latest and greatest one hit wonder.) So they can charge whatever the market can bear -- and not what it costs.
First of all, there are two typical types of collateral damage:
The case where the entire IP range of a colocation ISP is blocked, because the ISP itself hasn't responded to complaints, and simply allowed the spamming mail server to change IP addresses. This is not the case in the case of Telewest, but I'll discuss it for completeness. In this case, the ISP is behaving irresponsibly by not taking complaints seriously and simply just allowing the spammer to change IP addresses. What makes you think they won't just issue new certificates to the spammer if they receive complaints?
In the case of Telewest, the collateral damage was directed at broadband users sending e-mail through Telewest's broadband service. I already handled that case in the grandparent to this post. If the user has a dynamic IP address they can just shove it and send their e-mail through the ISP's mail server like a nice conformer. If they have static IP addresses, there won't be any collateral damage, unless the ISP is irresponsible. (And again, what's to prevent an irresponsible ISP from issuing new certificates just as in the case with the colo ISP?)
In either way, the process you outlined seems to be only directed at business users, completely ignoring that the bulk of spam actually passes through zombies on home computers connected to broadband conenctions, and not through business connections -- and in the case of the Telewest blocking, the residential users would still not be able to send e-mail because they're not subject to the certificate process.
Right. This is only for businesses who want to set up their own mail servers. I get it. I didn't quite catch that part in your first post, I'm sorry.
But, you then go on to say that IP adresses aren't a valid way to block, because IP addresses change with DHCP and what-not. Let me ask you: What in the world would a business who uses a dynamic-IP Internet connection do with a mail server that delivers directly to destination mail servers?!
If they are that big that they want to handle their e-mail themselves, they'd probably use a connection with a static IP anyway. Problem solved. You can block by IP address, no need for that fancy-schmancy new-fangled certificate nonsense.
If they are smaller, and want to use a dynamic IP address, and still handle outgoing e-mail with their own mail server, they're probably going to want to relay all their mail through their ISP:s mail server anyway. This is what we do at work, we have a dynamic IP ADSL connection, and we run a mail server. The reason we do this is not because port 25 outwards is blocked, but because a lot of e-mail servers won't accept e-mail from dynamic IP address pools anyway. (Ever heard of the DUL?)
You might not like the DUL, (I don't really like the idea of it either), but if you want to send e-mail from a dynamic IP address, you really want to send it through your ISP's mail server anyway. So, as the ISP, you can just block port 25 outward for all dynamic pools in addition to many receiving mail servers doing the same. Problem solved again, without fancy certificates.
Now tell me. If users of dynamic IP addresses are forced to send e-mail through the ISP:s mail server, due to the DUL blocking a lot of their mail delivery anyway, and static IP addresses are trivial to block without using certificates -- what possible benifit would certificates give you now again?
Slashdot Mirror
To quote what you were quoting:
Of course it's not a natural right! An artificial concession was made granting protection, granted. But what did this concession grant them? Legal rights! Artificial rights if you mind you, rights that are revokable, so to speak.
Basically, we agree in principle, but my point is that, whether you like it or not, copyright owners do have legal rights under the system, and as such, until the law changes, calling DRM for Digital Rights Management is entirely fair, even though it is a case of euphemistic marketing-speak.
That doesn't stop anti-DRM people from calling it "Digital Restrictions Management" though. It's pretty clever, using their own acronym against them that way.
So I'm a troll by virtue of being right? Go on. Burn some more karma. I can afford it.
Where on earth did you get that strange definition of "right"?
The law can very well give a certain person or group a "right" to do something. I think you're confusing the issue with the issue of inalienable and human rights with the more basic definition of the word right (pay special attention to definition 7 under 'noun'.)
I'm not kicking it. (Well I am, but not just for the sake of kicking.) I'm pointing out a factual error in the parent post.
IE for the Mac is pretty awful too. It won't even render MSN correctly.
Yes, that is the latest version from Microsoft. Which is pretty old, since Microsoft doesn't support IE on Mac any more due to all the competition.
This needs to be stressed. The biggest threat to computer security is not insecurity in the underlying operating system. It's users not knowing what they're doing.
In this sense, having operating systems hide operation details from you is a Very Bad Thing.
Also, it's naïve to think that the pure virtue of Linux and Mac OS X running everything as an unpriviledged user as standard is going to stop virus writers. You don't need to take over a computer completely to screw with it. You can install nice little keyloggers or remove user data just fine without having to become root.
I always thought of it as a mechanism of protecting record companies' "rights".
This makes a lot more sense than a satellite receiver in an iPod. A *lot* more sense.
The Battlestar Galactica doesn't use computers. That's how it wasn't totally pwned by the Cylons.
Star Trek starship computers uses LCARS.
First post seems to have slipped through your fingers.
You can't use tin foil. That's implanted with secret government RFID equipment they implanted in the tin ore making tin foil actually AMPLIFY the signal.
You need to use aluminum foil. They haven't figured out how to taint Bauxite quite yet.
This one goes to 11.
Where? I found no reference to rawmedia in the linked article. If it was in another article I'm not aware of, please tell me. If I write something incorrect in one article, but I have 10 other articles where I'm correct, does that make a person wrong for pointing out a mistake in any of the articles somebody has written?
Who mentioned Linux? I certainly only mentioned it as one of the sources I pulled man pages for, for a standard library function available on pretty much all operating systems today. If you want to go platform-specific, fine. That's not what I was doing. The only place he mentions any specific operating system is in his later clarification in the top of his post.
I understood this after he wrote his clarification. The thing is, I didn't intend to criticise the person or his knowledge. I can't do that. I was discussing the content of the article, where he specifies that the fsync() call IS guaranteed to flush to disk (without specifying which operating system) and then blames hard drive manufacturers for fsync() not delivering the guarantees it's specifically documented not to guarantee.
I'm willing to admit, publically, that he knows his shit, and that if I somehow doubted it, it's because he wrote a misleading article. I won't apologise for criticising a poorly written article though. I'm not a mind reader, I can't assess knowledge that's in somebody's head, but not in writing.
He does have a point -- enabling write caching on high-end drives by default is brain dead. If that were the point he was making, I'd agree. Instead, he went on about drives not obeying fsync(). Without knowing what operating system's fsync() he was talking about, I had no choice but to refer to as much as the library standard says.
For full disclosure, I did reply to his reply to me (he probably sent the same reply to many people) acknowledging that I'm somewhat happy with the way his article reads now that he's added his clarification at the top.
Either way, I don't think there's anything left to discuss here. The author of the article has already updated his blog with the relevant information, and I have no beef with him, and I hope he has no beef with me.
For full disclosure: a copy of the followup he sent and my final reply is now up at my web space.
There. I had the balls to admit he knows his shit after all. Now, the ball's* in your court. Unless you have the balls to identify yourself when you reply, don't bother replying at all. I have nothing more to say to an Anonymous Coward.
pv2b
* Man. That was a bad pun. Please hit me in the head with a large anti-pun readjustion device or whatever.
Right. And the author is implementing a program that sends raw commands to ATA drives... in perl. Right. He does no such thing, at least not what I can see, by glancing at the source code of the perl script. Granted, I'm not fluent in perl, but it doesn't seem to do anything else than to do an fsync() equivalent. Please do correct me if I'm wrong.
The truth is that he doesn't know wtf he's talking about. I decide to cut him some slack though, because the FreeBSD 4 man pages at least are very misleading, and I don't know what man pages he did read.
By the way, I sent him an e-mail. It's available on my web space. I'm not posting it in full here, because it's a little long and it would be redundant, since a lot of the surrounding posts discuss pretty much the same thing as I said.
Can I quote you on that?
You can't tell me that doesn't look like goatse. I swear! It does!
Britannia.
:-)
Why, after all, it rules the waves in Saturn's belt. Britannia rule the waves. Get it?
Besides, what more fitting tribute to the decline of the British Empire than naming an insignificant 7 kilometer wide hunk of rock(or whatever it's made of) after it.
When it comes to blocking e-mail from spammers sending directly to recipients, you already have blackhole servers which solve that particular problem. You ignore complaints, you're added to blacklists of all servers filtering based on specific blackholes. What you're trying to suggest is that the entire follow the same blacklist. Not only is it arrogant to think that one group can somehow get all the world's mail administrators to agree to let them decide who to receive mail from, it's also undesirable and open for wide abuse. I think the current system of blackholing works great, since the filters are applied selectively by the recipients, and if you're not happy with the policy a certain RBL uses, you can always as a recipient choose another RBL. So in essence, this problem is already solved, and in a better way than you suggest. Some ISP:s housing these kind of spammers can even be (and have been) blocked wholesale. There is collateral damage of course, but if the ISP is uncooperative, the legitimate customers will just switch ISP:s.
When it comes to blocking e-mail sent through zombies, that's a completely different problem, that I have outlined in my previous posts. The reason I want a limit on outgoing e-mails sent through *broadband* connections, is to stop the spam from being sent in the first place. It doesn't matter if the ISP responds timely to complaints, by the time the complaints are received, the e-mails are already away and the damage has been done, and by the time the zombie responsible is shut down, the spammers have already found new zombies to replace it. Blackholing zombies is futile in the long term, and the best RBLs can hope to achieve by doing it, is to encourage broadband ISPs to take better preventative measures, like the one I'm suggesting.
In short, the Internet isn't one big happy familiy that can be controlled from above. At best, you can get groups of disgruntled sysadmins together cooperating on blacklists, which is what's happening already. This will stop a lot of spam sent through business lines, but in practice does nothing to the problem of spam through zombied broadband machines.
First of all, who do you propose should decide who gets EDP:ed and who not? You? A consortium of large ISPs? A group of random roaming anti-spam vigilantes? And who is to watch that the group doesn't overstep it's boundaries and not block an ISP for completely arbitrary reasons?
A system similar to the one you propose already exists. There exist blacklists that individual mail administrators can use on an individual and voluntary basis. They don't block all e-mail on the Internet, but they block enough e-mail for ISP:s to be concerned when they get blocked. These people who run these anti-spam lists are hot-headed enough already, I sure as hell wouldn't want them controlling *all* the e-mail on the Internet.
The problem with these systems is that they only harm the ISP and its customers, all because some of their customers don't know how to properly secure their Windows machines. They don't need to be hurt more than they already are to get the message. The spammers themselves aren't hurt. They just move on to zombies on another as-yet-unblocked ISP.
So, basically, you're proposing to build another bigger and better black hole to encompass all traffic -- in order to reduce collateral damage?! This doesn't make sense. If you want to reduce collateral damage, you make your blocking less aggressive, not more aggressive.
Apparently, the blackhole systems that already exist are doing their job by blocking enough e-mail to be a major inconvenience and cause the ISP to be more proactive in shutting down spam zombies. Don't be fooled though. This isn't a system to fight spam. This is a system to force ISP:s to fight spam, and it's working.
The root of the problem is that there's only so much an ISP can do to combat the spam problem. Whacking individual zombies is never going to solve the core problem of shutting down spammers.
What I suggest instead, to combat zombies, is to block port 25 outwards for dynamic IP users and force them to send e-mail through a central SMTP server. This SMTP server would then be set only to permit a certain number of e-mails per day from a single user. Say, 100. This would be enough for any normal user, but would make individual zombies so much less valuable and raise the cost of spamming considerably.
Now, what about businesses that need to send out bulk e-mail? The ISP can provide them with the option of turning this limit off. No questions asked, except that they'll shut them down if they receive valid spam complaints. This would stop an ISP from having to play whack-a-mole with individual client machines, but would still allow bulk e-mail through for a small number of users who are easier to handle if something does go wrong.
The sentence may have been long. Doesn't mean it's coherent. How can a cost be profitable?
:-)
At the risk of putting words into your mouth I'm assuming you meant that even though the cost of pressing CD:s is and has always negligible, it's still lower than 15 years ago.
I think you need to look up what the word negligible means.
The fact that a negligible cost has lowered will have a negligible effect on the price of the final product. Which is entirely in line with what has happened.
Of course, this is irrelevant. The music industry isn't in the business of manufacturing shiny discs. They're in the business of financing music production and profiting on music distribution. And because they, because of copyright restrictions, have their own little mini-monopoly on every CD they publish. (There can't be several competing music publishers selling the latest and greatest one hit wonder.) So they can charge whatever the market can bear -- and not what it costs.
First of all, there are two typical types of collateral damage:
- The case where the entire IP range of a colocation ISP is blocked, because the ISP itself hasn't responded to complaints, and simply allowed the spamming mail server to change IP addresses. This is not the case in the case of Telewest, but I'll discuss it for completeness. In this case, the ISP is behaving irresponsibly by not taking complaints seriously and simply just allowing the spammer to change IP addresses. What makes you think they won't just issue new certificates to the spammer if they receive complaints?
- In the case of Telewest, the collateral damage was directed at broadband users sending e-mail through Telewest's broadband service. I already handled that case in the grandparent to this post. If the user has a dynamic IP address they can just shove it and send their e-mail through the ISP's mail server like a nice conformer. If they have static IP addresses, there won't be any collateral damage, unless the ISP is irresponsible. (And again, what's to prevent an irresponsible ISP from issuing new certificates just as in the case with the colo ISP?)
In either way, the process you outlined seems to be only directed at business users, completely ignoring that the bulk of spam actually passes through zombies on home computers connected to broadband conenctions, and not through business connections -- and in the case of the Telewest blocking, the residential users would still not be able to send e-mail because they're not subject to the certificate process.Right. This is only for businesses who want to set up their own mail servers. I get it. I didn't quite catch that part in your first post, I'm sorry.
But, you then go on to say that IP adresses aren't a valid way to block, because IP addresses change with DHCP and what-not. Let me ask you: What in the world would a business who uses a dynamic-IP Internet connection do with a mail server that delivers directly to destination mail servers?!
If they are that big that they want to handle their e-mail themselves, they'd probably use a connection with a static IP anyway. Problem solved. You can block by IP address, no need for that fancy-schmancy new-fangled certificate nonsense.
If they are smaller, and want to use a dynamic IP address, and still handle outgoing e-mail with their own mail server, they're probably going to want to relay all their mail through their ISP:s mail server anyway. This is what we do at work, we have a dynamic IP ADSL connection, and we run a mail server. The reason we do this is not because port 25 outwards is blocked, but because a lot of e-mail servers won't accept e-mail from dynamic IP address pools anyway. (Ever heard of the DUL?)
You might not like the DUL, (I don't really like the idea of it either), but if you want to send e-mail from a dynamic IP address, you really want to send it through your ISP's mail server anyway. So, as the ISP, you can just block port 25 outward for all dynamic pools in addition to many receiving mail servers doing the same. Problem solved again, without fancy certificates.
Now tell me. If users of dynamic IP addresses are forced to send e-mail through the ISP:s mail server, due to the DUL blocking a lot of their mail delivery anyway, and static IP addresses are trivial to block without using certificates -- what possible benifit would certificates give you now again?