Encrypting is useful, but then comes the very nasty thing that comes with it: Key management.
Google has an outstanding key management infrastructure. That problem was actually already thoroughly solved a while ago. Actually, it's pretty well-solved outside of Google as well, for point-to-point links within an enterprise. Kerberos (though Google's solution is more robust than Kerberos).
Oh, the CA keys. Are they stashed in an armored HSM
Google has a great answer there, too. I wish I could share it.
Does anyone bother to ask themselves how many other possible (yet to be publicly known) agencies are part of the US governments spying network, and that these companies are still openly cooperating with some branch of the spying network, at least till someone blows these agencies into the public's eye.
Google has flatly denied any such cooperation with anyone. Why would you believe Google is telling the truth about the NSA, but not about others?
Dude, I really wish I could give you a point by point response. Actually, I typed one out, and then realized that I went too far. I personally think Google is making a big mistake by not being more open about its security policies, procedures and technologies -- because they're awesome -- but the fact is that a lot of it is confidential, and I like my job.
What I will tell you is this: Google's general solution to cross-DC traffic wasn't to add link-level encryption to the cross-DC links, and there is so much cross-DC traffic that it would be a nightmare to try to identify the cross-DC connections and encrypt just them. Further, stuff gets shifted around between DCs a lot, so any such solution would be beyond brittle. I'll let you extrapolate from there.
The other thing I'll say is just to give you a testimonial of sorts. You take it with however much salt you want... and I guarantee I'm going to get a bunch of foul-mouthed ACs (and maybe even non-anonymous cowards) calling me all sorts of variations of "liar". Whatever.
I was an IBM security consultant for many years. I spent a lot of time working in the bowels of the security infrastructure of a lot of big companies, and even some governmental organizations -- including some military organizations. I was also a security policeman in the US Air Force in a previous life (long story), so I have a pretty solid grounding in physical security, not just infosec. One of my degrees is in mathematics, and I was fascinated with cryptography from an early age, so much of my independent study during my degree was around crypto, and I continued my self-education and practical education afterward (which is how I ended up as a security consultant).
My point? I know more than a little about security, and I've seen a lot of what passes for security in both government and industry, including in organizations that handle a lot of sensitive data and really should know how to secure it.
Google is better at it than any of them. Head and shoulders.
Perfect? No. Nothing is perfect. But Google has world-class security talent, a lot of it, and Google's engineers have always cared a lot about security... and are now angry as well.
Anyway, take that for whatever you want, but it's my absolutely honest opinion. Google can do a hell of a lot to obstruct the NSA's illicit snooping, and intends to do everything feasible.
(Disclaimer: I work for Google, but I don't speak for them and they don't speak for me.)
I agree that towers wouldn't work. It's not clear that balloons will, but it's also not clear that they won't.
I've seen estimates of numbers of balloons, equipment and operational costs, etc., plus discussions of a lot of other issues you probably haven't considered like, what about countries that don't want to allow Google to fly balloons over them? The winds don't pay attention to lines on the map. The people who are working on this are very bright, and they've been thinking very hard about all of these issues -- including land-based alternatives, hybrid options, etc. -- for years now... and they've even designed built, launched, flown and recovered balloons and the electronics, negotiated agreements with governments for overflight, and RF communications licenses, and quite a bit more.
My point: The Project Loon team knows a lot more about this than either of us, and their take is that it might be impossible, but so far it actually looks like it will work.
I love my boat. There's nothing I'd rather do in the summer than drag the kids around a lake. We do a fair amount of boat camping, too, camping at lakeshore campsites which are inaccessible except by boat.
I had to spend $600 on a complete carburetor rebuild for my boat last year because it had sat unused for two years and the ethanol had really screwed up the carb.
Out of curiosity: at what point is it better to just sell something that you're not "really" using, and put they money towards something else?
Oh, in general I use the boat plenty. But I changed jobs, relocated to another state and generally had a lot of life upheaval for a while which prevented me from using the boat.
You only need an altitude of around 120 meters to cover the same area and that is a not all that large tower.
But you need to land to put the tower on, plus a 120m tower is a lot more expensive than a balloon. And then you also have to worry about hardening the package against weather, keeping the towers from being hit by airplanes, etc. Extreme-altitude balloons avoid all of that.
Plus what about the recovery of the electronics packages? Not all of them will land where they want it to.
They actually have a very high degree of control over them. And the goal is to make the electronics package inexpensive enough that the inevitable small percentage that gets lost is easily absorbed.
Add in the costs of He unless they go to Hydrogen to fill them.
They have thought about that, too, and have some rather creative and clever solutions. I don't know what has been disclosed publicly, though, so I won't say more.
Notice how consumers aren't given the choice of buying "pure" gas, as opposed to E10. I'm pretty sure that if we had the choice we'd be buying the good stuff, not the corn crap.
+1
I'd really like to find a place I could get pure gasoline. I don't care so much for my road vehicles (one of which is an EV anyway), but I really hate putting ethanol in my boat. The alcohol is terribly corrosive if it ends up sitting for an extended period of time. Cars and trucks generally get driven enough that's not a problem but recreational vehicles may go months -- or occasionally, years -- between uses. I had to spend $600 on a complete carburetor rebuild for my boat last year because it had sat unused for two years and the ethanol had really screwed up the carb.
The mechanic said that in the future if I'm going to use ethanol and might be leaving the boat to sit for more than about six months, that I should ensure that every drop of fuel is cleared out of the carburetor and fuel lines. Fuel stabilizer that keeps the gasoline from separating doesn't prevent the alcohol corrosion. His recommendation is not to use ethanol, but about the only places I can find pure gasoline are boat fuel stations on lakes (where the gas is $5+ per gallon).
I'm all for reducing petroleum consumption, but ethanol is the wrong way to do it, for all sorts of reasons.
you should look at the history of vulnerabilities on it and Chrome's viewer. You'll see reason.
Wow.. that is such a dishonest comparison. Chromes viewer doesn't do all the stuff that Adobes viewer does.
That's by design. Chrome specifically excludes all of the rarely-used and hard-to-secure aspects of PDFs. That's a good thing. It doesn't prevent you from using Adobe for the rare cases where it's necessary, but it makes it much harder for compromises to be distributed via links to hacked PDFs.
I bought my car (Prius) not because I wanted to save the planet, but simply because I needed a new car, and Prius was a very good choice in many aspects - comfort (CVT rules!) and mieage, and reliability, and price, and cargo space, and passenger seats, and cost of service.
I bought my car (pure EV Nissan LEAF) for similar reasons. I needed a new car, I liked the LEAF, and it was cheaper than any new hybrid or ICE vehicle I compared it to, and I compared a lot of them. Yeah, the LEAF costs more up front, but I estimated that, given my driving patterns, I'd break even in just under six years due to the much lower fuel cost -- and that's without considering tax credits. With the tax credits (which which I disagree philosophically, but that's not going to stop me from reducing my tax liability in any way I legally can), the break-even point was just over two years. And I didn't even consider the much lower maintenance costs (the LEAF's maintenance schedule is hilarious... basically you rotate the tires every 7500 miles, and every 15000 miles you have someone look it over to make sure nothing is wearing or breaking).
Of course, the EV isn't usable for road trips, and there are a number of other limitations. But that's okay because I need more than one vehicle anyway. It does a great job in the role it fills, and it's cheap to own and fun to drive.
I believe Adobe Reader has its own sandbox so this might seem a bit weird... but at least one thing Chrome has going for it that Reader has not is that Chrome is more likely to be up-to-date
Not to mention the fact that the Adobe Reader has a long, rich history of serious security defects. The Chrome viewer has a big security advantage over Adobe Reader: It's not feature complete. Adobe has packed so many arcane capabilities into PDFs that it's a nightmare trying to support everything and keep it secure. The Chrome viewer doesn't do all that stuff that's hardly ever used in practice, so there are many classes of security vulnerabilities the dev team doesn't have to worry about. This means that occasionally a real, non-malicious PDF will require you to use a different reader, but I think that's a reasonable tradeoff.
Giving the pilots guns just makes it likely they'll "go back" to try to solve the problem.
You're projecting. This is very similar to the old "blood in the streets" argument against legal citizen carry... but directed at people who are already in positions of extreme trust and responsibility, making it even weaker.
To say nothing of the fact that it makes it far easier for a single pilot to take over the entire flight deck.
Meh, that's trivial anyway. Just wait until the other guy takes a nap, then bean him with the fire extinguisher.
The problem with blowing a small hole in a plane isn't the air rushing out so much as the risk of the metal tearing under pressure and turning a small hole into a huge one.
That only happens in Hollywood. Watch the MythBusters episodes on this topic. If you don't find their own testing convincing, they also interview some experts.
But perhaps the most telling counterargument is that Federal Air Marshalls carry.40 JHPs and aren't concerned about using them.
I predict that the US still won't have fully (or at least 99%) converted to chip&pin credit card terminals (even with magstripe fallback) by 2020.
The US is going to contactless chip & signature, and it's going to happen a lot faster than you think. Visa and MasterCard have announced they're imposing the liability shift in 2015, which will give merchants a huge incentive to deploy the new technology. Meanwhile, Google has finally figured out how to stop carriers from blocking Google Wallet, and opened up NFC on (new) Android devices to other players by offering open APIs, Apple has been quietly doing something with NFC for about two years now, ISIS has rolled out nationally (though barely making a splash as yet). Both sides of the tech are just 1-2 years from ubiquity.
As such running your battery down 20% and recharging 4 times versus running down to 20% and charging once shortens the useful battery life.
OTOH, running it from 80% down to 60% and recharging back to 80% four times is better. Lithium ion battery life is maximized by keeping the battery state of charge away from either extreme.
Why would you assume that? An electric truck wouldn't need that enormous engine compartment, so they could just get rid of it.
Basically, you would operate like a diesel locomotive, but on a smaller scale, with an alternator powering some type of traction motor. Size keeps this from working on cars
Er, Chevy Volt?
Not totally emmission free, but then neither is all electric, unless it is somehow charged off the grid as current power plants have emmissions, too.
Big power plants produce much less pollution per unit of energy produced than small ones.
You do realize that physical proximity != internet proximity?
But lowering latency is very often all about getting physically closer. The protocols we use most require a few round trips to set everything up before they get going, so whatever lightspeed delays you have get multiplied significantly. And it gets really bad when you get a bit of congestion and drop a packet or three. Long tail (95th or 99th percentile) latencies are often two to three orders of magnitude greater than median latencies, so a millisecond or two can turn into serious sluggishness from time to time. Reducing the number of hops is also useful, because routers add latency too, but when you've squeezed all you can there you're left fighting the speed of light, and the only way to win that battle is to reduce distance.
Of course, packets can take crazy routes. Physical proximity doesn't guarantee low latency, but it gives you a fighting chance, and distance does guarantee it's going to be slow.
I'm fine with armed pilots. They should be given frangible bullets suitable for use on aircraft./p
Frangible bullets suck. Pilots should be armed with jacketed hollow points, the same thing air marshals and every other sort of law enforcement carries.
Frangible bullets are lousy manstoppers. They tend to make wounds that are wide and shallow. Very ugly, but without enough penetration to reach major blood vessels they have no real effect on an attacker who doesn't decide to helpfully fall down and lie still. And yet they still penetrate walls and such much more than we'd like -- and would have absolutely no trouble blowing through the thin aluminum skin of an airplane.
The bottom line with bullets is that if they have enough penetration to be useful at stopping a person, they're going to be able to pass through a few walls.
But, really, it's not a problem. Airplanes aren't airtight to begin with. They leak air all the time when "pressurized", but continue pumping more in to maintain the desired pressure. Punch a few half-inch holes in the skin and the pumps will just compensate by increasing the flow a bit.
The pilots should be armed with standard defensive handguns and ammunition as a last resort in case the hijackers manage to get through the locked door before the passengers beat them to death. It's unlikely they'll need their guns, but it's better to have them and not need them.
You're unlikely to see any increased complexity, unless you're actually implementing the protocol. TCP is pretty complex, but how often do you care?
As for the gain, the hundreds of milliseconds saved are really important if you are trying to create web apps with performance comparable to desktop apps.
HTTP was great when pages were largely just a single block of HTML, but modern pages include many separate resources which are all downloaded over separate connections, and have for a long time, actually. HTTP pipelining helps by reducing the number of TCP connections that have to be established, but they still have to be sequential per connection, and you still need a substantial number of connections to parallelize download. This all gets much worse for HTTPS connections because each connection is more expensive to establish.
HTTP 2 is actually just Google's SPDY protocol (though there may be minor tweaks in standardization, the draft was unmodified SPDY), which fixes these issues by multiplexing many requests in a single TCP connection. The result is a significant performance improvement, especially on mobile networks. HTTP 2 / SPDY adds another powerful tool as well: it allows servers to proactively deliver content that the client hasn't yet requested. It's necessary for the browser to parse the page to learn what other resources are required, and in some cases there may be multiple levels of "get A, discover B is needed, get B, discover C is needed...". With SPDY, servers that know that B, C and D are going to be needed by requesters of A can go ahead and start delivering them without waiting.
The result can be a significant increase in performance. It doesn't benefit sites that pull resources from many different domains, because each of those must be a separate connection, and it tends to provide a lot more value for sites that are already heavily optimized for performance, because those that aren't tend to have lots of non-network bottlenecks that dominate latency. Obviously it will be well-optimized sites that can make use of the server-initiated resource delivery, too.
Actually, though, Google has decided that SPDY isn't fast enough, and has built and deployed yet another protocol, called QUIC, which addresses a major remaining problem of SPDY: it's built on TCP. TCP is awesome, make no mistake, it's amazing how well it adapts to so many different network environments. But it's not perfect, and we've learned a lot about networking in the last 30 years. One specific problem that TCP has is that one lost packet will stall the whole stream until that packet loss is discovered and resent. QUIC is built on top of UDP and implements all of the TCP-analogue congestion management, flow control and reliability itself, and does it with more intelligence than can be implemented in a simple sliding window protocol.
I believe QUIC is already deployed and is available on nearly all Google sites, but I think you have to get a developer version of Chrome to see it in action. Eventually Google will (as they did with SPDY) start working with other browser makers to get QUIC implemented, and with standards bodies to get it formalized as a standard.
Relevant to the topic of the article, neither SPDY nor QUIC even have an unencrypted mode. If the committee decides that they want an unencrypted mode they'll have to modify SPDY to do it. It won't require rethinking any of how the protocol works, because SPDY security all comes from an SSL connection, so it's just a matter of removing the tunnel. QUIC is different; because SSL runs on TCP, QUIC had to do something entirely different. So QUIC has its own encryption protocol baked into it from the ground up.
While you're right that there are issues with the certificate-based approach, it's not nearly as bad as you describe. There are solutions already implemented that mitigate much of the risk.
One example is certificate pinning. Google already pins all Google-owned sites in Chrome. This is actually how the DigitNotar compromise was discovered; Chrome users got an error when trying to get to a Google site.
Another example is SSH-style change monitoring, alerting users when certificates change unexpectedly. That doesn't help if the MITM attack is done from the beginning or during time periods around legitimate key changes, but it does narrow the window of opportunity significantly.
Another example is multi-perspective observation... does the same certificate get returned to multiple requesters from different places on the Internet, and is it the same one the server is actually serving (the last must be periodically verified by the the site owner).
There are other possibilities as well.
Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties.
Good luck with that. You can build it, but they won't come.
Slashdot Mirror
Encrypting is useful, but then comes the very nasty thing that comes with it: Key management.
Google has an outstanding key management infrastructure. That problem was actually already thoroughly solved a while ago. Actually, it's pretty well-solved outside of Google as well, for point-to-point links within an enterprise. Kerberos (though Google's solution is more robust than Kerberos).
Oh, the CA keys. Are they stashed in an armored HSM
Google has a great answer there, too. I wish I could share it.
Does anyone bother to ask themselves how many other possible (yet to be publicly known) agencies are part of the US governments spying network, and that these companies are still openly cooperating with some branch of the spying network, at least till someone blows these agencies into the public's eye.
Google has flatly denied any such cooperation with anyone. Why would you believe Google is telling the truth about the NSA, but not about others?
Dude, I really wish I could give you a point by point response. Actually, I typed one out, and then realized that I went too far. I personally think Google is making a big mistake by not being more open about its security policies, procedures and technologies -- because they're awesome -- but the fact is that a lot of it is confidential, and I like my job.
What I will tell you is this: Google's general solution to cross-DC traffic wasn't to add link-level encryption to the cross-DC links, and there is so much cross-DC traffic that it would be a nightmare to try to identify the cross-DC connections and encrypt just them. Further, stuff gets shifted around between DCs a lot, so any such solution would be beyond brittle. I'll let you extrapolate from there.
The other thing I'll say is just to give you a testimonial of sorts. You take it with however much salt you want... and I guarantee I'm going to get a bunch of foul-mouthed ACs (and maybe even non-anonymous cowards) calling me all sorts of variations of "liar". Whatever.
I was an IBM security consultant for many years. I spent a lot of time working in the bowels of the security infrastructure of a lot of big companies, and even some governmental organizations -- including some military organizations. I was also a security policeman in the US Air Force in a previous life (long story), so I have a pretty solid grounding in physical security, not just infosec. One of my degrees is in mathematics, and I was fascinated with cryptography from an early age, so much of my independent study during my degree was around crypto, and I continued my self-education and practical education afterward (which is how I ended up as a security consultant).
My point? I know more than a little about security, and I've seen a lot of what passes for security in both government and industry, including in organizations that handle a lot of sensitive data and really should know how to secure it.
Google is better at it than any of them. Head and shoulders.
Perfect? No. Nothing is perfect. But Google has world-class security talent, a lot of it, and Google's engineers have always cared a lot about security... and are now angry as well.
Anyway, take that for whatever you want, but it's my absolutely honest opinion. Google can do a hell of a lot to obstruct the NSA's illicit snooping, and intends to do everything feasible.
(Disclaimer: I work for Google, but I don't speak for them and they don't speak for me.)
I agree that towers wouldn't work. It's not clear that balloons will, but it's also not clear that they won't.
I've seen estimates of numbers of balloons, equipment and operational costs, etc., plus discussions of a lot of other issues you probably haven't considered like, what about countries that don't want to allow Google to fly balloons over them? The winds don't pay attention to lines on the map. The people who are working on this are very bright, and they've been thinking very hard about all of these issues -- including land-based alternatives, hybrid options, etc. -- for years now... and they've even designed built, launched, flown and recovered balloons and the electronics, negotiated agreements with governments for overflight, and RF communications licenses, and quite a bit more.
My point: The Project Loon team knows a lot more about this than either of us, and their take is that it might be impossible, but so far it actually looks like it will work.
I have one of those, too :-)
I love my boat. There's nothing I'd rather do in the summer than drag the kids around a lake. We do a fair amount of boat camping, too, camping at lakeshore campsites which are inaccessible except by boat.
I had to spend $600 on a complete carburetor rebuild for my boat last year because it had sat unused for two years and the ethanol had really screwed up the carb.
Out of curiosity: at what point is it better to just sell something that you're not "really" using, and put they money towards something else?
Oh, in general I use the boat plenty. But I changed jobs, relocated to another state and generally had a lot of life upheaval for a while which prevented me from using the boat.
You only need an altitude of around 120 meters to cover the same area and that is a not all that large tower.
But you need to land to put the tower on, plus a 120m tower is a lot more expensive than a balloon. And then you also have to worry about hardening the package against weather, keeping the towers from being hit by airplanes, etc. Extreme-altitude balloons avoid all of that.
Plus what about the recovery of the electronics packages? Not all of them will land where they want it to.
They actually have a very high degree of control over them. And the goal is to make the electronics package inexpensive enough that the inevitable small percentage that gets lost is easily absorbed.
Add in the costs of He unless they go to Hydrogen to fill them.
They have thought about that, too, and have some rather creative and clever solutions. I don't know what has been disclosed publicly, though, so I won't say more.
Notice how consumers aren't given the choice of buying "pure" gas, as opposed to E10. I'm pretty sure that if we had the choice we'd be buying the good stuff, not the corn crap.
+1
I'd really like to find a place I could get pure gasoline. I don't care so much for my road vehicles (one of which is an EV anyway), but I really hate putting ethanol in my boat. The alcohol is terribly corrosive if it ends up sitting for an extended period of time. Cars and trucks generally get driven enough that's not a problem but recreational vehicles may go months -- or occasionally, years -- between uses. I had to spend $600 on a complete carburetor rebuild for my boat last year because it had sat unused for two years and the ethanol had really screwed up the carb.
The mechanic said that in the future if I'm going to use ethanol and might be leaving the boat to sit for more than about six months, that I should ensure that every drop of fuel is cleared out of the carburetor and fuel lines. Fuel stabilizer that keeps the gasoline from separating doesn't prevent the alcohol corrosion. His recommendation is not to use ethanol, but about the only places I can find pure gasoline are boat fuel stations on lakes (where the gas is $5+ per gallon).
I'm all for reducing petroleum consumption, but ethanol is the wrong way to do it, for all sorts of reasons.
you should look at the history of vulnerabilities on it and Chrome's viewer. You'll see reason.
Wow.. that is such a dishonest comparison. Chromes viewer doesn't do all the stuff that Adobes viewer does.
That's by design. Chrome specifically excludes all of the rarely-used and hard-to-secure aspects of PDFs. That's a good thing. It doesn't prevent you from using Adobe for the rare cases where it's necessary, but it makes it much harder for compromises to be distributed via links to hacked PDFs.
I bought my car (Prius) not because I wanted to save the planet, but simply because I needed a new car, and Prius was a very good choice in many aspects - comfort (CVT rules!) and mieage, and reliability, and price, and cargo space, and passenger seats, and cost of service.
I bought my car (pure EV Nissan LEAF) for similar reasons. I needed a new car, I liked the LEAF, and it was cheaper than any new hybrid or ICE vehicle I compared it to, and I compared a lot of them. Yeah, the LEAF costs more up front, but I estimated that, given my driving patterns, I'd break even in just under six years due to the much lower fuel cost -- and that's without considering tax credits. With the tax credits (which which I disagree philosophically, but that's not going to stop me from reducing my tax liability in any way I legally can), the break-even point was just over two years. And I didn't even consider the much lower maintenance costs (the LEAF's maintenance schedule is hilarious... basically you rotate the tires every 7500 miles, and every 15000 miles you have someone look it over to make sure nothing is wearing or breaking).
Of course, the EV isn't usable for road trips, and there are a number of other limitations. But that's okay because I need more than one vehicle anyway. It does a great job in the role it fills, and it's cheap to own and fun to drive.
Slashdot may, at first glance, appear to be the intelligent and knowledgeable 0.01%, but it is really the idiotic 99.999999999999%
So, you're saying slashdot is everyone?
(You'd need 10^14 people -- more than 100,000 times the population of the planet -- in order for the 0.000000000001% to equal one person.)
I see no reason why their implementation would be any more secure than the applications I've already chosen.
Well, if the app you've already chosen is Adobe's, you should look at the history of vulnerabilities on it and Chrome's viewer. You'll see reason.
I believe Adobe Reader has its own sandbox so this might seem a bit weird... but at least one thing Chrome has going for it that Reader has not is that Chrome is more likely to be up-to-date
Not to mention the fact that the Adobe Reader has a long, rich history of serious security defects. The Chrome viewer has a big security advantage over Adobe Reader: It's not feature complete. Adobe has packed so many arcane capabilities into PDFs that it's a nightmare trying to support everything and keep it secure. The Chrome viewer doesn't do all that stuff that's hardly ever used in practice, so there are many classes of security vulnerabilities the dev team doesn't have to worry about. This means that occasionally a real, non-malicious PDF will require you to use a different reader, but I think that's a reasonable tradeoff.
Giving the pilots guns just makes it likely they'll "go back" to try to solve the problem.
You're projecting. This is very similar to the old "blood in the streets" argument against legal citizen carry... but directed at people who are already in positions of extreme trust and responsibility, making it even weaker.
To say nothing of the fact that it makes it far easier for a single pilot to take over the entire flight deck.
Meh, that's trivial anyway. Just wait until the other guy takes a nap, then bean him with the fire extinguisher.
The problem with blowing a small hole in a plane isn't the air rushing out so much as the risk of the metal tearing under pressure and turning a small hole into a huge one.
That only happens in Hollywood. Watch the MythBusters episodes on this topic. If you don't find their own testing convincing, they also interview some experts.
But perhaps the most telling counterargument is that Federal Air Marshalls carry .40 JHPs and aren't concerned about using them.
The US is going chip + signature, not chip + PIN.
I predict that the US still won't have fully (or at least 99%) converted to chip&pin credit card terminals (even with magstripe fallback) by 2020.
The US is going to contactless chip & signature, and it's going to happen a lot faster than you think. Visa and MasterCard have announced they're imposing the liability shift in 2015, which will give merchants a huge incentive to deploy the new technology. Meanwhile, Google has finally figured out how to stop carriers from blocking Google Wallet, and opened up NFC on (new) Android devices to other players by offering open APIs, Apple has been quietly doing something with NFC for about two years now, ISIS has rolled out nationally (though barely making a splash as yet). Both sides of the tech are just 1-2 years from ubiquity.
As such running your battery down 20% and recharging 4 times versus running down to 20% and charging once shortens the useful battery life.
OTOH, running it from 80% down to 60% and recharging back to 80% four times is better. Lithium ion battery life is maximized by keeping the battery state of charge away from either extreme.
An F150 (assuming it would be about that size)
Why would you assume that? An electric truck wouldn't need that enormous engine compartment, so they could just get rid of it.
Basically, you would operate like a diesel locomotive, but on a smaller scale, with an alternator powering some type of traction motor. Size keeps this from working on cars
Er, Chevy Volt?
Not totally emmission free, but then neither is all electric, unless it is somehow charged off the grid as current power plants have emmissions, too.
Big power plants produce much less pollution per unit of energy produced than small ones.
You do realize that physical proximity != internet proximity?
But lowering latency is very often all about getting physically closer. The protocols we use most require a few round trips to set everything up before they get going, so whatever lightspeed delays you have get multiplied significantly. And it gets really bad when you get a bit of congestion and drop a packet or three. Long tail (95th or 99th percentile) latencies are often two to three orders of magnitude greater than median latencies, so a millisecond or two can turn into serious sluggishness from time to time. Reducing the number of hops is also useful, because routers add latency too, but when you've squeezed all you can there you're left fighting the speed of light, and the only way to win that battle is to reduce distance.
Of course, packets can take crazy routes. Physical proximity doesn't guarantee low latency, but it gives you a fighting chance, and distance does guarantee it's going to be slow.
I'm fine with armed pilots. They should be given frangible bullets suitable for use on aircraft./p
Frangible bullets suck. Pilots should be armed with jacketed hollow points, the same thing air marshals and every other sort of law enforcement carries.
Frangible bullets are lousy manstoppers. They tend to make wounds that are wide and shallow. Very ugly, but without enough penetration to reach major blood vessels they have no real effect on an attacker who doesn't decide to helpfully fall down and lie still. And yet they still penetrate walls and such much more than we'd like -- and would have absolutely no trouble blowing through the thin aluminum skin of an airplane.
The bottom line with bullets is that if they have enough penetration to be useful at stopping a person, they're going to be able to pass through a few walls.
But, really, it's not a problem. Airplanes aren't airtight to begin with. They leak air all the time when "pressurized", but continue pumping more in to maintain the desired pressure. Punch a few half-inch holes in the skin and the pumps will just compensate by increasing the flow a bit.
The pilots should be armed with standard defensive handguns and ammunition as a last resort in case the hijackers manage to get through the locked door before the passengers beat them to death. It's unlikely they'll need their guns, but it's better to have them and not need them.
You're unlikely to see any increased complexity, unless you're actually implementing the protocol. TCP is pretty complex, but how often do you care?
As for the gain, the hundreds of milliseconds saved are really important if you are trying to create web apps with performance comparable to desktop apps.
Yes, there is a lot of need for HTTP 2.
HTTP was great when pages were largely just a single block of HTML, but modern pages include many separate resources which are all downloaded over separate connections, and have for a long time, actually. HTTP pipelining helps by reducing the number of TCP connections that have to be established, but they still have to be sequential per connection, and you still need a substantial number of connections to parallelize download. This all gets much worse for HTTPS connections because each connection is more expensive to establish.
HTTP 2 is actually just Google's SPDY protocol (though there may be minor tweaks in standardization, the draft was unmodified SPDY), which fixes these issues by multiplexing many requests in a single TCP connection. The result is a significant performance improvement, especially on mobile networks. HTTP 2 / SPDY adds another powerful tool as well: it allows servers to proactively deliver content that the client hasn't yet requested. It's necessary for the browser to parse the page to learn what other resources are required, and in some cases there may be multiple levels of "get A, discover B is needed, get B, discover C is needed...". With SPDY, servers that know that B, C and D are going to be needed by requesters of A can go ahead and start delivering them without waiting.
The result can be a significant increase in performance. It doesn't benefit sites that pull resources from many different domains, because each of those must be a separate connection, and it tends to provide a lot more value for sites that are already heavily optimized for performance, because those that aren't tend to have lots of non-network bottlenecks that dominate latency. Obviously it will be well-optimized sites that can make use of the server-initiated resource delivery, too.
Actually, though, Google has decided that SPDY isn't fast enough, and has built and deployed yet another protocol, called QUIC, which addresses a major remaining problem of SPDY: it's built on TCP. TCP is awesome, make no mistake, it's amazing how well it adapts to so many different network environments. But it's not perfect, and we've learned a lot about networking in the last 30 years. One specific problem that TCP has is that one lost packet will stall the whole stream until that packet loss is discovered and resent. QUIC is built on top of UDP and implements all of the TCP-analogue congestion management, flow control and reliability itself, and does it with more intelligence than can be implemented in a simple sliding window protocol.
I believe QUIC is already deployed and is available on nearly all Google sites, but I think you have to get a developer version of Chrome to see it in action. Eventually Google will (as they did with SPDY) start working with other browser makers to get QUIC implemented, and with standards bodies to get it formalized as a standard.
Relevant to the topic of the article, neither SPDY nor QUIC even have an unencrypted mode. If the committee decides that they want an unencrypted mode they'll have to modify SPDY to do it. It won't require rethinking any of how the protocol works, because SPDY security all comes from an SSL connection, so it's just a matter of removing the tunnel. QUIC is different; because SSL runs on TCP, QUIC had to do something entirely different. So QUIC has its own encryption protocol baked into it from the ground up.
While you're right that there are issues with the certificate-based approach, it's not nearly as bad as you describe. There are solutions already implemented that mitigate much of the risk.
One example is certificate pinning. Google already pins all Google-owned sites in Chrome. This is actually how the DigitNotar compromise was discovered; Chrome users got an error when trying to get to a Google site.
Another example is SSH-style change monitoring, alerting users when certificates change unexpectedly. That doesn't help if the MITM attack is done from the beginning or during time periods around legitimate key changes, but it does narrow the window of opportunity significantly.
Another example is multi-perspective observation... does the same certificate get returned to multiple requesters from different places on the Internet, and is it the same one the server is actually serving (the last must be periodically verified by the the site owner).
There are other possibilities as well.
Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties.
Good luck with that. You can build it, but they won't come.