- Last Active
AppleInsider said:...Fitbit Pay, an Apple Pay competitor which is still expanding U.S. bank support but should work anywhere NFC payments are accepted. Apple Pay often requires specific support by merchants.
There are some merchants that accept contactless cards but reject Apple Pay. These merchants (or their banks) have installed explicit software designed to look for and disable Apple Pay. Usually for political/ideological reasons (don't want to support Apple, wants to promote a competing mobile wallet tech, etc.) Convincing a merchant to remove their Apple Pay-disabling firmware is not "requiring specific support", no matter how many press releases to the contrary the merchant may make.ihatescreennames said:Are there places that accept NFC payments that do not accept Apple Pay?
WalMart is one of the worst examples. To be fair, they are blocking all contactless/NFC transactions, not just Apple Pay, but they definitely fall into this category. They and 14 other companies explicitly decided to block mobile payments in order to promote "CurrentC", their own mobile payment system (which requires granting the service direct access to you bank account) that after 4 years of vaporware was shutdown and abandoned. Today, WalMart still won't support NFC, but is instead trying to convince customers to make their in-store purchases through the WalMart app, which doesn't work anywhere else.
Why not just accept NFC payments? Because WaMart's CEO has some personal vendetta against Visa and MasterCard and is looking for some excuse to get rid of them, so they are using passive-aggressive BS to try and make customers pay with other mechanisms (like direct debits from checking accounts) instead.
I would love to see more details about what's really going on here. In iOS, user input comes in the form of an NSString object (or a String object in Swift). These string objects are fully UNICODE enabled, include length counters, and do not use NULL bytes as terminators.
If an application is grabbing the raw data and treating it as a C-style string, whether for internal use or for use with an external framework, then problems like this are likely to occur, because the byte-stream can include zero values.
On the other hand, if the application is doing the right thing, and calling appropriate member functions to get (for example) a UTF-8 representation of the UNICODE string, then there shouldn't be any zeros in the resulting byte stream. If there are, then Apple's got a bug somewhere, which will clearly need to be fixed.
suddenly newton said:So... NAND mirroring and using brute force to try every passcode does not equal "unlocking secure enclave."
The passcode is not the decryption key. It (in conjunction with algorithms provided by iOS) allows access to a key that is used by the secure enclave to decrypt the actual content. If the OS and the secure enclave chip are not functioning, then you would need to brute-force the internal key in order to read the content of the flash chip itself. That is much much more difficult than trying all combinations of a 4- or 6-digit passcode.
If the phone is working, you can try every passcode combination, but there are a few caveats. After a few failures, the phone makes you wait before you can try again - I think the delay can go up to an hour, if you fail many times. And there phone may be configured to wipe its contents after too many failures. In order to work around this, you need to make a backup of the flash storage and restore it after every 4-5 attempts, in order to reset the counter. But that only works on older versions of iOS - more recent versions store the counter in the secure enclave, where it can't be reset without already having the key.
Soli said:adm1 said:I call BS, how could she not have had access to a branded/decent set of batteries? I struggle to find cheap batteries in the shops here, it's always Duracell, Energizer etc.
That having been said, I've never had one overheat (let alone catch fire). Usually, the cheap ones just don't last very long. Which is fine for low-power devices like remote controls, but unacceptable for high-power devices like cameras.
Also note that this happened on a flight from China. It is likely that these batteries were purchased in China. It is likely that a foreigner who doesn't read Chinese would not know what brands are good and what are junk. And looking for a well-known brand like Duracell or Energizer may not help, given the amount of counterfeit goods sold there. Especially if they were purchased in a local market instead of, say, in an airport store.
Given the circumstances of the article, I think it's a mistake a lot of us could make if placed in the same situation.
tundraboy said:Headline is inaccurate. The headphones did not explode. The batteries did.
They clearly state that the batteries are what exploded. In which case, I agree - Apple has nothing to do with this. And it has nothing to do with "approved" brands. Most batteries - even no-name ones - don't explode. The fact that these did means that they were manufactured very poorly.
They are the ones who need to be sued, but (as another reader pointed out) it may be impossible if they are a fly-by-night operation in a foreign country.