Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Almighty Buck Android Cellphones

New NXP SoC Gives Android Its Apple Pay 122

Posted by Soulskill from the supported-by-one-used-book-store-and-a-dude-in-his-garage dept.
dkatana writes: NXP, having worked with Apple on Apple Pay, is now launching its PN66T module for secure NFC mobile transactions — for Android. It's intended to implement the same functionality of Apple Pay. While NXP claims the module is OS independent, the features clearly indicate that Android devices are the likely recipients of the SoC. The PN66T is Europay, MasterCard, and Visa (EMVCo) certified, and also supports American Express ExpressPay, thus fully covering the three big credit card companies, ensuring compatibility and interoperability with existing and future payment methods.
This discussion has been archived. No new comments can be posted.

New NXP SoC Gives Android Its Apple Pay More

New NXP SoC Gives Android Its Apple Pay

Comments Filter:

  • NXP is a huge secure element provider. (Score:5, Insightful)

    by LWATCDR ( 28044 ) on Friday November 07, 2014 @04:03PM (#48337053) Homepage Journal

    NXP making a secure element for any OS is about as shocking as nVidia making a GPU.
    That is what they do.

    • Re: (Score:1)

      by Anonymous Coward

      Yes, it is what they try to do.

    • Yeah, but see, since the apple marketing machine finally got around to making "replacing your credit cards" as essential feature of smartphones(in the US), everyone who already had all the tech to do it is eager to be the public face of doing it on Android.

      nVidia making GPUs would be "news" if somehow it became popular and cool to discuss GPUs in public.

      • Exactly what Apple also did with USB

        Everybody had USB but nobody used it until the iMac

        That's how I remember it

        • Re: (Score:3, Informative)

          by BronsCon ( 927697 )
          Actually, everybody had USB when the Mac had Firewire. Eventually, Apple caved in and added USB, then added USB support to the iPod, which was initially Firewire-only.

          • Re: NXP is a huge secure element provider. (Score:2, Informative)

            by Anonymous Coward

            Umm, no.

            Apple was the first vendor to ship machines that were USB only for peripherals. At that point USB had been on the market 2-3 years with virtually zero uptake.

            They boot-strapped the market for USB peripherals , by shipping a lot of machines that were USB only. It would have languished for at least another 3-5 years otherwise , if not longer.

            FireWire did not come on the scene from Apple for 2 years after that.

          • Re: (Score:1)

            by Gr8Apes ( 679165 )
            Sadly, the less capable, less secure, less in just about every way except "cheap" USB won out over Firewire. I'd still rather have FW800 than USB 3. Hook 2 devices up to a USB 3 hub, watch yourself get lower than USB 2 speeds, even when you only access 1 device. What a win that is. Then there's the USB security issues. I love the fact that you can take over a computer by plugging in a storage device, or is it? USB should have been restricted to keyboards and mice only, as an improvement to the PS/2 connecto
            • Firewire is a bigger security threat than USB in many ways, namely that it is a bus with direct memory access, meaning it can read and write anything in RAM at any time. The USB attack vector has nothing to do with USB itself; it's a flaw in a poor quality devices that allow their firmwares to be reprogrammed, enabling them to act as a different class of device. There is no reason Firewire would not be vulnerable in the same way, were a Firewire device's firmware made writable in the same way as the vulnera

              • Re: (Score:1)

                by Gr8Apes ( 679165 )

                Firewire is a bigger security threat than USB in many ways, namely that it is a bus with direct memory access, meaning it can read and write anything in RAM at any time.

                There is a DMA component, a quick search reveals they haven't fixed that either yet. Bah.

                The USB attack vector has nothing to do with USB itself; it's a flaw in a poor quality devices that allow their firmwares to be reprogrammed, enabling them to act as a different class of device.

                This is both wrong and technically right. It has everything to do with the design of USB, and nothing to do with any "flaws" in "poor quality devices". The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing.

                There is no reason Firewire would not be vulnerable in the same way, were a Firewire device's firmware made writable in the same way as the vulnerable subset of USB devices; only the exposure would be worse, given Firewire's DMA. Likewise with Thunderbolt, as it also has DMA.

                Might as well add expressCard, PCI, PCIExpress, and anything else with DMA capabilities.

                I love the fact that you can take over a computer by plugging in a storage device

                Citation? Maybe there's something I missed, but I think you're thinking of this [pcmag.com], in which case: Nope. Well, no more than a device with direct memory access. In fact, a little less.

                I was referring to WIred's story [wired.com]

                Also, maybe try getting a USB3 hub that i

                • There is a DMA component, a quick search reveals they haven't fixed that either yet.

                  You mean that drivers can determine whether they, themselves, require DMA? That's no worse than the device having DMA itself; in fact, it's damn sight better, given that Firewire device doesn't even have to identify itself, let alone have that identity accepted by the system, to gain that level of access, meanwhile a USB device must identify itself as a device whose driver required DMA, that driver must be present, and it must emulate that device well enough to fool the driver into actually talking to it;

                  • Re: (Score:1)

                    by Gr8Apes ( 679165 )

                    meanwhile a USB device must identify itself as a device whose driver required DMA, that driver must be present, and it must emulate that device well enough to fool the driver into actually talking to it; the bar is a fair bit higher with USB than DMA.

                    I didn't see any of that in the Wired story. It essentially stated: "plug it in, it infects your PC, Antivirus software is useless, and future USB devices plugged into your system can be infected". When Bruce wrote about it [schneier.com] along with quite a few others, the evidence seems to point to a rather bad security flaw.

                    If you're worried about USB, you need to be terrified about the other busses in your system.

                    The short answer to this one is I only usually have 1 set of devices that are relatively permanent for those other buses. It's not a thumbdrive that gets passed around.

                    Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub? Also, if not a hub, why did you say:

                    "Hook 2 devices up to a USB 3 hub, watch yourself get lower than USB 2 speeds"?

                    I'd figure there'd be no reason to mention a hub if you didn't use one.

                    All USB controllers on motherbo

                    • I didn't see any of that in the Wired story. It essentially stated: "plug it in, it infects your PC, Antivirus software is useless, and future USB devices plugged into your system can be infected". When Bruce wrote about it along with quite a few others, the evidence seems to point to a rather bad security flaw.

                      Well, as USB itself does not provide DMA (again, this is requested and handled at the driver level), a USB device can do absolutely nothing until the system recognizes it and starts talking to it (e.g. via a driver). You clearly didn't follow what you've read, or you'd understand that the nature of this vulnerability is that many devices don't have firmware programming disabled and can be reprogrammed to behave as other devices (in fact, you do seem to understand this, as you said "The problem lies in that

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      Which, of course, means the devices have to be identified by the system and a driver has to exist for whatever they identify as.

                      I was relatively sure that part of the problem was that the system's USB controllers could also be coopted by plugging in a bad USB device, whether the system recognized said device or not. At that point, as long as your system recognizes any USB devices, you're toast. Correct me if I'm oversimplifying the problem.

                      Firewire is still fairly widely used in media production, and the devices using it include cameras, control boards, and DAT decks, which do get passed around.

                      Yes it is, although disappearing rapidly, at least from the set of cameras I looked at last year.

                      And without USB, where do you think you'd plug that thumb drive?

                      I could see thumb drives going to a ROM only version in the near future. That solves the trust issu

                    • I was relatively sure that part of the problem was that the system's USB controllers could also be coopted by plugging in a bad USB device, whether the system recognized said device or not.

                      Then you've not read up on the issue as much as your stong opinions on it would seem to imply.

                      Correct me if I'm oversimplifying the problem.

                      I've been trying...

                      I'll also bet your SSDs are on SATA connections, those are 1:1 internal, you mention that yourself.

                      You know what else I mentioned?

                      Then why don't I see an issue with it when I connect 2 portable drives (bare enclosures in which I've put a couple of Samsung SSDs) via a USB hub?

                      Indeed, I've been trying in vain, as you clearly don't read. Mind you, these are drive I use every day for high-speed media transfer. I'm sure I don't know WTF I'm talking about, though, and the world is just bending to my will. Right?

                      As you've shown a complete unwillingness to actually consider that you may be wrong, or to even read the posts you're replying to,

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      As you've shown a complete unwillingness to actually consider that you may be wrong, or to even read the posts you're replying to, let alone the linked information (because you're likely sure it'll prove you wrong), I think we're done here. I'm sure anyone reading this will have read everything, leaving you the only one who still thinks you're right.

                      And yet you completely ignore the reference to the explanation of why USB speeds are far far lower than what you'd expect, and why your sanctimonious statements are nothing more than anecdotal hot air. Take a good look at the following snippets: From the spec:

                      At a 5 Gbps signaling rate with 8b/10b encoding, the raw throughput is 500 MBps. When link flow control, packet framing, and protocol overhead are considered, it is realistic for 400 MBps or more to be delivered to an application.

                      Just 1 Samsung SSD

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )
                      Somehow

                      ASMedia controllers deliver the best performance... isn't enough to push past 300 MB/s to the interface's peak potential

                      got dropped prior to the line:

                      "Now we're down to 300 MB/s."

                    • Forgot to log in... yes, that post was mine.

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      You're still side-stepping. I stated:

                      • there were performance issues with the USB bus.
                      • running multiple connections on a single bus drop performance way way down.
                      • USB can be compromised with merely plugging in an infected USB device.

                      These are all true statements backed by references. I note that you mislead frequently by bringing in unrelated items (Tbolt, DMA, intentional confusion about hubs, etc). Because I keep moving back to these points mean I'm staying on topic, instead of going down whatever

                    • there were performance issues with the USB bus

                      Were. Moving on.

                      running multiple connections on a single bus drop performance way way down

                      Not nearly to the levels you claimed. I have not disputed that there is a performance impact; in fact, I discussed that in one of my posts.

                      USB can be compromised with merely plugging in an infected USB device.

                      It cannot. You need to actually read up on BadUSB. I've pointed you to a few references, and you've pointed out a few, yourself, that you've clearly not read, or at least not understood. It's either willful ignorance, you not being willing to adming you might be wrong and go back and actually read, or you simply are incapable of understanding the subject

                    • Typo... adming == admit

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      there were performance issues with the USB bus

                      Were. Moving on.

                      running multiple connections on a single bus drop performance way way down

                      Not nearly to the levels you claimed. I have not disputed that there is a performance impact; in fact, I discussed that in one of my posts.

                      Still are, per your own admission. But moving on.

                      USB can be compromised with merely plugging in an infected USB device.

                      It cannot. You need to actually read up on BadUSB. I've pointed you to a few references, and you've pointed out a few, yourself, that you've clearly not read, or at least not understood.

                      I trust certain people when they say "it is 'x' bad". Bruce is one of those. I briefly reviewed this again, and what I get out of it is if the bus is alive, this works. Obviously, if the bus is disabled, it's not going to be infected. So, is Bruce wrong?

                      BTW, I did learn that Macs since 2012 are no longer subject to the DMA attacks.

                      Yes, by way of disabling DMA for the Firewire bus.

                      Interesting, thought it was to create a virtually mapped 4GB space, thus preventing random reading of the lower 4GB of potentially OS memory which shouldn't have that significant an impact on performance. That

                    • Have you reviewed the two links Bruce added to his post on the issue? I suggest you do. The attack works by a USB device being reprogrammed to behave as a different device; logically, that would require that the host system recognize it as that device. A USB device without a driver does nothing. Period.

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      I reviewed them more carefully. I get the following: if the USB bus is active and in use, at least some of the attack vectors work. Perhaps part of the miscommunication is that BadUSB isn't just 1 attack, but many different potential ones. I wrap them all up (perhaps incorrectly for this discussion) as a single attack vector. While being a supported device certainly expands the range of attack possibilities, being unsupported by no means eliminates the threat. The controller on the host can still be reprogr

                    • Slashdot doesn't like posts with too many quote blocks in them, so I have to break up this reply.

                      I reviewed them more carefully. I get the following: if the USB bus is active and in use, at least some of the attack vectors work.

                      BadUSB, by name, is a specific attack that requires cooperation of the host.

                      Perhaps part of the miscommunication is that BadUSB isn't just 1 attack, but many different potential ones. I wrap them all up (perhaps incorrectly for this discussion) as a single attack vector.

                      And there's our problem, yes. Perhaps, now that we've identified that, it's worth continuing this conversation.

                      While being a supported device certainly expands the range of attack possibilities, being unsupported by no means eliminates the threat.

                      But it does eliminate the threat we're discussing here.

                    • The controller on the host can still be reprogrammed, for instance

                      In theory. In practice, it is the controllers on the devices that are being left in a programmable state; host controllers conforming to the spec aren't programmable from the USB bus, so a system susceptible to such an attack would be so in spite of the USB spec, not as a result of it. This is not BadUSB.

                      and the bus communications can be sniffed

                      Yes, as with any serial bus. However, the spec allows for shutting down ports with no recognized device connected, so the device would have to be recognized, or the host controller not compliant with the sp

                    • in fact, several attack vectors occur before the OS is even in play

                      In fact, only one theoretical attack, based on a host controller violating the USB spec, occurs before the OS is in play (for purpose of a USB keyboard, the BIOS or EFI is the OS). This was discussed earlier in this very post and it is not BadUSB.

                      Finally, most systems will enable the keyboard USB device, so any claims of the original device not being supported are moot, since it can spoof itself as anything at any time, including the keyboard.

                      Wow! Now that is BadUSB! And if it spoofs a keyboard, it can do anything a keyboard can do. Nothing more. You can do some pretty awful things with a keyboard (as you've shown), but nothing on the level you're freaking out about. Spoofing a network adapter and sniff

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      you, sir, are wrong. That's what BadUSB is, reprogramming a device to behave as another device. Nothing more. Does it enable a variety of attack vectors that were previously impractical? Yes. But it doesn't do so entirely silently. I suggest you familiarize yourself with the USB spec [usb.org] to further your understanding on this matter.

                      I see where the problem is, BadUSB isn't at all what you think it is. Your hubris is poking you in the eye again. From the Wired story:

                      That’s the takeaway from findings security researchers Karsten Nohl and Jakob Lell plan to present next week, demonstrating a collection of proof-of-concept malicious software that highlights how the security of USB devices has long been fundamentally broken. The malware they created, called BadUSB, can be installed on a USB device to completely take over a PC, invisib

                    • Really, familiarize yourself with the USB spec, then apply that knowledge to what you already know of the security vulnerabilities discussed in the articles we've both linked to. For the record, Wired isn't exactly a first-class source.

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      For the record, Wired isn't exactly a first-class source.

                      No, but I suspect you'll also find some issue with Nohl and Lell's presentation [srlabs.de], and also perhaps the BadUSB homepage [srlabs.de].

                    • No, those are both very good sources for information on the problem SRLabs discovered. In fact, I referenced their presentation (one of the links on Bruces post that I suggested you review). Your understanding if the issue at hand is still way off, which is why I referred you to the USB spec, so you can educate yourself. The only way in which a BadUSB "infection" can persist on a host is if that "infection" modifies files on the host, just as with any other infection. It's persistent on the affected USB dev

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      Since I managed to find that last quote on my own, but I still cannot find any reference to DMA in relation to BadUSB, I'll ask, instead, for a quote or reference for that. Again, greatly appreciated.

                      I think we've addressed everything else, so I'll clarify this one: the reference to DMA was to FireWire et al security issues, and the fact that DMA access won't allow you to reprogram your BIOS/EFI, at least not as far as I'm aware of. I meant nothing more by this statement, nor did I mean to imply that USB allowed DMA access.

                      To sum up, BadUSB is a demonstration program of a collection of USB attacks allowed by a combination of poor spec security and bad controller implementation. If the USB bus is live,

                    • The point is that this shows the depth of what can be done given the current implementation and spec design short-comings

                      Except that these aren't shortcomings of the spec and, in fact, are never presented as such by Nohl and Lell. Quite the opposite, it is stated in their presentation that you (as a user) want these design features, the ability for a device to be multiple things (e.g. a video and audio device, a-la a webcam) and the ability for a device that can't talk to its driver to reattach itself to the bus as a CD-ROM drive to provide the driver. They referred to these as features, not flaws, and very clearly placed the

                    • Re: (Score:1)

                      by Gr8Apes ( 679165 )

                      Except that these aren't shortcomings of the spec and, in fact, are never presented as such by Nohl and Lell...They referred to these as features, not flaws, and very clearly placed the blame on the devices, stating that the fix is to make the devices themselves not reprogrammable.

                      I agree that they are features, and that the devices being reprogrammable is a problem. That still doesn't alleviate the fact that a bus designed to carry adhoc device traffic has 0 security features associated with it. There's no cryptographic signing, no validation. No notification that a new device hooked up. Etc. Those are the deficiencies in the spec. It's like saying that DOS has no design flaws related to user security. You can argue that there was no intent to provide system security, but that prove

          • You obviously were not old enough to actually live through the 90's because if you had you would know that:

            1) USB was not even part of the original Winows 98
            2)Apple released the iMac in 1998 and only had USB ports, dropping all legacy ports
            3) the iMac was released three years before the iPod
            4) You suck at history

      • Anybody who wants to perform financial transactions via an RF protocol should have their head examined.

        • As opposed to what? A mag stripe?

          An NFC chip requires the device be within millimeters of a terminal to activate. The payment system itself is anonymous and provides perfect forward secrecy of your financial information. To activate the payment you have to have to authenticate. That can be done with a pin or in Apple's case, a thumb print.

          I will take that system over a stupid mag strip or even a chip and pin.

          • Before NFC was even common in cell phones yet, a security researcher, Christopher something -- I don't remember his last name but he's the same guy who read (and copied!) passport RFIDs from his car 30 feet away in San Francisco -- showed that with a few hundred dollars worth of body-carried equipment, you could snarf NFC credentials from phones from several FEET away. And the phones only had to have NFC turned on... they didn't even have to be engaging in a transaction.

            That's called "broken".

            There ar

            • RFID technology is a diverse group of tech. NFC requires near contact to activate. RFID used in passports are not NFC, broadcasts without authentication and does not encrypt the data. NFC is nothing like that.

              • Please read my comment again, because you seem to have missed most of it.

                I wasn't comparing this to RFID, I was just saying it was the same guy who did both.

                It was proven that not only can NFC connections can be made from any arbitrary distance, credentials can be snarfed even when the phone is not making a transaction.

                Distance for a transfer depends solely on the equipment used and size (or architecture) of the antenna. Anybody who knows much about RF will tell you the same thing.

  • Why should I care? (Score:4, Funny)

    by danbob999 ( 2490674 ) on Friday November 07, 2014 @04:26PM (#48337227)
    I have a credit card since I am allowed to have one. I use it for all my purchase. It has never been cloned or compromised. New versions with chip and pin seems secure enough. Even if it wasn't, I am not liable in case of a fraud. So why would I want another payment system that would be more secure? At least my credit card doesn't run out of juice after 1-2 days in my pocket.
    • Comment removed based on user account deletion

      • 1st world problems.

        Visa in my country has been quick to upgrade their pos terminals for contactless payment. Who needs an iPhone?

    • My physical credit card (normal mag stripe) is compromised at least once a year and sometimes more often. I might not be liable for the fraud, but it is VERY inconvenient when it happens, the card gets locked out, plus it also causes my bank to start verifying more of the transactions which is just as inconvenient if I don't answer the text message quick enough and the card gets blocked for no reason.

      It got so bad that around 2 years ago I got a second credit card so I could file it with trusted sites like

      • Re: (Score:2)

        by jo7hs2 ( 884069 )
        Ditto. My number has been compromised about once a year for the past four or five years, too. It is why I keep a second credit card I use only minimally (for subscriptions like Netflix) for emergencies, and why I never expose my bank card number to anybody but the bank. The only benefit is that I get a nice new card...otherwise just really annoying few days without my card every year. In every instance, it wasn't a swiper or a stolen card, it was a data leak at a mid-sized or larger retail outlet.
    • in the form of higher merchant fees. A substantial amount of the fees Card Issuers and Merchant Banks charge is to cover the inevitable fraud. Cut that down and the merchants get charged less (there's tonnes of competition in the payment world, contrary to popular belief. Just look at Square). Merchants get charged less are likely to pass less of those fees on to you. So there you go.

    • Re: (Score:2)

      by Ancil ( 622971 )

      At least my credit card doesn't run out of juice after 1-2 days in my pocket.

      Give it to your wife. She can make that happen. [rimshot]

  • So another quick-pay scheme, intended to snoop a few seconds off the time it takes to do a payment (and a few percent of the money..) Now if they would implement a quick-get-rich scheme the same way I would be all ears :)

  • NFC alone isn't enough (Score:3, Informative)

    by m.dillon ( 147925 ) on Friday November 07, 2014 @06:04PM (#48337757) Homepage

    You need NFC (which many Android devices have had for years)... but you also need an actual secure chip (not a software emulation or intermediary), and the ability to initiate payment without having to turn on the phone or type in a security code (i.e. a fingerprint reader), and you have to be able to do it with the phone locked and turned off (meaning you need low power hardware to detect the NFC and wake the phone up). And then you need the OS integration to make it all work together seemlessly. And it has to not leak information to anyone except your bank which obviously needs to have the information anyway... and there is no smart phone app on the market other than ApplePay which can make that guarantee. Certainly not Google Wallet. Or CurrentC. Or anything else. And it's better than chip-and-pin and tap-to-pay which both have physical security issues (though they are much better than mag stripe).

    Android is missing too many pieces and it will be at least 1-2 years before it has them all. And even then there will be such a huge percentage of *new* android phones that won't have all the pieces that it will only create mass confusion for the general consumer.

    The reason Google Wallet has been a failure to-date is that it (and all other smartphone-based payment systems except ApplePay) is simply not convenient to use compared to swiping a credit card. The reason ApplePay became the #1 smartphone payment mechanism overnight is because it's utterly trivial and convenient to use.

    It took me exactly 3 seconds at the local Whole Foods to pull out my phone, tap it with my finger on the finger print reader, and put it back in my pocket. It takes me about as long to swipe my card if I don't have to sign, but half the time I do have to sign so ApplePay immediately wins because I never have to sign (at least not so far).

    Eventually all smart phones will do it the Apple way. For now, though, and for the next 1-2 years at a minimum, Apple is the only smartphone game in town that actually works well. Chip-and-pin and tap-to-pay cards work almost as well... they can even be more convenient in some situations, but they don't cover all the security bases.

    -Matt

    • Re:NFC alone isn't enough (Score:4, Interesting)

      by DigitAl56K ( 805623 ) on Friday November 07, 2014 @06:34PM (#48337925)

      The reason Google Wallet has been a failure to-date is that it (and all other smartphone-based payment systems except ApplePay) is simply not convenient to use compared to swiping a credit card.

      Bullshit. There is virtually no difference in the operation of either system except one has a fingerprint reader.

      The reason ApplePay became the #1 smartphone payment mechanism overnight is because it's utterly trivial and convenient to use.

      More bullshit. The reason ApplePay became the #1 mechanism overnight is because Apple leveraged their marketing and the media around it. Google hasn't ever done the same. In fact, it would be easy to be oblivious to the fact that Google Wallet even exists - it's almost as if Google doesn't give a crap in terms of marketing it (who knows why..)

      It took me exactly 3 seconds at the local Whole Foods to pull out my phone, tap it with my finger on the finger print reader, and put it back in my pocket.

      It takes me no more time to use Google Wallet.

      • Virtually no difference isn't good enough. Convenience is king as had been proven again and again and again.

        Also there is no way in hell that I would hand over my purchasing data to an advertising company. That's the big difference from my point of view

      • One thing that's not bullshit: ApplePay is far more secure.

    • The reason Google Wallet has been a failure to-date is that it (and all other smartphone-based payment systems except ApplePay) is simply not convenient to use compared to swiping a credit card. The reason ApplePay became the #1 smartphone payment mechanism overnight is because it's utterly trivial and convenient to use.

      Really? That's the reason? I would have gone with lack of advertising, lack of international support, not being a default in devices including the Nexus series itself, and brutal lock-down of people who hack their way into getting it working in other countries.

      But difficulty? You haven't used it have you?

      The only thing remotely difficult or time consuming was setting it up, and then only because I had to fake the fact that I wasn't in the USA because it isn't supported. For the most part Google Wallet has w

      • Re: (Score:2)

        by Dahan ( 130247 )

        But difficulty? You haven't used it have you?

        The person you replied to didn't say it was difficult; he said it wasn't convenient: "it ... is simply not convenient to use compared to swiping a credit card." And it's not. You have to wake up your phone, unlock it, and then enter the Google Wallet PIN. With Apple Pay, you just have to hold the phone with your thumb at the correct location; the phone display doesn't need to be turned on first, and the fingerprint reader takes the place of the unlock and PIN entry.

        I've tried Google Wallet a few times for t

  • I was just at walgreens and saw a small Apple Pay logo on the checkout screen for the first time,

    It made me smile

    • Re: (Score:1)

      by Anonymous Coward

      Just like I did years ago when I saw a Google wallet icon on it.

      Apple is that douchebag who shows up late for a party that everyone else is at and proclaims "*now* the party can start!"

  • NFC Bitcoin Checkout is more secure (Score:3)

    by codebonobo ( 2762819 ) on Saturday November 08, 2014 @08:07AM (#48339935)

    http://blog.bitpay.com/2014/11/04/bitcoin-checkout-one-tap-mobile-bitcoin-payments.html

    Yes, I understand the downsides of fewer merchant acceptance but there are plenty of upsides as well for everyone.

    Orders can be priced in 150+ currencies, and past payment information is only a few taps away.

    We’re now rolling out the app to every mobile market worldwide, in the 40 languages spoken by 99.99% of the world’s population.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close