It's the situation I immediately thought of. I remember reading back several months ago that OpenAI was stealing from Apple. I suppose apple is returning the favor.
This is largely a myth. Both unauthorized ACH debits and debit card payments can be disputed, and accountholders have a legal right to do so (Reg E) just like they have for credit cards (Reg Z).
The only difference is that you're potentially out your own money, but with credit cards you're also out of credit until the dispute is resolved, and you can have multiple debit cards and checking accounts just like you can have multiple credit cards as a backup.
The fact that someone has "a legal right to do" something does not mean that realising that right in practice is fast, easy, or even possible.
I'd rather not be in the situation where I have to realise my "legal right" to ACH chargeback — which will involve hurdles, wasted time, and probably also legal fees — by not giving anyone the authorisation to perform ACH pulls in the first place. Cash works best for this — you're never out of more than what you hand over — but Apple Pay gives me similar protections.
> The fact that someone has "a legal right to do" something does not mean that realising that right in practice is fast, easy, or even possible.
The legal right to have unauthorized payments returned is ultimately backstopped by law. This is the case for both credit and debit cards. That (and scheme rules) is the reason you don't have to shop for the "most chargeback friendly card" or similar.
> Apple Pay gives me similar protections.
How does Apple Pay factor in here? It's just a different way of using your existing credit and debit cards, with exactly the same dispute protections.
In theory; in practice, one reliably and repeatably works, and the other I'm not sure (and not willing to find out.) I've had some experience with stolen checks; while the money has been ultimately returned to me, it was a major hassle, and cost me several sleepless nights.
> How does Apple Pay factor in here?
Apple Pay gives the merchant a generated CC number (per-card, per-device) with a generated one-time security code (for every single purchase.) If the merchant is breached, all the hackers are getting is a generated CC number and a (expired after single use) security code, so they can't charge my Apple Pay card at all — and of course not my real card (which has never been exposed to the merchant to begin with.) The easiest and fastest chargeback is when there is no charge!
> one reliably and repeatably works, and the other I'm not sure (and not willing to find out.)
But that's exactly my point! People perceive credit cards as safer and don't try anything else, so the perception remains prominent.
It's just a regular trust bootstrapping problem that could only be solved by powerful market players breaking the cycle, and it seems like there isn't really appetite for that in the US.
> Apple Pay gives the merchant a generated CC number (per-card, per-device)[...]
Ah, yes, it does generally protect you from merchant data breaches. But your original point, "you're never out of more than what you hand over", is not quite true – the original merchant can post some subsequent charges on Apple Pay as well without you having to accept anything on your phone.
> trust bootstrapping problem that could only be solved
Onus of proof is on you that it needs to be solved, as the alternative exists and is working well. Think of it this way: I have my trust in US dollar (because everybody else has it too); maybe I could give the same trust in Swiss franc, or Emirati dirham, or South African rand — but why would I? US dollar already gives me everything I need.
> it does generally protect you from merchant data breaches
And from rogue merchants, too.
> the original merchant can post some subsequent charges
This has never happened to me; however my original point is that Apple Pay gives me better protections than regular CC, and it was given as a response to your point of "exactly the same dispute protections". Apple Pay is better since using it leads to fewer disputes in the first place; once the dispute is happening, the protections might be the same.
> Onus of proof is on you that it needs to be solved, as the alternative exists and is working well.
They are incredibly expensive. I think that part should be solved.
One obstacle on the way there is this perception that everything else is worse in terms of risk to consumers. A lot gets bundled up in the US to yield this common perception of "credit cards good, everything else bad".
>> > the original merchant can post some subsequent charges
> This has never happened to me;
I've rented cars, paid gym subscriptions etc. with Apple Pay. I can assure you merchant initiated charges are possible.
I'm trying to find this myself. Since I upgraded to the latest version of iOS, I have found no way to disable these stupid writing tools. Whenever I try to take a screenshot, the AI tries to give me suggestions on what to do with the photo before I can properly crop it, and speech to text continues to insert grammar into the output after removing the toggle that disables the auto insertion of grammar (it also seems worse now).
My guess is that we need some tailored configuration profile that will run on the device, which seems to be how this project solved it for macOS.
The struggle is the blind opening of chrome, like most people probably just do without thinking. Unless you are really a hardcore frontend developer, you lose nothing by switching to Firefox (or non chrome/chromium browser). I operate both and for 95%, maybe even more, there is no difference. By switching you will put pressure on google to keep on the users good side.
Not just that, I've been seeing a huge effort in the Ada community to leverage LLMs to convert a lot of libraries into formally verified SPARK code. One of the biggest issues I see with vibe coded stuff is that it's difficult to review and difficult to prove that it's doing what you think it's doing, but with a strongly type language like Ada and formal verification with SPARK, LLM output is easy to read and easy to prove.
I live out of my RSS reader for everything from YouTube to Reddit, and in this case I leverage this feed for the HN front page:
https://hnrss.org/frontpage
The front page of HN has always been pretty good at filtering out AI generated articles (and if one makes it it's usually flagged by the time I get to it). Then I just glance through the list of articles that made it to the front page and decide which ones I want to read.
I reported a blatantly sexual adult ad on Facebook the other day, they got back to me and said that their moderators reviewed the ad and that it was appropriate.
