Those terminals "don't work" yet. The hardware as you mentioned is there (slot/RFID) but it needs to be enabled by the software loaded to the POS for it to work.
Mastercard calls it the "Automatic Billing Updater" [1].
For non-fraud related reissues, it's not a flaw but actually an enhancement: you don't have to remember to update your card information whenever your card expires.
It's a feature for expired cards, it's a flaw for stolen credit cards. I know plenty of people that will report a card stolen and then cancel the card to avoid dealing with that kind of crap.
I'll just add that starting in October, the merchants will be liable for magstripe transactions completed with counterfeit cards but not for those coming from other type of frauds (e.g lost/stolen cards) as long as the merchants have proper card acceptance procedures.
Tabs being treated like apps is definitely annoying. However, you can fix that by going to the chrome settings and turning off the "Merge tabs and apps" switch.
I built a small app that retrieves data from a remote server, builds a summary and then pushes it to a local html file.
Number of people that tried it when I told them that to make it work they had to download python, pip, paramiko and install the pycrypto binary? Zero. Number of people that tried it after I just gave them a zip file with an executable? No longer zero.
I tried different libraries but Nuitka was the only one that made everything work seamlessly. I owe this guy a beer.
Edit: I no longer owe Kay a beer. I found the donation link on his website.
This issue has been addressed multiple times with considerable success by pyinstaller, py2app, cxfreeze. You can get your single-zip-file distribution package without nuitka, although it may have other advantages.
I recently ended up rewriting large parts of a python project in common-lisp due to this exact issue; in this case it was one stage of a pipeline that I prototyped with an existing python library that could output to xml, but delivery of python applications on windows is painful.
I think this is one of the reasons Go was a breath of fresh air to a lot of Python and Ruby programmers. The ability to quickly generate a static binary is a great feature.
If you packaged it correctly, you could get by just requiring Python and pip to be installed. But still, the zip and single executable is still faster.
If you exceed the limit of your current storage plan, you won’t be able to upload additional content but you'll still be able to view, download and delete your files, photos, and personal videos for at least three months.
During this time you can:
...Renew or sign-up for Amazon Prime to enjoy the Prime Photos benefit...
I would add that if the "FICO score forced you to take on debt" it would give a better score to someone with a 95% debt to credit line ratio than to an otherwise equal individual with only a 5% debt to credit line ratio. In reality, the opposite is true.
Having said that, for you to have a valid FICO score, you do need to have at least six months of credit history (credit card, loan, mortgage or otherwise).
That is mostly the case for consumer loans. For commercial lending, the parametric score is just one factor of the overall underwriting analysis which, among other things, has loan officers talking directly to clients about their businesses.
If by "companies behind the card" you mean banks, the reason they send you a plastic with a new account number when there's an issue is not only to protect you (although you aren't liable for fraudulent charges it's not precisely the best use of your time to go through the process) but also to protect themselves. A non-trivial amount of the fraud claims is absorbed by the issuing banks.
I wouldn't categorize CC numbers as public information though, just ask Target or Home Depot.
Yes, credit card numbers are used as passwords and need to be secret, but that doesn't change the fact that they are also used as names and need to be public.
This is the fundamental problem. We're using a single thing both as a secret and as non-secret public information. This confusion of purposes is what results in the massive data breaches we constantly hear about on the news.
When you buy something at a physical store like Target, their computers will store your credit card number. Why? They aren't Amazon. It won't ease your next purchase as you'll still have to present your card. Isn't it dangerous?
Yes, but consider what happens when you return something. They can't just give you cash. That would open the door to money laundering and plain old theft. They have to put the money back on in your card account. But which account? They need to name the account when informing the credit card company of the refund, which means they need to store the name. That name is the credit card number. I suppose they could store a hash of your account number and require you to swipe your card when returning items, but that's inconvenient. You might not have the correct card with you. You may have cut it up. You may be returning an item for somebody else.
A credit card number is the name of the account. As such, it must be public and cannot be secret. If instead it is to be the password, then the account really ought to have a different public name. After all, we need the ability to talk _about_ an account without the mere conversation granting all parties permission to _charge_ the account.
Here's another way to look at it: My bank will let most anybody take money out of my checking account -- provided they present the bank with two things: They need to tell my bank which account to take money out of, and they need to present an authorization token granting them permission to do so. One type of authorization token is called a "check" (though there are others). An "account number" is how a person specifies which account -- it is nothing more than the name of the account. Simply presenting the account number is not normally enough to grant access to withdraw from the account.
Everybody to whom I write a check will know my account number. It's not a secret. For convenience, it's even written on the check. What protects my account is that my bank is only allowed to withdraw money when presented with an appropriate authorization token. They aren't even a secret tokens: they are single-use, tied to a specific person and a single amount, and they can only be activated by me. Stealing my checkbook won't help you. Stealing a check I wrote to somebody else won't help you. You can't cash a check multiple times. You can't withdraw any more or less money than I authorized.
The problem with credit cards is that the account name is also the authorization token. Moreover, it's a multi-use, unrestricted token. It's a name that many people need to know and store long-term, but anybody can use it, multiple times, to withdraw any amount of money they choose. The credit card industry doesn't yet have anything that works like checks, which is why they work so hard at fraud detection.
The future is probably limited-use auth tokens for websites and chipped cards for physical stores.
For websites, I'm sure it'll be the same process as signing in to a random website with your facebook account. Imagine buying something on a website, but instead of entering your credit card number, you are redirected to your credit card company's website. You "sign-in-with Visa" by entering your account password. You are then redirected back to the website you came from, this time with an authorization token. That token will only be usable by the website you authorized. It would be useless to anybody who stole it. You may even be able to add restrictions. You could make a token that can only be used once. Or once a month for up to a year, and no more than $10 each time. The token will contain your unencrypted account number, so you won't need to enter that, but it also won't be secret. Only the token as a whole can authorize a charge, not the mere account number. The secret is your account password that only you know.
For physical stores, chipped cards will likely contain the secret. Or maybe cellphone hardware or apps. They can be used to create a valid auth token for a without ever having to surrender the secret to the computer that's processing the purchase.
Passwords are authorization tokens, but not all tokens work like passwords. Passwords are an inappropriate kind of authorization token to use for purchases. Confusing an account name with such a token is even worse.
> Imagine buying something on a website, but instead of entering your credit card number, you are redirected to your credit card company's website. You "sign-in-with Visa" by entering your account password.
