I'm not sure I agree with that assessment. I know we often talk about peering meaning an equal amount of traffic, but that's largely historical baggage. The direction of traffic is essentially arbitrary when it comes to the cost of setting up a network. If you know you're going to have asymmetric data flow, you just use more channels in one direction than the other. AFAIK, such configurations are possible over most network links.

More to the point, it really doesn't matter which side is pushing and which side is pulling. Both parties benefit from a better experience for their customers, which in this particular case are the exact same people. And although both companies have a vested interest in ensuring that the customer experience is good, if anything, Comcast has the most to lose if it isn't (assuming the particular customer has any choice in ISPs whatsoever), because statistically speaking, most users blame the ISP first. :-)

Either way, when it comes to no-cost peering, what's actually important is not the traffic direction, but rather that both parties send approximately the same amount of traffic through the other one to another network—that is to say, that both parties get approximately the same benefit out of the link. In this case, both of those numbers would presumably be zero, because all of the traffic Netflix would push into Comcast's network would be destined for Comcast's customers, and thus would go across Comcast's network no matter what. And every byte Comcast sent across the link would be destined for Netflix's servers.

By that standard, assuming they configured the network to allow routing only to one another rather than through one another, then the relationship between Netflix and Comcast should have been a peering relationship. Anything else is extortion by Comcast, pure and simple. And if they didn't configure it that way, Comcast should probably be paying for the peering, because it seems much more likely that Comcast would benefit from routing traffic over Netflix's fat pipes than that Netflix would benefit from routing traffic over Comcast's clogged pipes. :-)

"We are happy to inform you that as of this month, our IT infrastructure is 100% Animal Cruelty Free!"

The best part of that is the presumption that it previously was not. This is the point at which you are forced to explain to your IT director that a squirrel cage is not, in fact, animal cruelty, but rather an essential safety system. It can only go downhill from there.

Considering that similar attacks have been done in the past, yes, I'm serious.

Not necessarily even all that uncertain. I could see somebody with sufficient resources attacking this by fluctuating the building power or using focused EMP tricks to reduce entropy, thus weakening the resulting crypto.

Sadly, no, ML doesn't currently fix the 30 minute limit, at least according to its user guide. When asked about it a few months back, the devs implied that it probably wasn't practical to patch out all the different places in Canon's firmware where that limit is enforced.

How about the ability to turn to "off" to stop an engine affected by a stuck accelerator? Until the start button has a toggle or push button next to it to stop the engine, I don't want one anywhere near my car. And, when I say a button to stop the car, I mean a real kill switch that will ground out the ignition coil(s) or shut off the fuel pump or something similar, or for a diesel shut a fuel solenoid so the engine WILL die.

This. A thousand times, this.

If I lose power steering or braking I just have to steer or brake harder - ok, it sucks, but if you can't do that you shouldn't be driving. But then, I'm a firm believer that somewhere around 30% of the people on the road should have their licenses taken because they're either physically or mentally unfit to be in control of a vehicle.

The problem here isn't that a power steering failure can make it harder to steer. The problem is that the power steering and power brake pumps shouldn't have failed because of the ignition switch. These systems are mostly electrical these days, thanks to hybrids, which means there's no technical reason why you couldn't design the system such that the relay that provides power to those critical electrical systems can be held open by either the keyswitch or the computer if the car is still in motion. Such a solution would be even better than either the push-button system or the key-based system, because in the event of an emergency, you want to cut off power to the engine, but you'd ideally like to keep your steering and brake assist systems working. With a minor firmware change to one of the body control modules (assuming one of them has at least one spare output), plus about a $5 more expensive relay, you can make the ignition switch failure be a non-safety problem, while retaining its function as a safety-critical shutoff for the engine in the event of an emergency.

The only real question is why cars aren't already required to be built that way.

