But what constitutes abuse? What is seen as abusive overuse of bandwidth today is often the cutting-edge use of bandwidth that will be commonplace tomorrow. By metering bandwidth, you discourage these services from coming into existence by discouraging users, and discourage improvements in existing technology that would require more bandwidth. If we had been metered ten years ago, Netflix would still be limited to sending DVDs through the mail, Amazon Prime would have no streaming, Hulu wouldn't exist, YouTube wouldn't exist, and so on. In effect, bandwidth metering would permanently tie the hands of innovators behind their backs, and would freeze Internet technologies in roughly their current state. Future improvements would move at a snail's pace. Do you really want to do that?

And even if you ignore its effects on technological advancement, bandwidth metering is like putting a partially loaded gun to the heads of the Internet's users, spinning the barrel, and pulling the trigger. The problem with pay-per-gig schemes is that your Internet usage isn't entirely under your control. To give a non-high-tech analogy, imagine if you had an extra water faucet under your house that ran directly into the sewer, and anyone in the world could remotely turn on that water faucet, whether you were home to hear it or not. Now, would you still be in favor of paying for water by the gallon, knowing that other people outside your control could cause you to waste arbitrary, near-infinite amounts of water?

Internet usage behaves much like a house with just such a hidden, remote-controlled faucet. You're only in control of outgoing connections, not incoming connections. And even with outgoing connections, you aren't always in control. If you're running an FTP server, remote attackers can cause you to make arbitrary numbers of outgoing connections. If you're running a DNS server, the same applies (but not connections, per se). And if your computer gets bitten by any sort of virus, worm, or other malware, the command-and-control server could cause your computer to produce arbitrary amounts of outgoing traffic. And if you run software that falls victim to various amplification attacks... you get the idea. Therefore, anyone living anywhere in the world can turn your connection into a giant money pit, running up your bill arbitrarily, and there is no feasible way to prevent it without fundamentally breaking the end-to-end connectivity upon which the Internet depends.

Now in theory, we could create a new billing scheme for the Internet in which you paid for your Internet connection based only on outgoing connections, and that would reduce (but not eliminate) that risk. However, then you'd have folks who own servers getting massively undercharged because they would never pay for anything above the base bandwidth cost even though they were essentially using a lot more bandwidth. And how would you meter UDP? The truly abusive apps would move to UDP, thus concealing which end of the connection is the requestor, while leaving everyone else dealing with the extra costs of bandwidth metering without the benefits.

Therefore, the only fair, reasonable way to charge for Internet connections is an unlimited, unmetered connection, limited by bandwidth. Those who want more capacity should pay for more capacity, and those who don't won't. Ideally, this should be coupled with a temporary speed boost for the first few minutes of transfers, and you (as the user) should be able to control which computers get that boost. This provides the benefits of a faster connection to users who only occasionally need extra bandwidth, without requiring them to pay the extra cost of an always-faster connection. And those "bandwidth abusers", as you call them, would not be happy with that, and would pay the extra money for an always-faster connection.

Such "slow after a bandwidth limit" schemes seem perfectly reasonable to me, so long as all of the details are fully disclosed to the customer as part of the ISP's advertising materials (not buried in the contract terms), and so long as the connection is advertised at the rate-limited speed, not at the turbo-boost speed. (In other words the "After 250 gigabytes your speed is capped at 128 kbps" connections should be advertised as 128 kbps connections, not 50 Mbps connections. But then again, those schemes are badly broken because the boost is continuous up to a limit, rather than short-term on a per-connection basis or data-per-minute basis, so discouraging those broken schemes by calling them 128 kbps plans would be a good thing. But I digress.)

It's not just money, though. There are tangible benefits for users resulting from being tied to their Amazon account: discounts (for folks with Amazon cards), being able to see all of their Amazon purchases in the same place, being able to use the same customer service system for all their purchases, etc. It would be utterly bizarre if Amazon didn't integrate this with their own payment and purchasing system, because that's what produces the best user experience (notwithstanding the childishness that Apple is demonstrating in this regard).

Mind you, it would theoretically be possible to set up a billing system that handles Amazon payments, Play payments, and iAP payments for the same content, magically handling all the details differently depending on how a purchase was made, etc., but it would almost certainly turn into an unholy, bug-ridden, fetid pile of dingo turd pretty quickly. After all, this is the same Amazon that can't even figure out how to disable one-click purchases in a way that works reliably, the same Amazon that can't figure out how to make their parental controls distinguish between for-pay purchases and free viewing, the same Amazon that still can't figure out how to make it possible to go to the next episode of a TV series without leaving the player and navigating a web page full of too-small-to-read links, etc. I have about as much faith in Amazon's programming team as I do in the TSA....

