On the Chromium blog, Mike Belshe and Roberto Peon write about an early-stage research project called SPDY (“speedy”). Unhappy with the performance of the venerable hypertext transfer protocol (HTTP), researchers at Google think they can do better.

The main problem with HTTP is that today, it’s used in a way that it wasn’t designed to be used. HTTP is very efficient at transferring an individual file. But it wasn’t designed to transfer a large number of small files efficiently, and this is exactly what the protocol is called upon to do with today’s websites. Pages with 60 or more images, CSS files, and external JavaScript are not unusual for high-profile Web destinations. Loading all those individual files mostly takes time because of all the overhead of separately requesting them and waiting for the TCP sessions HTTP runs over to probe the network capacity and ramp up their transmission speed. Browsers can either send requests to the same server over one session, in which case small files can get stuck behind big ones, or set up parallel HTTP/TCP sessions where each must ramp up from minimum speed individually. With all the extra features and cookies, an HTTP request is often almost a kilobyte in size, and takes precious dozens of milliseconds to transmit.

In an attempt to avoid these issues, SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that’s already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a “server hint” feature.

On the SPDY white paper page, the Google researchers show a speed increase of up to 50 percent.

So should we all praise Google and switch to SPDY forthwith? Not quite yet. With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP. Of course HTTP also runs over SSL in many cases, but there’s also lots of content out there that doesn’t need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don’t bother getting a proper certificate for their server, meaning that users will become even more blasé about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

On small devices, SSL slows down the communication significantly, and because it can’t be cached, SSL-protected sites are often slower on big machines as well. The extra CPU cycles also mean that more servers are needed to handle the same number of clients.

It also looks like this protocol is designed by Web people, rather than network people. How the IETF applications area will respond to this effort is a big unknown. For instance, one thing that isn’t mentioned in the protocol specification is how a browser knows that it should set up a SPDY connection rather than an HTTP connection. Are we going to see SPDY:// in URLs rather than HTTP:// ? That wouldn’t work with browsers that don’t support the new protocol.

It’s for reasons like this that the IETF isn’t a big fan of replacing protocols wholesale. It’s much more in line with the IETF way of doing things to add the new features proposed in SPDY to a new—but backward-compatible—version of HTTP. Designing a new protocol that does everything better than an existing protocol usually isn’t the hard part. The real difficulty comes in providing an upgrade path that allows all the Internet users to upgrade to the new protocol in their own time such that everything keeps working at every point along that path.

This is something the SPDY developers recognize. There are proposals for running HTTP over SCTP, a protocol similar to TCP, but with the ability to multiplex several data streams within a single session. That would have some of the same advantages as SPDY. Unfortunately, most home gateways don’t know about SCTP and can only handle TCP and UDP, so HTTP over SCTP would face a long, uphill battle, not unlike IPv6, but without the ticking clock that counts down the available IPv4 addresses.

That said, it’s good to see interest in improving the underlying technologies that power the Web, and Google should be applauded for taking the discussion in a new direction. There’s still a lot to be done in this space.

The processes we use to obtain fuel, from pumping fossil fuels up from beneath the ocean to harvesting crops to turn into ethanol, create many environmental and practical concerns. These types of fuel work fine with the current generation of cars, but hydrogen has sometimes been touted as the fuel of the future. A publication in Nature Nanotechnology describes how researchers have found a way to use the photosynthetic machinery of a bacteria to produce the hydrogen equivalent of up to 79 gallons of gas per-acre, per-day. Their technique involved capturing the electrons produced during photosynthesis and binding them to some strategically placed protons.

The production of fuel has accelerated lately, from waiting millions of years for fossil fuels to waiting a few days or weeks for biomass-derived fuels such as ethanol. However, biomass fuels still present some difficulties: the fuel produced relative to the land area required is pretty small (the equivalent of a little more than a gallon of gas per acre), the conversion to ethanol requires a distilling period, and all the materials for making the fuel must be harvested, handled, and transported, all of which requires a significant energy expenditure.

The problem can be boiled down to one relationship: the more directly solar energy can be used, the more efficient the fuel production will be. In the case of ethanol, plants process the solar energy through photosynthesis, but we lose a good deal of that when we process the plants. Researchers have been trying to catch the energy earlier in the photosynthetic process, hoping to divert it into a fuel with a high energy density.