The reaction from Coverity was to issue a patch to find this kind of problem, but in my opinion, the "fix" throws the baby out with the bath water. The fix causes all byte swaps to mark the content as tainted. Which surely would have detected this bug, but it also leads to an enormous amount of false positives for development where swabs are common, like cross- or multi-platform development.

Yes, that solution is complete and utter crap. Claiming that marking all byte swaps as tainted will help you find this problem is like saying that arresting everyone in the entire greater Los Angeles area will reduce California's murder rate. While technically true, the vast majority of things it will consider tainted won't actually be.

POSIX networking code does byte-swapping all over the place, and almost none of those values come from user-provided data except possibly the port number (which, if tainted, would never realistically be a concern, because the legal range of the value is equal to the legal range of the integer that contains it). Half the time, you're calling htonl on a constant like INADDR_ANY. Presumably a static analyzer would ignore those, but is it any less wrong to treat as tainted the numerical IP address result of a hostname lookup?

Also, OpenSSL is rather unusual as software goes, in that it works with binary file formats. If you ignore crypto code, I'd guess that probably 95% of all user data is in a text format like XML. I can think of only one piece of software I've ever written that required byte-swapping binary, and that involved writing a tool that converted an unsupported file format into a better supported (but still archaic) file format that could then be translated into an XML format by existing tools. And even in the rare instances where I've done byte swapping on user data, I almost alwaysdo so right after reading it from disk anyway, which means that tainting the byte swapping operation misses the mark by only a few lines of code from an instruction like fopen or mmap that rightfully should cause tainting. If you don't do so, odds are, the tainted data will get used long before it reaches a byte swap operation, if it ever does. It is just as dangerous to trust an integer parsed using atoi from text that at one point was read from a file, or unserialized from a property list, or... what matters is that the data came from a file, and that it was passed to a function that returns a value derived from the data. For built-in library functions, those should be well known. For code you write, you can use static analysis to determine whether that is the case.

IMO, the only correct sane, non-silly approach to tainting is to recognize all the function calls that read data from disk, from a network socket, from the keyboard, from a UI binding, and so on, and then follow the data out from there, marking variables as tainted when you do. If there are by-reference parameters (explicitly or through pointers whose underlying objects can be modified), work your way back up to every possible caller until you the tainted data can no longer exist higher up the tree. Then work your way down the tree beginning right after each of those function calls, and working your way into every other function that those functions call, marking as tainted every variable that the data could end up in. Anything short of that just doesn't make sense. If that means the static analysis takes ten minutes instead of ten seconds, so be it. After the first run, it should be possible to incrementally update the static analysis results to remove warnings about things that have been fixed, so any performance hit ought to be a one-time penalty.

seriously speaking, under good lighting conditions phone cams have been on par with SLRs for all practical purposes for quite a while now.

Only if you're okay with a roughly f/2.0 to f/2.8 depth of field and you're no more than a few feet from your subject....

Even in good lighting, if you want to shoot with a shallow depth of field, a camera phone is likely to be softer, because you'll be shooting with the camera phone wide open, whereas you'll be shooting stopped down with an f/1.2 DSLR lens. Also, the cell phone could hit its diffraction limit as low as f/2.8, which means you can't stop it down to get a wider depth of field without the lens going soft.

And for distance, the cell phone loses horribly. A DSLR can handle a 600mm lens or longer. A cell phone is usually stuck at the equivalent of about 30mm, with only digital zoom from there.

The capped recording time is actually the fault of the European Union's import duties, which charge a higher tax rate for anything that can record 30 minutes or longer. Blame excessive government bureaucracy for your DSLR being crippled.

No. Apple pay companies by cheque once a month. It's no more difficult for Amazon that it is for any other developer. It couldn't be more easy.

Have you ever written a billing system that has to handle refunds through three entirely different mechanisms provided by three different companies? Have you ever had to explain to customers that the refund policy for product A is different from the policy for product B because you bought product A using an iOS app? Yes, it is more difficult for Amazon than it is for other developers, unless they have no intention of ever unifying the purchasing experience, which is something that they are obviously trying to do.