To be fair, at least for books (the only Amazon contracts I've studied) Amazon's MFN clause is optional. You trade a higher rate for automatic price matching with other channels.

And AFAIK, Amazon also doesn't prevent you from selling digital downloads on their tablets without going through the Amazon marketplace, though they don't provide the Google in-app purchase libraries, so if you use that in your app, you'd have to find a way to provide your own copy.

Don't get me wrong; Amazon isn't without its faults. This just doesn't happen to be one of them. :-)

If I'm just waiting for something, I don't have time to watch a movie, and I don't want to watch one three minutes at a time anyway. If I'm going to be somewhere long enough to watch an entire movie or TV show, I almost certainly have my laptop either with me or out in the car.

Which doesn't work for iOS in-app purchases.

It works fine for purchases on iOS. The Amazon app uses it all the time. Amazon just doesn't allow you to buy any digital content on iOS.

Even if you didn't try to move the goalposts.

I'm really not moving the goalposts. I'm making an assumption—that Amazon is transitioning Comixology to use their own purchasing system—a move that will make them a lot more profit and will result in a better, more consistent user experience across their product lines, but a move that is fundamentally incompatible with using Apple's in-app purchasing system.

And advertise all the prices as "$7 + $3 Apple Tax"

Read the rules again. They're not allowed to charge more for an in-app purchase through Apple's store than they charge through other channels. So they either jack up all their prices everywhere or....

Those others don't have an existing credit card purchasing infrastructure that they have to integrate with Apple's App Store. In that context, your comment would be roughly like Intel saying, "Dell and HP never complained about the lack of [insert chipset feature here]" while ignoring the fact that they all run Windows and aren't trying to integrate it with their own OS.

You see, though, that's the problem. They'll likely make a lot more money as part of Amazon, because Amazon's potential reach is much broader than that of any mobile app, even if it is on both iOS and Android. And as part of Amazon, their users are going to demand that their purchases show up in their Amazon accounts, which means unifying the payment system. Supporting purchases of the same content using three separate payment processing systems (one for iOS, one for Android, plus Amazon for everything else) and tying it into back-end systems that aren't designed to handle anything but Amazon payments... well, that would be a nightmare waiting to happen.

Probably true, but if Amazon sued them on antitrust grounds, their loss of the previous lawsuit means that this could easily be seen as Apple knowingly violating the law, which could make Apple liable for treble damages. Apple would be wise to remove the MFN clause from all of their contracts sooner rather than later.

Not quite true. Apple can host in-app purchases. You can also host them yourself, and you can even use in-app purchases to unlock parts of your app without delivering any content at all. Apple claims the same 30% even if they don't do anything but handle the money.

Apple handles the payments. The seller gets paid by Apple. As a buyer this is good. Sellers don't get my credit card #, they don't don't get my name, and they don't get my email address. No spam, no fraud, no BS.

As a buyer, this is sometimes good, sometimes very, very bad. With Amazon, the seller already has your credit card for non-electronic purchases. Therefore, using Apple's in-app purchase would be very, very bad for the user, for several reasons:

• Your Amazon credit card would give you only a third as much cash back for an in-app purchase, because Amazon doesn't get the discount from the CC company if Apple is the merchant of record.
• You wouldn't be able to use Amazon credit card points to pay for purchases made through Apple.
• Different purchases would get billed in different ways, depending on the type of purchase, so you wouldn't be able to easily see all your Amazon purchases in one place, and they would look different on your credit card statements.
• You would be unable to choose which credit card to use for your electronic purchases in the same way that you do for other purchases.
• It would add an extra layer of red tape between you and your ability to get a refund if something goes wrong.
• It would add extra software complexity that is likely to cause purchase failures and other glitches.
• The majority of content would still not be sold on iOS, because Apple's 30% digital royalty rate would claim Amazon's entire profit margin.

All in all, when applied to Amazon, the iAP requirement is a huge net loss for iOS users, in nearly every way.

Please name me one phone other than the iPhone that works with Amazon streaming, be it pay-per-view or Prime.

Please name one phone including iPhone that works with Amazon streaming. The Amazon Instant Video app only lets you watch content when you're on a Wi-Fi network, not over the cellular network, even if you have an unlimited bandwidth plan. I don't know about you, but if I have Wi-Fi, I'm going to use my laptop to watch the content, not a dinky little cell phone with a four-inch screen. They might as well have made it an iPad-only app.

That's just another reason why I plan to switch to Netflix when my Prime membership runs out. Just saying.

What you're clearly missing is that Amazon already has a very good payment processing system. In fact, I'd go so far as to say that it is night and day better than Apple's payment processing system in terms of its flexibility, integration across Amazon systems, etc.

If you're a mom-and-pop shop who can't afford your own infrastructure, being able to do in-app purchases through the iOS store is great, because it is much, much better than nothing, and it does provide a much better user experience than having every app ask for the user's credit card number. However, if you're Amazon, it means giving a worse user experience to iOS customers even if they agreed to support it, because it won't ever work as well as using your existing Amazon stored credit cards. It would necessarily be a horrible hack, and that's the best-case scenario.

In my studied opinion, Apple's position on this goes way beyond absurd. Their "logic", if you can call it that, is that because the user bought an app through Apple's App Store, any sales bought through that app are the result of sales leads that the company wouldn't have gotten were it not for the App Store—because the users must have heard of the service through Apple. That might be true for a minor app that only exists in the iProducts world, but for Amazon's apps, it's ass backwards because:

• Nearly 100% of those users were already Amazon customers before downloading the app.
• The only reason the users downloaded the app from Apple's store is because they can't get the app onto their device in any other way. Were that not the case, they would have downloaded it from Amazon's website instead.

Therefore, Amazon owes Apple absolutely nothing. If anything, Apple owes Amazon a portion of ad revenue on every device that contains Amazon's apps, because the availability of Amazon's highly popular apps results in increased sales of iOS devices. Of course, the higher-ups at Apple would s**t kittens if anybody suggested such a thing, but there you go.

To make matters worse, Amazon isn't in control of their prices. Those are dictated by the publisher. For small publishers, they pay either 35% or 70% to the publisher, depending on what countries you're selling in, etc., potentially leaving as little as 30% of the purchase price as Amazon's total profit. And for larger publishers, I'd imagine they accept even smaller profit margins. Therefore, Apple is effectively claiming that Amazon should pay them every cent they make on the transaction, all for the privilege of being able to sell^H^H^H^Hgive away their content on iOS devices. Umm... NO.

IMO, what is needed is for a major player like Amazon to call Apple on this bulls**t and sue Apple for permanent injunctive relief, demanding the immediate removal of the "in-app-purchases only" requirement from Apple's iOS App Store terms and conditions. It constitutes unfair competition by a monopolist (at almost half of U.S. smartphone market share, iPhone/iPad are plenty big enough to fall under federal monopoly rules) against their competitor (Amazon also builds tablets), and therefore is prima facie illegal restraint of trade in this situation. If Amazon were willing to actually take this to court, I have very little question but what they would win, and win handily, at which point iOS would be forced to open up to a proper competitive market for in-app-purchase systems, and Apple would be forced to fairly compete based on quality of service, ease of use, and ease of integration. In the long run, that would result in a much better user experience, a much better developer experience, and more money for Apple, even though they would hate it in the short term.

I'm not holding my breath, because I don't think Amazon has the testicular fortitude to actually sue Apple, but it badly needs to happen. This contract term has always been dubious in its legality, and it should have been challenged years ago. The result of this stupidity is that even if you know you want to get a Netflix subscription, you can't just download the app and get a subscription. You can't even get a link from the app to the website to buy a subscription, because that would violate Apple's rules. So the iOS user has to manually run Safari and type in www.netflix.com, buy their subscription, and then run the app. This stupidly painful user experience (which affects a growing number of apps) hurts the iOS user experience and damages the brand, which is why Apple needs to be stopped for their own good.

BTW, I'm usually a rabid Apple fanboy, and I've defended Apple on many occasions when other Slashdot users call them out. For me to call Apple on their crap means you know they're doing something just amazingly wrong. I do understand Apple's desire to avoid, as I said, having every app ask you for a credit card number, and I would not at all object to Apple requiring that all purchases be made through either Apple's iAP or through a reputable payment system (where Amazon clearly is, Paypal might or might not be, and Joe's Merchant Account Processor And Shrimp Shack definitely isn't). However, requiring all apps to use a different payment system on iOS than they use on every other platform is truly the height of arrogance, particularly when that payment system is one that those customers are almost certainly already using outside the iProducts ecosystem. Such requirements are morally and ethically wrong, and legally dubious beyond words.

Are you managing to keep the bird on the auto-focus point (or the majority of points for multipoint focus)? While you're tracking it? Including when you press the shutter?

This is where AF point expansion on the current-generation DSLRs comes in handy. But for any camera more than a couple of years old, yes, it's rather a pain, and the keeper rate often isn't great. Of course, depending on how fast the bird is moving, at 300mm, even with IS, half the time, I can't keep the bird fully in the frame, so focus is the least of my problems when taking bird photos. I'm better with people. ;-)

