Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Feasibility of exploiting real instruments? (Score 1) 147

by fuzzyfuzzyfungus (#49149331) Attached to: Can the Guitar Games Market Be Resurrected?
If you have a large enough market, the simplicity and repeatability of dedicated controllers with buttons chosen precisely for your game's design and so on is attractive.

If you don't, you run into the problem that low volume production of such gear isn't going to make the price point any more attractive, and it's fairly bulky and expensive for something you can only play a few games with.

Anyone know what the feasibility might be of, instead, of taking advantage of what is already available? For mics, the attempt to make voice control a fad left a fair number of consoles already equipped with one, cellphones and tablets all have them and support wired or wireless headsets, and USB mics of unexceptional quality cover everyone else for not much money. On the guitar side, probably-awful 'beginner' units are $60-80(probably less if you get one used after buyer's remorse claims the original victim), and essentially any electric guitar will support putting out a low-level signal into a 1/4inch jack. If a device already has a line in, a simple mechanical adapter will do, if not, cables that are a USB audio-in on one end, 1/4inch jack on the other are quite cheap. Once you had that, your game could presumably crunch the guitar's output and (depending on how much 'game' and how much 'learning tool' you want) do anything from treating a few large contact areas as 'buttons' to actually grading you on the degree to which your results match the correct output.

I doubt that, if the user needs to purchase everything, particularly new, you could beat the package cost of a mass-produced controller pack; but if you don't think that you have the volume for a suitable production run of instrument-controllers, it seems like an approach that has very low marginal cost and can work with more or less any instrument floating around in the wild, might be less risky and more approachable.

Comment: Always a cheaper fish... (Score 2) 82

by fuzzyfuzzyfungus (#49146395) Attached to: Microsoft Closing Two Phone Factories In China
Given that China has historically been the nominally-communist-but-attractively-cheap-and-open-for-business destination, they can't be entirely surprised that Vietnam is now cutting into their action.

That aside, though, I wonder if this is more or less purely cost focused, or whether the quasi-mercantalist Chinese government policies aimed at aiding domestic firms and speeding up acquisition of foreign firms' tech has a bigger role? They aren't necessarily irrational, given that competing on price and low environmental standards isn't exactly a fun game, even when you are winning it; but such policies presumably do encourage foreign firms to head for the exit more quickly at the same time as they reduce the impact of their doing so.

Comment: Re:Pesticides for humans (Score 1) 224

by fuzzyfuzzyfungus (#49125975) Attached to: 100 Years of Chemical Weapons
The other problem with chlorine is that it's among the cheaper ways of bringing a semblance of sanitation to a municipal water supply.

Really classy first-world jurisdictions can use Ozone systems(which have the advantage of basically perfect decomposition into harmless oxygen by the time the water reaches customers, and need only electricity and occasional spare parts at the treatment plant, rather than big tanks of chlorine); but anywhere else is probably chlorinating the fecal bacteria out of the water supply, which saves a ton of lives(especially if the medical system is lousy); but also means that chlorine is basically just sitting around.

We ran into that issue in Iraq from time to time. Chlorine is a really lousy war gas, barely toxic enough to count as one at all; but just sending a couple guys with guns and a truck down to the water treatment plant could score you enough of the stuff to release in the nearest crowded area for some reliable freaking out and some casualties.

Comment: Re:Pesticides for humans (Score 1) 224

by fuzzyfuzzyfungus (#49125949) Attached to: 100 Years of Chemical Weapons
I'm no industrial process chemist, so I don't know how different the factories look; but my understanding is that that is part of why the lists of scheduled chemicals, and the multiple schedules, for the Chemical Weapons Convention, are as messy as they are. There are some that we've decided nobody has any legitimate reason to be playing with; but loads of dual-use chemicals.

Comment: Re:Pesticides for humans (Score 1) 224

by fuzzyfuzzyfungus (#49125939) Attached to: 100 Years of Chemical Weapons
The history gets a little muddled because different classes of chemicals were developed with different primary purposes at different times.

Various primitive fumigants (burning sulfur, various other 'noxious smoke' type stuff) date back approximately forever, and have been used to discourage pests; and also 'discourage' the guys digging a tunnel under your castle; but are pretty tepid war gasses in the open, more suffocating than overtly toxic.

Some of the WWI war gasses were substantially tailored for effect on humans(or, even where previously known, like Chlorine, pretty expensive and annoying to deal with as agricultural agents), though at least the arsenicals also overlapped with pesticide developments.

Nerve agents started as pesticide research(and to this day, the lesser organophosphates are used for the purpose); but(thanks to lousy benchtop practice that nearly killed a few of the scientists involved) it became clear that the peppier flavors were also...eminently suitable...for getting rid of large mammalian pests. Thankfully, in WWII, the Germans overestimated allied knowledge of nerve agents, based on a misreading of the patent literature, and didn't want to risk reprisal. Had this not been the case, V-2s full of sarin would have been technologically feasible, which would have really ruined some days.

Comment: Re:How's this any different... (Score 1) 114

by fuzzyfuzzyfungus (#49125923) Attached to: Lenovo Hit With Lawsuit Over Superfish Adware
There's also the basic difference that 'enterprise' MiTM-ing is potentially kind of a dick move, depending on exactly how hard HQ feels like squeezing somebody's innocent checking of their email over lunch or whatever; but it's a fairly clear exercise of control over hardware by that hardware's owner.

Seeding hardware with malware and then selling it? Not so much. Yeah, maybe there is some nonsense clickwrap EULA; but there is no real consent of any kind, or even a proper warning.

If only for your own sake(having your own employees getting fooled because your MiTM proxy re-signs bogus certs without flagging them would be counterproductive) odds are that 'enterprise' systems are also more competent; but even if they aren't it's a pretty major difference in scope.

In my own admin-ly capacity, playing content cop is something I do reluctantly, and only as much as network security requires; but we never tamper with devices we don't own(deny them access to the network, sure, touch them, never) and staff are proactively warned and welcome to ask in more detail, if they wish, about what we do and why we do it.

Comment: Re:No no! (Score 1) 95

by fuzzyfuzzyfungus (#49118013) Attached to: Advertising Tool PrivDog Compromises HTTPS Security
It's quite possible; but there definitely are web types(and, even more so, their 'content provider' masters) who think exactly this, so I was willing to take the risk.

Pretty much this exact attitude is why the "Encrypted Media Extension" 'spec' exists, to provide something that qualifies as 'HTML 5' (Don't call it a plugin! It's a 'Content Decryption Module' that just happens to be operationally identical to or worse than a plugin!); but allows the site operator full control over execution.

Comment: Re:No no! (Score 1) 95

by fuzzyfuzzyfungus (#49117583) Attached to: Advertising Tool PrivDog Compromises HTTPS Security

Excuse me, but I am a (web) developer! I have a right to run whatever code I want on your computer if you visit my site. You don't have the right to edit my code!

Pernicious nonsense. If you elect to put some mixture of code, markup, and art assets on a public webserver my user agent will handle the results as much in accordance with my desires as I can make it do so.

This is how the 'web' has always been supposed to work: support for flexible rendering and fallback to accommodate a variety of user agents with different characteristics and capabilities is built in(although often underused, unless one forces the issue). Were it designed to be all about you, the arrangement would be much more along the lines of a relatively rigid page description language(PDF style, say) and a more robust VM for you to do whatever you want in(like the late and largely unlamented Java Applet).

Yes, unfortunately, nothing short of fire and sword will rid us of people who want the internet to be more like TV; but a web developer claiming that the user agent must take it and like it is about the same as a writer or publisher saying that highlighting sections of a book, or cutting a magazine apart, are copyright infringement. Stuff it.

Comment: Re:How's this any different... (Score 4, Informative) 114

by fuzzyfuzzyfungus (#49113871) Attached to: Lenovo Hit With Lawsuit Over Superfish Adware
This fine bloatware didn't merely act as an MiTM, it do so so incompetently that it exposed the user to basically any MiTM attack on an SSL connection(the root cert it used to sign bogus certificates was identical across every installation and effectively unprotected and the MiTM component would re-sign any cert handed to it, even an invalid one, opening the user to downright trivial MiTM attacks.

Even if the actual behavior of the bloatware were downright saintly(which is not the case) it was so incompetently constructed as to be indistinguishable from malice.

Comment: Re:even more interesting (Score 1) 155

by fuzzyfuzzyfungus (#49112795) Attached to: NSA, GHCQ Implicated In SIM Encryption Hack
I think that it depends on how the keying is handled, and what role the smartcard plays.

As best I've been able to tell from what articles I've read, the NSA and friends were snarfing the Kis as they were sent from telcos ordering SIMs to Gemalto, where they were burned in. They may have some other program aimed at bugging the silicon or firmware of the smartcard ICs themselves, which would be a different problem; but according to what we know of this attack, it would not affect smartcards that are used to generate their own private key, onboard, or provisioned by the customer, after delivery, just the ones provisioned by Gemalto on behalf of the customer.

That's a very large number of affected units, of course; but (barring disclosure of further nasty tricks) it isn't an attack on the actual function of the smartcard, just on a weak link in the production process for preconfigured smartcards.

Comment: Re:Corruption == Treason (Score 2) 155

by fuzzyfuzzyfungus (#49112715) Attached to: NSA, GHCQ Implicated In SIM Encryption Hack
As much as I agree that white collar criminals and spooks are tragically under-executed, and would love to change that, the US constitution (very wisely) includes a comparatively precise and narrow definition of 'treason'. Our 'founding fathers' included some fairly shitty people; but they were mostly shitty people who knew a thing or two about how governments go bad, and that 'treason' is a...delightfully elastic...charge. Thus, they did their best to ensure that it wouldn't be one here.

There are plenty of other things that they should probably be judged guilty of, and which should probably be capital offenses; but 'treason' is something that you just shouldn't throw around lightly.

Comment: Re:Fallout? (Score 1) 155

by fuzzyfuzzyfungus (#49112679) Attached to: NSA, GHCQ Implicated In SIM Encryption Hack
I would certainly lay the blame at the feet of the NSA and friends; but such attacks should also be used to refine processes to make them more resistant to such attacks in the future.

In the case of this SIM hacking, it appears that the current model involves Kis being transmitted(mostly insecurely) to Gemalto and then burned in. This is an obvious weakness compared to having the high-value keying material generated on-SIM and never leaving, ever, short of a direct attack on the chip. Doesn't mean that the feds shouldn't be nailed to the wall(they should); but it is also a useful lesson in what part of the process to harden if we want to be more resistant next time, whether to feds, sophisticated criminals, or others.

Comment: Re:Fallout? (Score 3, Insightful) 155

by fuzzyfuzzyfungus (#49112641) Attached to: NSA, GHCQ Implicated In SIM Encryption Hack
Some mixture of pragmatism and the victim blaming, I imagine.

Given that, operationally speaking, the NSA and GHCQ, and friends, are above the law(where it hasn't been modified to simply make what they do legal, because it's them doing it); your only real option is to start assessing providers of security-critical products and services according to the "Were a dangerously out-of-control clandestine entity to come knocking, would you be fucked or really fucked?" standard.

It is obviously Bad that you need to ask that question; but, since you do, you at least want the answer to be reassuring. Given that, according to what we know so far, the production process for SIMs involved Gemalto burning (insecurely transmitted) Kis in, at the factory, it looks like the production process is dangerously weak against tampering. As with the RSA seed storage/hack fiasco, it looks like that is going to have to change, with the vital secrets either stored a lot more carefully, or, ideally, generated on-SIM and never leaving the SIM during its operational life, short of a direct silicon-level attack.

fortune: cpu time/usefulness ratio too high -- core dumped.