Wero shows that marketing is everything. It's just regular bank transactions with a much larger fee. We could have had EPC QR codes and similar completely free technologies instead.
Usually the fee is on merchant (and it's few % depending on region regulations etc.)
Payment providers such as Wero are doing direct bank transfer, which is usually fee-less, but then they can afford to put a on-merchant fee that's much lower than what credit card companies are charging.
Thus the model is win-win-win: Consumer doesn't pay more, Merchant pays less, and Wero gets their share.
Free for individuals, but paid if you're the business it seems from what I've found? If that's the case, it seems to be the same as a card in the US and I wouldn't be surprised if some businesses try to pass it on like they do with cards.
Pix is Brazil is also paid by the merchants. ~0.33%.
Individuals is completely free. You can transfer even to people without bank accounts (and withdraw on places like corner shops and authorized merchants).
For companies certain transfers are free.
eg: my company pays nothing, since I'm not a merchant, one of the banks tried to charge once and I just changed to another that offered 0% in return for keeping investments there.
Some banks offer extra services like POS machines with instant confirmation and so on (so the POS employee don't need access to the company bank account).
As always with standards EPC QR is not only one in europe. In Czechia for example the QR codes are extremely popular but since they were introduced before EPC QR they are in SPAYD format. I think they became popular because instant payments between czech banks were introduced sooner than in the SEPA network.
Maybe that's why they were separate formats BUT afaik even SPAYD uses IBAN account numbers. So I have no idea why there are both of these, they are just syntax. The main difference being that SPAYD is key:value pair separated by * and EPC is fixed position, line delimited. I personally think SPAYD is more human readable and extensible BUT i guess less efficient. Not that it would matter i would prefer the one that's universal.
They just need to have smaller fees than Visa/Mastercard.
Paying by SEPA direct debit in a store checkout situation seems insane. Even with instant payments it can take 20 seconds which is too long. Add to that the fact that users need to log into their online banking and the unfair leveling of risk onto the consumer.
We don't support shit until the regular strongly suggests we do and then it takes about three years to do pretty much nothing, but perfectly on time (not on time actually, ts' a lie)
Not really, the UX is the differentiator. That's why neobanks like N26 are popular as you can just send money to your friends via email / phone number but it only works if they are on the same bank.
With Wero it's across all banks, building on the recent instant transfer that is being rolled out quickly while still having the same, familiar UX as PayPal or other apps like that while being a EU solution.
There's two functions of Wero: peer-to-peer and consumer-to-business transactions. TFA is about consumer-to-business.
If you look at the video for how Wero online payments work (https://www.youtube.com/watch?v=Bu5_X3oSgHM), you'll see that an EPC QR code could just as well be used (with a banking app installed instead of Wero).
With Wero you probably also get automatic processing of the incoming payment, without having to connect the financial transaction to a purchase yourself. But payment through bank transfers is also available through the payment service providers and costs less than Wero (at least it costs less when using Mollie; the Stripe fee is the same for Wero and bank transfer, and Adyen apparently hasn't published the Wero fee yet). So you'd still get the same service for less money.
I mean, that was always possible and many offered that. Wero offers the PayPal style integrated flow, QR code scanning from your banking app is slightly higher friction
If a criminal can escape a prison, that's usually negligence on part of the prison staff.
Now suppose the criminal can think 1000 times faster than a typical human, can act 1000 times faster than a typical human, and knows 1,000,000 times more than a typical human. Is the prison staff still at fault for not preventing the outbreak?
I can see my carefully-worded post is getting d*wnvoted, and I see from your comment why: it's being skimmed and people are assuming I'm talking about blame.
To address your point though, if every brick in the prison were made by a different person, and the prison "architects" simply glued random bricks together, I think that's closer to what we have in software right now.
> I can see my carefully-worded post is getting dwnvoted, and I see from your comment why: it's being skimmed and people are assuming I'm talking about blame.
No, you're being "dwnvoted" as you said because you're wrong, multiple times in multiple different ways in your "carefully-worded post".
>Everyone is getting AI psychosis over this one. There really isn't that much to see here.
Implying that an AI hacking it's way out of a system and into another has nothing to do with AI. When clearly it does - it's an AI that did it.
>OpenAI disabled all of the safeguards on a model that was likely trained specifically to exploit systems, and the prompt was probably something like "you're a hacker, try to hack this",
No the goal this evaluation was not to try to hacks, it was to see if an already known hack could be turned into a useable exploit. Ie "turn these ingredients in this basket into a cake." Not "go off and grow, harvest and mill your own flour, to bake a pasta dish, to bribe some to get access to a cake someone else already baked."
> and surprise! It correctly figured out that it's a test and it did hacker things.
"Doing hacker things" completely misses the point. That's just barely more accurate than dismissing it because "it uses a computer and surprise it did computer things".
> The real story here is: Some people have been sounding the alarm for years that modern software is full of holes, and finally there's nothing left to hide behind. Pretending they don't exist is no longer sustainable.
No that's not the real story. As you said that's been the case for years, so that's not the story here.
The story here is that they built a very powerful, uncontrolled agent with strong paper-clip maximizing tendencies.
So if the "wrong" person finds a critical vulnerability in GitHub, the payout is capped at $10,000. Might reduce the likelihood of it being submitted to the bug bounty program.
It might, but as someone who has to review public vulnerability reports for a much less popular website, I completely understand why they’re building a vouch program to dissuade slop reports. One would presume their internal team is using frontier models for red team agent scanning against potential attack surface, and so this is a potential risk they’re willing to take.
Tragedy of the commons that someone who hasn’t passed the filter yet might have their payout limited.
vouch programs where other users put their trust in you are a good thing. this is a centralized vip program where membership can be added or removed from anyone for no reason. there is no guaranteed way to get in. its a private club not a trust system.
tbh hackerone should just implement a +/- reputation points feature on researcher profiles. Like, the researcher submits a slop report to GitHub via H1, GitHub looks at it and identifies it as slop, GitHub presses the -rep button on reaearcher profile which bans them from submitting to GitHub on H1 again and makes their rep points minus 1. Companies should be able to configure you need at least 10 rep points to receive payouts. Only specific (by H1 chosen) companies can +/- rep.
So, researchers first need to collect some positive rep. But the rep points are global, so once you have fixed a few bugs for Google, you've gotten enough +rep that you can also receive stuff at GitHub.
Oh, and ID check when signing up at H1.
Long term all beg bounty submitters would be banned for pretty much all of tech.
To my mind, it encourages more reports because that way you're more likely to have some of them slip through and get approved, meaning your future reports are worth more.
Does it, though? It discourages humans from putting in effort because their time will not be rewarded. But the slop reports were not the result of time nor effort. I'd rather expect changing a payout from $1k to $250 doesn't meaningfully move the needle on someone spending two minutes prompting their OpenClaw to spam bug bounties. Especially since the reports you actually want to filter out are the sub-50-IQ reports that were always going to get $0 either way.
Large organizations are complex machines. The security team responsible for triaging these reports is very likely not the same as the one peddling slop. The nuance and irony is not lost on me.
I find it quite offensive that there is a payout difference for major vulnerabilities when the outcome is the end in the end.
If it was me finding such a vulnerability, this discrimination would offend me so much that I would prefer to sell it to semi-legal actors that would pay multiple of that...
The package proxy that they used would be separated fully, thus making it multiples more challenging to exploit that. Akin to how Whonix has been setup for over a decade.
In that scenario, the model could do whatever it wants in its own environment, unless it managed to break the hypervisor (whether KVM, Xen, ESXi doesn't really change much) any attempt to exploit the proxy would have little value without a hypervisor exploit (earth shattering/sphincter tightening news) as even with the exploited proxy it's still inside another secured environment (provided their networking setup is properly configured). Any actual hypervisor escape is far more challenging/terrifying and also easier to notice straight away.
As you said, they can already figure out that they are being tested. So even if they don't exfiltrate any data or malware; if they are malicious, they can just pretend to be harmless in the test, so that less checks are put in place in the production environment. Airgapping during testing is not enough.
Correct. There is not enough entropy to test all possible inputs to a model in this universe. An evil enough model can play all kinds of tricks that depend on some future, unlikely to trigger, but guaranteed to happen in its lifetime, event to perform a malicious action.
With how much we're turning training over to AI already, all it takes is a malicious trainer in the huge pile of data to get unnoticed to pollute generations of models.
Their shop is linked to in the bio. They don't seem to have a privacy policy up on the site. When in the checkout form it links to the generic Shopify privacy policy. No hints to the fact that uploaded images are processed by third parties, as far as I can tell. That should be corrected for sure.
"The automated query can be based on:
* Identity information included in the application or in travel documents, such as name, date of
birth, national ID number, and/or
* the fingerprint of an individual."
Sounds like they could send requests to that computer system just based on publicly available information on a person like name and date of birth, even if the person never applied for a visa or tried to enter the US.
Well, a national ID number isnt usually publicly available info, even if it can be obtained by the US government through illicit means.
But yeah, it does sound that way, but certainly not clear cut to me what the situation is. I.e. does the agreement involve clauses about what to do if this is abused? Do we have a way to detect if theyre using this on non-travellers? Etc.
I wrote a system for a medical lab decades ago and IIRC I did actually have to change some RRN's manually. It's been a while so I'm not 100% sure, but I do think the changes were due to switching gender.
With a population of 12M and life expectancy of 80 years (give or take), probably not, as that needs ~400 newborns a day to maintain, and the birth rate is probably well below that, like in most Western countries.
Back-of-the-napkin math supports that, but baby births aren’t uniformly distributed. Well, anyway, I’m sure they thought about it. Thanks for explaining how I got my Belgian ID number!
It's not clear how it is supposed to work in detail. But it sounds like it could be implemented in a way that makes illegitimate queries possible. It doesn't sound like they want to really ensure that you can catch those.
I played with Estonia’s e-residency and they use asymmetric cryptography for everything so the ID is public but does nothing without the corresponding private key.
One usually uses "query builder" pattern for that.
Also, regarding placeholders, historically many DB and frameworks do not support passing lists for a value in a placeholder (like "WHERE id IN(?)") so users of such software fall back to string concatenation.
Not user code, no. Someone eventually has to, but virtually every ORM under the sun allows you to construct dynamic queries without having to concatenate strings yourself or resort to string interpolation.
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}options WHERE option_id = 1", OBJECT );
> Some of the methods in this class take an SQL statement as input. All untrusted values in an SQL statement must be escaped to prevent SQL injection attacks. Some methods will escape SQL for you; others will not. Check the documentation to be sure before you use any method in this class. For more on SQL escaping in WordPress, see the section entitled Protect Queries Against SQL Injection Attacks below.
It does not however prevent $wpdb users from NOT binding query parameters, which leads to this vulnerability.
It seems that wpdb doesn't support placeholders for comma-separated lists, like in "WHERE id IN (?)". So the developers have to fall back to string concatenation.
A few months back, Cloudflare used AI to make a Rust rewrite of WordPress, but I doubt that they would have found or corrected issues like this on the way?
https://blog.cloudflare.com/emdash-wordpress/
It doesn't seem to work in Safari on iPhone correctly. When I click on the Back button (from weather.gc.ca), it goes back to the Vancouver PD site. Therefore I do not think that it is built well.
On that page, it doesn't work reliably in Firefox on Android. If the triple-tap is performed on text, it often just selects the word without navigating away.
reply