In order to manipulate photosynthesis, the researchers worked with a thermophilic cynobacterium, T. elongatus. Scientists isolated its photosystem I (PSI), which is one of two reaction centers that the bacteria use to conduct oxygenic photosynthesis. At the most basic level, the PSI helps to transfer electrons from water to systems that use them to produce sugar and oxygen.

The researchers found that they could intercept these electrons if they coupled nanoclusters of platinum or convalently linked hydrogenase to the acceptor end of PSI complexes. The electrons would then bond with extra protons, or H⁺, that were adsorbed onto the platinum, resulting in hydrogen (the process is outlined in the picture above).

The experiments were also performed on the PSI obtained from both spinach and another variety of bacteria, the mesophilic cynobacterium Synechocystis. They found the T. elongatus version remained stable at higher temperatures than the one from Synechocystis; its chlorophyll became less efficient at temperatures above 130°F. The T. elongatus version remained sufficiently functional up to 194°F, and in fact worked better at temperatures above 130°F.

The spinach’s PSI’s ability to absorb light reached an early plateau; researchers found that the productivity of the PSI from T. elongatus could continue to scale with light four times brighter than the PSI of the spinach. For this method of hydrogen harvesting, the T. elongatus proved to be the best choice of the three.

Given the functionality of the PSI of T. elongatus, the researchers calculated that a one-acre solar collector that is 10 centimeters deep and operated at a temperature of at least 130°F could produce the energy equivalent of 79 gallons of gas per day. The collector could operate continuously for about three months before the PSIs would be exhausted and need to be replaced, but during that time, it would pump out the hydrogen equivalent of over 7000 gallons of gas. Unlike the PSI, the platinum catalyst could be reused for many more cycles.

The scientists point out that this method has many advantages over the production of biofuels. Notably, it doesn’t involve a single-use crop that has to be planted, harvested, fermented, and distilled to obtain more fuel.

However, there’s still the challenge of delivery. Since the proteins work best in the warmest parts of the planet, it would be hard for most people to produce hydrogen in their backyard. Nor does the paper consider the cost of isolating the protein or the use of precious metals in hydrogen production. There is also the small issue of hardly anyone currently owning anything that runs on hydrogen, aside from the occasional concept car. Still, the 79-gallon yield per day of the collectors is impressive, and further modification of the basic approach may make the hydrogen economy look relatively practical.

Nature Nanotechnology, 2009. DOI: 10.1038/nnano.2009.315

As the telecommunications world went wireless and digital, the tried-and-true method law enforcement agencies used for wiretaps—splicing into the local loop—was in danger of becoming an anachronism. In 1994, Congress passed the Communications Assistance for Law Enforcement Act, which required telecommunications switches to incorporate a capacity for government monitoring of phone calls and other communications. That requirement ultimately produced an ANSI standard, J-STD-025, that dictated the capabilities of the hardware interface used by law enforcement agencies. A team of academic researchers has now put that standard to the test, and found that it’s vulnerable to various forms of denial and obfuscation attacks.

As the authors note, the monitoring of domestic communications has been a source of controversy in recent years; others have questioned whether having a standard capacity built into every piece of communication hardware leaves the US communications infrastructure at risk of external attack. They avoid these issues, however, and focus on a simpler question: how well does the J-standard actually work?

The answer, it appears, is that it’s trivial to defeat it and interfere with wiretaps. The big caveat to this work is that the authors didn’t have access to any of the actual hardware used by law enforcement agencies; they simply tested whether hardware that follows the J-standard could hold up to a variety of attacks. It’s possible that hardware makers have exceeded the standards with more recent equipment, and obviated some of the problems.

Still, there are two reasons to think that at least some wiretaps would be vulnerable. The first is that the hardware that’s actually deployed is probably from a variety of generations and manufacturers, making it likely that some of it does the bare minimum needed to comply. The second is that the authors demonstrate multiple vulnerabilities, making it unlikely that even the best equipment handles all of them.

