5 ms·
Can you clarify what you had in mind for this? Are you imagining the ransomware would grab users' locally-stored credit card info? In which case, is there reas
by hbn 5y ago
Can you clarify what you had in mind for this? Are you imagining the ransomware would grab users' locally-stored credit card info?
In which case, is there reason to believe they'd actually be storing your card info locally? Isn't it more likely that after initially adding your card, it stays on MS servers as it does now, and this settings screen only gets sent the last 4 digits of your credit card?
Or am I misunderstanding and/or missing something obvious?
- archi42 5y agoYou can interpret my comment as part joke since I really hope that zero-click attacks on the payment method will not be possible, but also part "uuh, that can go wrong". I expect MS to reduce the user friction to some minimum, since less friction = more users = more profit. But often security adds friction ("enter your payment pin or click here if you forgot it", "we need to verify your payment, please follow steps x, y and z", "Please enter the code we send to your mobile +15551234",...). I imagine a low friction scenario in which the user only clicks a button to pay (e.g. s/he clicks an article in a newspaper application and have to confirm a UAC-style popup "Do you want to buy this stuff for x Pound Eurodollars?"). Even less friction if the user can allow an application s/he trusts to trigger payments without further user interaction (e.g. a pay-as-you-read newspaper application). A local attacker could abuse both scenarios. So yeah, I could imagine that (given some bad design or implementation decisions) even while all the critical data is stored on the MS servers, a local attacker could trigger fraudulent payments.