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.

More than a few are also essentially pesticides. Both the V and G series organophosphate nerve agents were discovered in the course of pesticide research, and VG was even sold for agricultural use for a time, before the safety issues became apparent.

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.

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.

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.

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.

Just ask the Holy Spirit, he's consubstantial with both the Son and the Father; despite begetting the son(yet not being the father).

Indeed. It's an adequate enough conductor that plating something with gold won't ruin its conductivity(at least not as badly as a layer of tarnish/oxidation will), and it's good enough to use for wirebonding in chip packaging; but it's merely adequate. Corrosion resistance and extreme ductility are the really neat tricks.

I would have liked to; but(thankfully) I wasn't on the procurement side in the case of that particular job(given the nightmare that was our PO system, I am most grateful). Ultimately pragmatism won out over principle and(for the small subset of affected users) we got some $5 c-media USB sound cards, which proceeded to work perfectly regardless of CPU frequency.

It was one of those situations where the villains skated free; but the number of hours it would have taken on the phone, fighting it out between the vendor of the software that most notably exposed the problem, the PC OEM, the maker of the onboard sound device, and possibly Microsoft, just would have been hell. Not the desired outcome; but the slog to get something better probably would have cost more than entire new systems, never mind new soundcards.

For me, it was mostly a wake-up call about how bloody awful some peripherals and peripheral drivers still are, and how long assumptions that were recognized as dangerous and hacky back when 8MHz was a respectable CPU clock can stick around. Not a pleasant learning experience; but not all are. Somewhat amusing troubleshooting, though. You don't usually expect 100% CPU load to make audio playback better.

SLC is too rich for my blood, so I don't really have the luxury of comparison; but (just as a mixture of RAID and backups has proven cheaper than absolutely bulletproof engineering in HDDs), it wouldn't entirely surprise me if MLC's cost advantage, combined with ongoing improvements in masking its deficiencies, ultimately relegate SLC to relatively niche applications that don't have space for lots of redundancy; but do have the budget for classy hardware. (After all, just look at how well NOR flash's superiority over NAND flash has...mostly not saved it... from being replaced by stacks of cheap NAND behind a controller designed to make it looks like it doesn't suck as much as it does).

I'd be the last to deny that SLC is, in fact, objectively better; but you can buy so much MLC for the price of a given amount of SLC that, given decent controller design, there tends to be room for nontrivial redundancy and greater usable capacity. I can see why it offends purists; but practically all computer equipment today is the direct descendant of inferior crap that beat beautifully engineered and overtly superior systems on price.

My concern is less about that than about the possibility that(if any judge from any district will do) the tendency of the judiciary to rubber-stamp warrants will be markedly increased.

If the FBI has to deal with Judge X, Y, or Z; because they are in district 61, it is at least possible that they'll have to put together a convincing warrant request, lest it be denied. If they can pick any federal district judge, it won't exactly be a big secret which judge you want to talk to if you need some utter bullshit approved.

When it is the job of the judiciary to be at least skeptical, if not somewhat adversarial, when law enforcement comes knocking with a request to go break into something looking for evidence, increasing the pool of candidates for an "If you won't, someone else will." approach to getting a warrant approved really isn't much of a virtue.

Maybe they could turn it around, they at least have enough assets to burn to give them some time; but I'd be a little pessimistic about Sony just because they don't seem to have a clue when it comes to software. Some of the products from their glory days definitely have some firmware burned into them, so it's not as though they are utterly incapable of writing any kind of code; but UI/UX and user-facing software are more or less uniformly horrific on Sony products. Unfortunately for them, that's increasingly the part of the product that isn't entirely commodified, and where there is a real difference between companies.

It's somewhat like watching Nintendo try to comprehend what happened to the console market, now that "Having online services that actually works" has become something of a requirement.

They don't directly generate any sound(unlike systems, like CPU/GPU power supply circuitry, that have enough magnetics to really whine under the right load); but basically any digital bus puts out some EMI(not the litigious one, the noisy one) so if your audio player hardware is total shit the analog signal lines may pick some up and feed it into the amp, producing a variety of deeply unpleasant effects.

The root problem in such a case is that the analog lines for the sound output are grossly under-isolated from the rest of the system(and it's likely that one or more other high speed digital busses are scribbling on them) so trying to solve the problem with fancy SD cards is a bit of a waste; but electrical noise seeping into the audio output is certainly a real thing, especially on lousy gear with space and cost constraints.

Given how ghastly things can get if you try to use a really terrible SD card to do an SSD's job(eg. find the cheapest thing that a camera won't spit out in horror, and then write a liveCD image to it and see how much fun you have), I can understand Sony's desire to guarantee a minimum performance level for an expansion card that they knew would be doing almost nothing but storing executables and art assets.

What is inexcusable is the fact that they decided to spin an entirely new format for that purpose, rather than just telling people that "If you don't use one of these, blessed, microSD cards, on your own head be it if the games stutter".

Assuming that they aren't simply lying(sometimes a safe assumption...sometimes not so much) "Class 2", "Class 4", "Class 6", and "Class 10" are supposed to be guarantees of 2, 4, 6, and 10 MB/s minimum write speed, respectively, while UHS1 is supposed to be 10MB/s with support for UHS bus operation, and U3 is supposed to be 30MB/s with support for UHS-II bus operation.

How they store bits, internally, is not specified; but minimum write speed is obviously fairly important to people shooting video or enough large still images, quickly enough, that dumping them to flash can be a bottleneck. Unfortunately, despite the increasingly common case of SD/MMC-bus connected devices being used in situations where read performance matters as well(eg. storing programs in cellphones, being rPi root filesystems) standards for testing and labeling read speed, random I/O performance, and similar SSD-enthusiast stats are more or less nonexistent.

As bulk storage for music files, a Class 4 is likely to do just fine( even golden-ears FLAC is what, 5-6 megabytes/minute?); but unless the stickers are pure lies, a Class 10 is likely to be a rather nicer card.