The flaw we're seeing here is various "computer security journalists" (and journals) destroying their reputations.

This is on the order of discovering that big heavy things that fall on your foot can cause pain.

Definitely a weird article. If you ignore the hyperbole, all you get is a military boondoggle. The idea that it's part of some NSA spying operation falls apart in the face of the Raytheon promotional material - "double digits of swarming boats" and "hundreds of cars" in the Baltimore area sounds woefully insufficient, either for tracking suspected cruise missile delivery systems or giving the NSA anything more useful than what they have.
I suppose it might be practical for protecting Marquette, MI from an invasion from Canada.

Given how overweight most Americans are, I suspect that any effects of nude flying on TSA worker morale will be negative.

If the tolls were used to offset another public good (public schools being the only other one that's nearly as expensive), it might work to encourage either people living in-town, or some businesses leaving town. Of course, that would only work if schools and the toll roads were under the same authority. (FYI, I live in Ann Arbor, Michigan where while we might complain about traffic and parking, we don't have anything like LA's situation. But being part of Michigan, we probably have the worst roads in the nation and a GOP/Tea Party dominated state government that's so tax-phobic that it's even more dysfunctional than the US House of Representatives.)

On a Ubuntu 14.04 install, Chrome's most unique component was WebGL. On a Macbook Pro (Mavericks), it was the list of plugins, followed by the font list. For both, the Canvas was shared with less than 1%

Curiously, Do Not Track is reported as "yes" for Ubuntu, but "1" for Safari.

Union? That's a four-letter word around here - with an off-by-one error.

The video shows some kind of wide laser projector about a centimeter or so above a test-rig, with sparks flaring off, and the rail moving at a (relatively) slow rate - perhaps one or two Kph.

If the sparks were only burnt excess "leaf material", that isn't a problem - but if it's rust or steel fragments burning up, that's material coming off of the rails - in effect, wear.

If this is intended to be used continuously while the train is in motion in order to keep the rails clear of debris, how much energy can be delivered to a leaf from a fixed projector moving at 50Kph? If this does deliver enough power to cause the leave to disappear in a puff-of-smoke, isn't there a chance of heating the surface of the rail enough for the carbon ashes pressed into the rail by the subsequent advance of the train to chemically react with the rail?

This might be ok for single layers of leaves - but how long does it take for multiple layers of leaves to build up on a rail?

If the huge amount of leaves in the video is characteristic of the problem they want to solve, won't the wind from the passage of any train moving at speed just redistribute more leaves on the rails behind it?

I predate MIMO, so I had to take a brief refresher in what it is - and if I understand correctly what I read of MIMO (and what I read was correct - two important provisos!), MIMO seems to depend on using digital signal processing to be able to match the emit and receive channels, but it is using a physical separation (on the WiFi access-point side) of a few centimeters between antenna. I can see where you might find that kind of separation in laptops or even tablets, but not necessarily in a cell phone or an Internet-of-Things tiny appliance (like a light-bulb.) I couldn't tell how stateful the DSP part would have to be, or how long it would take to optimize for a particular set of signal paths. I also couldn't tell how well MIMO works out in a mix of MIMO clients and non-MIMO clients (like my IoT light-bulb). Can anyone offer any guidance?

QAM strikes me as (somewhat) incompatible with MIMO because using phase-shifted channels (QAM) (carrying different data) would be akin to space-shifted channels (MIMO) when the wavelengths and the distance between the antenna are similar - and the distance (and phase) between the MIMO antenna depend on the orientation between the sender and receiver of MIMO. But maybe that's just more DSPing?

Perhaps if you have real hardware for your data, and your data is static. But once you escape into the real world, you shouldn't be designing web applications that depend on L1 (or L2) cache.

800bps (call it 1600Ghz, using Shannon) is in the Far Infrared to (barely) mid infrared spectrum, and that's just base-band signaling (from a point-like source.) Doing any kind of modulation (to allow multiple channels for multiple simultaneous transmissions) is going to put that more firmly in the mid-infrared spectrum where things like the atmosphere appears to be opaque. I realize that this is a mass-media article, and depends on "... and then magic will happen" sort of science, but I don't see how this works (much less scales) without excessive speculation using ancient undergraduate digital communications classes too far.

But, to speculate WITH ancient undergraduate digital communications classes, I would think of things like this:

• Multi-point (physical separation) of channels, with individual channels at more "modest" speeds. Something like 1000 locations per. simultaneous customer being served 800Gbps.
• (As. per. above) very, very tiny cells, packed very, very, very, very closely together.
• Very, very tiny ceramic antennae.
• Extreme differences between upload and download speeds, like on the order of 10E6.
• A hot-spot would literally be that.

It makes sense when you understand the trust model, but that takes some explaining and isn't as simple to "civilians" as "check to make sure that the site begins with 'https://' or look for the 'key' icon provided by your browser." (Asking them to verify the host/site part of the URL is the advanced part of the explanation.)

It's rather like teaching people how to cook by telling them "be careful of hot burners, pots, and pans", but that is what we in IT have been doing to "civilians".

It's the organizations that put strong controls over their staff use of desktop computers that do this when they generate an image. Those organizations that value micromanaging what their staff can do more than getting work done used to (and may still) block much of the internet, etc. and in that context of tightening everything down so much that the threads get stripped, managing the CA root list makes sense.

There's already toddlers squeezing through the fence ... perhaps Rep. Gohmert's intent is "cull the herd" by having a moat.

• (A) Nearly worthless because a lot of the advice given out to "civilians" is that "https" can be trusted, "look for the lock", etc. More subtle advice (like check the URL, don't mistake "1" for "l" or "0" for "O", etc) are advanced techniques (at least for too many civilians.) Charging for SSL certificates - and the turnaround time it takes to issue them, install them, etc. meant that a certain class of quick-and-fast scams weren't practical. Cheap, fast, easy to install SSL certificates make this easier, thereby making the "https" indicator less valuable. (In short, use of "https" to "trust" a site is a gross mistake - but a mistake IT people have been advising civilians to do.)
• (C) I'm not a security researcher, I know a little about running a CA. A faked up CA isn't going to help someone trying to figure out what an App is trying to send over a SSL session, unless they're somehow able to replace the certificate and key in the App. Of course, a web app isn't going to have a certificate and key - but a smartphone/tablet app might.
• (i) On this, I think you're arguing that the CA system is even more broken than I am. I won't protest that.
• (ii) I'm not going to cry - but if there's enough money involved, Congress will do something stupid.
• (iii) I'm talking about "Extended Validation" certificates - which were an enhancement (via. another X.509 attribute) that suggested that the issuing CA did some due diligence (other than verifying that a credit card accepted a charge.) Whether the CA actually followed the guidelines is another matter. Is there a way for an outsider to audit this 'Extended Validation' for a particular Certificate? Without that, "Extended Validation" is just a way for CAs to charge more money.

Apps

Why do this?
So that:

• (1) App developers get used to designing and testing with https/SSL instead of gluing it in at the last minute AND GETTING IT WRONG
• (2) to encourage encryption and privacy, and to make the use of https/SSL less likely to distinguish between valuable communication and noise

Why not do this?
Because it:

• (A) makes the value of the https signifier on a URL / browser bar nearly worthless
• (B) will encourage App developers to send even more information to poorly secured servers
• (C) prevent researchers from determining what privacy-violating information an App is sending

What might happen because of this?
It will:

• (i) break the already weak link between certificates and the organizations they represent.
• (ii) kill the business model of the certificate authorities
• (iii) result in another somewhat meaningless revision of the "verified" certificate

Overall, it might work out well - but I doubt that App developers are going to bother so the major good reason will be ignored. App developers will STILL get it wrong, and even if they do set up https, that'll just encourage them to pass even more sensitive information to poorly secured APIs.