Forgot your password?

Comment: Re:Nope they are clever (Score 2) 239

by swillden (#47935779) Attached to: Apple Locks iPhone 6/6+ NFC To Apple Pay Only

Oh google? You mean mean the Google Wallet that isn't available in large parts of the world? They need to deploy terminals? That's a fail right there.

Apple Pay will be able to use Google Wallet / ISIS (SoftCard) terminals, and vice versa. They all use the same protocols and base technology.

Apple Pay will be successful, and Apple will garner much praise for that success from people like you who don't know the industry, but what's really going to make it successful isn't anything Apple is doing or has done, but what Visa and MasterCard did two years ago, when they announced that the liability shift will be imposed in the US in October 2015. That policy change by the card networks will give merchants huge financial incentive to get all of the necessary terminals deployed, which is why many of them are now (and have been for some time) gearing up to integrate and deploy chip-capable point-of-sale terminals.

And, if you want to look at the causes for Visa and MasterCard's decision... the biggest single factor was almost certainly the deployment of Google Wallet, which moved NFC payment in the US from a "someday" possibility to "people are using it now". At the end of the day, Apple Pay will owe most of it's success to Google.

I don't want to disparage Apple too much here, though, because they have been able to do one thing of huge significance, and it is their market position and clout with the mobile network operators (MNOs) that made it possible: They helped push through the deployment of network-level tokenization. This is a somewhat abstruse technical detail, but it's pretty important.

Right now Apple Pay, SoftPay and Google Wallet all use different approaches to how they push the transaction through the networks. Google Wallet uses a "proxy card". When you pay with Google Wallet you're actually paying with a Google-issues MasterCard debit card. That's what the merchant sees. Then Google turns around and charges whatever backing instrument you've specified (Wallet balance, bank account, debit card or credit card). This approach offers maximum flexibilty; if someone dreams up some payment mechanism and Google integrates it, you can get your payments directed to it. The downsides are that (1) it's the same credit card number every time, which means that if it gets stolen and used fraudulently (which is far harder than for a magstripe card) then Google has to take on the fraud liability; (2) the point-of-sale transaction is "card present" while Google's transaction with your payment instrument on the back end is "card not present", which means if the backing instrument is a credit card Google has to eat the difference between the front and back-end transaction fees; and (3) all transactions pass through Google, which means Google sees how much you spend through Wallet and where (which has some upsides as well; I like the payment notifications it enables and the ability to look up my payment history on any device as well as the level of control it offers me). Note that Google can't see what you bought, but obviously a lot can be inferred from location.

SoftPay (nee ISIS) uses "issuer tokenization". You can only pay with credit cards from a certain (and still fairly small -- AMEX, Chase and Wells Fargo) set of issuing banks. The banks issue "tokens" which look like credit card numbers but are only good for a single use. These are stored in the secure element on your phone and transmitted to the merchant when you pay. Security is arguably better than with Google Wallet, and there are some corner cases that are less problematic. SoftPay doesn't get involved in your transactions, although there are some indications that the app may deliver information about them to SoftPay and to your carrier, though they don't provide that information back to you as a convenient transaction log like Google does. The reason the list of cards you can use is small is because each individual issuer has to get their systems set up to support token issuance. That's actually not quite as limiting as it sounds, because the majority of credit card issuing banks in the US outsource their operations to one of a couple of service companies, so as soon as those companies (First Data and Total Systems Solutions) get set up, the card options will grow dramatically.

Apple Pay uses "network tokenization". You can pay with credit cards from any integrated card network, which right now means Visa and MasterCard. The tokens are generated by the network, not by the issuer, so issuers don't have to change anything. Apple isn't involved in the transactions, and they say they don't receive any information about them. They're obviously trying to use privacy as a way to differentiate from Google Wallet, and maybe from SoftPay as well. Note that the reason I said Apple used their clout with the MNOs to make this happen is because the MNOs have been fighting to retain control of the secure element chip needed to make it work. SoftPay didn't have a problem because the MNOs are part of SoftPay. Google Wallet ultimately had to find a way to avoid using the SE, instead falling back on something called "Host Card Emulation", where the security-sensitive stuff happens on a server (though you don't need a data connection at the point of sale; it still works offline). Apple of course, tells the MNOs how it's going to be and, beyond that, since Apple manufactures all the iPhones itself with no MNO participation, Apple will have the secret keys that provide access to their secure elements and the MNOs will not, so from a technical perspective the MNOs will have zero ability to try to block or influence what Apple is doing, even if they dared. Which they don't.

