> The point of SynthID is to make generated images identifiable, in an attempt to prevent 1984-esque situations where you can't believe your eyes and ears.
You can still use traditional methods to manipulate images, too, so I don't think a "does not contain SynthID watermark" means you can trust that image more. In the other hand, encoding a lot of personal and other information in the watermark (136 bit is a lot) that can not be easily removed and most of the people are unaware of it seems really an 1984-like dystopia.
Wero is just another private company trying get their cut of payment fees. You can do the same thing with SEPA Instant Payment (or some member states outside of the Eurozone have their own similar thing).
I don't see why Wero should exists, their business model seems like "trying to get money for the same service you can get for free".
Wero does several things. You can already send instant payments if you fill out IBAN and such, but entering order numbers, account references, and other such cruft for purchasing products is a pain. Companies receiving such payments also need to connect payment to a user and update their digital processes somehow. Wero offers such a solution so you don't have to find a PSD2 processor (which will probably cost just as much).
For interpersonal transactions I don't really see the advantage here, but for commercial use cases it's got a solid product and purpose.
Wero doesn't stand to benefit much from payment fees as European payment fees are already rather slim compared to, for instance, American ones (crazy things like percentages of purchase price with a minimum amount!).
So how can a QR code not supply the necessary data? Example:
payment://iban=XXXXXXXXXXXXXXX&amount=12.34EUR
Any bank app should be able to read this. What is so complicated? Right, nothing. Credit card companies are a hidden tax, worse, they are a tax on turnover, not profits.
But in EU you don't usually get credit... The cards are often debit only. Yes, credit cards do exist but they are not like the american cards, and things like chargebacks are not super simple. I for example haven't had a credit card over a decade now...
Chargebacks exists for (EU style) debit cards, too. It doesn't need to be simple just available, so if the merchant disappears with your money or someone uses your stolen card, there is a way you can get your money back. With bank transfers that's not possible (at least here).
wero is a european initiative set up by a consortium of banks that is built layered upon instant payments. it's not a private company like paypal or visa, its an attempt at making European payment infrastructure
Wero's Dutch predecessor, iDEAL, has been an established part of online payments for 20 years now.
As barely anyone has a credit card and very people want to deal with the faff of manually entering billing codes or account numbers, iDEAL usage is near universal for online payments. I don't recall fees ever going up as an end customer.
Card fees aren't paid by end customers either. The Swedish iDEAL equivalent, Swish, is more expensive than cards for smaller transactions (below 15 euros). Wero will be like Swish, not Pix.
Yep. The new thing is that you can pay your groceries with it in the supermarket early next year.
What I was reading, you're supposed to be able to send money to people with it this summer, pay in internet shops late this year and supermarkets and restaurants will follow in 2027.
I couldn't have said it better. I don't understand what they solve.
We need instant, free SEPA transfers around the clock. Switzerland is not part of SEPA but IBAN is used so it is trivial to send payments to foreign accounts that have an IBAN.
I always say that the day Trump decides to block Visa/MasterCard outside the US is the day we get instant payments and finally get rid of cards.
In Germany we have free instant SEPA transfers. What Wero solves is that you can send money without giving your IBAN number, which at least in Germany can be used to take money from your account.
So you get standardized payment system where you scan a QR code or NFC tag with your bank app and the payment goes through IBAN and the system shows an approval of payment.
It's called SEPA direct debit. For some reason people don't want to use their web bank to pay for things, so what you usually do is you do a SEPA direct debit contract and the company takes the money from your account every month.
Switzerland since last summer, but banks aren't forced to expose the feature to retail customers yet, at least not for free. We could have had that 15 years ago if our government wasn't so afraid of upsetting the banking lobbies.
> We need instant, free SEPA transfers around the clock.
We have? SCT inst has been rolled out almost everywhere
> Switzerland is not part of SEPA
We definitely are. Transfers in EUR from/to CH IBANs use SEPA rails. CHF accounts can also send or receive EUR transparently (usually at a bad FX rate, but it just works).
> I don't understand what they solve. [...]
> I always say that the day Trump decides to block Visa/MasterCard outside the US is the day we get instant payments and finally get rid of cards.
You answered your own question. We need pan-European payments systems on top of the existing banking infrastructure. Payments and transfers aren't the same thing. By moving to mobile wallets with QR code and NFC payments, this opens up interoperability beyond Europe too.
> We have? SCT inst has been rolled out almost everywhere
That is true; I should have said "EEA" or "countries supporting IBAN".
> We definitely are. Transfers in EUR from/to CH IBANs use SEPA rails. CHF accounts can also send or receive EUR transparently (usually at a bad FX rate, but it just works).
Yes, which is exactly my point. We need it to work for CHF as well. Instant payments are not the norm and in fact UBS is charging for it.
> You answered your own question. We need pan-European payments systems on top of the existing banking infrastructure. Payments and transfers aren't the same thing. By moving to mobile wallets with QR code and NFC payments, this opens up interoperability beyond Europe too.
A payment should be a bank transfer. Anything more complicated is just something that is to be exploited by middle-men.
This is a false dichotomy. You can have very cheap transaction fees, Pix is state-run and probably operates at a loss, with merchant fees as low as 0.2~0.3%. In comparison the cheapest card payment under the EEA interchange cap is probably slightly above 0.5% when you add scheme fees and PSP costs.
However businesses do require payment systems and not just barebones bank transfers. Except for high trust, low volume transactions such as buying a car, paying your rent...
> A payment should be a bank transfer. Anything more complicated is just something that is to be exploited by middle-men.
I disagree with that. Payments (especially online and contactless ones) should have some form of buyer protection, chargeback and a way to handle fraudulent transaction, lost / stolen cards, etc.
Maybe that's changes by country, but here bank transfers are basically final and can not be cancelled or recalled. Why would a bank cover your losses from their profits?
Which has zero incentive to side with the other party. You pay by bank transfer, once the money is on the merchant's account, why would their bank ever agree to a refund in case of dispute? Now it's between you and the merchant, good luck with filing police reports and court claims especially abroad.
The most common scams nowadays involve social engineering to make people log into their online banking and transfer money, specifically because there's no way to revert transactions. The victims are typically 100% liable as they accept and authorize these.
How big this cached data is? Wouldn't it be possible to download it after idling a few minutes "to suspend the session", and upload and restore it when the user starts their next interaction?
I often see a local model QWEN3.5-Coder-Next grow to about 5 GB or so over the course of a session using llamacpp-server. I'd better these trillion parameter models are even worse. Even if you wanted to download it or offload it or offered that as a service, to start back up again, you'd _still_ be paying the token cost because all of that context _is_ the tokens you've just done.
The cache is what makes your journey from 1k prompt to 1million token solution speedy in one 'vibe' session. Loading that again will cost the entire journey.
What they mean when they say 'cached' is that it is loaded into the GPU memory on anthropic servers.
You already have the data on your own machine, and that 'upload and restore' process is exactly what is happening when you restart an idle session. The issue is that it takes time, and it counts as token usage because you have to send the data for the GPU to load, and that data is the 'tokens'.
Wrong on both counts. The kv-cache is likely to be offloaded to RAM or disk. What you have locally is just the log of messages. The kv-cache is the internal LLM state after having processed these messages, and it is a lot bigger.
I shouldn't have said 'loaded into GPU memory', but my point still stands... the cached data is on the anthropic side, which means that caching more locally isn't going to help with that.
> upload and restore it when the user starts their next interaction
The data is the conversation (along with the thinking tokens).
There is no download - you already have it.
The issue is that it gets expunged from the (very expensive, very limited) GPU cache and to reload the cache you have to reprocess the whole conversation.
That is doable, but as Boris notes it costs lots of tokens.
> Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency
NSA still has the secret Suite A system for their most sensitive information. If they think that is better than the current public algorithms and their goal is to make telecommunications vendors to have better encryption, then why doesn't they publish those so telco could use it?
> Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.)
The NSA weakened DES against brute-force attack by reducing the key size (while making it stronger against differential cryptanalysis, though).
The thing that sets this effort apart from DES and Clipper is that USG actually has skin in the game. Neither DES or Clipper were ever intended or approved to protect classified information.
These are algorithms that NSA will use in real systems to protect information up to the TOP SECRET codeword level through programs such as CNSA 2.0[1] and CsFC.
Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm?
What's the PQC construction you couldn't say either thing about?
> Couldn't NSA have not known about an issue with ML-KEM, and thus wanted to prevent its commercial acceptance, which it did simply by approving the algorithm?
Could, but they did not do that. So, the question is to be stated: Why?
I think you could use dm-integrity over the raw disks to have checksums and protect against bitrot then you can use mdraid to make a RAID1/5/6 of the virtual blockdevs presented by dm-integrity.
I suspect this is still vulnerable to the write hole problem.
You can add LVM to get snapshots, but this still not an end-to-end copy-on-write solution that btrfs and ZFS should provide.
reply