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
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 packe
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
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.
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 kn
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.
Slashdot Mirror
This. A thousand times, this.
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.
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.
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.
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.
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)".
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.
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....
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.
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 really hope that's sarcasm.
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.
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.
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....
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. :-)
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
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.
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.
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).
There are no router options that can help. By the time the data reaches your router, even if your router drops the packe
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
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.
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.
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.
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.
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:
All in all, when applied to Amazon, the iAP requirement is a huge net loss for iOS users, in nearly every way.
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:
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 kn
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. ;-)
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.
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.
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:
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.
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.