/proc/cpuinfo doesn't show it, presumably because no kernel support is needed at all for this feature. (And that's why, if this is indeed a privilege escalation issue, it won't be easily fixed with a kernel change.)
Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.
This seems unlikely to me. I'd expect that the patch will clear the cpuid bit for TSX and cause #UD (undefined opcode) on XBEGIN, etc.
Buying an R7000 is a waste of money. The whole "AC1900" class is a joke -- they squeeze out the extra Mbps by supporting a nonstandard, Broadcom-only modulation in the 2.4 GHz band. Good luck finding any client devices that can use that modulation.
Stick with AC1750 and stop feeding the marketing trolls.
The TP-Link Archer C7 v2 is pretty mature. The v1 is discontinued, and most US-based vendors are now explicitly advertising v2 hardware.
The only real caveat is that the open-source ath10k support is very slightly flaky -- you may have intermittent issues if you have a Macbook Pro. This will probabaly be fixed soon.
This is incorrect. You can't build a passive device that is 100% transmissive from one side and 100% reflective on the other side.
You can, however (in theory), build a device that with these properties:
Light from side A is transmitted and comes out side B
Light from side B is absorbed and turns into heat
Absorbed heat is re-radiated, mostly from side A
This thing will be non-reciprocal. I've never heard of anyone building one that looks like a sheet of glass, but they're common for microwaves -- they're called circulators. There's a reason that this new contraption is called an acoustic circulator. The only misleading part is that one-way glass is reciprocal -- this new thing is much more impressive than one-way glass.
Here is what I personally don't get and since I'm not a crypto guy maybe I'm missing something but here goes...it looks like all these attacks come from using a RNG that has been rigged to be less than random, but why use their RNG when there are so many sources of randomness in the world?
There is the background radiation of the universe for starters, and how many webcams are freely accessible in heavily trafficked public places? It shouldn't be hard to write a program that does a quick head count, multiple that by the dollar amount of the biggest box office draw last week. How many letters is in headlines of the top 60 newspapers on the planet? Multiple that by the amount of temp detected by 30 weather stations and divide by the number of folks who went to see the fourth most popular movie yesterday squared by the ratings of the most popular reality show.
You can do things like this (with a little bit more care) to generate numbers that can't be predicted in advance. Unfortunately, that's not the point. Web servers need random numbers that can't be guessed or manipulated by anyone, and they need to generate lots of them. If everyone generated the same random numbers (because they looked at the same webcams), then those numbers aren't useful for cryptography.
Except that RSA destroyed their whole business a couple of years ago when it was found that they'd left the root keys for their SecureID tokens on an unsecured, network-connected machine. After that no one could trust them again.
RSA lost my trust when I found out that root keys or critical secrets for the SecureID system existed in the first place.
If they designed the system well, they would make physical tokens and deliver the tokens and the keys for those tokens to the clients. They would not keep any record whatsoever of those keys, nor would they have a way to reconstruct them
As a physical analogy, a locksmith making safety deposit box keys should make a random key and not write down the key code
Before the battery replacement, the car lost 3.5kWh/day. After the replacement, it lost 1.1kWh/day. That's a difference of 2.4kWh/day, which is 100W. That's something like 8 Amps internally leaking in the 12V battery. That seems shockingly high.
Or maybe there's something else going on. If the battery was marginal, then perhaps the car's DC-DC converter was continually "charging" it but actually overcharging it. Then it would be electrolyzing 8A worth of water and battery acid. I expect that would make a giant mess.
Alternatively, it just keeps running the DC-DC converter at very low output. The DC-DC converter could be incredibly inefficient when producing just a little bit of current (Tesla is reputed to use a huge (~200A) DC-DC converter, so the thing could be running at about 1% of rated output at, say, 10% efficiency).
A class action lawsuit for gross negligence might do the trick.
Sometimes I think that things like this should be felonies, though. Criminal offense or not, in a sensible world this would put alphanetworks out of business.
These people should be using a real time Java VM and an ahead of time compiler for those parts.
It means you can skip the warm up. The only problem with it is you can't hire regular Java guys - real time Java is a little bit special, and you can't use regular Java collections and other things in the ways you'd expect.
That's not the only problem. Doing this switches you from using a well-standardized, well-supported language to a nonstandard subset. This removes a lot of the advantages of Java.
One of the most technically competent exchanges I work with is trying out Azul, which is (AFAIK) the top-of-the-line low-latency JVM. I was a bit surprised to learn that their software didn't Just Work. In fact, it didn't work at all. So now they have to decide which AOT-compiling JVM to run and figure out how to support it. I suppose that Excelsior and gcj (eek!) would be other options.
My main point here is that, when low latency is involved, a lot of people cite the existence of high-quality real-time JVMs as evidence that Java is a good choice. These JVMs exist, but they are by no means panaceas, and users of Java for real-time or low-latency work will need to make a real technical and monetary investment in dealing with them. Hotspot is not (yet?) appropriate for this kind of thing. Oddly,.NET seems be in better shape here, at least in terms of AOT compilation.
I'm not a Java user, so I've never directly tuned for things like GC, nor do I interact with it directly. Warm up is a different story.
I interact with quite a few exchanges (over all kinds of protocols). Most are, unsurprisingly, written in Java. Almost all of them perform terribly at the beginning of the week. The issue is a standard one: the JVM hasn't JITted important code paths, and it won't until several thousand requests come in. For a standard throughput-oriented program, this doesn't matter -- the total time wasted running interpreted code is small. For a low-latency network service, it's a different story entirely: all of this wasted time happens exactly when it matters.
The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.
If JVMs some day allow you to export a profile of what code is hot and re-import it at startup, this problem may be solved. Until then, low-latency programmers should weigh the faster development time of Java with the time spent trying to solve annoying problems like warm-up.
No, because the summary is (as usual) thoroughly overstated. This experiment, like any other form of quantum state tomography lets you take a lot of identical quantum systems and characterize them. For it to work, you need a source of identical quantum states.
As a really simple example, take a polarized light source and a polarizer (e.g. a good pair of sunglasses). Rotate the polarizer and you can easily figure out which way the light is polarized. This is neither surprising nor a big deal -- there are lots of identically polarized photons, so the usual uncertainty constraints don't apply.
The whole point of QKD (the BB84 and similar protocols) is that you send exactly one photon with the relevant state. One copy = no tomography.
First, keeping the voltage on requires power, which drives up the energy consumption of the microchip.
Barely. Almost every digital chip out there uses CMOS logic. The whole point of CMOS logic is that, when the gates aren't switching, no current flows. That means that no power is drawn. In practice, a little bit of current leaks, but this is a small effect at all but the smallest process sizes.
It's not all clear from the abstract how the authors expect to maintain a magnetic field without any static power consumption. Perhaps using ferromagnets, but I wouldn't hold my breath -- MRAM still hasn't happened.
If you ignore all the weird DRM-ish uses (which are basically unsupported for now anyway [1]), the TPM makes a nice cryptographic token. Unfortunately, TPM v1.1 hard-coded the OAEP label to "TPM", which made it incompatible with everything. TPM v2.0 fixes this -- the label is now user-specified. That means that you can use it for modern hardware crypto (sadly, using SHA-1, which should be phased out).
I don't think this is a good fit for 802.11n. From the paper:
We assume that there is are [sic] random erasures within in the network.
802.11n aggregates frames. This means that (at least for throughput-limited flows) multiple packets will be transmitted at once, and they're likely to all be lost together. This won't help.
In any case, it makes sense for inherently lossy links to do their own FEC -- the end-to-end principle is not a good way to maximize capacity. But hacking around TCP like this seems silly -- just fix the problem at the link layer.
TFA does a good job of using units that are incomprehensible to anyone who isn't an expert in thermoelectrics. But we can convert them...
Considering a thermoelectric device with a cold-side temperature of 350K and a hot-side temperature of 950K, respective waste-heat conversion efficiencies of ~16.5% and ~20% are predicted.
For a hot-side temperature of 950 K and a cold-side temperature of 350 K, the Carnot efficiency (i.e. the maximum possible efficiency of any device) is ~63%. So this is somewhere between 1/4 and 1/3 as efficient as it could possibly be.
Large generators, such as combined cycle gas turbines are considerably more efficient, but these devices are small and silent. In other words: not bad.
It seems like the big vulneraibilites in mobile platforms these days involve apps doing things they shouldn't. Android is, for the most part, way ahead of Apple in terms of technical mitigations. Android sandboxes apps with explicit permission grants. Apple just vets them, incompletely. iOS also seems vulnerable to odd things, like this. Apparently executing unsigned code on iOS, if you can pull it off, sidesteps part of the sandbox. Android is based on the assumption that any app can execute unsigned code and it still tries to be secure.
I think it's a bit ridiculous, but not for these reasons.
(1) They suggest using very high temperatures, presumably to avoid exactly this issue.
(2) Not sure what you mean. She subtracts what from what? But see below.
(3) The authors propose adding low-pass filters for exactly this reason. They'll filter out high-frequency signals, leaving low-frequency components that have no effective time delay.
My attack would be for Eve to add a small probe signal -- she would insert a voltage source in the line, with a time-dependent (or even constant) voltage of her choice. She would then measure the correlation between the voltage she injects and the current in the wire. Alice and Bob are supposed to check for this by comparing the conditions on their ends of the wire with their expectation, but this assumes that they have measuring devices as good as Eve's.
The idea that the security is based on the second law of thermodynamics is, IMO, absurd. The second law says that a bunch of things that would decrease entropy are impossible. But Eve can do whatever she wants as long as she sinks enough entropy somewhere else -- Alice + Bob + the wire is not a closed system.
This is endorsed by Audi, BMW, Chrysler, Daimler, Ford, GM, Porsche and Volkswagen. Tesla is conspicuously missing. The Tesla Roadster and the Tesla Model S are the only electric cars in or near production that are close to road-trip worthy, so the omission is unfortunate.
There are several asymmetric protocols with very nice security properties, even against adversaries with quantum computers. My personal favorite is based on the Learning With Errors problem, which is in turn based on some lattice results. Wikipedia has a decent summary, and the original paper is here.
The old McEliece cryptosystem might be secure against quantum attack. NTRU is commercialized but its security bounds make me very nervous. There also systems based on elliptic curve isogenies, but a new quantum algorithm comes somewhat close to breaking them.
The main problem with these cryptosystems is that the resulting ciphertexts and signatures tend to be fairly long. RSA produces ciphertexts that are about the same length as the original messages and DSA produces nice, short signatures. ECC protocols are even better, but Shor's algorithm breaks them just as easily as RSA and DSA. The fancy post-quantum protocols, on the other hand, tend to produce large messages that are slow to work with.
What is this thing supposed to be? TFA is rather clear on the point that it's "a new type of laser". But it also says (as though it's obvious) that "the more power one puts into a laser accelerator, the more powerful and precise the light beam that comes out on the other end". I don't know exactly what a "laser accelerator" is, so I don't really know whether pumping more power in makes the other end more precise.
Of course, even if FoxNews.com can't explain how it works, it was a dramatic "supercharged electron beam that can burn through 20 feet of steel per second". Well, FoxNews.com, WTF is it? A laser or an electron beam? (Hint: a laser shoots light not electrons.)
I think it's really a Free-electron laser, in which you inject electrons into a tube and laser light comes out the other end. So TFA has it completely backwards.
I know that slashdotters automatically love anything involving making information more free, but...
I liked Wikileaks, too, until they published all the reports from the ground in Afghanistan. Up until then, at least the high-profile stuff revealed actual coverups of things that could be damaging because the fact that it happened was embarrassing or wrong. But the latest stuff? It's pretty much mundane, but it reveals important sources of information to American troops. Revealing that the troops have sources of information would be fine if completely unsurprising. But who benefits (other than the Taliban) from revealing their names?
C'mon, Wikileaks. Step up and act like real journalists. Think before you post. And if you fsck up, don't be surprised when people get pissed off.
Slashdot Mirror
The fix and half the quotes attributed to Linus were from me. Apparently people can't figure out who posted which GitHub comment.
If you have a recent version of the cpuid tool, you can run:
cpuid |grep RTM
and you'll see something like:
RTM: restricted transactional memory = false
RTM: restricted transactional memory = false
RTM: restricted transactional memory = false
RTM: restricted transactional memory = false
/proc/cpuinfo doesn't show it, presumably because no kernel support is needed at all for this feature. (And that's why, if this is indeed a privilege escalation issue, it won't be easily fixed with a kernel change.)
Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.
This seems unlikely to me. I'd expect that the patch will clear the cpuid bit for TSX and cause #UD (undefined opcode) on XBEGIN, etc.
Buying an R7000 is a waste of money. The whole "AC1900" class is a joke -- they squeeze out the extra Mbps by supporting a nonstandard, Broadcom-only modulation in the 2.4 GHz band. Good luck finding any client devices that can use that modulation.
Stick with AC1750 and stop feeding the marketing trolls.
The TP-Link Archer C7 v2 is pretty mature. The v1 is discontinued, and most US-based vendors are now explicitly advertising v2 hardware. The only real caveat is that the open-source ath10k support is very slightly flaky -- you may have intermittent issues if you have a Macbook Pro. This will probabaly be fixed soon.
Do you consider the TPM acceptable? I have sort-of-working but woefully incomplete code for this. There's also the work-in-progress OpenCryptoChip.
This is incorrect. You can't build a passive device that is 100% transmissive from one side and 100% reflective on the other side.
You can, however (in theory), build a device that with these properties:
This thing will be non-reciprocal. I've never heard of anyone building one that looks like a sheet of glass, but they're common for microwaves -- they're called circulators. There's a reason that this new contraption is called an acoustic circulator. The only misleading part is that one-way glass is reciprocal -- this new thing is much more impressive than one-way glass.
Here is what I personally don't get and since I'm not a crypto guy maybe I'm missing something but here goes...it looks like all these attacks come from using a RNG that has been rigged to be less than random, but why use their RNG when there are so many sources of randomness in the world?
There is the background radiation of the universe for starters, and how many webcams are freely accessible in heavily trafficked public places? It shouldn't be hard to write a program that does a quick head count, multiple that by the dollar amount of the biggest box office draw last week. How many letters is in headlines of the top 60 newspapers on the planet? Multiple that by the amount of temp detected by 30 weather stations and divide by the number of folks who went to see the fourth most popular movie yesterday squared by the ratings of the most popular reality show.
You can do things like this (with a little bit more care) to generate numbers that can't be predicted in advance. Unfortunately, that's not the point. Web servers need random numbers that can't be guessed or manipulated by anyone, and they need to generate lots of them. If everyone generated the same random numbers (because they looked at the same webcams), then those numbers aren't useful for cryptography.
Except that RSA destroyed their whole business a couple of years ago when it was found that they'd left the root keys for their SecureID tokens on an unsecured, network-connected machine. After that no one could trust them again.
RSA lost my trust when I found out that root keys or critical secrets for the SecureID system existed in the first place.
If they designed the system well, they would make physical tokens and deliver the tokens and the keys for those tokens to the clients. They would not keep any record whatsoever of those keys, nor would they have a way to reconstruct them
As a physical analogy, a locksmith making safety deposit box keys should make a random key and not write down the key code
Before the battery replacement, the car lost 3.5kWh/day. After the replacement, it lost 1.1kWh/day. That's a difference of 2.4kWh/day, which is 100W. That's something like 8 Amps internally leaking in the 12V battery. That seems shockingly high. Or maybe there's something else going on. If the battery was marginal, then perhaps the car's DC-DC converter was continually "charging" it but actually overcharging it. Then it would be electrolyzing 8A worth of water and battery acid. I expect that would make a giant mess. Alternatively, it just keeps running the DC-DC converter at very low output. The DC-DC converter could be incredibly inefficient when producing just a little bit of current (Tesla is reputed to use a huge (~200A) DC-DC converter, so the thing could be running at about 1% of rated output at, say, 10% efficiency).
Or we could finally fix the law and declare EULAs to be unenforceable. Unilateral contracts like EULAs are out of control.
Sometimes I think that things like this should be felonies, though. Criminal offense or not, in a sensible world this would put alphanetworks out of business.
These people should be using a real time Java VM and an ahead of time compiler for those parts.
It means you can skip the warm up. The only problem with it is you can't hire regular Java guys - real time Java is a little bit special, and you can't use regular Java collections and other things in the ways you'd expect.
That's not the only problem. Doing this switches you from using a well-standardized, well-supported language to a nonstandard subset. This removes a lot of the advantages of Java.
One of the most technically competent exchanges I work with is trying out Azul, which is (AFAIK) the top-of-the-line low-latency JVM. I was a bit surprised to learn that their software didn't Just Work. In fact, it didn't work at all. So now they have to decide which AOT-compiling JVM to run and figure out how to support it. I suppose that Excelsior and gcj (eek!) would be other options.
My main point here is that, when low latency is involved, a lot of people cite the existence of high-quality real-time JVMs as evidence that Java is a good choice. These JVMs exist, but they are by no means panaceas, and users of Java for real-time or low-latency work will need to make a real technical and monetary investment in dealing with them. Hotspot is not (yet?) appropriate for this kind of thing. Oddly, .NET seems be in better shape here, at least in terms of AOT compilation.
I'm not a Java user, so I've never directly tuned for things like GC, nor do I interact with it directly. Warm up is a different story.
I interact with quite a few exchanges (over all kinds of protocols). Most are, unsurprisingly, written in Java. Almost all of them perform terribly at the beginning of the week. The issue is a standard one: the JVM hasn't JITted important code paths, and it won't until several thousand requests come in. For a standard throughput-oriented program, this doesn't matter -- the total time wasted running interpreted code is small. For a low-latency network service, it's a different story entirely: all of this wasted time happens exactly when it matters.
The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.
If JVMs some day allow you to export a profile of what code is hot and re-import it at startup, this problem may be solved. Until then, low-latency programmers should weigh the faster development time of Java with the time spent trying to solve annoying problems like warm-up.
No, because the summary is (as usual) thoroughly overstated. This experiment, like any other form of quantum state tomography lets you take a lot of identical quantum systems and characterize them. For it to work, you need a source of identical quantum states.
As a really simple example, take a polarized light source and a polarizer (e.g. a good pair of sunglasses). Rotate the polarizer and you can easily figure out which way the light is polarized. This is neither surprising nor a big deal -- there are lots of identically polarized photons, so the usual uncertainty constraints don't apply.
The whole point of QKD (the BB84 and similar protocols) is that you send exactly one photon with the relevant state. One copy = no tomography.
First, keeping the voltage on requires power, which drives up the energy consumption of the microchip.
Barely. Almost every digital chip out there uses CMOS logic. The whole point of CMOS logic is that, when the gates aren't switching, no current flows. That means that no power is drawn. In practice, a little bit of current leaks, but this is a small effect at all but the smallest process sizes.
It's not all clear from the abstract how the authors expect to maintain a magnetic field without any static power consumption. Perhaps using ferromagnets, but I wouldn't hold my breath -- MRAM still hasn't happened.
If you ignore all the weird DRM-ish uses (which are basically unsupported for now anyway [1]), the TPM makes a nice cryptographic token. Unfortunately, TPM v1.1 hard-coded the OAEP label to "TPM", which made it incompatible with everything. TPM v2.0 fixes this -- the label is now user-specified. That means that you can use it for modern hardware crypto (sadly, using SHA-1, which should be phased out).
[1] For meaningful DRM, you need an endorsed TPM, which most vendors don't provide. See http://www.privacyca.com/ekcred.html
We assume that there is are [sic] random erasures within in the network.
802.11n aggregates frames. This means that (at least for throughput-limited flows) multiple packets will be transmitted at once, and they're likely to all be lost together. This won't help. In any case, it makes sense for inherently lossy links to do their own FEC -- the end-to-end principle is not a good way to maximize capacity. But hacking around TCP like this seems silly -- just fix the problem at the link layer.
Considering a thermoelectric device with a cold-side temperature of 350K and a hot-side temperature of 950K, respective waste-heat conversion efficiencies of ~16.5% and ~20% are predicted.
For a hot-side temperature of 950 K and a cold-side temperature of 350 K, the Carnot efficiency (i.e. the maximum possible efficiency of any device) is ~63%. So this is somewhere between 1/4 and 1/3 as efficient as it could possibly be. Large generators, such as combined cycle gas turbines are considerably more efficient, but these devices are small and silent. In other words: not bad.
It seems like the big vulneraibilites in mobile platforms these days involve apps doing things they shouldn't. Android is, for the most part, way ahead of Apple in terms of technical mitigations. Android sandboxes apps with explicit permission grants. Apple just vets them, incompletely. iOS also seems vulnerable to odd things, like this. Apparently executing unsigned code on iOS, if you can pull it off, sidesteps part of the sandbox. Android is based on the assumption that any app can execute unsigned code and it still tries to be secure.
I think it's a bit ridiculous, but not for these reasons.
(1) They suggest using very high temperatures, presumably to avoid exactly this issue.
(2) Not sure what you mean. She subtracts what from what? But see below.
(3) The authors propose adding low-pass filters for exactly this reason. They'll filter out high-frequency signals, leaving low-frequency components that have no effective time delay.
My attack would be for Eve to add a small probe signal -- she would insert a voltage source in the line, with a time-dependent (or even constant) voltage of her choice. She would then measure the correlation between the voltage she injects and the current in the wire. Alice and Bob are supposed to check for this by comparing the conditions on their ends of the wire with their expectation, but this assumes that they have measuring devices as good as Eve's.
The idea that the security is based on the second law of thermodynamics is, IMO, absurd. The second law says that a bunch of things that would decrease entropy are impossible. But Eve can do whatever she wants as long as she sinks enough entropy somewhere else -- Alice + Bob + the wire is not a closed system.
This is endorsed by Audi, BMW, Chrysler, Daimler, Ford, GM, Porsche and Volkswagen. Tesla is conspicuously missing. The Tesla Roadster and the Tesla Model S are the only electric cars in or near production that are close to road-trip worthy, so the omission is unfortunate.
There are several asymmetric protocols with very nice security properties, even against adversaries with quantum computers. My personal favorite is based on the Learning With Errors problem, which is in turn based on some lattice results. Wikipedia has a decent summary, and the original paper is here. The old McEliece cryptosystem might be secure against quantum attack. NTRU is commercialized but its security bounds make me very nervous. There also systems based on elliptic curve isogenies, but a new quantum algorithm comes somewhat close to breaking them. The main problem with these cryptosystems is that the resulting ciphertexts and signatures tend to be fairly long. RSA produces ciphertexts that are about the same length as the original messages and DSA produces nice, short signatures. ECC protocols are even better, but Shor's algorithm breaks them just as easily as RSA and DSA. The fancy post-quantum protocols, on the other hand, tend to produce large messages that are slow to work with.
What is this thing supposed to be? TFA is rather clear on the point that it's "a new type of laser". But it also says (as though it's obvious) that "the more power one puts into a laser accelerator, the more powerful and precise the light beam that comes out on the other end". I don't know exactly what a "laser accelerator" is, so I don't really know whether pumping more power in makes the other end more precise.
Of course, even if FoxNews.com can't explain how it works, it was a dramatic "supercharged electron beam that can burn through 20 feet of steel per second". Well, FoxNews.com, WTF is it? A laser or an electron beam? (Hint: a laser shoots light not electrons.)
I think it's really a Free-electron laser, in which you inject electrons into a tube and laser light comes out the other end. So TFA has it completely backwards.
I know that slashdotters automatically love anything involving making information more free, but...
I liked Wikileaks, too, until they published all the reports from the ground in Afghanistan. Up until then, at least the high-profile stuff revealed actual coverups of things that could be damaging because the fact that it happened was embarrassing or wrong. But the latest stuff? It's pretty much mundane, but it reveals important sources of information to American troops. Revealing that the troops have sources of information would be fine if completely unsurprising. But who benefits (other than the Taliban) from revealing their names?
C'mon, Wikileaks. Step up and act like real journalists. Think before you post. And if you fsck up, don't be surprised when people get pissed off.