And this is why there's an essay on how OpenBSD is insecure. Because security breaches do happen. You need to lock your systems down against internal attackers as well. Defense in depth and all that. Not just hermetically sealing your system by abstaining from running any services at all.
This concern is one of the fundamental issues to consider in discussing philosophy of "violence". Another is what degree of force is appropriate.
Thinking on these things and recognizing that people make mistakes in both action and perception, and that people often have a tendency to perceive malice from others, it seems that there's a positive bias for violence. That is, "violence begets violence".
Similarly to how servers on the net should be conservative in what they do, liberal in what they accept, and how this maximizes smooth interoperation, humans should minimize the appearance or effect of harm to others and maximize tolerance of injury from others to negate the aforementioned spiraling violence bias. Though this philosophy is hard to swallow for people with chips on their shoulders. (Probably already victims of injury.)
In particular, this situation indicates why tivoized systems are a bad thing and why the GPLv3 was necessary. Not that this system had GPL'd software in it necessarily, but if it had, it would have needed the updated, v3 license to allow customers to run their own mods to make the hardware work for them.
Oh, wait. Are the Sony HDD 250 and 500 DVR systems digital signature-locked to prevent modified software from operating?
I may have been participating in a DDoS. UDP DNS requests were being made of my authoritative nameserver for domains in its bailywick, but I suspect the source IPs were spoofed victims and that the ANY record requests were designed to amplify the total data. These packets may be going out from a botnet and bouncing off legit DNS servers around the world, doubling or maybe octupling the data size, laundering the actual source IPs...
Any recommendations on how to handle this sort of thing?
You buy/use the product for the sake of the product.
"Buying" an OS is not like buying a lawn chair. No matter how secure you think your OS is. You have to update systems. OpenBSD had remote holes in the default install in 1997, 2002, and 2007. We're about due for another, huh?
But more to the point, the mentality of the leader sets the mentality of the group and it affects membership. Operating systems don't spring up out of nothing. They're made by groups of people, and those people determine how the OSs turn out. You can't divorce the two.
Look at the late February part of the exchange during the disclosure process for OpenBSD's last remote hole. They say their focus is security, but, I suspect, their attitudes kept them from taking the right steps until their noses were pushed into the problem. This reflexive rejection of fault is an understandable attitude when you live in a contemptuous, dog-eat-dog social environment. You can't have humility when you get attacked. But you need humility when you're doing security.
And that's just the more direct impact on security effects. What about viability of the project at large? To join the project, you need expertise and thick skin already formed. Similarly for the community. Not exactly newbie friendly. The focus should not be on having skill, scorning ignorance, because skill doesn't come fully-formed from the head of Zeus. The focus should be on gaining skill. Because only by gaining will you have it.
As you learn the ins and outs of an OS you want to administer, you're investing time and effort that you're hoping will pay off in the future by being able to apply your skill with later, improved versions of the OS. You don't say "I'm learning OpenBSD 5.1", thinking you won't use anything else. You're banking on the developers and community to continue making that OS. I have several times looked at competing incipient open source projects and decided which app I wanted to use based on the strength of the community associated with it. They were going to teleport me a new lawn chair every year.
Not being able to see how corrosive Theo's attitude is to the people and the "product", not being able to understand how disdain weakens a community, increases inefficiency, and increases errors, means you're an ignorant worthless shit.
(That last bit there is kind of a ballsy rhetorical device, innit? I don't actually hate you, even if you don't understand. *hug*)
The point of DNT is not itself to stop tracking, but to give the user a voice about their preference. The difference is a bit subtle, but you can understand it in less than 30 seconds if you try.
Before DNT, you did not have a way to say whether you preferred that companies not track you or you preferred that they track you and give you delightfully relevant targeted advertising. Now you have a way to express this to the sites you visit. DNT is your choice voice.
Giving your preferences a voice is valuable.
It doesn't mean that the sites who get the message are going to obey it. It's an expression of your preference, not a magical spell to cause them to act a certain way. However, when this protocol for expressing choice becomes adequately standardized, when we know that DNT expresses the actual user's desires (rather than is automatically set), we can then enact laws to coerce businesses into complying with users' desires.
Is there a code v. comment synchronization system yet? I'm imagining something where a comment is associated with nearby code (delineated by whitespace or scope) and includes a checksum of that code.
foreach my $atom (@atoms) {
my $radius;
# calculate thermal radii as inverse of temperature, scaled to allowed range (CC 58e2 c902)
$radius = $atom->{'temp'} / ($max_temp * ($radius_max - $radius_min) + $radius_min);
print "$atom->{'x'},$atom->{'y'},$atom->{'z'} $radius\n"; }
And your editor can highlight it for you if it falls out of sync.
"that's when Spamhaus and the RBL became evil"... "is to not use spamhaus or the RBL".
What is the RBL? It generally sounds like you're a native speaker of English, so I'm wondering why you're using the definite article ("the") for this. Because there is no single RBL, neither as a (non-Spamhaus) blacklist with the name "RBL", nor as a product of Spamhaus's called "RBL", nor as a distinguished technology/method called "the RBL". There are RBL's.
Not All A's Are A Certain Kind Of A...
No, but if 30% of all A's are dangerous A's, then knowing if something is an A gives you a better understanding of what that given A may be. Knowing a mail server is an open relay, for example, meant there was a 30% chance it was used for spam, perhaps back in 1994. Today's open relays are probably 99.9% spam-involved.
So, no, it doesn't follow necessarily, not 100%, but it does give you an idea. So, being told "Fix your open relay!" even if your relay hasn't sent spam isn't so bad. It's like saying "Lock away that gun!" even if a guest hasn't picked it up off the coffee table and discharged it.
(Note this is not an argument about open relays, but more generally about systems that can be abused, or more generally still about things that probablistically have certain qualities you care to know about and make decisions on.)
BL's As Sole Arbiters...
It's perhaps not rare for people to use blacklists as the sole determinant for actions like refusing SMTP connections, but it is certainly widely understood that it's a bad idea. Popular understanding is that the best practice is to use BL's to contribute to scoring systems that take action based on aggregate score.
You appear to assume the way to use a BL is as a sole arbiter, as you are criticizing BL's for how single-determinant decision making is harmful. Single-determinant decision making is not an inherent quality of BL's. What's more, you denigrate automation in a similar way, by association, rather than directly criticize automation with points regarding automation itself.
"Don't Use Spamhaus"
You talk about Spamhaus as if it were a single service or a homogeneous product. I think maybe you don't understand, neither Spamhaus's offerings or this blacklist stuff generally.
Spamhaus has three IP-oriented DNSBL's useful for mail system administrators in the fight against spam (ignoring the "Zen" aggregate DNSBL, and various component lists): The XBL, SBL, and PBL. These are for exploited machines, (human) forensics-agents-determined spam sources, and service-policy-denied relays respectively. As a mail administrator, you can individually choose which to use and how much to weigh their votes. You don't have to eat the entire buffet.
Advice
My recommendation to people who want to tell system and network admins about how to handle spam and blacklists is that they try doing some actual spam blocking before advising.
The whole premise behind DNT is stupid. Trust marketers to respect a flag in your browser? Seriously?.
That would be stupid, yes. But I think the point of DNT isn't that. It's to allow the user to express their desire.
The current default is that it's acceptable to track users. To begin to eliminate tracking you have to give users a voice, the ability to declare that they don't want to be tracked. That's what DNT is. The next step is enforcement.
I was thinking more like offensive anti-religious or pornographic content. I'm sure there's plenty that would run afoul of the ToS that would be good to have.
The real barrier, as I've said all along, is that nobody would join in the first place, unless the project was launched by a company so popular that they could get new users to sign up just by announcing it. So there's not much that I, or anybody else outside of those behemoth companies, can do except to sit back and wait for someone like Google to try it.
Getting critical mass would be difficult, but large company promotion isn't the only way it could happen. Using the "killer app" concept, you might encourage usership by providing a feature that Facebook or Google+ don't provide, or better yet, can't provide. Figuring out what that is I'll have to leave as an exercise for the reader because I haven't figured it out. You would probably want to spend time contemplating the unseemly side of possibilities.
Online behavior is closer to New York frankness than what we usually get face-to-face, and that's good, like you suggest. But then there's a large contingent who go overboard or are just venting their spleens rather than being sincere about their criticism. Weeding out that chaff is the trick.
Slashdot Mirror
Ah, but I should point out that a leading g is often enough a soft g in English that it's not inconceivable that yet another word would have it so.
Anyone willing to do a frequency check of how leading g's are pronounced in common English words?
Roger that.
I invented a new format, "BIF". It's pronounced "ROO barb soo FLEY".
Indeed.
And this is why there's an essay on how OpenBSD is insecure. Because security breaches do happen. You need to lock your systems down against internal attackers as well. Defense in depth and all that. Not just hermetically sealing your system by abstaining from running any services at all.
It does not mean "very simple".
This concern is one of the fundamental issues to consider in discussing philosophy of "violence". Another is what degree of force is appropriate.
Thinking on these things and recognizing that people make mistakes in both action and perception, and that people often have a tendency to perceive malice from others, it seems that there's a positive bias for violence. That is, "violence begets violence".
Similarly to how servers on the net should be conservative in what they do, liberal in what they accept, and how this maximizes smooth interoperation, humans should minimize the appearance or effect of harm to others and maximize tolerance of injury from others to negate the aforementioned spiraling violence bias. Though this philosophy is hard to swallow for people with chips on their shoulders. (Probably already victims of injury.)
If going into another's system is intruding on someone's privacy (regardless if it's a "guilty" party) it is not investigation without impact.
jibe
verb (used without object), jibed, jib ing
to be in harmony or accord; agree: The report does not quite jibe with the commissioner's observations.
jive
verb (used with object)
Slang. to tease; fool; kid: Stop jiving me!
In particular, this situation indicates why tivoized systems are a bad thing and why the GPLv3 was necessary. Not that this system had GPL'd software in it necessarily, but if it had, it would have needed the updated, v3 license to allow customers to run their own mods to make the hardware work for them.
Oh, wait. Are the Sony HDD 250 and 500 DVR systems digital signature-locked to prevent modified software from operating?
Actually, I think that's not meant to be possessive. Looks like an (attributive) adjective. But I can certainly see taking it as a possessive.
I may have been participating in a DDoS. UDP DNS requests were being made of my authoritative nameserver for domains in its bailywick, but I suspect the source IPs were spoofed victims and that the ANY record requests were designed to amplify the total data. These packets may be going out from a botnet and bouncing off legit DNS servers around the world, doubling or maybe octupling the data size, laundering the actual source IPs...
Any recommendations on how to handle this sort of thing?
"Buying" an OS is not like buying a lawn chair. No matter how secure you think your OS is. You have to update systems. OpenBSD had remote holes in the default install in 1997, 2002, and 2007. We're about due for another, huh?
But more to the point, the mentality of the leader sets the mentality of the group and it affects membership. Operating systems don't spring up out of nothing. They're made by groups of people, and those people determine how the OSs turn out. You can't divorce the two.
Look at the late February part of the exchange during the disclosure process for OpenBSD's last remote hole. They say their focus is security, but, I suspect, their attitudes kept them from taking the right steps until their noses were pushed into the problem. This reflexive rejection of fault is an understandable attitude when you live in a contemptuous, dog-eat-dog social environment. You can't have humility when you get attacked. But you need humility when you're doing security.
And that's just the more direct impact on security effects. What about viability of the project at large? To join the project, you need expertise and thick skin already formed. Similarly for the community. Not exactly newbie friendly. The focus should not be on having skill, scorning ignorance, because skill doesn't come fully-formed from the head of Zeus. The focus should be on gaining skill. Because only by gaining will you have it.
As you learn the ins and outs of an OS you want to administer, you're investing time and effort that you're hoping will pay off in the future by being able to apply your skill with later, improved versions of the OS. You don't say "I'm learning OpenBSD 5.1", thinking you won't use anything else. You're banking on the developers and community to continue making that OS. I have several times looked at competing incipient open source projects and decided which app I wanted to use based on the strength of the community associated with it. They were going to teleport me a new lawn chair every year.
Not being able to see how corrosive Theo's attitude is to the people and the "product", not being able to understand how disdain weakens a community, increases inefficiency, and increases errors, means you're an ignorant worthless shit.
(That last bit there is kind of a ballsy rhetorical device, innit? I don't actually hate you, even if you don't understand. *hug*)
The point of DNT is not itself to stop tracking, but to give the user a voice about their preference. The difference is a bit subtle, but you can understand it in less than 30 seconds if you try.
Before DNT, you did not have a way to say whether you preferred that companies not track you or you preferred that they track you and give you delightfully relevant targeted advertising. Now you have a way to express this to the sites you visit. DNT is your choice voice.
Giving your preferences a voice is valuable.
It doesn't mean that the sites who get the message are going to obey it. It's an expression of your preference, not a magical spell to cause them to act a certain way. However, when this protocol for expressing choice becomes adequately standardized, when we know that DNT expresses the actual user's desires (rather than is automatically set), we can then enact laws to coerce businesses into complying with users' desires.
Is there a code v. comment synchronization system yet? I'm imagining something where a comment is associated with nearby code (delineated by whitespace or scope) and includes a checksum of that code.
foreach my $atom (@atoms)
{
my $radius;
# calculate thermal radii as inverse of temperature, scaled to allowed range (CC 58e2 c902)
$radius = $atom->{'temp'} / ($max_temp * ($radius_max - $radius_min) + $radius_min);
print "$atom->{'x'},$atom->{'y'},$atom->{'z'} $radius\n";
}
And your editor can highlight it for you if it falls out of sync.
Oh, that's very interesting.
Here I thought running full VMs was a fun and clever way to support legacy apps. A mostly transparent wrapper takes that to a new level.
As if there could be only one greedy company?
Which sites are hosed by HTTPS Everywhere? I haven't run into any myself.
Might I recommend, as much as is possible, pack your trash.
I second that. Anyone who's got experience with npf, please speak up.
"The" RBL...
"that's when Spamhaus and the RBL became evil" ... "is to not use spamhaus or the RBL".
What is the RBL? It generally sounds like you're a native speaker of English, so I'm wondering why you're using the definite article ("the") for this. Because there is no single RBL, neither as a (non-Spamhaus) blacklist with the name "RBL", nor as a product of Spamhaus's called "RBL", nor as a distinguished technology/method called "the RBL". There are RBL's.
Not All A's Are A Certain Kind Of A ...
No, but if 30% of all A's are dangerous A's, then knowing if something is an A gives you a better understanding of what that given A may be. Knowing a mail server is an open relay, for example, meant there was a 30% chance it was used for spam, perhaps back in 1994. Today's open relays are probably 99.9% spam-involved.
So, no, it doesn't follow necessarily, not 100%, but it does give you an idea. So, being told "Fix your open relay!" even if your relay hasn't sent spam isn't so bad. It's like saying "Lock away that gun!" even if a guest hasn't picked it up off the coffee table and discharged it.
(Note this is not an argument about open relays, but more generally about systems that can be abused, or more generally still about things that probablistically have certain qualities you care to know about and make decisions on.)
BL's As Sole Arbiters...
It's perhaps not rare for people to use blacklists as the sole determinant for actions like refusing SMTP connections, but it is certainly widely understood that it's a bad idea. Popular understanding is that the best practice is to use BL's to contribute to scoring systems that take action based on aggregate score.
You appear to assume the way to use a BL is as a sole arbiter, as you are criticizing BL's for how single-determinant decision making is harmful. Single-determinant decision making is not an inherent quality of BL's. What's more, you denigrate automation in a similar way, by association, rather than directly criticize automation with points regarding automation itself.
"Don't Use Spamhaus"
You talk about Spamhaus as if it were a single service or a homogeneous product. I think maybe you don't understand, neither Spamhaus's offerings or this blacklist stuff generally.
Spamhaus has three IP-oriented DNSBL's useful for mail system administrators in the fight against spam (ignoring the "Zen" aggregate DNSBL, and various component lists): The XBL, SBL, and PBL. These are for exploited machines, (human) forensics-agents-determined spam sources, and service-policy-denied relays respectively. As a mail administrator, you can individually choose which to use and how much to weigh their votes. You don't have to eat the entire buffet.
Advice
My recommendation to people who want to tell system and network admins about how to handle spam and blacklists is that they try doing some actual spam blocking before advising.
That would be stupid, yes. But I think the point of DNT isn't that. It's to allow the user to express their desire.
The current default is that it's acceptable to track users. To begin to eliminate tracking you have to give users a voice, the ability to declare that they don't want to be tracked. That's what DNT is. The next step is enforcement.
Advanced neural net-based processing has already been put to powerful use with the Proteus IV home control system.
I was thinking more like offensive anti-religious or pornographic content. I'm sure there's plenty that would run afoul of the ToS that would be good to have.
Getting critical mass would be difficult, but large company promotion isn't the only way it could happen. Using the "killer app" concept, you might encourage usership by providing a feature that Facebook or Google+ don't provide, or better yet, can't provide. Figuring out what that is I'll have to leave as an exercise for the reader because I haven't figured it out. You would probably want to spend time contemplating the unseemly side of possibilities.
Getting straight talk is great, but you need to have an expected context or folks might be overly sensitive and reject the message.
http://www.bbc.co.uk/news/magazine-19335267
Online behavior is closer to New York frankness than what we usually get face-to-face, and that's good, like you suggest. But then there's a large contingent who go overboard or are just venting their spleens rather than being sincere about their criticism. Weeding out that chaff is the trick.