So in order to totall screw someone all you have to do is get on their box, phisically or by cracking and download some kiddy porn. Then drop a dime on them (just in case you did not click on the honey pot) and voila! Instant conviction.
Easier than that.
Just copy the URL from the honeypot link into a hyperlink apparently to something innocent-looking and entice them to click on that. The FBI uses their click to get the warrant, seize everything, and disrupts their lives for months. Then they're embarrassed at getting the wrong guy. So if they find ANYTHING ELSE they'll prosecute anyhow.
Having the link go to a page with IMG links to offsite kiddie porn that redirects to the honeypot would also end up with the images in their web cache. But I'm not familiar enough with HTTP to know if the fact that they were redirected would be visible at the honeypot site.
It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.
You've got to be kidding. Maybe it's not natural for most software "engineers", but I bet it's pretty natural for engineers in general.
Indeed.
I was tempted to take issue with Bruce on that point. After I cut my programming teeth in classified research I built a career in automobile automation engineering. I was ALWAYS looking at all the things that could go wrong, through bugs, mischance, or malice, and insuring that they were properly handled.
And this was expected. And it was honored, and the extra time required was paid for gladly. (I happened to be better at it than most, but everybody at least tried.)
But then I got out to Silicon Valley. And here I discovered that there was another, and much lower, standard of reliability when it came to software. The contrast was almost painful. (One of my colleagues once remarked that I was the only guy he would trust to program his pacemaker. B-) )
And I finally realized what it was:
In Detroit, virtually ANY hunk of software can be life-critical. A bug in the idle speed control might result in a year's production of cars that tend to stall a car's length into the intersection when accellerating from a stop sign. A bug in the factory energy management system might shut off the lights in the plant while the machines are still moving and the workers are within inches of them. A bug in the alarm on the annealing oven's flame curtain could let the plant fill with hot gas loaded with carbon monoxide, then blow the roof into the next county. A bug in the airbag tester program could fire the bag with the worker inside the test cell trying to hook it up. (To name four that I actually worked on.)
In Silicon Valley, on the other hand, there is massive pressure to get the product out marginally ahead of the competitors. And there are business models that turn product bugs into revenue streams via maintenance services and updates. (I finally switched to "the hard side of the force" - chip design - where a million dollars of nonrecurring expenses per bug-fix chip spin and months of lead time promotes the same sort of attention to perfection that I was used to.)
Bruce lives and works out here in the land of fruits, nuts, flakes - and software engineers that treat bugs as features and ship dates as the holy grail. So perhaps most of his experience is with "software engineers" of that sort, leading him to make an overgeneralization.
(Then again, while I apply that sort of thinking to my software and now hardware work, Bruce lives it 24/7. So perhaps he has a point. B-) )
If I read correctly, a GRB of this magnitude occurring 2700 light years away would be as bright as the sun. Ouch.
Ouch indeed. (I'm sure somebody will check your math and adjust the distance if necessary. So let's go with the premise of a solar input's worth from nearby.)
At that sort of distance the red shift would be virtually nonexistent. A kilowatt per square meter of gamma rays would make you toasty warm all the way through, not just on the skin.
Also: Goodbye DNA and RNA. Presuming you're still alive (for some value of alive) after the flash you'd be running on the proteins you've already got for your last few days. Then the deep ocean and rift vent critters get their chance. (Presuming, of course, that an associated neutrino flux didn't get them and the planet has to start from scratch.)
Shouldn't any distribution based on a kernel build that doesn't require anything more or significantly different from the underlying hardware, relative to SUSE E.S. work just as well?
Put another way:
If you have a problem with another distribution under Hyper-V, and Microsoft is refractory about support, shouldn't you be able to replicate the problem under SUSE and make them fix THAT?
Are they only supporting SUSE E.S. as an ongoing policy? Or is it just the only one they've certified as of the first release?
Shouldn't any distribution based on a kernel build that doesn't require anything more or significantly different from the underlying hardware, relative to SUSE E.S. work just as well?
Yes, I know there are times that we've all had to drive with less sleep than we should have... but is this a good answer? To me it would seem to inspire false confidence on the part of the driver, where they might think that they could stay up and not have to worry about falling asleep driving since they had their blue lights blinking or whatever.
IMHO designing car lighting so that anyone who drives at night ends up with jet lag as a way of life is a Really Rotten Idea (tm).
Some states have laws forbidding passing on the right, others do not.
They were commoner in the past than now, because many have been repealed due to their tendency to imped traffic on high lane-count expressways. (I think California may have been the one to start repealing the rule.)
= = = =
What drives me nuts is that driver education classes no longer teaches a safety rule they once taught: NEVER hold the same speed as the car in the adjacent lane. To do so causes accidents two ways:
1) It turns a pair of cars into a two-lane rolling roadblock (or more into a multi-lane roadblock ditto) impeding other drivers who want to go faster (whether legally or otherwise). The result is a number of closely-packed cars behind the cars that are pacing each other. This leads to chain-reaction collisions if something causes one or both of them to suddenly brake.
2) Pacing a car means you aren't moving relative to it. So you're not triggering the motion detection mechanism in the driver's peripheral vision system. After a minute or so he forgets you're there. Then he may turn into you during a lane change or when avoiding an obstacle. Or he may startle the next time he notices you and swerve, brake suddenly, or otherwise behave erratically - and startle YOU, causing you to do the same. A near-miss if he swerves or changes lanes may also cause YOU to brake. (In addition to direct problems between the two of you, if you've collected a pack this may be the start of the chain reaction accident.)
I've always thought the rightmost continuous lane (i.e. the one that doesn't keep disappearing down exits and rejoining after) should be marked, and the speed limit should rise five MPH per lane on those to its left. That would encourage a smooth flow of traffic, with the cars on the left slowly passing those to their right. While holding exactly the same speed may cause accidents, the problems arise mainly from significant speed differences between cars and the surrounding obstacles (stationary or other cars). So though traveling faster, the drivers on the left have less processing load from tracking the nearby cars going roughly the same speed than those on the right who are dealing with cars entering or exiting, debris and cars stopped in the shoulder, nearby roadsigns and other visual destractions, etc.
I have noticed that most people, myself included, cannot focus their vision on "deep blue" (sapphire blue) glowing signs at night, those remain "fuzzy" no matter how hard you concentrate.
That's mainly because the layout of the eye's cones (the color receptors) is a sparse hexagonal array of blue sensors filled in with a randomly-blotchy sea of red and green sensors. The blue image is lower resolution than the red, green, or black-and-white. (I'm not sure if there's also an issue with chromatic aberration causing the focus to be less accurate in blue. But that would be appropriate given the sensor layout.)
Some older taillight designs take advantage of this to produce a distance cue at ranges far beyond binocular vision usability: They have a blue jewel in the midst of the red lens. When the car is close you see red with a blue dot. When it's farther away the blue "leaks" out due to the lower resolution and the whole taillight appears purple. Still farther and the blue leaks beyond the red, producing a purple taillight with a blue aura. Result: You can keep track of the car at all distances but see red only when the car is close enough to be an immediate hazard.
Unfortunately government regulations now penalize showing colors other than red to the rear.
The RIAA are EXACTLY like the mafia! Because they assault and kill people! Except they, uh...don't.
Nope. They send the Sheriff to do it for them.
Sue you. Bankrupt you. Send the law to seize your assets. You get evicted. If you try to stay the sheriff's men will throw you out. If you try to resist them they'll use as much force as necessary - including deadly force if your resistance appears to be a threat to them.
Will this produce the same ozone (O3) emissions that the Ionic breeze does?
Yes.
And if nothing is done to react it back harmlessly the ozone will corrode downwind metals and degrade downwind plastics.
But I'm more concerned about the leftover ions that are carried past the plates. Those can accumulate very high charges (even beyond the voltage used to create the ions) on downstream surfaces. This could destroy semiconductors (if they carry more power when arcing over than the ESD protection can handle) as well as corrupt data (through direct signal injection, capacitive coupling of surges, and mini-EMPs).
Not to mention the fact that SiH4 autoignites at room temperature.
Also: I hear silanes (beyond n=1) are VERY toxic.
Back in my undergraduate days my chemistry teaching fellow was doing research on them. He claimed that the ones he was working on were so toxic that if you could smell them you had already exceeded the fatal dose.
(Now he might have been feeding me and the rest of the class a line of bull. But I wasn't about to argue with him. It WAS his thesis project, which implies that he should know what he was talking about. And he DID grade the class, after all... B-) )
Also: Mass-driver reaction engines. (Electric catapults using asteroidial debris for the "exhaust".) They work much more efficiently if you don't have resistive losses in the wiring and coils. (But rapidly changing the current through a superconductor is also problematic...)
Government bodies can take land by eminent domain when it is for the public good. Why can't they do that with IP?
They can't just TAKE it. They have to BUY it for a fair value. (Though they can force the sale.) See the Fifth Amendment.
In this case the fair value could be the discounted current value of all the potential future revenue for the product line - which the company could claim would be lost if their code was leaked to a competitor.
In short, NJ signed the license agreement, which presumably says that NJ can't give the voting machines to outside testers for evaluation and reporting.
And such a clause should be void on its face, because being inspected for proper function is a necessary part of being a voting machine. See the Doctrine of Unconscionability
I question the "last". (For instance: Wounded Knee...) But it is the last well known one by the bulk of ordinary citizens, and a great example of your point that voting corruption can lead to armed citizen uprisings.
Also: If there is a suspicion or legitimate accusation of vote fraud (or other violation of the state's election laws) committed with the aid of some aspect of the operation of the machine or its software, the state could perform the same inspections as part of a case investigating and prosecuting the fraud. That would let them do it under their own criminal law and procedures - even demanding the source code to examine (under court seal). B-)
Their voting machines are paid for by public dollars, used by the majority of the members of the public, to elect public officials, and they claim evaluation of their software cannot occur without their "permission"?
Their voting machines are SOLD (or maybe leased) to the government agencies that operate elections and have a contract specifying terms of use. They're claiming the contract forbids the sort of investigation that is proposed.
Now perhaps there are indeed such terms in the contract. In which case the New Jersey secretary of state (or a past one) made an unwise decision. Nevertheless, the state has a duty to insure that the system is not defective. Inspecting its operation, including that of the software if there is any question about its functionality (or even if there isn't, just to check), is obviously a part of that duty, and being inspected is obviously part of what it is to be a voting machine. So such contract terms, if present and interpreted as Sequoia claims, are clearly unconscionable. On that basis the state should be free to ignore the clause.
Alternatively, if the clause were to stand the resulting terms of use would make the machines "unsuitable for the intended use", violating the implied warranty of fitness. So the state could return them for a full refund. B-)
It would be interesting to see what would happen if Sequoia actually sued. If the contract specified interpretation under the laws of New Jersey (or didn't specify jurisdiction) the state might just refuse to be sued. B-) If it specifies another state (or they sue in their own) it would still be a funny show.
As for suing the professor, either he's acting as an agent of the state (in which case they're suing the state) or he's not (in which case he has no contract with them to enforce.) In the latter they'd have to go after him for something like DMCA violations or some part of contract law I'm unaware of.
Of course IANAL - and especially not a contract lawyer. So take the above with a suitable quantity of salt. B-)
Sorry. Missed the extra "a". (Should have been all-caps, though.)
Mafiaa != Mafia
Where'd you get that idea? I was under the impression that the RIAA is a direct descendant of the jukebox protection racket / Crosby organization. (That's what makes the "MAFIAA" coinage so poignant.)
A significant amount of mating behavior (across many species, including humans) consists of treating the partner as one would treat the offspring, to demonstrate to the partner that the childrearing behavioral components are normal, or to mimic infantile behavior to elicit such a demonstration.
Such demonstrations usually include some indication that the partner is really pretending, rather than actually being underage or developmentally retarded. ("I'm doing something naughty.")
You'll find lots of verbal forms of this in human relationships. Some examples: Babytalking. Referring to the partner with pronouns appropriate to children or parents. ("Baby" / "Babe", "Daddy.") Terms for partners in concubinage relationships. ("Sugar daddy") I could go on.
Much of this is politically incorrect at the moment, due to the meme, spread by the women's liberation movement in the middle of the 20th century, that such dimunitive forms of address were attempts by men to oppress women.
What's the general characteristic for something to be called "nano" something?
The technology must involve constructing mechanical structures where the position of each atom in the structure and its bonds to its neighbors are all controlled - in a mechanical engineering rather than a chemical reaction sense. (Biochemistry is a "found nanotech" - and was the proof of concept.) Think of it as industrial Tinkertoys (tm) where the spools are atoms and the rods are chemical bonds.
It's called "nanotechnology" because you're dealing with feature sizes in the 1 to 100 nanometer range.
why don't ISPs just set up honey pots and use them as test beds to determine what traffic is being generated by a bot, and kill the traffic as it leaves the costumer's computer
That doesn't solve the problem - it just moves it. Onto the vendors of networking hardware.
Core routers are "dumb as rocks" and can be relatively low reliability. The idea there is to treat each packet as a hot potato and move it on with as little "thought" about it as possible - so limited processing power can handle large numbers of packets. If the box goes down the others can find a way around it. But not thinking about each packet means these boxes are gullible.
Edge routers (the last router before the customer, or sometimes the one between two competing ISPs) are smarter and more robust: In the core there are multiple connections, but at the (customer) edge there is usually only one line to only one box, so it has to be as reliable as a phone switch. (If the ISP hasn't routed ALL traffic to/from the user through an extra box at the Network Op Center) it has to act as a "reverse firewall" to protect the gullible network routers from the users and keep the user from using resources he hasn't paid for. It's also the only box on the carrier side where all the customers' packets come together. So if the carrier is to provide comprehensive anti-malware service, that's where it ends up.
Edge routers have a lot of brains and a significant amount of memory. But for their main jobs they only have to look at headers and keep a small amount of state per customer. Add "deep packet inspection" for anti-malware on the current model and you explode the resources required. Now they have to look at the whole content of every packet and apply thousands of tests to it, exploding processor requirements. Worse they have to keep the state for every flow rather than just every customer - and a single tool-generated web page may be hundreds or thousands of separate flows, running in parallel due to browser optimization. And the state for each of the flows is enormous, including the state of the processing of each of the signatures being tested. Finally, they may actually have to hold the packets themselves, to reorder and/or defragment them for the analysis. So the storage requirements explode. And this resource requirement increases their susceptability to DOS attacks.
Further, smartening up the edge routers still further and giving them massive storage upgrades and inbound firewall duties makes them, not the users' machines, the primary target for malware vendors. They'd now have to spoof or subvert this machine to get their stuff to the users. But what a prize! Once it's subverted they get access to ALL the users and their traffic, regardless of the users' OS or anti-malware tools. (The zero-day window becomes "pwnership" of ALL the customers' data - no race between the infection spreading and the AV companies working out and deploying a signature.) Once in control, tapping should be a snap: The routers already have a government-mandated "lawful intercept" capability in place - just reconfigure it to send to the malware operation rather than the authorities. And talk about monocultures: The number of edge router vendors can be expressed with a single digit, likely with (at least at first) only one deep-packet-inspection product each. And they'll no doubt ally with the current anti-malware vendors to obtain their algorithms and signature updates.
So going to ISP-based filtering transfers the computational load of defense from a distributed web of end-users' machines to a small set of ISP boxes, increases the "software monoculture" vulnerability, provides an upstream target that the end user can't defend with a limited number of instances, makes it as vulnerable as the current worst-of-breed approach (microsoft OS and tools plus signature-based active immunity), gives access to ALL users on EVERY success, and raises the cost of the network boxes (and thus your networking bill).
Lowered security at a higher price doesn't seem like a good approach to me.
Slashdot Mirror
So in order to totall screw someone all you have to do is get on their box, phisically or by cracking and download some kiddy porn. Then drop a dime on them (just in case you did not click on the honey pot) and voila! Instant conviction.
Easier than that.
Just copy the URL from the honeypot link into a hyperlink apparently to something innocent-looking and entice them to click on that. The FBI uses their click to get the warrant, seize everything, and disrupts their lives for months. Then they're embarrassed at getting the wrong guy. So if they find ANYTHING ELSE they'll prosecute anyhow.
Having the link go to a page with IMG links to offsite kiddie porn that redirects to the honeypot would also end up with the images in their web cache. But I'm not familiar enough with HTTP to know if the fact that they were redirected would be visible at the honeypot site.
It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.
You've got to be kidding. Maybe it's not natural for most software "engineers", but I bet it's pretty natural for engineers in general.
Indeed.
I was tempted to take issue with Bruce on that point. After I cut my programming teeth in classified research I built a career in automobile automation engineering. I was ALWAYS looking at all the things that could go wrong, through bugs, mischance, or malice, and insuring that they were properly handled.
And this was expected. And it was honored, and the extra time required was paid for gladly. (I happened to be better at it than most, but everybody at least tried.)
But then I got out to Silicon Valley. And here I discovered that there was another, and much lower, standard of reliability when it came to software. The contrast was almost painful. (One of my colleagues once remarked that I was the only guy he would trust to program his pacemaker. B-) )
And I finally realized what it was:
In Detroit, virtually ANY hunk of software can be life-critical. A bug in the idle speed control might result in a year's production of cars that tend to stall a car's length into the intersection when accellerating from a stop sign. A bug in the factory energy management system might shut off the lights in the plant while the machines are still moving and the workers are within inches of them. A bug in the alarm on the annealing oven's flame curtain could let the plant fill with hot gas loaded with carbon monoxide, then blow the roof into the next county. A bug in the airbag tester program could fire the bag with the worker inside the test cell trying to hook it up. (To name four that I actually worked on.)
In Silicon Valley, on the other hand, there is massive pressure to get the product out marginally ahead of the competitors. And there are business models that turn product bugs into revenue streams via maintenance services and updates. (I finally switched to "the hard side of the force" - chip design - where a million dollars of nonrecurring expenses per bug-fix chip spin and months of lead time promotes the same sort of attention to perfection that I was used to.)
Bruce lives and works out here in the land of fruits, nuts, flakes - and software engineers that treat bugs as features and ship dates as the holy grail. So perhaps most of his experience is with "software engineers" of that sort, leading him to make an overgeneralization.
(Then again, while I apply that sort of thinking to my software and now hardware work, Bruce lives it 24/7. So perhaps he has a point. B-) )
If I read correctly, a GRB of this magnitude occurring 2700 light years away would be as bright as the sun. Ouch.
Ouch indeed. (I'm sure somebody will check your math and adjust the distance if necessary. So let's go with the premise of a solar input's worth from nearby.)
At that sort of distance the red shift would be virtually nonexistent. A kilowatt per square meter of gamma rays would make you toasty warm all the way through, not just on the skin.
Also: Goodbye DNA and RNA. Presuming you're still alive (for some value of alive) after the flash you'd be running on the proteins you've already got for your last few days. Then the deep ocean and rift vent critters get their chance. (Presuming, of course, that an associated neutrino flux didn't get them and the planet has to start from scratch.)
Depends on whether the moon is up. Scatter off that would toast you pronto as well.
Shouldn't any distribution based on a kernel build that doesn't require anything more or significantly different from the underlying hardware, relative to SUSE E.S. work just as well?
Put another way:
If you have a problem with another distribution under Hyper-V, and Microsoft is refractory about support, shouldn't you be able to replicate the problem under SUSE and make them fix THAT?
Are they only supporting SUSE E.S. as an ongoing policy? Or is it just the only one they've certified as of the first release?
Shouldn't any distribution based on a kernel build that doesn't require anything more or significantly different from the underlying hardware, relative to SUSE E.S. work just as well?
Thanks for the jog: The grad student was actually working on carboranes, not silanes. Oops!
Guess my memory hardware needs an upgrade. B-(
Yes, I know there are times that we've all had to drive with less sleep than we should have... but is this a good answer? To me it would seem to inspire false confidence on the part of the driver, where they might think that they could stay up and not have to worry about falling asleep driving since they had their blue lights blinking or whatever.
IMHO designing car lighting so that anyone who drives at night ends up with jet lag as a way of life is a Really Rotten Idea (tm).
Some states have laws forbidding passing on the right, others do not.
They were commoner in the past than now, because many have been repealed due to their tendency to imped traffic on high lane-count expressways. (I think California may have been the one to start repealing the rule.)
= = = =
What drives me nuts is that driver education classes no longer teaches a safety rule they once taught: NEVER hold the same speed as the car in the adjacent lane. To do so causes accidents two ways:
1) It turns a pair of cars into a two-lane rolling roadblock (or more into a multi-lane roadblock ditto) impeding other drivers who want to go faster (whether legally or otherwise). The result is a number of closely-packed cars behind the cars that are pacing each other. This leads to chain-reaction collisions if something causes one or both of them to suddenly brake.
2) Pacing a car means you aren't moving relative to it. So you're not triggering the motion detection mechanism in the driver's peripheral vision system. After a minute or so he forgets you're there. Then he may turn into you during a lane change or when avoiding an obstacle. Or he may startle the next time he notices you and swerve, brake suddenly, or otherwise behave erratically - and startle YOU, causing you to do the same. A near-miss if he swerves or changes lanes may also cause YOU to brake. (In addition to direct problems between the two of you, if you've collected a pack this may be the start of the chain reaction accident.)
I've always thought the rightmost continuous lane (i.e. the one that doesn't keep disappearing down exits and rejoining after) should be marked, and the speed limit should rise five MPH per lane on those to its left. That would encourage a smooth flow of traffic, with the cars on the left slowly passing those to their right. While holding exactly the same speed may cause accidents, the problems arise mainly from significant speed differences between cars and the surrounding obstacles (stationary or other cars). So though traveling faster, the drivers on the left have less processing load from tracking the nearby cars going roughly the same speed than those on the right who are dealing with cars entering or exiting, debris and cars stopped in the shoulder, nearby roadsigns and other visual destractions, etc.
I have noticed that most people, myself included, cannot focus their vision on "deep blue" (sapphire blue) glowing signs at night, those remain "fuzzy" no matter how hard you concentrate.
That's mainly because the layout of the eye's cones (the color receptors) is a sparse hexagonal array of blue sensors filled in with a randomly-blotchy sea of red and green sensors. The blue image is lower resolution than the red, green, or black-and-white. (I'm not sure if there's also an issue with chromatic aberration causing the focus to be less accurate in blue. But that would be appropriate given the sensor layout.)
Some older taillight designs take advantage of this to produce a distance cue at ranges far beyond binocular vision usability: They have a blue jewel in the midst of the red lens. When the car is close you see red with a blue dot. When it's farther away the blue "leaks" out due to the lower resolution and the whole taillight appears purple. Still farther and the blue leaks beyond the red, producing a purple taillight with a blue aura. Result: You can keep track of the car at all distances but see red only when the car is close enough to be an immediate hazard.
Unfortunately government regulations now penalize showing colors other than red to the rear.
The RIAA are EXACTLY like the mafia! Because they assault and kill people! Except they, uh...don't.
Nope. They send the Sheriff to do it for them.
Sue you.
Bankrupt you.
Send the law to seize your assets.
You get evicted.
If you try to stay the sheriff's men will throw you out.
If you try to resist them they'll use as much force as necessary - including deadly force if your resistance appears to be a threat to them.
Will this produce the same ozone (O3) emissions that the Ionic breeze does?
Yes.
And if nothing is done to react it back harmlessly the ozone will corrode downwind metals and degrade downwind plastics.
But I'm more concerned about the leftover ions that are carried past the plates. Those can accumulate very high charges (even beyond the voltage used to create the ions) on downstream surfaces. This could destroy semiconductors (if they carry more power when arcing over than the ESD protection can handle) as well as corrupt data (through direct signal injection, capacitive coupling of surges, and mini-EMPs).
Not to mention the fact that SiH4 autoignites at room temperature.
Also: I hear silanes (beyond n=1) are VERY toxic.
Back in my undergraduate days my chemistry teaching fellow was doing research on them. He claimed that the ones he was working on were so toxic that if you could smell them you had already exceeded the fatal dose.
(Now he might have been feeding me and the rest of the class a line of bull. But I wasn't about to argue with him. It WAS his thesis project, which implies that he should know what he was talking about. And he DID grade the class, after all... B-) )
Also: Mass-driver reaction engines. (Electric catapults using asteroidial debris for the "exhaust".) They work much more efficiently if you don't have resistive losses in the wiring and coils. (But rapidly changing the current through a superconductor is also problematic...)
Using that logic Microsoft shouldn't try to improve security in Windows ...
Isn't that already their business plan?
Government bodies can take land by eminent domain when it is for the public good. Why can't they do that with IP?
They can't just TAKE it. They have to BUY it for a fair value. (Though they can force the sale.) See the Fifth Amendment.
In this case the fair value could be the discounted current value of all the potential future revenue for the product line - which the company could claim would be lost if their code was leaked to a competitor.
In short, NJ signed the license agreement, which presumably says that NJ can't give the voting machines to outside testers for evaluation and reporting.
And such a clause should be void on its face, because being inspected for proper function is a necessary part of being a voting machine. See the Doctrine of Unconscionability
I question the "last". (For instance: Wounded Knee...) But it is the last well known one by the bulk of ordinary citizens, and a great example of your point that voting corruption can lead to armed citizen uprisings.
Also: If there is a suspicion or legitimate accusation of vote fraud (or other violation of the state's election laws) committed with the aid of some aspect of the operation of the machine or its software, the state could perform the same inspections as part of a case investigating and prosecuting the fraud. That would let them do it under their own criminal law and procedures - even demanding the source code to examine (under court seal). B-)
...have I got this straight?
Their voting machines are paid for by public dollars, used by the majority of the members of the public, to elect public officials, and they claim evaluation of their software cannot occur without their "permission"?
Their voting machines are SOLD (or maybe leased) to the government agencies that operate elections and have a contract specifying terms of use. They're claiming the contract forbids the sort of investigation that is proposed.
Now perhaps there are indeed such terms in the contract. In which case the New Jersey secretary of state (or a past one) made an unwise decision. Nevertheless, the state has a duty to insure that the system is not defective. Inspecting its operation, including that of the software if there is any question about its functionality (or even if there isn't, just to check), is obviously a part of that duty, and being inspected is obviously part of what it is to be a voting machine. So such contract terms, if present and interpreted as Sequoia claims, are clearly unconscionable. On that basis the state should be free to ignore the clause.
Alternatively, if the clause were to stand the resulting terms of use would make the machines "unsuitable for the intended use", violating the implied warranty of fitness. So the state could return them for a full refund. B-)
It would be interesting to see what would happen if Sequoia actually sued. If the contract specified interpretation under the laws of New Jersey (or didn't specify jurisdiction) the state might just refuse to be sued. B-) If it specifies another state (or they sue in their own) it would still be a funny show.
As for suing the professor, either he's acting as an agent of the state (in which case they're suing the state) or he's not (in which case he has no contract with them to enforce.) In the latter they'd have to go after him for something like DMCA violations or some part of contract law I'm unaware of.
Of course IANAL - and especially not a contract lawyer. So take the above with a suitable quantity of salt. B-)
Woosh!!
Mafiaa == RIAA + MPAA
Sorry. Missed the extra "a". (Should have been all-caps, though.)
Mafiaa != Mafia
Where'd you get that idea? I was under the impression that the RIAA is a direct descendant of the jukebox protection racket / Crosby organization. (That's what makes the "MAFIAA" coinage so poignant.)
The solution is obvious: sic the Mafiaa on the attackers
That didn't work when the US tried it on Castro. (But the mafiosi DID laugh all the way to the bank.)
The Mafia is very overrated as a tool for governmental clandestine activities.
They're CROOKS! DEAL with it!
A significant amount of mating behavior (across many species, including humans) consists of treating the partner as one would treat the offspring, to demonstrate to the partner that the childrearing behavioral components are normal, or to mimic infantile behavior to elicit such a demonstration.
Such demonstrations usually include some indication that the partner is really pretending, rather than actually being underage or developmentally retarded. ("I'm doing something naughty.")
You'll find lots of verbal forms of this in human relationships. Some examples: Babytalking. Referring to the partner with pronouns appropriate to children or parents. ("Baby" / "Babe", "Daddy.") Terms for partners in concubinage relationships. ("Sugar daddy") I could go on.
Much of this is politically incorrect at the moment, due to the meme, spread by the women's liberation movement in the middle of the 20th century, that such dimunitive forms of address were attempts by men to oppress women.
What's the general characteristic for something to be called "nano" something?
The technology must involve constructing mechanical structures where the position of each atom in the structure and its bonds to its neighbors are all controlled - in a mechanical engineering rather than a chemical reaction sense. (Biochemistry is a "found nanotech" - and was the proof of concept.) Think of it as industrial Tinkertoys (tm) where the spools are atoms and the rods are chemical bonds.
It's called "nanotechnology" because you're dealing with feature sizes in the 1 to 100 nanometer range.
why don't ISPs just set up honey pots and use them as test beds to determine what traffic is being generated by a bot, and kill the traffic as it leaves the costumer's computer
That doesn't solve the problem - it just moves it. Onto the vendors of networking hardware.
Core routers are "dumb as rocks" and can be relatively low reliability. The idea there is to treat each packet as a hot potato and move it on with as little "thought" about it as possible - so limited processing power can handle large numbers of packets. If the box goes down the others can find a way around it. But not thinking about each packet means these boxes are gullible.
Edge routers (the last router before the customer, or sometimes the one between two competing ISPs) are smarter and more robust: In the core there are multiple connections, but at the (customer) edge there is usually only one line to only one box, so it has to be as reliable as a phone switch. (If the ISP hasn't routed ALL traffic to/from the user through an extra box at the Network Op Center) it has to act as a "reverse firewall" to protect the gullible network routers from the users and keep the user from using resources he hasn't paid for. It's also the only box on the carrier side where all the customers' packets come together. So if the carrier is to provide comprehensive anti-malware service, that's where it ends up.
Edge routers have a lot of brains and a significant amount of memory. But for their main jobs they only have to look at headers and keep a small amount of state per customer. Add "deep packet inspection" for anti-malware on the current model and you explode the resources required. Now they have to look at the whole content of every packet and apply thousands of tests to it, exploding processor requirements. Worse they have to keep the state for every flow rather than just every customer - and a single tool-generated web page may be hundreds or thousands of separate flows, running in parallel due to browser optimization. And the state for each of the flows is enormous, including the state of the processing of each of the signatures being tested. Finally, they may actually have to hold the packets themselves, to reorder and/or defragment them for the analysis. So the storage requirements explode. And this resource requirement increases their susceptability to DOS attacks.
Further, smartening up the edge routers still further and giving them massive storage upgrades and inbound firewall duties makes them, not the users' machines, the primary target for malware vendors. They'd now have to spoof or subvert this machine to get their stuff to the users. But what a prize! Once it's subverted they get access to ALL the users and their traffic, regardless of the users' OS or anti-malware tools. (The zero-day window becomes "pwnership" of ALL the customers' data - no race between the infection spreading and the AV companies working out and deploying a signature.) Once in control, tapping should be a snap: The routers already have a government-mandated "lawful intercept" capability in place - just reconfigure it to send to the malware operation rather than the authorities. And talk about monocultures: The number of edge router vendors can be expressed with a single digit, likely with (at least at first) only one deep-packet-inspection product each. And they'll no doubt ally with the current anti-malware vendors to obtain their algorithms and signature updates.
So going to ISP-based filtering transfers the computational load of defense from a distributed web of end-users' machines to a small set of ISP boxes, increases the "software monoculture" vulnerability, provides an upstream target that the end user can't defend with a limited number of instances, makes it as vulnerable as the current worst-of-breed approach (microsoft OS and tools plus signature-based active immunity), gives access to ALL users on EVERY success, and raises the cost of the network boxes (and thus your networking bill).
Lowered security at a higher price doesn't seem like a good approach to me.