The one that gets via Internet -of-things the number, age, gender, medical record of the passengers in another car/bus, to minimize casualties. What a brave new world, when we start to steer vehicles in problematic situations into a state of minimal loss to society.
Are you drunk or retarded? No car manufacturer would ever program a vehicle to preference hitting/not-hitting humans based on fucking medical records.
The car will be programmed to try to stop, or swerve into clear space. Failing that, it will be programmed to reduce its speed before impact. That's it. No moral assessments of your life's potential verses another pedestrians. Stop. Avoid. Reduce.
As the programming gets better, it simply means the cars will avoid more and more of the situations you are describing by reacting much earlier. They won't be assessing the relative worth of pedestrians to decide who to crash into, they will be assessing road conditions and probably future risk scenarios to avoid accidents.
However, with 37,000 less deaths on the road each year, 2.5 million less road injuries/disabilities each year, the cost to cities/states should be so much less that they can afford to carry the budget short-fall for their PD. I mean, just the reduction in the cost of accident attendance, rescue and recovery each year.
Anyone capable of wiring up a car-bomb, especially one with a remote detonator (usually a heavily modded cellphone), would probably have the ability to RC an existing non-robot car from off-the-shelf parts. (A quad-copter kit for the electronics and cameras, plus some larger motors and actuators for the car controls.) Even better, unlike bomb making, you can pick the brains of the RC community without fear of being reported. "Hey guys, I thought I'd RC an old van to hack around my farm as a summer project, anyone in the area want to help?"
If there was a demand for this from terrorists (whether domestic or Muslim), it would already be happening.
A robot car would actually make it harder, since it will obey traffic laws, stop when blocked, never exceed the speed limit. That means, for example, you couldn't speed up and jump the curb to get your bomb closer to the building. Or drive through a pedestrian-only path for the last 100 yards. Or smash through a entry barrier. Etc, etc. And hacking it to bypass those controls would likely be harder than RCing a non-robot car, IMO.
An RC car can be driven however you want. A robot car only how Google wants.
Investigators already have methods to deal with drug shipments. You follow and wait for a human to intercept the shipment.
You don't want to stop the car, if the dealers have any kind of monitoring system, they'll know they've been rumbled and go to ground. You don't want the dealers to know that anything is wrong until the shipment reaches them.
Robot cars will be programmed to obey road laws. Which means they'll pull over for emergency vehicles (to get out of the way), they'll stop for traffic lights, or for pedestrians or any vehicle blocking their path. Any of those is your kill switch. Bad guys with the ability to bypass such programmed behaviour can obviously bypass a kill-switch.
Hell, bypassing the kill-switch will be a common hack in the car-mod community, so the bad guys won't even need to do the hard work.
And if there's a kill signal to stop any car it's pointed at, the triggers must be mass produced for all law enforcement vehicles (and mobile security zones, etc). Which means they will be easily diverted onto the black market and thus available to bad guys to ambush important targets much more easily. That's ignoring hobbyists who break the system and publish the details, and copycat boxes quickly available online. [This means there'll be an exemption to the kill switch requirement for "important" vehicles, which means the kill switch will become a class-based item.]
Thus the only people who could possibly be even inconvenienced by kill switches are everyone except the bad guys.
For that matter, anyone with the ability to wire up a car bomb (especially the ones that use hacked cellphones as triggers) probably has the ability to RC an existing car. So if there was a danger of "guided missile" cars, we'd have already seen it. (Hell, hand grenade on a quad-copter.) It isn't how the bad guys operate. Fill a truck full of ANFO, park it next to the target, run away. Strap a bomb to a gullible teenager, send him into a shopping centre. Who needs a "guided missile" car outside of a lame Hollywood movie?
Well, I'd argue pen, paper, hand count, not pencil, but your point still holds.
Pens in voting booths run out without showing an obvious external sign, you have to test them continuously, one at a time, for the whole day. Pencils in booths can be easily checked by sight at walking pace whether they are blunt without touching them. Much quicker. Also pencils tips don't dry out.
Your concern, I'm guessing, is someone rubbing out the pencil and changing other people's vote? Soft graphite on thin cheap matte paper can't be easily erased without leaving marks or ripping the paper. The marks allow counters/auditors to see changes made to the ballot. A few corrections might be ignored, a thousand ballots in the same ballot box all with the same "correction" either means fraud or a huge design flaw on the ballot. Either way, it's a big red flag.
[I recall reading that the AEC actually chooses their paper & pencil brands specifically for this property.]
Likewise, graphite is just black carbon, it's pretty inert unless you set fire to it. OTOH, many organic inks can be erased with certain basic solvents that otherwise leave the paper unharmed, and metallic inks are never used in cheap pens. In theory you could spray the right fast-drying solvent on each ballot, then re-mark them when they are dry. (More convoluted hence less likely than basic ballot stuffing, but if it's a concern, pens are not the answer.)
I'd also thought about electronic means that generate a paper receipt, but there's still no real guarantee that the machine tabulated the vote correctly or that the voter will have recourse if the receipt shows something other than what the voter intended.
If you are willing to give up the non-sellable/forcible vote, there are one-way functions that can generate keys for tracking ballots. Ie, the voter gets a receipt with a number that enables them to later check their vote online. The key function can't be reversed, so the Ruling Party stooges can't pull up all the votes for Rival Party candidate to to unmask those voters. Indeed, even the personal key isn't linked to the voter's ID, except on the piece of paper held by the voter.
[And therein lies the flaw. It is possible for people to be individually coerced into logging in and showing their vote to Party loyalists. Say by bosses or union heavies. This sort of thing apparently happens in Russia a lot (except using postal ballots), along with the more usual voter intimidation and fraud. Or more peacefully, it allows people to buy votes. "Show me your vote, if it's for Rich Party, win $50".]
Such a system would also allow "floating proxies". A system where you assign your one-vote to a proxy (who either uses it or assigns it to a further proxy) and proxies vote in Parliament/Congress in proportion to the number of votes assigned to each of them. Unlike current representatives, you could reassign your vote as often as you want (hence "floating"), and, unlike current representatives, no voter is unrepresented (because there's no "winning" or "losing" candidates, only proxies.)
[This still has the same flaw. Someone can force you to surrender your key so they can manipulate your proxy.]
Hence my support for optical scan with the ability to hand-count.
Not disagreeing with that part. Except that the hand count should be the "official" count, and the optical scan just the election-night "indicator".
Security through obscurity might work for something like a power plant control system because we don't know the architecture of the hardware that it runs on, the operating system or if there is a third-party OS, the language it's written in, or even its name, and given the importance of the application it probably wouldn't be permanently Internet-connected, and if it needs to send out notifications it might communicate through a unidirectional RS232 link or something along those lines, or through a transmit-only fiber link (so that there's not even receive hardware on the platform).
Power companies don't develop bespoke security on their control systems (and would likely suck if they did). A particular power system most likely use off-the-shelf 1970s or '80s Siemens systems whose specs are widely known through the industry because of the decades of technicians who have worked on them.
Security through obscurity doesn't work because it relies on the security of your obscurity, and most of the time your obscurity is weak. Key-based crypto systems are a form of security through obscurity, the obscurity is your key. But you have a reasonable ability to control the key, if they are issued per-person/per-session/etc. A key crypto system becomes useless if the key is distributed to multiple people, because you've breached the security of your obscurity. OTOH, the back-end system for the key-crypto cannot be obscure because someone other than the individual user had to develop it, install it, maintain it, operate it, etc. The same is true of the power station example, since there must be thousands of people trained to maintain such systems, plus all the developers/etc at Siemens, plus any rival company who's reverse engineered a Siemens system to develop "compatible" systems, plus... In the case of a voting system, you've got all the system devs, all the system maints, all the people who have access to the secret Trust Me computer when it's in use, all the people who have access to the secret Trust Me computer when it's not in use, etc. Your obscurity is inherently insecure.
But in the case of voting (or vote counting, in this case), we don't want security through obscurity specifically because obscurity is a known risk in voting systems. We want security through multiple independent observation of the entire process, the more observers the better. A vote count that is carried out entirely within a piece of code on a computer is, by definition, no matter how secure and air-gapped and guarded that computer, unable to be observed by independent observers. It lacks the fundamental requirement of being verifiable.
That's why you can't beat a hand count.
[If they want to put the count on a computer, then every piece of data (in this case, the preference information on individual ballots) should be put on-line - in addition to the hand count. That way, hundreds of independent, 3rd party systems can do a quick electronic count, not just the AEC's secret Trust Me box. (Parties, NGOs, media networks, university politics professors, university statistics students, etc.) Likewise, during the data entry process by AEC officials, on-site observers watching over their shoulders would be able to, would be encouraged to, enter each ballot into their own separate (tablet/laptop-based) systems. If the results of the later official hand count disagrees wildly with the majority of 3rd party systems, it's cause for panic/re-count/inquiries. If a few 3rd party systems get different results from the majority, there's probably a flaw in those. In net, you end up with multiple, overlapping, self-reinforcing and completely open counting systems that assures everyone of the integrity of the system and which gets stronger over time, while at the same time giving the advantage of faster (electronic) results.]
They don't understand how it works, therefore they're afraid of it.
That also applies to 90% of the comments in this post. (Or indeed, 90% of comments on Slashdot, full stop.)
That's also probably a better justification for opening source code and design documentation than the usual "obscurity != security" nerd rage. There's less to fear when the lights are on.
The problem with printing out each vote on site becomes apparent when you look at the history of machine voting. Even punch-card machines (the completely non-electronic punch tables themselves, not the subsequent reader) become unusable during elections because of poor maintenance, lack of cleaning, age, bad design, etc.
With pre-printed forms, you know they are all correct (or all wrong) before the election. With on-site printing, the printers can run out of ink or paper, or jam, or smudge. And that prevents votes from being recorded, which creates delays and long lines, both causing voters to give up. By selectively assigning resources to preferred precincts, and away from undesired precincts, the ruling party can (and do!) target such interruptions to alter the result. You're adding an extra layer of shit to go wrong, and hence be manipulated to go wrong.
Pencil, paper, hand count.
Anything else is more trouble than it's worth. People over-think things.
I firmly believe that all electronic voting machines should have full source code released and receipts that should be printed and signed by the voter and placed in a box next to the machine in case of recounts or verification questions.
The system in the article is about counting the pieces of paper we manually write our votes on, because we use a preference voting system (instant run off), if your #1 candidate gets eliminated, your vote gets reassigned to your #2 candidate. In the Senate, there's also a seat-quota system, where preferences simultaneously flow "down" as well as "up", so it's difficult to give the quick result that everyone wants on election night.
The AEC trialled actual electronic voting in one Australian territory, ACT, because it has an even more complex preference system (Hare-Clark).
If you have a power failure so complete you lost every instrument
"Instruments" are on independent systems to the "controls". There have been examples of ac losing the instruments but having functional controls. (Or losing some of the controls, but retaining sufficient backups to control the aircraft.) Indeed, one of the procedures in the event of fire is to pop the breakers for all but a handful of instruments (it doesn't kill your controls), to try to isolate the fire-causing electrical fault.
If you have a single display set-up that combines your camera view and your instrument display, you could lose the entire display system while retaining flight controls. So you're sitting in a darkened sealed room in an otherwise perfectly flyable ac, because one system failed.
[That said, having external cameras for the pilots would be useful. And internal ones. Being able to see the engines, the rudder or ailerons, the landing gear, inside the cargo-bay or cabin. Thermals too. And long range, low-light/IR, forward cameras. This would also give you 20 years of data on the failure rate of imaging systems before some idiot designer blacks out the cockpit.]
Think of all those space capsules that don't have a windshield.
Every capsule had view-ports for navigation, at the insistence of the astronauts. Came in handy during Apollo 13 when they lost power for the guidance computer (and everything else.)
"Hi, welcome to MIT Tech Review. You've never read our site before, you probably know nothing about our site since you followed a link from an aggregator, and we're blocking you from reading the site now via this pop-over. WOULD YOU LIKE TO SUBSCRIBE?!?!?!?!?!"
The vendors set their price, the scalper pays them the full price they ask, then merely resells for a higher price. If the vendor set the price too low, in numbers too low, the market corrects for it.
but that is not even remotely Occulus' intention here. They have a limited supply but want to keep the price low to stimulate development.
Except they are not targeting devs. They are just selling a limited number of devices too cheaply. That neither targets devs nor provides development funds for themselves. There's nothing about selling-low that prevents "rich folks" buying a toy. Essentially whether a dev, a rich toy buyer or a tech collector gets a unit is a matter of first-come-first-served.
Other than shutting off an entire region (which cuts off Chinese devs as much as it does "scalpers") they are just selling alpha versions to anyone who will pay.
[Sounds like your Eve team suffered the tragedy of the commons. Your manufacturers wanted to be part of a team for their benefit, preferentially profited from that membership compared to other members, but didn't want to pay proportionally more to defend the team. This is why real world "teams" end up with governments and taxes.]
The value of the Oculus brand is greater the more developers they can snag to work on/with their product, and so the more developers that get their hands on the devkit the better for Oculus.
That isn't consistent with them selling the units. The moment you charge money you are just selling them. If you are selling them, you can't argue you're trying to target devs. (And if the units are worth more second hand than new, you are clearly charging too little.)
They are limited in how many devkits they can build however and so it is important to Oculus that every single one that they make goes to an actual developer
Then they shouldn't be selling them to anyone who orders one. They should be lending units to their preferred developers on an invitation-only basis. They can then put any conditions they want in the loan agreement (such as a large penalty for any unit not returned, to prevent (or at least discourage) them being sold.)
Since being purchased by Facebook, they have much less need for new cash to fund their ongoing development, so that isn't an excuse. When they were independent, cash was an issue, in which case selling "dev" units for less than market demand price is just robbing themselves of money they could use to pay for the second batch or second version.
That "problem" was solved years/decades ago. Event ticket sales were limited to a certain number per customer
That's not a solution. That's just a pig-headed attempt to preserve the flaws of the existing system.
A solution would be to sell the tickets at the highest price people are willing to pay, at the number the vendor wants to offer. The easiest way to do that is to use auction systems. If people are paying what they are willing to pay, there's no profit margin for scalpers to resell. And if people are willing to pay more than the vendor expected, that extra profit goes to the vendor, not resellers/scalpers. If people are only willing to pay less, at least it guarantees the venue is full, which may still allow them to cover costs avoiding cancelling shows. (If demand is high enough, ie number of bids above an arbitrary price, the vendor might be able to book a larger venue. If it's low, they might be able to drop to a smaller (cheaper) venue, keeping the sense of "full house" for the atmosphere, plus increasing the intimacy of the show. Much better than a half empty venue. Such decisions could be built into the auction system to trigger automagically.) This system would also allow last-minute sales of the block of tickets held for the celebrity guest list (who often don't show.)
As I said elsewhere, there's no such thing as scalping. Only stupid vendors.
[If you are concerned about pricing certain people out of the market, you could offer a portion of the tickets on a lottery basis. Say limited to members of the local fan-club. Just as you offer "prize" tickets to radio-stations as part of your promotion.]
Mark said nothing to suggest he's confused about it being a devkit. Just that you can limit "scalping" by not allowing multiple sales. Any individual resales beyond that is irrelevant.
I'd go further, there's no such as scalping. If someone can resell an item at higher than your retail price, you failed to price or supply your product properly. The error is yours, not the "scalper's".
[In my state, there are specific laws that protect resellers. Preventing "one per customer" restrictions precisely for that reason. Many major retailers hate that law because it prevents them from using "loss leaders" to drive smaller rivals out of business.]
but it is not released to the public yet!
If you are selling a dev version, then you are retailing a product to the public. Again, if there is more demand at a higher price than you are supplying either quantity/price, the error is the vendor's, not the "scalper's".
Even if this story was about using the dog's response to establish probable cause for a search, any assessment of the validity of that probable cause is done during the preliminary stages of the trial, before the jury is called in. The jury is then merely instructed that the search was valid. It's incredibly rare that a jury is allowed to assess the validity of evidence gathering, or even told that the defence raised any issue at all.
You STILL don't get nine. You either settle for the current eight, or you will, eventually, have hundreds, at least.
Not necessarily. If you make the definition of "planet" as wide as possible, you can then create (non-exclusive, overlapping) sub-categories for different classes. Terrestrial, gas-giant, dwarfs, KBOs, super-Jupiter, hot-Jupters, hot-Earths, super-Earths, rogue (or free flying) planets, etc.
And, of course, then you can have "Traditional Planets", which is the nine.
Everyone gets a toy, everyone goes home happy.
[Except I'd make the definition wide enough to include large moons (eg, "non-stellar bodies over 500km diameter and/or hydrodynamically spherised"), then "major moons" would be one of the sub-categories of "planet", which would piss off the sort of people twisting their knickers over Pluto.]
Basically, they are repeated all the old mistakes of Shuttle and ISS. Single unaffordable top-down designs, expensive sole-source cost-plus contracts, convoluted designs more intended to feed the contractor networks in Congressional districts than to deliver improved hardware, flubbery half-hearted missions that mutate to fit the rapidly contracting hardware abilities rather than hardware designed for missions. And because everything is so expensive and poorly planned, development has to be smeared out over decades, giving time for endless Congressional budget games with the attendant schedule and cost blow-outs, and design compromises piled on top of design compromises just to get something launched.
Paraphrasing Gen. Augustine, in the analysis over Constellation (SLS's precursor), "If someone handed it to NASA, already build and paid for, NASA still couldn't afford to operate it."
Falcon 9 has a payload capicity of 13,150 Kg to LEO.
He said "Falcon 9 Heavy" (the original name of the Falcon Heavy). So 50,000kg to LEO, should fly in the next year or two, and cost less than $100m per launch (say $150m with a "NASA paperwork tax".)
SLS is to have a payload capacity of 130,000 Kg to LEO.
SLS Block "zero" will lift around 60,000kg, and may fly in 2017 or 2018. Development will have cost $10-12 billion from now 'til then. It won't be able to lift Orion (which won't be ready anyway).
Block I is meant to loft 70,000 kg to LEO, flying in 2021 at the earliest. Development will have cost $21 billion from now 'til then. It will be able to lift Orion, but only for 14 day missions around the moon and back.
Block IA is meant to lift 105,000kg, some time in the mid-2020's. And Block II, the one you are talking about, with 130,000kg to LEO, by 2032. Development will have cost over $50 billion from now 'til then.
That doesn't include any other hardware, nor any launch or mission costs. Just development.
Slashdot Mirror
The one that gets via Internet -of-things the number, age, gender, medical record of the passengers in another car/bus, to minimize casualties. What a brave new world, when we start to steer vehicles in problematic situations into a state of minimal loss to society.
Are you drunk or retarded? No car manufacturer would ever program a vehicle to preference hitting/not-hitting humans based on fucking medical records.
The car will be programmed to try to stop, or swerve into clear space. Failing that, it will be programmed to reduce its speed before impact. That's it. No moral assessments of your life's potential verses another pedestrians. Stop. Avoid. Reduce.
As the programming gets better, it simply means the cars will avoid more and more of the situations you are describing by reacting much earlier. They won't be assessing the relative worth of pedestrians to decide who to crash into, they will be assessing road conditions and probably future risk scenarios to avoid accidents.
However, with 37,000 less deaths on the road each year, 2.5 million less road injuries/disabilities each year, the cost to cities/states should be so much less that they can afford to carry the budget short-fall for their PD. I mean, just the reduction in the cost of accident attendance, rescue and recovery each year.
Anyone capable of wiring up a car-bomb, especially one with a remote detonator (usually a heavily modded cellphone), would probably have the ability to RC an existing non-robot car from off-the-shelf parts. (A quad-copter kit for the electronics and cameras, plus some larger motors and actuators for the car controls.) Even better, unlike bomb making, you can pick the brains of the RC community without fear of being reported. "Hey guys, I thought I'd RC an old van to hack around my farm as a summer project, anyone in the area want to help?"
If there was a demand for this from terrorists (whether domestic or Muslim), it would already be happening.
A robot car would actually make it harder, since it will obey traffic laws, stop when blocked, never exceed the speed limit. That means, for example, you couldn't speed up and jump the curb to get your bomb closer to the building. Or drive through a pedestrian-only path for the last 100 yards. Or smash through a entry barrier. Etc, etc. And hacking it to bypass those controls would likely be harder than RCing a non-robot car, IMO.
An RC car can be driven however you want. A robot car only how Google wants.
Investigators already have methods to deal with drug shipments. You follow and wait for a human to intercept the shipment.
You don't want to stop the car, if the dealers have any kind of monitoring system, they'll know they've been rumbled and go to ground. You don't want the dealers to know that anything is wrong until the shipment reaches them.
Robot cars will be programmed to obey road laws. Which means they'll pull over for emergency vehicles (to get out of the way), they'll stop for traffic lights, or for pedestrians or any vehicle blocking their path. Any of those is your kill switch. Bad guys with the ability to bypass such programmed behaviour can obviously bypass a kill-switch.
Hell, bypassing the kill-switch will be a common hack in the car-mod community, so the bad guys won't even need to do the hard work.
And if there's a kill signal to stop any car it's pointed at, the triggers must be mass produced for all law enforcement vehicles (and mobile security zones, etc). Which means they will be easily diverted onto the black market and thus available to bad guys to ambush important targets much more easily. That's ignoring hobbyists who break the system and publish the details, and copycat boxes quickly available online. [This means there'll be an exemption to the kill switch requirement for "important" vehicles, which means the kill switch will become a class-based item.]
Thus the only people who could possibly be even inconvenienced by kill switches are everyone except the bad guys.
For that matter, anyone with the ability to wire up a car bomb (especially the ones that use hacked cellphones as triggers) probably has the ability to RC an existing car. So if there was a danger of "guided missile" cars, we'd have already seen it. (Hell, hand grenade on a quad-copter.) It isn't how the bad guys operate. Fill a truck full of ANFO, park it next to the target, run away. Strap a bomb to a gullible teenager, send him into a shopping centre. Who needs a "guided missile" car outside of a lame Hollywood movie?
Well, I'd argue pen, paper, hand count, not pencil, but your point still holds.
Pens in voting booths run out without showing an obvious external sign, you have to test them continuously, one at a time, for the whole day. Pencils in booths can be easily checked by sight at walking pace whether they are blunt without touching them. Much quicker. Also pencils tips don't dry out.
Your concern, I'm guessing, is someone rubbing out the pencil and changing other people's vote? Soft graphite on thin cheap matte paper can't be easily erased without leaving marks or ripping the paper. The marks allow counters/auditors to see changes made to the ballot. A few corrections might be ignored, a thousand ballots in the same ballot box all with the same "correction" either means fraud or a huge design flaw on the ballot. Either way, it's a big red flag.
[I recall reading that the AEC actually chooses their paper & pencil brands specifically for this property.]
Likewise, graphite is just black carbon, it's pretty inert unless you set fire to it. OTOH, many organic inks can be erased with certain basic solvents that otherwise leave the paper unharmed, and metallic inks are never used in cheap pens. In theory you could spray the right fast-drying solvent on each ballot, then re-mark them when they are dry. (More convoluted hence less likely than basic ballot stuffing, but if it's a concern, pens are not the answer.)
I'd also thought about electronic means that generate a paper receipt, but there's still no real guarantee that the machine tabulated the vote correctly or that the voter will have recourse if the receipt shows something other than what the voter intended.
If you are willing to give up the non-sellable/forcible vote, there are one-way functions that can generate keys for tracking ballots. Ie, the voter gets a receipt with a number that enables them to later check their vote online. The key function can't be reversed, so the Ruling Party stooges can't pull up all the votes for Rival Party candidate to to unmask those voters. Indeed, even the personal key isn't linked to the voter's ID, except on the piece of paper held by the voter.
[And therein lies the flaw. It is possible for people to be individually coerced into logging in and showing their vote to Party loyalists. Say by bosses or union heavies. This sort of thing apparently happens in Russia a lot (except using postal ballots), along with the more usual voter intimidation and fraud. Or more peacefully, it allows people to buy votes. "Show me your vote, if it's for Rich Party, win $50".]
Such a system would also allow "floating proxies". A system where you assign your one-vote to a proxy (who either uses it or assigns it to a further proxy) and proxies vote in Parliament/Congress in proportion to the number of votes assigned to each of them. Unlike current representatives, you could reassign your vote as often as you want (hence "floating"), and, unlike current representatives, no voter is unrepresented (because there's no "winning" or "losing" candidates, only proxies.)
[This still has the same flaw. Someone can force you to surrender your key so they can manipulate your proxy.]
Hence my support for optical scan with the ability to hand-count.
Not disagreeing with that part. Except that the hand count should be the "official" count, and the optical scan just the election-night "indicator".
Security through obscurity might work for something like a power plant control system because we don't know the architecture of the hardware that it runs on, the operating system or if there is a third-party OS, the language it's written in, or even its name, and given the importance of the application it probably wouldn't be permanently Internet-connected, and if it needs to send out notifications it might communicate through a unidirectional RS232 link or something along those lines, or through a transmit-only fiber link (so that there's not even receive hardware on the platform).
Power companies don't develop bespoke security on their control systems (and would likely suck if they did). A particular power system most likely use off-the-shelf 1970s or '80s Siemens systems whose specs are widely known through the industry because of the decades of technicians who have worked on them.
For example: http://www.wired.com/2013/10/ics/
Security through obscurity doesn't work because it relies on the security of your obscurity, and most of the time your obscurity is weak. Key-based crypto systems are a form of security through obscurity, the obscurity is your key. But you have a reasonable ability to control the key, if they are issued per-person/per-session/etc. A key crypto system becomes useless if the key is distributed to multiple people, because you've breached the security of your obscurity. OTOH, the back-end system for the key-crypto cannot be obscure because someone other than the individual user had to develop it, install it, maintain it, operate it, etc. The same is true of the power station example, since there must be thousands of people trained to maintain such systems, plus all the developers/etc at Siemens, plus any rival company who's reverse engineered a Siemens system to develop "compatible" systems, plus... In the case of a voting system, you've got all the system devs, all the system maints, all the people who have access to the secret Trust Me computer when it's in use, all the people who have access to the secret Trust Me computer when it's not in use, etc. Your obscurity is inherently insecure.
But in the case of voting (or vote counting, in this case), we don't want security through obscurity specifically because obscurity is a known risk in voting systems. We want security through multiple independent observation of the entire process, the more observers the better. A vote count that is carried out entirely within a piece of code on a computer is, by definition, no matter how secure and air-gapped and guarded that computer, unable to be observed by independent observers. It lacks the fundamental requirement of being verifiable.
That's why you can't beat a hand count.
[If they want to put the count on a computer, then every piece of data (in this case, the preference information on individual ballots) should be put on-line - in addition to the hand count. That way, hundreds of independent, 3rd party systems can do a quick electronic count, not just the AEC's secret Trust Me box. (Parties, NGOs, media networks, university politics professors, university statistics students, etc.) Likewise, during the data entry process by AEC officials, on-site observers watching over their shoulders would be able to, would be encouraged to, enter each ballot into their own separate (tablet/laptop-based) systems. If the results of the later official hand count disagrees wildly with the majority of 3rd party systems, it's cause for panic/re-count/inquiries. If a few 3rd party systems get different results from the majority, there's probably a flaw in those. In net, you end up with multiple, overlapping, self-reinforcing and completely open counting systems that assures everyone of the integrity of the system and which gets stronger over time, while at the same time giving the advantage of faster (electronic) results.]
Or I just misread it. D'oh.
True, but I think old Doc Barnowl actually just out a word.
II) It's easier to mess with than paper ballots,
They don't understand how it works, therefore they're afraid of it.
That also applies to 90% of the comments in this post. (Or indeed, 90% of comments on Slashdot, full stop.)
That's also probably a better justification for opening source code and design documentation than the usual "obscurity != security" nerd rage. There's less to fear when the lights are on.
The problem with printing out each vote on site becomes apparent when you look at the history of machine voting. Even punch-card machines (the completely non-electronic punch tables themselves, not the subsequent reader) become unusable during elections because of poor maintenance, lack of cleaning, age, bad design, etc.
With pre-printed forms, you know they are all correct (or all wrong) before the election. With on-site printing, the printers can run out of ink or paper, or jam, or smudge. And that prevents votes from being recorded, which creates delays and long lines, both causing voters to give up. By selectively assigning resources to preferred precincts, and away from undesired precincts, the ruling party can (and do!) target such interruptions to alter the result. You're adding an extra layer of shit to go wrong, and hence be manipulated to go wrong.
Pencil, paper, hand count.
Anything else is more trouble than it's worth. People over-think things.
I firmly believe that all electronic voting machines should have full source code released and receipts that should be printed and signed by the voter and placed in a box next to the machine in case of recounts or verification questions.
The system in the article is about counting the pieces of paper we manually write our votes on, because we use a preference voting system (instant run off), if your #1 candidate gets eliminated, your vote gets reassigned to your #2 candidate. In the Senate, there's also a seat-quota system, where preferences simultaneously flow "down" as well as "up", so it's difficult to give the quick result that everyone wants on election night.
The AEC trialled actual electronic voting in one Australian territory, ACT, because it has an even more complex preference system (Hare-Clark).
Here's the source code for the ACT machines: http://www.elections.act.gov.au/__data/assets/file/0004/8185/evacs2012.zip Linux-only.
If you have a power failure so complete you lost every instrument
"Instruments" are on independent systems to the "controls". There have been examples of ac losing the instruments but having functional controls. (Or losing some of the controls, but retaining sufficient backups to control the aircraft.) Indeed, one of the procedures in the event of fire is to pop the breakers for all but a handful of instruments (it doesn't kill your controls), to try to isolate the fire-causing electrical fault.
If you have a single display set-up that combines your camera view and your instrument display, you could lose the entire display system while retaining flight controls. So you're sitting in a darkened sealed room in an otherwise perfectly flyable ac, because one system failed.
[That said, having external cameras for the pilots would be useful. And internal ones. Being able to see the engines, the rudder or ailerons, the landing gear, inside the cargo-bay or cabin. Thermals too. And long range, low-light/IR, forward cameras. This would also give you 20 years of data on the failure rate of imaging systems before some idiot designer blacks out the cockpit.]
Think of all those space capsules that don't have a windshield.
Every capsule had view-ports for navigation, at the insistence of the astronauts. Came in handy during Apollo 13 when they lost power for the guidance computer (and everything else.)
"Hi, welcome to MIT Tech Review. You've never read our site before, you probably know nothing about our site since you followed a link from an aggregator, and we're blocking you from reading the site now via this pop-over. WOULD YOU LIKE TO SUBSCRIBE?!?!?!?!?!"
No.
To the best of my knowledge, no.
Who is stealing when scalping?
The vendors set their price, the scalper pays them the full price they ask, then merely resells for a higher price. If the vendor set the price too low, in numbers too low, the market corrects for it.
but that is not even remotely Occulus' intention here. They have a limited supply but want to keep the price low to stimulate development.
Except they are not targeting devs. They are just selling a limited number of devices too cheaply. That neither targets devs nor provides development funds for themselves. There's nothing about selling-low that prevents "rich folks" buying a toy. Essentially whether a dev, a rich toy buyer or a tech collector gets a unit is a matter of first-come-first-served.
Other than shutting off an entire region (which cuts off Chinese devs as much as it does "scalpers") they are just selling alpha versions to anyone who will pay.
[Sounds like your Eve team suffered the tragedy of the commons. Your manufacturers wanted to be part of a team for their benefit, preferentially profited from that membership compared to other members, but didn't want to pay proportionally more to defend the team. This is why real world "teams" end up with governments and taxes.]
The value of the Oculus brand is greater the more developers they can snag to work on/with their product, and so the more developers that get their hands on the devkit the better for Oculus.
That isn't consistent with them selling the units. The moment you charge money you are just selling them. If you are selling them, you can't argue you're trying to target devs. (And if the units are worth more second hand than new, you are clearly charging too little.)
They are limited in how many devkits they can build however and so it is important to Oculus that every single one that they make goes to an actual developer
Then they shouldn't be selling them to anyone who orders one. They should be lending units to their preferred developers on an invitation-only basis. They can then put any conditions they want in the loan agreement (such as a large penalty for any unit not returned, to prevent (or at least discourage) them being sold.)
Since being purchased by Facebook, they have much less need for new cash to fund their ongoing development, so that isn't an excuse. When they were independent, cash was an issue, in which case selling "dev" units for less than market demand price is just robbing themselves of money they could use to pay for the second batch or second version.
Re: ticket scalpers.
That "problem" was solved years/decades ago. Event ticket sales were limited to a certain number per customer
That's not a solution. That's just a pig-headed attempt to preserve the flaws of the existing system.
A solution would be to sell the tickets at the highest price people are willing to pay, at the number the vendor wants to offer. The easiest way to do that is to use auction systems. If people are paying what they are willing to pay, there's no profit margin for scalpers to resell. And if people are willing to pay more than the vendor expected, that extra profit goes to the vendor, not resellers/scalpers. If people are only willing to pay less, at least it guarantees the venue is full, which may still allow them to cover costs avoiding cancelling shows. (If demand is high enough, ie number of bids above an arbitrary price, the vendor might be able to book a larger venue. If it's low, they might be able to drop to a smaller (cheaper) venue, keeping the sense of "full house" for the atmosphere, plus increasing the intimacy of the show. Much better than a half empty venue. Such decisions could be built into the auction system to trigger automagically.) This system would also allow last-minute sales of the block of tickets held for the celebrity guest list (who often don't show.)
As I said elsewhere, there's no such thing as scalping. Only stupid vendors.
[If you are concerned about pricing certain people out of the market, you could offer a portion of the tickets on a lottery basis. Say limited to members of the local fan-club. Just as you offer "prize" tickets to radio-stations as part of your promotion.]
the oculus rift2 devkit
Mark said nothing to suggest he's confused about it being a devkit. Just that you can limit "scalping" by not allowing multiple sales. Any individual resales beyond that is irrelevant.
I'd go further, there's no such as scalping. If someone can resell an item at higher than your retail price, you failed to price or supply your product properly. The error is yours, not the "scalper's".
[In my state, there are specific laws that protect resellers. Preventing "one per customer" restrictions precisely for that reason. Many major retailers hate that law because it prevents them from using "loss leaders" to drive smaller rivals out of business.]
but it is not released to the public yet!
If you are selling a dev version, then you are retailing a product to the public. Again, if there is more demand at a higher price than you are supplying either quantity/price, the error is the vendor's, not the "scalper's".
you need to be on the jury.
Even if this story was about using the dog's response to establish probable cause for a search, any assessment of the validity of that probable cause is done during the preliminary stages of the trial, before the jury is called in. The jury is then merely instructed that the search was valid. It's incredibly rare that a jury is allowed to assess the validity of evidence gathering, or even told that the defence raised any issue at all.
You STILL don't get nine. You either settle for the current eight, or you will, eventually, have hundreds, at least.
Not necessarily. If you make the definition of "planet" as wide as possible, you can then create (non-exclusive, overlapping) sub-categories for different classes. Terrestrial, gas-giant, dwarfs, KBOs, super-Jupiter, hot-Jupters, hot-Earths, super-Earths, rogue (or free flying) planets, etc.
And, of course, then you can have "Traditional Planets", which is the nine.
Everyone gets a toy, everyone goes home happy.
[Except I'd make the definition wide enough to include large moons (eg, "non-stellar bodies over 500km diameter and/or hydrodynamically spherised"), then "major moons" would be one of the sub-categories of "planet", which would piss off the sort of people twisting their knickers over Pluto.]
You do realize that pretty much everyone at NASA who actually designed a rocket or rocket engine has now retired, right?
"and whose designers are all in nursing homes."
I don't understand the criticism regarding ...
Basically, they are repeated all the old mistakes of Shuttle and ISS. Single unaffordable top-down designs, expensive sole-source cost-plus contracts, convoluted designs more intended to feed the contractor networks in Congressional districts than to deliver improved hardware, flubbery half-hearted missions that mutate to fit the rapidly contracting hardware abilities rather than hardware designed for missions. And because everything is so expensive and poorly planned, development has to be smeared out over decades, giving time for endless Congressional budget games with the attendant schedule and cost blow-outs, and design compromises piled on top of design compromises just to get something launched.
Paraphrasing Gen. Augustine, in the analysis over Constellation (SLS's precursor), "If someone handed it to NASA, already build and paid for, NASA still couldn't afford to operate it."
Falcon 9 has a payload capicity of 13,150 Kg to LEO.
He said "Falcon 9 Heavy" (the original name of the Falcon Heavy). So 50,000kg to LEO, should fly in the next year or two, and cost less than $100m per launch (say $150m with a "NASA paperwork tax".)
SLS is to have a payload capacity of 130,000 Kg to LEO.
SLS Block "zero" will lift around 60,000kg, and may fly in 2017 or 2018. Development will have cost $10-12 billion from now 'til then. It won't be able to lift Orion (which won't be ready anyway).
Block I is meant to loft 70,000 kg to LEO, flying in 2021 at the earliest. Development will have cost $21 billion from now 'til then. It will be able to lift Orion, but only for 14 day missions around the moon and back.
Block IA is meant to lift 105,000kg, some time in the mid-2020's. And Block II, the one you are talking about, with 130,000kg to LEO, by 2032. Development will have cost over $50 billion from now 'til then.
That doesn't include any other hardware, nor any launch or mission costs. Just development.