They are the seeds of the internet. You plant some and sprinkle them with bits. Eventually they grow into a huge series of tubes. How do you think the internet was created? With lots and lots of netbeans.
Those clients represent an ever decreasing share of the browser market. By the time SSL virtual hosts are deployed on a wide scale, those browsers may be a tiny fraction of the ones in use. A service provider may also decide that the ability to support SSL virtual hosts outweighs the loss of those clients and instead encourage them to upgrade to a different browser such as Firefox.
So even if you were silly enough to run experimental code in your server, a large percentage of your clients can't use the extension anyway.
You're making the faulty assumption that a large portion of my visitors would be using those browsers.
The GP is correct:
No, the GP is demonstrably wrong. Just because you think something can't be done, you should not get in the way of those who are currently doing it.
regular SSL requires a dedicated IP address for each certificate. The fact that an experimental extension to SSL gets around this requirement does not alter that fact.
You state that SSL requires a dedicated IP then you admit that it doesn't. Make up your mind. Since software exists that allows SSL virtual hosts to be used, multiple IP addresses are not a requirement. You may still have a business or technical requirement for multiple IPs because you are not using the approrpriate software, but that's another matter entirely.
This article assumes that the state of AI will be advanced. That won't happen unless the spammers share their research or code. I doubt that's going to happen.
Security? Although software doesn't wear out, one must keep updated against the newest vulnerabilities.
XP will receive security support until 2014. Just to put that into perspective, XP will still be receiving security patches after the next, not-yet-released Ubuntu LTS is already retired.
I don't see how that's possible if he doesn't have the private key which is held by the client only.
The private key is held by the compromised host. Try this: Run ssh-keygen, create a key, don't use a password. Copy the ~/.ssh/id_rsa.pub file to another computer and add the contents to ~/.ssh/authorized_keys. Now you can ssh from the first computer to the second computer and you will not be prompted for a password.
If the account on the first computer is compromised, the attacker could gain access to the second computer because of this lack of password. The OpenSSH people realized this a while back and started to hash the contents of the ~/.ssh/known_hosts file. This file used to contain the plaintext names of the hosts on each line. See this article for some history of the problem. Even though the contents of known_hosts are now hashed, it may be possible to discover other hosts via shell history or other means.
you might consider using ssh keys instead of passwords
If you don't have a password as well then if your account is compromised the attacker will be able to access your accounts on other servers without entering a password. I know generating a ssh key without a password is convenient but it also creates risk.
Furthermore password+ssh keys is rather pointless.
Until your account is compromised and the attacker can now ssh into your other accounts without having to enter a password. I'd rather have to enter the password when the key is used. Better safe than sorry.
Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit/etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.
Why do companies go to these great lengths to censor these people? Its a lot more effective to let the bloggers blog in relative obscurity then to make a big deal of it and then increase the pagerank of their blog.
Did you mean "then" or "than"? Your post is interpreted differently with either word. You said "then" which makes this read as they left him to blog in obscurity and now they have decided to make a big deal about it which means they are doing the most effective thing, according to you.
E-stamps are the only effective way to reduce spam. Bulk spammers will go from paying something like 0.1 cents per message to say 25-cents, making it uneconomical, and more trace-able. When you buy an e-stamp, 1/3 of the amount goes to the recipient (usually as credit), 1/3 to the ISP, and 1/3 to a monitoring agency. "Approved" recipients could send for free.
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses ( ) Mailing lists and other legitimate email uses would be affected (X) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks ( ) It will stop spam for two weeks and then we'll be stuck with it (X) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it (X) Requires too much cooperation from spammers (X) Requires immediate total cooperation from everybody at once ( ) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it (X) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats (X) Jurisdictional problems (X) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email (X) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers (X) Dishonesty on the part of spammers themselves ( ) Bandwidth costs that are unaffected by client filtering ( ) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck ( ) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks ( ) Countermeasures must work if phased in gradually (X) Sending email should be free ( ) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. (X) Nice try, assh0le! I'm going to find out where you live and burn your house down!
I wish I could remember the 'rule' you've just broken about making an argument into a personal attack.
I did not intend an attack, personal or otherwise. Making the decisions that you mentioned in your post are decisions that programmers have made many times in the past when they want to create a GUI for configuring a program. Compared to writing the software, these decisions are trivial. You claim they are indefensible, yet the preponderance of GUI-based tools and GUIs for configuring programs with text-only configuration files belies your claim. You even brought up in your response that GUI tools such as Gimp and OpenOffice have the ability to be configured via a GUI. I reached the conclusion that your objection to writing such tools, and making the trivial decisions that you outlined, came from laziness. Could you please clarify why you feel these decisions are indefensible, particularly in light of the fact that there are so many programs can can be configured via a GUI?
The only GUI based configuration tool for Samba that I'm aware of that covers anything but a tiny subset of Sambas functionality is SWAT, and it does not address every possibly configuration item (or combination)
Good point. Then again, the functionality covered by a GUI may be sufficient for the majority of users.
Nothing is preventing you from filling this gap in the Linux domain. Or perhaps you'd rather pay for someone else to do it. Either way, this point is moot, Linux is built by (largely) unpaid contributors. They work on the bits they're interested in. Few developers have the broad base of skills to produce quality GUI based applications (which a config tool would be), as well as high performance server apps like Apache (httpd), or Samba (smbd/nmbd).
You're right, nothing is stopping you, me, or anyone else from fixing these issues. Then again, other operating systems have already solved many of these issues. When Linux advocates encourage people to switch to Linux, a potential user can weigh their options:
Option A: Learn to program and write the code to fix these problems.
Option B: Use another system that already meets the user's needs.
An overwhelming majority of people will choose option B and use the system that already meets their needs. Therefore, Linux advocates should not complain when people refuse to migrate to their operating system of choice.
Besides, aren't we conveniently skipping a huge range of apps such as OpenOffice, or VLC, or Gimp (end user apps) which do indeed contain GUI based configuration utilities ?
It seems that the stuff you're really complaining about are the server based apps, which by their very nature have no GUI since they run as daemons.
Because they have no native GUI doesn't mean that they can't be configured via a GUI. As I pointed out, there are several GUI configuration tools for Samba. There are also GUI configuration tools for X.org, allowing one to change screen resolution and other settings without having to edit xorg.conf with a text editor. There are even several GUI tools for configuring the Linux kernel options prior to compilation.
I want Linux to succeed outside of the technical community. For that to happen it will need to match the ease of use of its competitors. That means adding a GUI for many common operations. Unlike the person that you first responded to, I don't share the view that everything needs to be configurable with a GUI. Even Windows hides away advanced functionality in things like the registry. I imagine that Mac OS X is the same. But linux needs to get up to speed and m
It seems to me that if websites stopped using more and more intrusive ad techniques that people would be less likely to want to use ad-blockers.
I couldn't agree more. Advertisers were able to get together and develop standards for ad sizes for web pages. There's no reason they couldn't develop the same standards for acceptable content (no playing video or audio unless clicked; no flashing, blinking; etc). Until they do that, I'm happy to treat them like little children; One misbehaving advertiser means they all get blocked until they all can behave.
That's a subjective statement. At least when playing videos in MPC while it is maximized, it will stay maximized. When I maximize the VLC window and then double-click on another video to play, the window will return to an unmaximized state and position itself at the top left corner of my screen. If I click on the maximize button again, the window doesn't maximize but instead repositions to some other location on the screen. I then have to click maximize again to have the window maximize. If I double-click on a different video file, I have to go through these actions again.
Media Player Classic is superior to VLC because of this issue, even if it does have security issues.
Slashdot Mirror
They are the seeds of the internet. You plant some and sprinkle them with bits. Eventually they grow into a huge series of tubes. How do you think the internet was created? With lots and lots of netbeans.
Those clients represent an ever decreasing share of the browser market. By the time SSL virtual hosts are deployed on a wide scale, those browsers may be a tiny fraction of the ones in use. A service provider may also decide that the ability to support SSL virtual hosts outweighs the loss of those clients and instead encourage them to upgrade to a different browser such as Firefox.
So even if you were silly enough to run experimental code in your server, a large percentage of your clients can't use the extension anyway.
You're making the faulty assumption that a large portion of my visitors would be using those browsers.
No, the GP is demonstrably wrong. Just because you think something can't be done, you should not get in the way of those who are currently doing it.
You state that SSL requires a dedicated IP then you admit that it doesn't. Make up your mind. Since software exists that allows SSL virtual hosts to be used, multiple IP addresses are not a requirement. You may still have a business or technical requirement for multiple IPs because you are not using the approrpriate software, but that's another matter entirely.
This article assumes that the state of AI will be advanced. That won't happen unless the spammers share their research or code. I doubt that's going to happen.
Your first link gives a 404.
Then what's the point of packaging software for distros if you can't rely on it working?
No they don't.
Yes you can. Read.
What do you mean by significant? All of the major browsers currently support SNI.
It'd be nice to see SSL used on all web sites. Apache can now handle SSL virtual hosts so that obstacle is gone.
XP will receive security support until 2014. Just to put that into perspective, XP will still be receiving security patches after the next, not-yet-released Ubuntu LTS is already retired.
Something has to be different so they can patent it.
You can use ssh-agent if you get tired of typing your password over and over.
The private key is held by the compromised host. Try this: Run ssh-keygen, create a key, don't use a password. Copy the ~/.ssh/id_rsa.pub file to another computer and add the contents to ~/.ssh/authorized_keys. Now you can ssh from the first computer to the second computer and you will not be prompted for a password.
If the account on the first computer is compromised, the attacker could gain access to the second computer because of this lack of password. The OpenSSH people realized this a while back and started to hash the contents of the ~/.ssh/known_hosts file. This file used to contain the plaintext names of the hosts on each line. See this article for some history of the problem. Even though the contents of known_hosts are now hashed, it may be possible to discover other hosts via shell history or other means.
Yes, that is what I am talking about. Make sure you have a password on the ssh key.
If you don't have a password as well then if your account is compromised the attacker will be able to access your accounts on other servers without entering a password. I know generating a ssh key without a password is convenient but it also creates risk.
Until your account is compromised and the attacker can now ssh into your other accounts without having to enter a password. I'd rather have to enter the password when the key is used. Better safe than sorry.
Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.
Did you mean "then" or "than"? Your post is interpreted differently with either word. You said "then" which makes this read as they left him to blog in obscurity and now they have decided to make a big deal about it which means they are doing the most effective thing, according to you.
Your post advocates a
( ) technical ( ) legislative (X) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
(X) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(X) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
(X) Jurisdictional problems
(X) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(X) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(X) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
(X) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
(X) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
No it doesn't. Using the plus sign in an email address is already specified in the RFC and has been for quite some time.
I think the objection that the poster has to the name GIMP is that it's a program that has an offensive slur as its name.
I did not intend an attack, personal or otherwise. Making the decisions that you mentioned in your post are decisions that programmers have made many times in the past when they want to create a GUI for configuring a program. Compared to writing the software, these decisions are trivial. You claim they are indefensible, yet the preponderance of GUI-based tools and GUIs for configuring programs with text-only configuration files belies your claim. You even brought up in your response that GUI tools such as Gimp and OpenOffice have the ability to be configured via a GUI. I reached the conclusion that your objection to writing such tools, and making the trivial decisions that you outlined, came from laziness. Could you please clarify why you feel these decisions are indefensible, particularly in light of the fact that there are so many programs can can be configured via a GUI?
Good point. Then again, the functionality covered by a GUI may be sufficient for the majority of users.
You're right, nothing is stopping you, me, or anyone else from fixing these issues. Then again, other operating systems have already solved many of these issues. When Linux advocates encourage people to switch to Linux, a potential user can weigh their options:
An overwhelming majority of people will choose option B and use the system that already meets their needs. Therefore, Linux advocates should not complain when people refuse to migrate to their operating system of choice.
Are we? You were just listing the reasons why there shouldn't be GUIs to configure programs and that my position, which I had not yet stated, is indefensible.
Because they have no native GUI doesn't mean that they can't be configured via a GUI. As I pointed out, there are several GUI configuration tools for Samba. There are also GUI configuration tools for X.org, allowing one to change screen resolution and other settings without having to edit xorg.conf with a text editor. There are even several GUI tools for configuring the Linux kernel options prior to compilation.
I want Linux to succeed outside of the technical community. For that to happen it will need to match the ease of use of its competitors. That means adding a GUI for many common operations. Unlike the person that you first responded to, I don't share the view that everything needs to be configurable with a GUI. Even Windows hides away advanced functionality in things like the registry. I imagine that Mac OS X is the same. But linux needs to get up to speed and m
People aren't saying or implying that XP is better. They are just saying that it's good enough.
So much for all that change Obama kept talking about.
I couldn't agree more. Advertisers were able to get together and develop standards for ad sizes for web pages. There's no reason they couldn't develop the same standards for acceptable content (no playing video or audio unless clicked; no flashing, blinking; etc). Until they do that, I'm happy to treat them like little children; One misbehaving advertiser means they all get blocked until they all can behave.
That's a subjective statement. At least when playing videos in MPC while it is maximized, it will stay maximized. When I maximize the VLC window and then double-click on another video to play, the window will return to an unmaximized state and position itself at the top left corner of my screen. If I click on the maximize button again, the window doesn't maximize but instead repositions to some other location on the screen. I then have to click maximize again to have the window maximize. If I double-click on a different video file, I have to go through these actions again.
Media Player Classic is superior to VLC because of this issue, even if it does have security issues.