Browsers Will Store Credit Card Details Similar To How They Save Passwords (bleepingcomputer.com) 182
An anonymous reader quotes a report from Bleeping Computer: A new W3C standard is slowly creeping into current browser implementations, a standard that will simplify the way people make payments online. Called the Payment Request API, this new standard relies on users entering and storing payment card details inside browsers, just like they currently do with passwords. The API is also a godsend for the security and e-commerce industry since it spares store owners from having to store payment card data on their servers. This means less regulation and no more fears that an online store might expose card data when getting hacked. By moving the storage of payment card details in the browser, the responsibility of keeping these details safe is moved to the browser and the user. Browsers that support the Payment Request API include Google Chrome, who first added support for it in Chrome for Android 53 in August 2016, and added desktop support last month with the release of Chrome 61. Microsoft Edge also supports the Payment Request API since September 2016, but the feature requires that users register a Microsoft Wallet account before using it. Firefox and Safari are still working on supporting the API, and so are browser implementations from Facebook and Samsung, both eager to provide a simpler payment mechanism than the one in use today.
With the greatest respect: no (Score:5, Informative)
With the greatest respect:
How about no.
Re: (Score:2)
Re: (Score:2)
Howsabout "HELL FUCKING NO!!!"?
If this hits browsers, the first thing I'm doing is disabling it.
Re: (Score:2)
With the greatest respect, how about fuck no.
Re: (Score:1)
I suggest: Fuck, NO!
The API is news but not the functionality (Score:3)
This story is not news. I've stored my credit cards along with information for other important accounts in Lastpass for a long time using it's "form fills" feature. And, better than storing it in a browser, it is available across all browsers I use on all devices as well as with the standalone app.
In addition to bank accounts it's very convenient to store things like your AAA account info, insurance accounts, etc. This way it's always readily available to you on any device.
Re: (Score:2)
No it's not tokenization, it autofills the card info along with name, phone, address, etc. when you make a payment on a site.
But I even use it to store non-autofill information for things such as insurance accounts, etc. because it has fields to store things and you can create custom fields. I also have one form fill profile set up to autofill the info required when corresponding with elected representatives.
Re:With the greatest respect: no (Score:5, Interesting)
How about no.
How about YES. It is implausible that this will be any worse than the existing system.
Read TFA. If the payment info is stored in the browser, then *any* website can query your browser for available payment info. In addition, the browser maker - Mozilla, Microsoft, Google, etc... - could (will) have access to this info and any transactions.
As it is now, for me at least, is that, with the exception of Amazon, I don't save my payment information on any website and prefer to re-enter it whenever I make a payment. Furthermore, on sites other than Amazon, I almost always use a virtual credit card (ShopSafe) so the CC info is different for each vendor/purchase - rendering storing it in the browser useless.
Re: (Score:3)
If the payment info is stored in the browser, then *any* website can query your browser for available payment info.
I would actually welcome that -- let them access my credit card.
Credit card charge is not like a popup, I can find and roll back unauthorized charges (at a very real cost to the vendor).
In addition, the browser maker - Mozilla, Microsoft, Google, etc... - could (will) have access to this info and any transactions.
Ok, that is bad.
Re: That's ridiculous (Score:1)
Re: (Score:2)
OK, hand over your details here and now if that's how you feel.
It doesn't work if you give them out to somebody willingly, as that is effectively authorizing them to use your card, which you are liable for.
Personally I think this is a good idea, but I think it needs to be improved. GGP mentions using ShopSafe, which uses virtual credit card numbers, but it's ultimately not going to stop fraud:
http://creditcardforum.com/blo... [creditcardforum.com]
A good system, IMO, would be one where you authorize only a single transaction to a single merchant using modern cryptography. I.e. a message hold
Re: (Score:2)
That requires people who want to use the system to create a key pair, and keep the private key safe in a place where it can be used. That's difficult. Even reasonably computer-savvy people can get their computers hacked into. The message is almost certainly going to be composed on the user's main computer, and even if the private key is held on a USB drive and only plugged in when needed (which isn't going to go over well) a hostile process can monitor USB drives and act accordingly.
Re: (Score:3)
*any* website can query your browser for available payment info.
Nonsense. That is NOT what TFA says, and that is not how it currently works in Chrome. The website can request a popup, just like they can now display an order form. But that does not "query your browser for available payment info". I requires user input before any payment is made, and requires the user to enter the CVV#. In the future, the vendor will never even see the CC#.
In addition, the browser maker - Mozilla, Microsoft, Google, etc... - could (will) have access to this info and any transactions.
I trust Google more than I trust Equifax, or any other random vendor. Google will have a huge incentive to keep this secure, and
Re:With the greatest respect: no (Score:4, Informative)
*any* website can query your browser for available payment info.
Nonsense. That is NOT what TFA says, and that is not how it currently works in Chrome.
From TFA:
The researcher notes that sites that don't sell any products or advertisers could abuse the API to fingerprint and profile users (detect what payment options each user/browser has stored in its settings), or detect when the user is paying from a normal or incognito mode session.
Though, it's unclear as to what information can be queried. And whatever Chrome has implemented isn't the final API being developed.
Re: (Score:3)
Nonsense. That is NOT what TFA says, and that is not how it currently works in Chrome. The website can request a popup, just like they can now display an order form. But that does not "query your browser for available payment info". I requires user input before any payment is made, and requires the user to enter the CVV#.
There are multiple API calls at play which provide different information.
Obviously user input is required before sending card data.
What is explicitly NOT mandated by the current work is requests for available pay methods. This is explicitly allowed to be answered without prompting the user first.
In the future, the vendor will never even see the CC#.
The future... WTF ... It's 2017... why is there NEW work on shit that is obviously not fit for purpose out of the gate?
Re: (Score:2)
It sounds to me like you are assuming that this browser API won't be hacked.
I think I'd rather wait a few years before trusting it...perhaps a decade. (OTOH, I also don't trust on-line banking.)
Re:With the greatest respect: no (Score:5, Insightful)
If the payment info is stored in the browser, then *any* website can query your browser for available payment info. In addition, the browser maker - Mozilla, Microsoft, Google, etc... - could (will) have access to this info and any transactions.
Okay so since this features has been available for a while why not look at how it actually works:
- The browser implementation never hands over the CC info without checking with the user.
- The browser does not hand over the CVV code.
- Google's implementation at least handles the CC info exactly the same was as it does on Google's Play store so if you already have a mobile phone and purchased an app on it, you're level of trust does not change between using this new system vs buying an app on your phone.
- Additionally Google's implementation won't hand over any CC info if the security chain isn't perfect which is a damn sight better and more secure than how the vast majority of users handle their credit card online.
As it is now, for me at least, is that, with the exception of Amazon, I don't save my payment information on any website and prefer to re-enter it whenever I make a payment.
Then you should love this system.
Furthermore, on sites other than Amazon, I almost always use a virtual credit card (ShopSafe) so the CC info is different for each vendor/purchase - rendering storing it in the browser useless.
Why? I know the USA lack all sorts of basic consumer protection laws, but I was under the impression that your quite well covered for credit card fraud.
Re: (Score:2)
...because we have better thing to do than invest hours in repairing our credit?
Thats... not how it works. If someone fraudulently charges something against your credit card, you simply call up the CC company and report it. In most cases, that's it, it's gone, they handle it, you're done. Your credit history will not be tarnished because disputed charges are not reported until the matter is settled, and only then if the matter is not settled in your favor.
More than once my CC company has called me to ask if I had made certain charges, the same day they were made, and before I had ev
Re: (Score:2, Insightful)
In what world is storing credit card info not worse than not storing credit card info?
Re:With the greatest respect: no (Score:5, Insightful)
Yes.. (Score:5, Insightful)
Do you even need to ask that question?
The funz will really start when they extend the APIs to allow for recurring charges, one of the common billing scams - it wont be long I am sure.
'WE JUST NEED TO VERIFY YOUR CCARD WITH A $0.01 CHARGE TO VALIDATE YOU' (tinyprint hidden, we will also start charging you $39.95 per month for an email telling you our monthly lucky numbers, and it is basically impossible to cancel).
So yes, the ONLY valid answer to this if 'NO F'in WAY'
Re: (Score:3, Insightful)
Just enter your credit card number? are we that fucking lazy?
Do you write your pin code on your credit card?
Do you post-it your password to your screen?
I honestly can't believe you would carry around a card with a bunch of numbers on it that allows someone to buy something without any additional checks. Lazy doesn't come into it. I can't remember 19 digits, but I can remember 3 (CVV code) and when I do then I can stop carrying a stealable physical item around that anyone who pick pocket me can use to run up charges.
What has this got to do with lazy?
Re: With the greatest respect: no (Score:1)
How the fuck can u consider a browser storing credit cards better. Every browser is by far the weakest component security wise in transactions. Only a moron would trust any of the current crop of browsers to do this.
Re: (Score:3)
It is implausible that this will be any worse than the existing system.
It's also not going to improve any system. You'll still have zero control over how merchants are handling the CC details at their end - they're probably still going to store them in an unencrypted Acces or MySQL database with an Admin portal using an admin:admin username/password.
I don't store passwords in my browser. I'm sure as heck not storing CC info in my browser, either.
Re:With the greatest respect: no (Score:5, Insightful)
How about YES. It is implausible that this will be any worse than the existing system.
Having standardized interfaces malware can leverage to trivially extract card details from user systems has the potential to lead to worse outcomes. We already see malware looking for bitcoin wallets which on a realitive basis very few people have. A future in which everyone is storing card details in their browsers does not seem productive.
Neither is encouraging use of dead-end inherently dangerous pull based technology (credit cards) when push based systems (e.g. PayPal) are MUCH safer only leads to worse outcomes for all.
Statements like: "The PaymentRequest API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this."
Indicates developers of the API are not serious and are just going to punt on security.
They don't seem to care very much about privacy allowing payment type data to be probed without explicit permission at the whim of the browser vendor.
The overall approach is pedestrian. Shoving complex ecommerce workflows and interfaces into browser APIs is a ridiculous nonstarter. Why not work on something useful like native browser support for distributed authorization or common information request profiles? The approach reeks.
Re: (Score:2)
You misunderstood the encryption issue. The connection to the site must be encrypted, so it's the same as if you just typed your CC number in manually.
They are talking about additional encryption that could e.g. stop the merchant being able to see your number.
Watch the credit card companies mod this post down (Score:2, Insightful)
There is an insidious and non-obvious way that it will likely be worse than the existing system. In the current system, when your credit card number is stolen and misused, you usually are not responsible to pay because the credit card company would have to prove that it was your computer that was compromised rather than the merchant. That would require an expensive forensic investigation. But with these new systems like ShopSafe, Verified by Visa, or this new browser API, the merchant never gets your card n
Re: (Score:2)
How is it implausible that this would be worse than not storing your CC numbers in your computer?
Re: (Score:2)
I've had browsers bleed username information across websites, as those browsers seem to add features well before thinking about the consequences. Having credit card stuff stored in-browser makes it just as secure as anything else the browser does (i.e. not very secure).
Also, it's not supposed to be auto-saved, since credit cards are supposed to be in your possession when you use them, rather than still being in the wallet found on a dresser. As much as it is "inconvenient", this really should be the normal
Not for anybody who cares for privacy/security (Score:5, Interesting)
... just like they currently do with passwords
I don't trust any browser to store even my Slashdot login password. Why in the world would I trust it with my credit card? In fact, I don't even let merchants store my credit card if at all possible (I either choose the option not to save the card or manually delete the card after the purchase).
It seems like nobody who understands and actually values privacy and security would do this.
Re:Not for anybody who cares for privacy/security (Score:5, Interesting)
I don't trust any browser to store even my Slashdot login password. Why in the world would I trust it with my credit card?
Because the alternative to sharing your password is to keep it secret and type it each time you need it. But the alternative to your browser storing your CC# is that it is stored by every online merchant you buy from.
Re: (Score:1)
If I, as a consumer, could control the use of, the "When", that this number can be used, then I would be in control. And "Control" is the whole point. Everything else is advertising.
Re: (Score:2)
If I, as a consumer, could control the use of, the "When", that this number can be used
That is exactly how it works. You get a popup, and you type in your CVV# to authorize the transaction. You have total control.
Re: (Score:3)
Because the alternative to sharing your password is to keep it secret and type it each time you need it. But the alternative to your browser storing your CC# is that it is stored by every online merchant you buy from.
Unless you specifically ask the website to store your CC info, it's not saved beyond that transaction (or it's not suppose to be saved). This is why you need to re-enter it otherwise. With the data stored in the browser, then *any* website can query your stored payment info.
Re: (Score:2)
With the data stored in the browser, then *any* website can query your stored payment info.
Bullcrap. This is totally wrong. RTFA ... or download the latest Chrome and try it.
Re: (Score:3)
With the data stored in the browser, then *any* website can query your stored payment info.
Bullcrap. This is totally wrong. RTFA ... or download the latest Chrome and try it.
From TFA:
The researcher notes that sites that don't sell any products or advertisers could abuse the API to fingerprint and profile users (detect what payment options each user/browser has stored in its settings), or detect when the user is paying from a normal or incognito mode session.
Though, it's unclear as to what information can be queried. Furthermore, whatever Chrome has implemented isn't the final API being developed.
Re: (Score:2)
or detect when the user is paying from a normal or incognito mode session.
But what if incognito is your normal way of browsing?
Turn off incognito to continue (Score:2)
But what if incognito is your normal way of browsing?
Then you've probably already run into a lot of demands to whitelist a site.
Private Browsing in Firefox enables tracking protection [mozilla.org], a built-in blacklist of servers involved in tracking a user's behavior from one site to another. Numerous ad-supported websites depend on this tracking for interest-based advertising and aren't smart enough to fall back to self-hosted ads if the tracking servers can't be reached. So if tracking doesn't work, a site like TV Tropes pops up a demand to disable tracking protection.
Re: (Score:2)
Good investigation of the current API here: https://blog.lukaszolejnik.com... [lukaszolejnik.com]
TL;DR there are some major privacy problems with it, but bug reports have been filed so hopefully they will be fixed.
Re: (Score:2)
A better payment system would be the store getting your id and details and than clearing the payment with your credit supplier, who than confirms those details with you via you card details and limited remote authorisation code (spend limited). Onsite with a photo taken of the transaction and attached to the spend and offline, digital ID hardware could be used, a rotating aligning crypto exchange, unique to the device and the credit provider servers (think an encrypted clock client connected to an encrypted
Re: (Score:2)
But the alternative to your browser storing your CC# is that it is stored by every online merchant you buy from.
No, the alternative to your browser storing it is that you type it in every time you buy something -- just like with passwords.
Re: (Score:2)
No, the alternative to your browser storing it is that you type it in every time you buy something
And getting demerits on your credit report for failing to remember to pay a monthly bill.
Re: (Score:2)
Not so. For instance, I currently used a password manager to load my passwords and credit card details directly into my browser, without necessarily having to type my master password in each time I need any specific password or credit card.
Why not take that a step further? Have browsers implement an API through which they can request payment details from external apps of our choosing. The browser sends out a request for information that would allow it to engage in a transaction for a certain amount to a cer
Re: (Score:2, Insightful)
yes, it is very stupid to store stuff like this in the browser; but you're fooling yourself if you believe that by not 'saving' the card or by 'deleting' the card at the merchant site you're preventing the merchant from retaining the card details. they ALL store that shit anyway, regardless of what the user does. and a lot of them also retain cvv security code as well, even though they aren't supposed to.
the only thing you can do is use virtual numbers (like what paypal used to offer years ago, or what a fe
Comment removed (Score:5, Interesting)
Re: (Score:2)
It's an extensible API. It will work with PayPal, Apple Pay, Google Wallet, etc as well if they choose to support it.
Re: (Score:2)
Re: (Score:2)
It seems like nobody who understands and actually values privacy and security would do this.
I understand and value privacy and security, and I have no problem with storing my credit card info in my browser, as long as there's full disk encryption on the laptop in case it gets stolen.
The browser is not a concern; the world of online payments already is a gigantic farce. If you ever have the opportunity to integrate some of those payment gateways in an app you'll see how fubar it is. Besides the serious ones like paypal, Google Pay or Apple Pay, there's a shitload of smaller players with plain terri
Re: (Score:2)
I don't trust any browser to store even my Slashdot login password.
Obviously this article is not aimed at the tinfoil hat crowd.
Google uses government mind control satellites for that.
The helicopters aren't black... they're invisible (Score:2)
Shows what you know.
Using DGPS, they have millimeter resolution, and can ID the individual teeth on your necklace AND the ones in your mouth, and figure out which ones are really you by the alignment to the dead RF spot your faraday cage creates. Then the black helicopters bounces an IR laser off you in case they decide to guide smart weapons in. And that, of course, is simply a matter of where and what you post. In fact, I really shouldn't be postin
*&^%#$^#$ LOST CARRIER
Re: (Score:2)
Re: (Score:2)
No absolutely spot on.
agreed
Re: (Score:2)
It's YOUR browser. It's as safe as you are.
This is the funniest thing I've read today.
Not My Browser (Score:2)
April Fools (Score:1)
When I saw this story I had to double check that it's not April 1st. This is a bad joke in terms of security. Like a zero trust model, users should give their browser zero trust, or the next sandbox or plugin exploit means everything your saved in your browser is in the hands of criminals.
Wow, the first quantum computer (Score:2)
will enable its user(s) to rule the world.
Seriously, is everything in these encryption algorithms protected by hoping that the product of two large prime numbers can't be easily factored? If so, then I would assume all the world's secrets (and ability to conduct financial transactions) are theirs.
It's sad that the first network using quantum encryption was put up (literally) by the Chinese (it's using satellites).
Re: (Score:2)
Seriously, is everything in these encryption algorithms protected by hoping that the product of two large prime numbers can't be easily factored?
No. State-of-the-art encryption algorithms haven't been based on "factoring prime numbers" for decades.
Re: (Score:2)
state of the art isn't what's in common use though, rsa and elliptic curve crypto use primes and sem-primes
AES doesn't
RSA uses semiprimes (Score:2)
The RSA crypto used to negotiate a session's ephemeral AES key still uses semiprimes.
HELL NO! (Score:2)
In NO way should ANY browser store Credit Cards!
Re: (Score:2)
In NO way should ANY browser store Credit Cards!
Why not?
I'd rather have someone steal my credit card info than my slashdot credentials.
I can always cancel (and get a full refund for) any fraudulent CC charges. But a slashdot post under my name is permanent.
Re:HELL NO! (Score:5, Insightful)
In NO way should ANY browser store Credit Cards!
Why not?
I'd rather have someone steal my credit card info than my slashdot credentials.
I can always cancel (and get a full refund for) any fraudulent CC charges. But a slashdot post under my name is permanent.
Have you ever tried to cancel a payment? It can take many months. During this time you will no doubt have to get a new card/account details, update regular payments and quite likely be without any spending cash for several days. I think the inconvenience factor and being observant enough to catch fraud before you're rendered bankrupt far out weighs potential gain vs risk.
Re: (Score:2)
PCI DSS Requirements (Score:5, Interesting)
Does this mean that browsers are going to have to be PCI DSS certified?
That would certainly be interesting, because PCI for example prohibits using anything less than TLS1.2 for secure comms, which might bleed-over into general communications. Could this be the end of non-HTTPS web traffic and SSL/TLS before v1.2? Will browser vendors have to choose between interoperability with (old, shitty) servers and providing storage and transmission of credit card info?
It would be kind of awesome if one DID imply the other, because the internet would get a lot less shitty really quickly.
Re: (Score:2)
Of course not - you're not handling other people's credit card numbers, and you do not have a merchant agreement with the card issuers.
PCI DSS is for businesses that extract money from other people's cards, it's not about storing your own card's info.
Re: (Score:2)
You are not but the browser is. This is Google's browser that is handling other peoples CC's
And for payments outside the browser. (Score:3)
Payment providers like PayPal or Amazon might not be on board with this new API since it makes them obsolete, but almost everyone else is.
Or because, in the case of something like Amazon Payments or "Pay with Amazon" they actually need to store your payment information to process transactions that occur outside the browser. If I'm using that, I don't need my browser to handle it too.
In many ways, the Payment Request API is a much secure method of handling online transactions, but it's not perfect either.
For starters, browser makers now have a full view of your finances and transactions, a situation that some people might not like, and will refuse to store any such information in their browser.
Ya think? I imagine the above will be a non-starter for many. Like I want Mozilla, Microsoft or Google accessing my CC transactions.
Sniffing the browser for CC info. (Score:3)
The researcher notes that sites that don't sell any products or advertisers could abuse the API to fingerprint and profile users (detect what payment options each user/browser has stored in its settings), or detect when the user is paying from a normal or incognito mode session.
Just great. Then any website could query your browser for available payment information.
Re:Sniffing the browser for CC info. (Score:4, Informative)
Saw this after posting above. Also from TFA:
The researcher notes that sites that don't sell any products or advertisers could abuse the API to fingerprint and profile users (detect what payment options each user/browser has stored in its settings), or detect when the user is paying from a normal or incognito mode session.
Just great. Then any website could query your browser for available payment information.
And? Note that they just say payment information. They don't say anything about credit card details, which don't get handed over without user interaction, and in the case of Chrome still needs a CVV code manually entered. Whether or not you have 1 VISA, or 1 Mastercard and 1 PayPal as a payment option really doesn't matter much. Tracking users is already done with near perfect success. It's kind of hard to get worked up about the leak of trackable information.
Absolutely dumb idea (Score:2)
Kaspersky Credit Card Number App (Score:1)
Personally I prefer the Kaspersky Credit Card App to store and retrieve my Credit Card Information, because Kaspersky is an Industry Leader in security applications worldwide, and I know that my payment credentials are safe in their hands.
What problem does this solve? (Score:2)
They still need your card data, they still need a payment processor. So, now we don't have to enter our CC, it just sends it behind the scenes. So, this helps lazy people and means that a browser flaw could allow an attacker to charge my CC.
Re: (Score:2)
Re: (Score:2)
Again, remember: it's not really about you (Score:5, Informative)
Conversion rates in the checkout flow are a key measure for ecommerce sites. 46% of e-commerce shoppers abandon the checkout process during the payment phase, signaling frustration with the complexity and redundancy of re-entering form data or tracking down payment information. Even a small increase in the success rate of checkout make a direct impact on your site’s bottom line, while improving the shopping experience for customers.
From Payment Request API [mozilla.org]
Many problems related to online purchase abandonment can be traced to checkout forms, which are user-intensive, difficult to use, slow to load and refresh, and require multiple steps to complete.
Sure, this API may make things simpler for you -- the purchaser -- but it seems the focus is on benefiting the seller. Perhaps a narrow distinction, but one that may matter if/when push comes to shove and a side must be chosen by the developers.
Another thing to consider: Since this is implemented in the browser, if you use multiple browsers to shop, then you'll have to store your information in each browser rather than once on the websites on which you shop -- unless the browser vendors can cooperate on a single, shared data storage method.
Re: (Score:2)
Sure, this API may make things simpler for you -- the purchaser -- but it seems the focus is on benefiting the seller.
A purchaser / seller relationship is just that, a relationship. It can get frustrated and end for external reasons. That doesn't mean it benefits one side or the other. E.g. I am hungry, I see McDonalds, I drive into the drive through and see a huuuuuuuuge queue. I leave. Sure If they efficiently handled the drive through and there was no queue my shopping there may have "benefited the seller" but as I drive away I'm still hungry.
If you get to the point where you check-out, not being able to complete the sa
Re: (Score:2)
That's an odd way of interpreting it. Surely the user indicated that they wanted to pay, but were frustrated by a crap UI (or were just trying to find out what the postage cost was).
This sounds like they are trying to encourage merchants to adopt it by insulting their web sites.
Re: (Score:2)
Conversion rates in the checkout flow are a key measure for ecommerce sites. 46% of e-commerce shoppers abandon the checkout process during the payment phase, signaling frustration with the complexity and redundancy of re-entering form data or tracking down payment information.
No, that is not the reason and the conclusion is wrong.
Most web sites do not show the actual price till actually reach the checkout process. "Log in to see the price", "Check out to see the actual price including shipping handling and the random charge we tack on". Well, I will click it, see the price and decide it is not worth it.
If the actual price is shown up front, most of that 46% would not have bothered to go to check out process.
And there are price comparison bots who use the check out process t
MAP pricing (Score:2)
"Log in to see the price" is part of how sites work around "minimum advertised price" (MAP) policies imposed by manufacturers.
Re: (Score:2)
They are shifting the cost of protecting customer information on to the customer. Which is a bad idea - merchants have the resources to protect that info
BWAHAHAHAHAHA! /me wipes tears from eyes.
Do you not pay any attention to the news?
NO. (Score:2, Informative)
The browser is the one component in my system I trust less. I mean: its job is to go around the Intratubes picking up every bit of dirt out there and *executing it*?
I don't put my banking data into that now. Much less when there's a standard with a clear label on it "BANKING DATA HERE".
"But, but" "Sandboxes". Yeah, right. Ponies. Rainbows. Farts.
No. Fucking. Way.
That's it (Score:1)
I'm getting into the malware industry
Safari already offers to store credit card details (Score:2)
Safari already offers to store credit card details.
It's got a little popup that shows up when you use a credit card, and offers to "save the card".
Unfortunately Safari also offers an "autofill" feature, and doesn't distinguish between hidden fields and visible fields when providing data.
Automatic phishing.
Re: (Score:2)
Credit card information isn't stored with the browser (on the Mac at least, I don't know about anywhere else). It's stored in the Keychain, a much safer place. Also, all of your payment history isn't stored like with this proposal. When filling in the information for a credit card there is only the name on the credit card, the card number, and the expiry date. The CCV isn't stored. Any other fields that would get filled in would be part of some other autofill. You don't start entering your name and have you
Re: (Score:2)
Credit card information isn't stored with the browser (on the Mac at least, I don't know about anywhere else). It's stored in the Keychain, a much safer place.
It doesn't matter, if Safari is willing to go into the keychain and then to provide the data to a hidden field, without a user notification.
I talked to Visa, gave them the information, and a list of about 150 sites that had the exploit being actively used. Then it was also reported to Apple.
They'll push this hard (Score:5, Insightful)
I read quite a few of the comments, and noticed that people here are well aware of the problems with having a browser store this kind of information. And yet, I have a bad, bad feeling that in a few years, it's going to be ubiquitous, perhaps even compulsory. I'm surprised they actually spelled it out so clearly:
"By moving the storage of payment card details in the browser, the responsibility of keeping these details safe is moved to the browser and the user."
That's it right there. The banks and credit card companies have been trying ever since plastic was invented to make consumers responsible for losses due to fraud and theft. This is their ticket to paradise.
So watch for deep discounts. Watch for a flood of trolls masquerading as coolest-of-the-cool tech lords explaining how everybody who isn't a doddering old fool is using it. Watch for laws drafted to force you to use it. Like when you have to renew your driver's license, you get a choice of waiting in an endless line during business hours at a single tiny government office, or bringing your smart phone and an app to a no-wait kiosk in a mall, or doing it from home...ONLY if you use the browser function. Watch for more and more stores refusing to accept bills larger than $10 for cash transactions "because counterfeit" or "because security".
I'm sure there's a dozen more ways, all based around that "well, nobody's forcing you" lie that's been used so often and so well.
Let's hope that for once people get together and shut this down before it gets started. Right now liability for fraudulent financial transactions is right where it belongs. We need to keep it that way.
Re: (Score:2)
This.
It's becoming more difficult to dispute a CC charge. When a merchant fails to deliver the product, when Airbnb sends you to a unreachable or rat infested destination. When a product is not as advertised and the merchant doesn't care about making a second sale you are left holding the bag. This is about shifting responsibility to the consumer.
What makes me hesitate purchasing online is experiences with online merchants. With Airbnb I found myself in a situation far from home in a dangerous rental. It wa
Re: (Score:2)
Well said.
And thanks for the tip about Airbnb. I remember seeing some stuff about them, but it's different coming first-hand from somebody you can get more information from, if necessary.
Re: (Score:2)
There's a difference between disputing a charge because it's fraudulent from the start and disputing a charge because the vendor didn't come through with the advertised product.
Re: (Score:2)
perhaps even compulsory.
Here's why I don't fear that future (even if it happens): I generate a one-time-use CC# for every online purchase, so I use a different credit card number every time. The browser (or website) can store it as long as it wants. Once the charge clears, the number is no longer valid.
Re: (Score:2)
Thank you.
"Best idea ever!" (Score:2)
"This feature is long overdue and can't come soon enough!" - Blackhats everywhere
They already do, for me (Score:2)
I don't let my browsers remember my passwords. I'm absolutely not going to let them remember credit card numbers.
Re: (Score:2)
Which moron thought this is a good idea? (Score:2)
Can we get password generation built in? (Score:2)
Penny Per Page (Score:2)
Nov 2001 howstuffworks.com threw up the idea of a 'penny per page' when visiting websites. http://computer.howstuffworks.... [howstuffworks.com]
Looks like that day is fast approaching. Washingtonpost.com blocks me as I use a hosts file or ADblocker browser on Cell, so I ignore/avoid them. A Payment Request API will allow them to now pull from a previously setup account. Once it starts, all will be looking at it.
Hell would freeze over first (Score:2)
Re:These days saving a CC number doesn't last for. (Score:5, Funny)
very long since we have to change numbers pretty often because of fraud. With my Chase card, I think my number changed three times since I got it six years ago. With my Barclays card, I've already changed number three times just this year! Neither card has a chip, so I swipe them at a lot of places. Food trucks seem to be the worst since twice immediately after I bought something from a taco truck, I had charges from FAST STOP 1107 in Texas three different times.
The government has a program in place that you can take advantage of to prevent credit card fraud at high-risk situations like taco trucks. It's a paper certificate called a "Federal Reserve Note", and it's now widely available.
Re: (Score:2)
You must be new here; it's actually What could possibly go wrong?