Most people will mangle the bird in flight on an auto camera because the shutter speed was too long and the photographer's tracking wasn't perfect (and the bird did something silly like flap it's wings).

True, full auto isn't great for those situations except maybe in bright sunlight. If I'm anticipating taking pictures of fast-moving objects in less-than-ideal light, I tend to use the time-value (Tv) mode—I guess you'd call that a partial auto mode. I set the shutter speed to ensure a reasonably crisp photo, and let the camera worry about changing light levels by adjusting the aperture and ISO settings automatically to get the best picture that it can manage.

Most of the point and shoot I've used refocus when you actually shoot, so there's an extra second while it adjusts, while the bird disappears from your view. Most of those either focus on the clouds, some tree on the horizon, or tall grass in the foreground.

Agreed. The contrast detection autofocus that they use on point-and-shoot cameras (and on DSLRs in live mode) is mostly a train wreck. They're using the image sensor itself to determine whether the image is in focus, by adjusting the focus in each direction to see if doing so results in increased contrast in a particular part of the photo. Therein lies the path to madness. It's amazing that it works at all. :-)

I'll be interested to see how well Canon's new dual pixel autofocus does at solving this problem. In effect, it turns the entire image sensor into a phase detection AF sensor similar to what you get with a DSLR when used with the OVF, but with a ridiculous number of autofocus line sensors of fully adjustable length, and nearly infinite ability to do motion tracking across almost the entire sensor area. I'm looking forward to the day when DPAF appears in DSLRs for live view purposes. If it works as well as Canon implies, then when combined with decent motion tracking algorithms (and, in an ideal world, eye tracking), it promises to make manual focusing mostly obsolete except when using lenses that don't have AF capabilities.