And then you proposed that all kinds should be allowed to have their own billing systems. Thus making life more difficult for users.

Yes. Let the market sort it out. The three companies who go off on their own and do things outside of in-app purchase without a really good reason (companies without an ongoing customer relationship outside of the iOS world) will get slammed in the press, and nobody will make that mistake again. The companies that do have a legitimate reason won't be criticized for it, and in the end, it will all "just work (out)".

Your notion that these are just other products from Amazon is simply nonsense.

My assumption is that they will eventually be "just other products from Amazon". That's normally how it works when one company buys another company. They buy the customer base, but transition all the billing and distribution. The situations where a corporation continues to operate a purchased competitor as a fully independent subsidiary are few and far between in the business world. It happens, but rarely.

That's quite an amusing irony given that Amazon imposes most favoured nation clauses on it's own suppliers!

Citation needed. As I understand it, Amazon's MFN contract clauses were mostly phased out a while back because they they were found to be illegal by a court of law. The closest thing to an MFN clause that remains, as far as I know, is Amazon's book sales option, in which they give you a better royalty rate if you agree to let them price match their competitors and pay you a percentage of the (potentially) lower price.

Of course, in the worst case, with a suitable synthetic workload in which every 512-byte block write causes a 512 KB flash page (again, worst case) to get erased and rewritten, that could translate to only a 40-day lifespan. Mind you, that worst-case scenario isn't likely to occur in the real world, but....

Again, no it's not just because it's on their platform. Apple are providing many things I already mentioned. You still aren't including them because most of them are lumped in with the original app for which Apple has usually supplied all services FREE. I've already covered that.

No, I'm not including the benefits from Apple distributing the app, because Apple doesn't allow developers to distribute apps themselves. Saying, "You owe me because you did X" doesn't really work if you forced me to do X.

And of course you're missing the fact that every business charges what the market will bear, not their costs plus a minimal profit. And in general the market is quite happy with the market they are offered for a mere 30% charge.

If the market in general is happy with that rate, then that just further strengthens my assertion that Apple doesn't need a rule mandating that everyone use their service.

I can't imagine how awful that would be to integrate multiple in-app purchase systems into such a giant behemoth of a billing system. :-)

It's pretty easy. They get a cheque from Apple once a month.

I really hope that's sarcasm.

Because smaller companies almost certainly need Apple to provide the infrastructure for handling payment and distribution, whereas larger companies already have that infrastructure. To small companies, Apple's offerings are awesome, and make their lives easier. To larger companies, Apple is a leech. It's not a question of whether big corporations should get better terms. Everyone should get better terms.

You've already accepted that users don\'t want to enter their credit card details over and over for different apps. Your proposal just made users lives worse. Ergo Apple's solution is better than yours.

Huh? That doesn't even halfway make sense. What I said was that for smaller businesses who don't have an ongoing business relationship with the customer outside the iOS ecosystem, customers won't want to enter their credit card details. For large companies that already process payments outside of the iOS ecosystem, like Amazon, customers have already entered their credit card details when they created an account with the company.

If you use Apple's in-app purchase system for digital purchases from iOS, then suddenly you have a situation where one purchase on Amazon follows one set of refund rules, and another purchase follows a different set of rules, solely because of what device was used when the user purchased it. This tends to result in confused and angry customers. It also means that some of your Amazon charges show up on your billing statement as being from Amazon, while others show up as being from Apple. There are lots of headaches associated with a company providing some content through in-app purchase and other content through a separate system, both for the company and for the users..

And if you extend in-app purchases to other digital products sold via Amazon (e.g. the online videos), it would mean that the prices have to go up for everyone by 30% so that they can comply with Apple's most-favored-nation policy, which doesn't let them charge more to buy content through in-app purchase, thus pricing Amazon out of the market entirely, and giving Apple's iTunes Movie Store an illegal competitive advantage. That's where this really becomes a potential problem for Apple.

