> Surely this is massively vulnerable to double spend attacks?
FeliCa uses mutual authentication with eventual bookkeeping and sync. I believe that there are some theoretical attacks on older cards but the terminals are regularly synchronized and get a ban list. In-practice, you’ll also be reported to the police, probably.
My understanding here is that there's less risk of double spends here because of the extreme difficulty of cloning the smartcards involved.
So to execute the double spend you would have to find an authorized card provider, convince them to load and sign your double spend-capable program onto the smartcard (with their signature!), and then be found out within a week when reconciliation is off.
So doing a double spend will be found out, and not only will you be on a bunch of cameras doing the thing, whoever made your card will also have been compromised.
I think that in practice the "eventual" reconciliation is fairly quick nowadays. Just that the offline spend can happen quickly, and then the packet gets sent over the wire maybe a minute later rather than before the spend is approved.
It's really not that big of an issue when the spends are reasonable sized (e.g. public transport). You don't need to prevent literally all fraud, just enough that it becomes an acceptable cost of doing business. Fielding customer complaints because they couldn't ride due to an offline reader isn't free either.
> I think that in practice the "eventual" reconciliation is fairly quick nowadays. Just that the offline spend can happen quickly, and then the packet gets sent over the wire maybe a minute later rather than before the spend is approved.
This is definitely the case, and it's also "relatively instant" in the happy path. There are cases like vending machines, or during system outages where the reconciliation happens much later, but those instances are definitely becoming rarer!
Maybe you can, but I had the impression that it would be quite difficult given physically unclonable function-y stuff. Handwave-y and I have no clue if Suica-style payments use it but that was my impression.
It's been in widespread use for a while at this point so in practice probably not. I imagine the authentication keys to present as a card are very tightly controlled and not just anyone can become a provider.
In Taiwan, there is a similar system called EasyCard. That works offline.
...And as you expect it is vulnerable to double spend attacks. Hilariously the vulnerability was revealed in 2014 and nothing has been done to mitigate it. Yes, you can double spend in Taiwan today if you don't mind risking jail time.
From my (rudimentary) understanding of CAP, there is no prefect solution to this. I wonder how Japan handles it.
Not really - what's the attack? You could maybe somehow clone a card with a balance on it and spend that balance twice, if you can figure out that a particular terminal is offline (or have a way to take it offline), but how do you turn that into an attack that you can scale enough to cover the fixed costs? You're not getting your own terminal without a contract and due diligence on your company, so you can't really pull off an attack that needs to control both sides.
The problem here is societal, not technological. An end state where people do less work than they do today but society is more productive is desirable, and we shouldn't be trying to force companies/governments/etc to employ people to do an unnecessary job.
The problem is that people who are laid off often experience significant life disruption. And people who work in a field that is largely or entirely replaced by technology often experience permanent disruption.
However, there's no reason it has to be this way - the fact people having their jobs replace by technology are completely screwed over is a result of the society we have all created together, it's not a rule of nature.
> However, there's no reason it has to be this way - the fact people having their jobs replace by technology are completely screwed over is a result of the society we have all created together, it's not a rule of nature.
I agree. We need a radical change (some version of universal basic income comes to mind) that would allow people to safely change careers if their profession is no longer relevant.
Reminds me of Mondragón, a corporation and federation of worker coops in Spain. It builds new coops to meet the needs of its community, and when a coop ends, workers are given financial support and trained for new jobs in its other coops.
No way that will ever happen when we have a party that thinks Medicare, Medicaid and social security is unnecessary for the poor or middle class. But you better believe all our representatives have that covered for themselves while pretending to serve us (they only serve those that bribe/lobby them)
> No way that will ever happen when we have a party that thinks Medicare, Medicaid and social security is unnecessary for the poor or middle class.
This is obviously because the current ruling class can't see what is coming. Historically speaking, the motivation for the elite to support social programs or reforms has been the instinct to preserve social stability, not altruism.
The New Deal did not happen because "the party thought that Social Security and unemployment insurance are necessary for the poor or middle class." It happened to prevent civil unrest and the rise of radical ideologies.
> The problem here is societal, not technological.
I disagree. I think it's both. Yes, we need good frameworks and incentivizes on a economic/political level. But also, saying that it's not a tech problem is the same as saying "guns don't kill people". The truth is, if there was no AI tech developed, we would not need to regulate it so that greed does not take over. Same with guns.
> The truth is, if there was no AI tech developed, we would not need to regulate it so that greed does not take over.
Same could be said for the Internet as we know it too. Literally replace AI with Internet above and it reads equally true. Some would argue (me included some days) we are worse off as a society ~30 years later. That’s also a legitimate case that can be made it was a huge benefit to society too. Will the same be said of AI in 2042?
Oh the web was full of slop long before LLMs arrived. Nothing new. If anything, AI slop is higher quality than was SEO crap. And of course we can't uninvent AI just like we can't unborn a human.
Yes, AI text could be considered higher quality than traditional SEO, but at the same time, it's also very much not, because it always sounds like it might be authoritative, but you could be reading something hallucinated.
In the end, the text was still only ever made to get visitors to websites, not to provide accurate information.
> it's also very much not, because it always sounds like it might be authoritative, but you could be reading something hallucinated.
People telling lies on the internet is an old enough and well known enough issue that it’s appeared in children’s TV shows. One need only dive down the rabbit hole of 9/11 “truthers” to see how much completely made up bullshit is published online as absolute fact with authoritative certainty. AI is the hot new thing and gets all the headlines, but Scottish Wikipedia was a problem long before AI and long after society largely settled its mind about how reliable Wikipedia is.
> the fact people having their jobs replace by technology are completely screwed over is a result of the society we have all created together, it's not a rule of nature.
How did the handloom weavers and spinners handle the rise of the machines?
> How did the handloom weavers and spinners handle the rise of the machines?
In the past, new jobs appeared that the workers could migrate to.
Today, it seems that AI may replace jobs much quicker than before and it's not clear to me which new jobs will be "invented" to balance the loss.
Optimists will say that we have always managed to invent new types of work fast enough to reduce the impact to society, but in my opinion it is unlikely to happen this time. Unless the politicians figure out a way to keep the unemployment content (basic income etc.),
I fear we may end up in a dystopia within our lifetimes. I may be wrong and we could end up in a post scarcity (star trek) world, but if the current ambitions of the top 1% is an indicator, it won't happen unless the politicians create a better tax system to compensate the loss of jobs. I doubt they will give up wealth and influence voluntarily.
> In the past, new jobs appeared that the workers could migrate to.
There was no happy and smooth transition that you seem to allude to. The Luddite movement was in direct response to this: people were dying over this. Factory owners fired or massively reduced wages of workers, replacing many with child workers in precarious and dangerous conditions. In response, the workers smashed the machines that were being used to eliminate their jobs and prevent them from feeding themselves and their families (_not_ the machines that were used to make their jobs easier).
I think if we zoom out of the tech and into a bit more of economic the risk I see is that the incumbent hold a lot of advantages and also control the means of production due secondary factors like gpu scarcity.
If we want to draw some parallel this may trigger a robber baron kind of outcome more than an industrial revolution.
The existence of workable open weight models tips me more toward the optimistic outcome
Butthere's trillions at stake now and that must not be discounted it's the kind of wealth accumulation that can easily trigger a war. (And if you thinkit isn't you can look at the oil wars in the 90s and other more recent resources war bring fought in Europe today.
Expect "gpu gap" talks sooner that later, and notice there's a few global power with no horse to race.
So it's simple: don't do anything at all about the technology that is the impetus for these horrible disruptions, just completely rebuild our entire society instead.
I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. (That does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)
Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.
Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.
Which is why they won’t have a public API that allows running transactions that send money to arbitrary accounts.
If someone altered the terminal to charge more (a hypothetical suggestion above), they could recoup that money from the merchant’s account because they have an agreement in place.
You can’t run arbitrary transactions to arbitrary accounts (the other proposed attack above) because there isn’t an agreement in place.
Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
> Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.
> Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.
That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend.
In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know:
a) Where your terminals are deployed
b) Your real details
c) The terminal's ID and the terminal's serial that maps to that specific merchant ID.
So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24.
Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have:
1. Their bank account number
2. Their physical address
3. The company registration number
4. Verified ID copies of the owner, directors, managers, etc.
5. Their money (from their transactions).
So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree.
> Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance.
Not supposed to be possible on a certified terminal. The certification tests this particular case (the transaction is a hash of the keys, amount and a few other things. The display of the swipe/tap/insert screen and the pin-entry are under control of the certified kernel, so the userspacve application has no control of the amount that is displayed).
> And maybe even send the money to a different account.
I've heard of it happening here in Brazil. In the simplest variant, something is glued on top of the screen to hide the higher digits, making the value appear to be lower; supposedly, some more advanced variants of the scam have a damaged or tampered screen.
unless it's changed recently that only applies to tap and chip payments (which you should always prefer to avoid card skimmers) and not the old slide the ~~barcode~~ magnetic strip kinda payment.
Does anyone still use the magnetic strip? I think it's been over a decade since I've seen a credit card without the chip, and terminals have been able to read the chip since forever. I think the last few times a store tried to use the magnetic strip on my card (because the chip failed to read due to a bad contact), the transaction was simply rejected due to not using the chip.
Yes, occasionally when refueling a shared car owned by a company that distributes those cars all over The Netherlands. It's common here in leased car fleets as well, where the user gets a magstripe card to refuel (and needs to provide details about current mileage and if the car was a replacement car).
I used it recently because my bank denied the contactless and chip payments I tried before that. Surprisingly the mag stripe worked - and this is with card issues from a EU bank where mag stripes have been an historical artifact much longer than in the US.
USA was very late to adopt chip/tap terminals, even relative to Canada. I could be wrong but IIRC it was only when Apple Pay came along that tap-enabled terminals began to hit critical mass.
It's always incredible to see few people in the US uses the tech that's available until Apple makes it a thing, and seeing that play out over and over.
This is the same everywhere though. See, e.g. incredibly late fibre rollout in many well off EU countries because they already had copper in the ground everywhere vs. developing countries that never had that legacy infrastructure inertia.
What I'm talking about is a lot of those terminals supported tap to pay well before Apple Pay became a thing. The infrastructure was there, the technology was there, you could use it if you cared to do so. Most people just didn't know it was even an option. Google Wallet supported tap to pay years before Apple Pay was even announced. Tap to pay credit cards existed years before then. Nobody gave a shit about the technology until Apple announced Apple Pay and suddenly it became a big deal for vendors to actually check if their POS systems had it enabled or not.
I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.
Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.
“which you should always prefer to avoid card skimmers” could use a disambiguation comma between “prefer” and “to”; I misread it several times before the intended meaning clicked.
Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.
> could just make it collect CC details with every transaction
Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it.
And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.
I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware.
That's happened at least several times already.
I believe breached PoS terminals were what happened in the big Target hack.
> I believe breached PoS terminals were what happened in the big Target hack.
The problem is that PoS terminals are not EMV terminals. EMV terminals have been through a certification process, and the hardware part of that certification ensures that the vendor only runs signed-binaries.
Honestly, even if you could write and sideload (or even replace) the applications on the EMV terminal, I do not see a way to get them to a) run, and then b) send money elsewhere.
This is a fair thing to point out! I as a user feel I'm being much more respected when I'm allowed to use some independent client software of my choices, than being told that "for my own good" I must use the absolute abomination that is most of the software provided by Big Tech firms themselves. Like, thanks for your opinion, Google, but 90% of these "security audits" are about box checking and ass-covering. It's the technology equivalent of all of the silliest parts of the TSA process, meaning that it contributes nothing to security while employing a lot of people to do valueless work at the expense of those doing useful work.
Facebook provided a general API for apps, not some kind of data feed. The API required user consent from the app user, though almost certainly not informed consent.
The API also provided too much data, in particular on the user's social graph, which is why a single user giving uninformed consent would lead to data being extracted for multiple others. But even if the app had informed users about intending to steal the social graph, most users would still have consented. They would not have read the text, or not cared. Just click ok until the computer lets you do what you wanted.
So we really do know that the only way to safeguard the data is to design safe scoped APIs for the typical use cases, and keep dangerous unscoped APIs around only as an escape hatch with much stricter security and safety requirements.
Facebook users shared data with their friends. Those friends gave access to the data to CA. So like if you share a document with me and I then give CA access to my GDrive.
In the same sense that if someone uses a third-party Google Drive client, the input of other collaborators on shared documents is exposed without their consent. (It was data about friends of users who authorized the application in Facebook's case).
IIRC the way Facebook's "platform" stuff worked was that when one user authorized an application, it got to see all their friends' data. Farmville had to be able to access your friends list to see who you could send a sheep to, you see.
Nowerdays this seems like an incredibly dumb idea, sure, and personally I disabled it entirely the moment it came out. But we can cut them some slack, because back in ~2006 facebook was a new thing, for young people - and nobody was sure where this new "social media" thing was going to go.
On top of that I believe Cambridge Analytica did the usual "personality test" trickery where you fill out a survey, then it won't show your result until you hand over your details and accept some legal mumbo-jumbo.
So your Great Uncle wanted to know what harry potter character he was, clicked a consent button, and Cambridge Analytica got your PII.
Disclaimer: My full time job involves developing a CSI driver that is on this list (not simplyblock, but I won't say more than that to avoid completely doxxing myself).
A lot of this chart seems weird - is it somehow autogenerated?
For example, what does it mean for a driver to support ReadWriteOncePod? On Kubernetes, all drivers "automatically" support RWOP if they support normal ReadWriteOnce. I then thought maybe it meant the driver supported the SINGLE_NODE_SINGLE_WRITER CSI Capability (which basically lets a CSI driver differentiate RWO vs RWOP and treat the second specially) - but AliCloud disk supports RWOP on this chart despite not doing that (https://github.com/search?q=repo%3Akubernetes-sigs%2Falibaba...).
I bet there are lots of mistakes yet. It's not really automatically generated, but I started from the list at https://kubernetes-csi.github.io/docs/drivers.html and split the table into a YAML file, marking the features that are mentioned in the docs.
Fixed a few, where I saw thinks in their respective docs, and added features like file or object storage. Also added a few that weren't mentioned.
Surely this is massively vulnerable to double spend attacks?