Part of the problem is that there are two classes of phone monitoring available to law enforcement: simple call logging, which is relatively easy to obtain, and full call recording, which is typically more challenging. The two are handled separately within the protocol, and the capacity granted for the logging was based on typical usage patterns at the time: a single, 64kbps ISDN line. The authors go on to show that it’s relatively simple to exceed this bandwidth with a single computer or smartphone, creating a denial of service situation.

Part of the problem is that there’s an asymmetry between the basic information that needs to be sent down a phone line—there’s a connection waiting—and all the information that law enforcement needs, such as the source, a datestamp, a case identifier, etc. This asymmetry ensures that even a simple unconnected call produces significant data that has to be stuffed down the 64kbps pipe.

The other part of the problem is that modern telephony creates a variety of methods of sending a lot of traffic to an individual phone line with minimal effort. So, for example, the authors use an ISDN phone to send commands to voicemail boxes at a rate of 94 calls a second. Forty-two text messages a second would also work, as would repeated call/hangups using IP telephony. A rate of 20 hangups a second would do the trick, and the researchers were easily able to exceed that from a residential broadband connection.

Since the J protocol doesn’t allow for queueing or buffering, once the bandwidth is exceeded, any information that can’t be stuffed down the pipes is lost. So, once these levels are exceeded, law enforcement call logging becomes unreliable. The protocol is less clear about the capacity allocated to content monitoring, but the authors’ analysis suggests that this would be even easier to saturate.

More sophisticated attacks are also possible. For example, the J protocol calls for a termination of call recording once a tone is registered. However, communications hardware will only register the tone if it originates from specific hardware. As a result, a person being monitored could send the tone over their phone; the monitoring equipment should hang up, while the call would continue.

The authors were also able to craft a variety of IP packets that would interfere with monitoring. These include false datestamp information—which would inject irrelevant packets into the middle of a conversation—and eliminating the directionality information used by packets in some CDMA cellular systems. They also built packets that would be routed part of the way to the end user, but never reach them; these would be seen by the tap, but not interfere with the phone conversation.

All told, the authors come up with six attack scenarios that they consider practical, in that they could be carried out with readily available equipment. In fact, they tested a number of them using a laptop tethered to a CDMA phone (in one case, causing Sprint to throttle back their bandwidth).

They also suggest a number of stopgap measures that could be used to help avert some of their own scenarios, such as providing law enforcement with greater bandwidth. Still, it’s clear that they think the J standard is due for a complete rewrite, as they suggest it was the product of compromise among law enforcement, hardware makers, and telcos, and a product of simpler telecommunications times.

NEW YORK — Two former computer programmers for Bernard Madoff’s investment firm were arrested Friday on charges they helped cover up the disgraced money manager’s massive fraud for more than 15 years.

The U.S. attorney’s office said Jerome O’Hara, of Malverne, N.Y., and George Perez, of East Brunswick, N.J., were arrested at their homes. It said the pair formerly worked for Bernard L. Madoff Investment Securities.

The Securities and Exchange Commission said the two men provided the technical know-how needed to produce false documents and trading records, and took hush money to help keep the scheme going.

“Without the help of O’Hara and Perez, the Madoff fraud would not have been possible,” George S. Canellos, director of the SEC’s New York Regional Office, said in a statement.

Their attorneys did not immediately return calls for comment.

According to an SEC complaint filed in U.S. District Court in Manhattan, O’Hara and Perez wrote programs that generated thousands of pages of fake trade blotters, stock records “and other phantom books and records to substantiate nonexistent trading.”

O’Hara and Perez “had a crisis of conscience in 2006 and tried to cover their tracks by attempting to delete approximately 218 of the 225 special programs” from a computer, the SEC said.

“According to O’Hara’s handwritten notes … one of them told Madoff, `I won’t lie any longer. Next time, I say ‘ask Frank,’” the SEC said.

Frank DiPascali, Madoff’s former finance chief, is cooperating after pleading guilty in August to helping Madoff carry out his fraud.

Madoff, 71, was sentenced in June to 150 years in prison for orchestrating a decades-long Ponzi scheme in which investors are paid with other investors’ money rather than actual profits on their investment. The scheme destroyed thousands of people’s life savings and wrecked charities.

http://www.huffingtonpost.com/2009/11/13/jerome-ohara-george-perez_n_356886.html