Sharply limit password tries before account lockout

No, don't. Besides the DOS problem that other folks have already mentioned (which can be solved by doing per-IP bans), there's also the "Your site isn't as important as you think it is" problem.

Most folks have a handful of low-security passwords that they use for sites that they don't care about. If you limit the number of login requests to anything less than about ten, a user who hasn't logged in for a while won't remember which of those old passwords he or she used, and will hit the limit before successfully logging in. At that point, the user may just not bother to visit your site anymore, or worse, may create a second account.

No, good security requires multiple levels of security, depending on the harm that allowing the action would cause. For example:

• Amazon won't let you ship to a new address without reentering some of your credit card info.
• Banks won't let you add a new account for transfer without some additional verification.
• Good banks will contact you before authorizing a large transfer to a new account.

These techniques significantly reduce the damage that can be caused by someone breaking into your account.

Unfortunately, too many organizations use security questions for their additional verification. Security questions need to die already. They are an almost completely useless form of verification, because (unless you're smart enough to lie in your answers) they're highly vulnerable to identity theft.

As of this writing, we lack a robust, general-purpose second factor for authentication purposes. Email doesn't work, because odds are, they got access to the user's account on your server by compromising the user's email account. Cell phone text messages may or may not work for the same reason. Even a phone call is dubious in this age of VoIP. A physical crypto token could provide an appropriate level of verification, but only if combined with a shared authentication server that can be queried by anyone, and only if broadly deployed. Otherwise, users will end up with a hundred crypto tokens in their pocket, and nobody wants that. And AFAIK, nobody is doing this.

Everyone's "real" password is crypto-strong, because there's a properly-generated cert involved, and rotated at ITs discretion with no burden on the user. But people only need to remember something easy, just something that would take more than 3 tries to guess.

That's fine for a corporate VPN, where your IT folks are at least to some degree in charge of the hardware, but it isn't realistic for websites, which is how the vast majority of e-commerce happens these days.