No, they charge you 30% for the access to a marketplace of hundreds of millions of people who are actually willing to buy stuff and can simply do so with the click of a button.

Not at all. Apple already provides free access to that marketplace through Safari, and even lets you create a web app and save it to the home screen if you want a more app-like experience. Apple only charges you 30% if you want to sell stuff in your own native app.

Further, the notion that Apple somehow brings additional customers to the table is just laughable when you're talking about Amazon. Both names have comparable brand recognition, and Amazon has almost as big a worldwide customer base as Apple, with a very high degree of overlap. It is safe to say that Apple has brought zero or near-zero customers to Amazon through Apple's App Store who weren't already customers, and it is remarkably unlikely that this statistic will ever change, as both companies are growing very quickly and are pretty much targeting the same people.

So what you're saying is that Android take a cut of either 30% or 65% to list the comic on their market. Without any criticism. Yet others here are arguing that Apple is charging too much at a fixed 30%.

You're comparing apples and oranges. Amazon takes a cut of 30% or 65% to sell your book, makes it searchable as part of their listings, and distributes your book. Apple takes a cut of 30% for merely allowing you to sell content using an app that you wrote, solely because that app is running on their hardware platform. For that 30% cut, they aren't providing any sort of public listing (your app provides the listing). They may or may not be providing asset distribution (the app developer can choose whether to have them do so). Often, all they're doing is handling the money. In that context, 30% borders on extortionate. It's not like selling an app, where Apple is actually promoting the app through their listing service. I can't search for a particular in-app purchase in iTunes....

As to them not being able to make it work... it appears Comixology were making it work before Amazon bought them. So I'm not so sure you are right there. To me this looks more like Amazon just refusing to let another player have the marketplace, because they feel that Amazon should be THE marketplace for everything.

Sure, you can argue that Amazon shouldn't have bought them, and that they could continue as a separate entity under that model indefinitely. But as with any other service purchased by a major corporation, once purchased, consumers would expect it to be integrated under Amazon's brand, which means integrating their billing system into Amazon's. I can't imagine how awful that would be to integrate multiple in-app purchase systems into such a giant behemoth of a billing system. :-)

Your comments that this is all about Apple having a trusted one stop shop for purchases, rather than the riskiness of typing credit card details in to some unknown on the internet is right. That is part of the reason. And the other part is that apps with in-app purchase are typically free to download and install, so Apple HAS to charge at in-app purchase time, or provide services for a loss, that others are making money from.

First, there's a big difference between charging for in-app purchases that are part of a game and charging for actual content that is also sold outside the context of the app. Just as Apple makes an exception for physical products, it should make a similar exception for any in-app purchase that is also sold outside the context of the app. That would cover everything that companies like Amazon and Comixology do, without providing further incentive for game companies to give away an app and then charge money to play it.

Second, the reason the free-to-download, fee-to-play model works is that Apple makes the in-app purchases nearly transparent to the user. If the user is forced to enter a credit card number on an outside site, that ceases to be true, and the model breaks very badly for the game developer. Because those users don't already have an outside relationship with the game developer, customers would be unwilling to give up their credit card number. Therefore, there's no incentive for game developers to use an outside payment system to avoid the fees. They would lose far more from customers' unwillingness to give up their credit card numbers than they could possibly gain in the difference between a 30% fee and a 5% merchant account fee, particularly given that the cost of the "products" is almost entirely arbitrary anyway. The market itself will prevent Apple's irrational fears from manifesting themselves in reality.

All the Apple-iAP-only rule does is screw over the companies that do have legitimate, long-term relationships with customers—the Dropboxes and Amazons of the tech world—by trying to extort a fee out of those companies that isn't at all justified by Apple's near-complete lack of involvement in the user's purchasing decision. The rule just plain needs to go away. It doesn't make any sense at all. It never did.

For sure Amazon is a name as trusted as Apple itself for purchases, but there might be bigger legal problems should Apple make an exception for them. Why should big corporations get better terms than smaller companies?