Now that network tokenization is available, it seems pretty likely that SoftPay and Google Wallet will switch to it, at least for credit card-backed transactions. I expect Google Wallet will continue to support an expanding array of backend payment options, and the proxy card approach will still be required for non-CC backing instruments. So Apple did make a major technical contribution and actually helped Google solve one of the problems that Wallet has.

Still, Apple's technical achievements are incremental at best, and really Apple didn't design or build the network tokenization infrastructure, they just used their clout to get others to do it. That's worthwhile, but not nearly as groundbreaking as what Google did with the first version of Wallet.

Comment: Re:So much for mobile payments in Japan (Score 3, Informative) 239

by swillden (#47935517) Attached to: Apple Locks iPhone 6/6+ NFC To Apple Pay Only

essentially the existing SoftCard EMV standard

SoftCard EMV standard? Wow, that's like calling HTTP the Google networking standard. EMV existed long before SoftCard (formerly called ISIS), and in fact long before Google Wallet (which predated SoftCard/ISIS by quite some time)... before NFC existed, even.

Comment: Re:So much for mobile payments in Japan (Score 2) 239

by swillden (#47935499) Attached to: Apple Locks iPhone 6/6+ NFC To Apple Pay Only

put a cover on their iPhone that they can put their NFC card into and use it that way

Terminology clarification: If it's in a card, it's not NFC, it's a "contactless smart card". NFC is, specifically, a variant of the contactless smart card protocols embedded in a larger, battery-powered device. It does emulate a contactless smart card, which is how it enables payments, but it does a lot more as well. NFC devices can also act as smart card readers (note that "reader" is something of a misnomer; it's just two computers talking to one another) and they can also act as RFID tags or readers (or writers, for tags that are writable).

This broad array of capabilities, BTW, just highlights how unfortunate it is that Apple is limiting it. In Android-land, not only can you use NFC to make payments (Google Wallet, whatever the ISIS Wallet has been renamed to), but there are a lot more uses:

1. You can download one of many smart card reader apps (or write your own) and use them to read any contactless smart card you have around, including many payment cards. What you can see depends on the security protocols implemented by the card, obviously, and also depends on whether your app knows the right commands to send. If you like you can buy your own Javacards, program them, and write your own app to talk to them, to do whatever it is that you'd like to do.

2. Most of said smart card reader apps also support reading and writing RFID tags, which you can buy inexpensively. Many people have come up with uses for these, such as automatically changing phone configuration (volume, etc.) when a particular tag is scanned. My Moto X offers the ability to register an RFID tag as an unlocking device; whenever I scan one of the registered tags, my phone unlocks.

3. Ever since Jelly Bean (IIRC), Android has used NFC as a method to initiate device-to-device data transfer. On several occasions when my wife and I have been driving separate vehicles to the same location, I pull it up on Google Maps, tap my phone to hers and touch the screen, and then it's on her phone. You can transfer pictures, files, and anything else apps care to support. NFC isn't actually used for the data transfer to avoid having to hold the phones together for a long period of time, but it identifies the pair of phones that wish to do the transfer, which is then carried out through Wifi or mobile data.

... and more. Here are some more concrete examples of clever uses to which people have put Android's NFC capabilities:

Comment: System updates over dialup are painful/impossible (Score 4, Informative) 297

by swillden (#47933023) Attached to: Ask Slashdot: Remote Support For Disconnected, Computer-Illiterate Relatives

Though even an out-of-date Linux distro is going to be safer against malware than Windows, keep in mind that it's almost impossible to keep one of the major distros updated with security patches via dialup. I tried that with my father in law's computer for a couple of years, setting up a cron job to dial up automatically late at night, every night, and chip away at the downloads. It fell further and further behind.

Other than the fact that I don't know if any of them even support dialup, a Chromebook seems ideal for this application. Updates are smaller and less frequent, and ChromeOS is strongly hardened as compared to a standard distro, so it's less worrisome if they miss some. Chrome Remote Desktop would enable you to take control of the machine when needed (that actually works on any platform) and while it's painful at dialup speeds I have used it successfully.

Comment: Re:define (Score 1) 290

by swillden (#47931151) Attached to: German Court: Google Must Stop Ignoring Customer E-mails

What a content-free quote. You can easily find a dozen quotes from Google -- including in their privacy policy, which is legally binding -- which show they don't share any individual user data at all. If you can find a way to prove they're lying, you can get both the SEC and the FTC to take legal action against them.

Comment: Re:More importantly (Score 2) 358

by swillden (#47931049) Attached to: Is the Tesla Model 3 Actually Going To Cost $50,000?

Also, Brakes and Tires are functionally identical between a BMW and a Tesla, and, on the Model S

Sort of. The tires, yes. The brakes are functionally identical, but should wear much more slowly on the Model S thanks to regenerative braking. How much less depends on driving style, obviously.

Comment: Re:Fear of changing code.... (Score 1) 223

by swillden (#47930845) Attached to: Ask Slashdot: Have You Experienced Fear Driven Development?

I have also seen/heard of circumstances where "doing the minimum to keep the thing working" is allowed but actually improving the code is not because improving the code counts as "new work" and comes from a different budget than maintenance. Seems stupid but that's how some shops operate.

"The minimum to keep the thing working" nearly always implies improving the code. All developers need to realize this and stop this silly false dichotomy between "maintenance" and "refactoring".

IMO, developers know there isn't a difference but management does not.

Does management review the diffs?

Comment: Re:Anti-math and anti-science ... (Score 2) 852

by swillden (#47929687) Attached to: ISIS Bans Math and Social Studies For Children

There are obvious differences between Christianity and Islam that make Christianity able to coexist with a modern secular state while Islam is showing all over the world that it can't.

This is only because Christianity has changed. Christianity as it was during the era of the crusades, and for hundreds of years after them, not only could not coexist with a secular government, it couldn't even coexist with an ostensibly Christian government which espoused a slightly different form of Christianity.

Note that I'm not bashing Christianity here... I am a Christian. But let's not whitewash the history of Christianity.

can you imagine the Pope leading a frenzied crowd in the St. Peters square in chants of "death to infidels"

Well, historically, the Pope doesn't lead chants. Instead he just issues orders to root out and forcibly "convert" infidels via torture, to save their souls. Of course, popes haven't done that for centuries because it has become unacceptable to Christians.

Comment: Re:they will defeat themselves (Score 1) 852

by swillden (#47929619) Attached to: ISIS Bans Math and Social Studies For Children

That said, what would really make it tough for them is a lack of opposition. Their tactics tend to be very self defeating when the larger powers don't overreact and get drawn into conflict with them.

Not from any evidence I've ever seen. No larger power had given them any attention for the past year, and their numbers, financial resources, and power swelled unchecked; they only become a greater threat with time.

That's only because they're riding the wave created by previous overreactions and conficts, and the (reasonable from their perspective -- and probably correct) that if they keep at it they'll get the reaction that will justify their existence.

Comment: Re:The UK Cobol Climate Is Very Different (Score 1) 254

by swillden (#47926027) Attached to: College Students: Want To Earn More? Take a COBOL Class

yield to a hateful culture where we judge people by arbitrary qualities of the clothing they wear is an awful feeling

All cultures do that. Try being the guy at a t-shirt and sandals development shop who likes to wear a suit or even business casual. Personally, I like the t-shirt and sandals approach, but don't make the mistake of thinking you're not judged for your conformity there.

No amount of genius can overcome a preoccupation with detail.