Forgot your password?

Comment: Android decryption (Score 1) 305

by swillden (#47939417) Attached to: Apple Will No Longer Unlock Most iPhones, iPads For Police

If you encrypt your Android phone, neither Google nor anyone else has any special access to its contents. However, there is a caveat.

In the current (KitKat) implementation of device encryption, the actual data encryption is done by standard Linux dm_crypt, which is very strong assuming the master encryption key is well-protected. The master encryption key is in turn encrypted by a key derived from your password. The derivation algorithm is good (scrypt) but it's still possible to brute force the password space. How difficult that is depends on how long your password is and unfortunately there's a clear conflict between security and convenience here. You can choose a very long password and have high confidence that it's infeasible for anyone to break it, but then you have to type that long password on your phone all the time.

Apple has undoubtedly made use of the "Secure Vault" chip they have in their devices to store a significant portion of the material needed to derive decryption keys in secure hardware, which is almost certainly configured to rate-limit brute force attempts, and eventually just to lock the device up forever. Given that the obvious and straightforward implementation of such a system would never have given Apple the ability to unlock phones, they must have decided to add a sort of "back door" for themselves, probably to rescue customers who'd locked themselves out. Now, they're removing that back door. Good for them.

Comment: Re:So much for mobile payments in Japan (Score 1) 277

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

Apple Pay is basically a contactless EMV wrapper for iPhones. SoftCard complies with EMV too, but I've seen nothing indicating that Apple Pay will work with SoftCard processors. This is purely a contractual thing though; there's nothing technical to stop it from working.

There aren't even any contractual issues, because there is no such thing as a "SoftCard processor". SoftCard transactions are processed by normal merchant acquirers, through normal clearinghouses and back to their issuing banks. Nothing in between even knows it's not a plastic contactless smart card chip. The same is true of Apple Pay, with the exception that at some point in the network the network token gets translated into a issuer-specific data (SoftCard gets issuer-specific tokens delivered to the device).

Google Wallet is different because Google is acting as the issuing bank for the Wallet proxy card, so Google does have to process payments, charging them back to whatever backing instrument you have selected (which needn't be a credit card).

Basically, you can't roll out something like Google Wallet for an iPhone, but you can support all sorts of NFC payment types with it.

Well, on any network that supports network tokenization, which, so far, is only AMEX, MC and Visa, and only in the US. Discover supports contactless smart card payment, but doesn't support Apple Pay (yet; I'm sure they will) because they have to implement the necessary pieces.

Comment: Re:So much for mobile payments in Japan (Score 1) 277

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

Can you put the above mentioned smart card reader apps into a kind of promiscuous mode? It would be interesting to have your android device in your pocket in a crowded bus or elevator to see what info it could capture.

Sure you can. You won't get much, though, for three reasons.

First, NFC is really short range. Like, less than a centimeter in practice. So you'd pretty much have to actually bump your pocket into another pocket containing a phone or contactless smart card (in a very thin wallet).

Second, at least with Android phones that you might bump into, if the screen is turned off, NFC is turned off, so most of them won't respond.

Third, and most important, the whole point of smart cards is that they're smart. They're microprocessors which implement secure challenge-response protocols, and are picky about what information they'll share with anyone who doesn't authenticate properly. NFC is just smart cards in a different form factor.

Comment: Re:So much for mobile payments in Japan (Score 1) 277

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

You can transfer pictures, files, and anything else apps care to support.

Apple already has that capability; but it's far less caveman-like. It's WIRELESS. So, if you have already gotten into your respective vehicles, you can still transfer the information... Yes, I'm talking about the almost ubiquitious "Share" Button. Your data-transfer method reminds me of the Zune's "Squirting" feature. How quaint. We iOS users have the internets for that.

You didn't read my post. Android also uses the Internet for file transfer; it uses NFC to make indicating which device to send it to as easy as tapping the phones together. Obviously there are other options if you like typing or picking from lists, the way you have to on iOS.

Oh, and if NFC were the actual data transfer mechanism, it would also be WIRELESS, because it is wireless. Radio frequency. But at just shy of 1 megabit per second it would be a little slow for moving large files.

Comment: Here's how (Score 1) 145

by IPFreely (#47939031) Attached to: Ask Slashdot: How To Pick Up Astronomy and Physics As an Adult?
I've gone through this. Here's how you do it.

Start gathering a few popular science books on subjects directly on and also near to your goal. Some people reject popular science books as too light weight, but it does have value. This exposes you to the variety of subjects in and around your interest. You might not have been aware of some aspects of your topic and you are introduced to them here without too much effort. You also learn to associate detailed technical topics to the wider areas where they are used.

Read the whole book. Books are better than random google searches and videos because they will guide you into areas you might not have considered relevant. Broadening your base knowledge will allow you to make a more informed decision about your favorite topics. Once you have a broader and more informed understanding of the topics and areas involved, you are better able to identify your interests, or even switch interests.

That is when you start going into a more detailed dive into your target topic. Follow through and read the whole thing. Again, pick one or more text books or deeper science books. The purpose again is to guide you into areas you might not have considered before.

This time, you will hit lots of technical subjects that you might not know. That is when you go searching for online information, wikipedia, online course videos, Youtube content or other textbooks. For these, you will only need to cover enough to support your primary interest, and you will have a fairly good idea how much that is.

You are not going to go professional with this, but it will be more than enough to keep your interest up and curiosity satisfied.

Comment: Re:what is this even talking about? (Score 1) 78

by MightyMartian (#47937617) Attached to: An Open Source Pitfall? Mozilla Labs Closed, Quietly

Indeed. And quite often even dead FOSS projects can be cannibalized. The difference between dead open source and dead closed source projects is that the bones of one sit in an open pit that anyone can pick at, and the other sits in a concrete bunker twenty miles underground.

Comment: What? (Score 0) 259

by argStyopa (#47936329) Attached to: FCC Chairman: Americans Shouldn't Subsidize Internet Service Under 10Mbps

Isn't this sort of a 2014 version of the phrase "Let them eat cake!"

Parallel statements:
Poor people shouldn't have to ride the bus, we should all just give them cars - and not crappy econoboxes, something nice.
We should give homeless people luxury condos on the seaside.

I mean, if you're talking about a SUBSIDIZED service, shouldn't it BE subpar? Asserting otherwise is to say, in effect, "people who can't pay for stuff, should get stuff as good as everyone else" Why, then, would anyone pay for anything?

Comment: Re:Nope they are clever (Score 3, Interesting) 277

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 5, Informative) 277

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.

"Be *excellent* to each other." -- Bill, or Ted, in Bill and Ted's Excellent Adventure