Because smaller companies almost certainly need Apple to provide the infrastructure for handling payment and distribution, whereas larger companies already have that infrastructure. To small companies, Apple's offerings are awesome, and make their lives easier. To larger companies, Apple is a leech. It's not a question of whether big corporations should get better terms. Everyone should get better terms.

But really, as I said, it's about an ongoing business relationship with the customer, not about the size of the company. A company that has that sort of relationship should be able to choose whether or not to pay higher fees to Apple for the convenience of not having to mess with a payment system. A company without that relationship (which inherently includes all pay-to-play app developers) doesn't have that ability anyway.

At reasonable cost bandwidth metering is fine.

Which will never happen. Nearly every ISP that has ever used a metered approach (at least for consumer connections) has had an obscenely low baseline cost, with huge overage charges. As long as the average household has access to only about 1.5 broadband ISPs, there's no competition to keep prices sane.

The infrastructure doesn't allow for every user to benefit from 10Mbs non stop. Instead it allows bursts. These bursts allow whatever content to be buffered so that it can eventually be viewed normally.

I'm not sure I follow your logic. Either the average data rate to the user is above the average bitrate of the content or it isn't. If it is, then even in the best case, bursting results in inconsistent latency for the network as a whole, because requesting a big chunk of content saturates the link for short periods of time, and nothing else can get through. If any of your network's users are trying to do any sort of interactive audio or video (e.g. A/V chat), having to share links with folks doing bursting video is very, very bad unless the routers are doing QoS smoothing. And if the network's average data rate is below the content's average bitrate, then you'll have to wait for a big chunk of the content to download before you start watching, which is a terrible user experience. There's no free lunch to be had from bursting. If anything, all the networking research papers have consistently demonstrated that bursting makes things worse on average, not better.

Or by bursting, are you really talking about oversubscription—selling several times as much bandwidth as you actually offer, under the assumption that most people won't be watching video all the time? If that's what you're talking about, then I already described the best way to do precisely that in my previous comment—providing fast data rates for a period of time, then throttling the connection to a more moderate rate, and allowing the user to specify that the boost be reserved for certain machines (e.g. not your VoD clients).

And oversubscription is precisely the reason that ISPs have always tried to push back against new technologies with greater bandwidth requirements. If given carte blanche license to limit users' bandwidth by charging by the gigabyte, they will always set prices high enough to stifle any bandwidth-consuming innovation to the maximum extent that they can. After all, why build out their infrastructure when they can charge ever-increasing amounts of money for the same amount of bandwidth? That's just the nature of for-profit businesses—particularly when they are monopolies or near-monopolies.

Fact and the matter is that charging per GB is fine. The only complainers are those who download lots of pirated content.

I'm complaining, and I don't download pirated content. Therefore, your premise is wrong. It isn't hard to burn through hundreds of gigabytes of data in a month just by watching entirely legal content sources like Amazon Prime, Netflix, etc. in the background while you work from home, or on weekends, or evenings, or whatever. And over time, the top quality tiers provided by those providers will continue to increase, because their customers demand better quality. In a pay-by-the-gigabyte rule, any customers with fast enough pipes would scream because their bandwidth bills would get too high, which means any future improvements in streaming video quality would be stillborn (except for codec improvements, of course, but those aren't free, either, because the user has to pay for the electricity to decode the more complex formats).

If the system changed to be charged per GB, routers and other devices would evolve to provide options to their owners.

There are no router options that can help. By the time the data reaches your router, even if your router drops the packets on the floor, you've already been billed for them. Therefore, if I wanted to ring up a few hundred gigabytes of traffic on your connection, all I would have to do is point a couple of machines from a fast, unmetered network at it for a few hours in the middle of the night every night, and you'd come home one day to a $200 bandwidth bill. The only way to "fix" that would be to put all the users behind carrier-grade NAT, and that brings with it a whole host of other problems.