The super promise died with crypto, now you have to add no backsies. My site uses No Backsies Proofs (NBPs) which are encrypted to prove that all my super promises are backed by a no backsie which is stored in the no backsie vault in Antarctica.
Later on moxie ends up writing a quick review of NBPs
> Instead of storing the data on-chain, NBPs instead contain a URL that points to the data. What surprised me about the standards was that there’s no hash commitment for the data located at the URL. Looking at many of the NBPs on popular marketplaces being sold for tens, hundreds, or millions of dollars, that URL often just points to some VPS running Apache somewhere. Anyone with access to that machine, anyone who buys that domain name in the future, or anyone who compromises that machine can change the image, title, description, etc for the NBP to whatever they’d like at any time (regardless of whether or not they “own” the token). There’s nothing in the NBP spec that tells you what the image “should” be, or even allows you to confirm whether something is the “correct” image.
this is why my startup is launching backsies rollups for the blob, with null-effect prebacksies. this way everyone can be assured that any backsies issued are technically equivalent to just not making the original agreement! if you can discover a post-agreement backsie within the availability period of 0 days, and we can confirm it, we'll pay you $2,000 no backsies. so we have a market incentive not to lie to you. it's very efficient
I would feel more comfortable if your super promises were all on a blockchain, and we made No Backsie NFTs so people could clearly see these were legitimate and bid on them.
Today they have announced further, related vulnerabilities, and if you're running your own instance you should patch again, or disable your instance until you have a chance to do so.
The vulnerabilities allow an unauthenticated attacker to run arbitrary commands with the same privileges as the Metabase server on the server you are running Metabase on. This would allow arbitrary querying of any database that Metabase is connected to.
UsabilityHub | Engineering | Remote (Australia or New Zealand) | Full-time, 9 day fortnight, or 4 day week | https://usabilityhub.com/careers
Hey HN, Nick here, CTO and co-founder at UsabilityHub.
We're looking to hire a couple of engineers, with some flexibility on seniority level. We're a remote first and cross functional team, and UsabilityHub is a bootstrapped and successful business that's been focused on sustainable growth over the last ten years.
The team is small, close knit, and has some really excellent engineers and designers. The focus of these roles is building new customer facing functionality - we're effectively building three new products this year so there's lots of greenfields work to do.
The big pieces of our tech stack are Ruby, Rails, Typescript, Postgres. We're not fussy if you haven't used some or any of those, but prefer T-shaped developers that are keen and able to pick new things up quickly and contribute throughout the stack.
For the three roles we have open, starting compensation ranges from $120k AUD to $160k AUD (or NZD equivalents) plus ESOP and profit share. We review this every six months and adjust upwards based on performance in the role.
There's lots more info about these specific roles on our careers page at https://usabilityhub.com/careers. Feel free to reach out to me directly with any questions (email is in profile).
Some kind of concurrency bug in a library they were using to retrieve cached data from Redis led to this leak.
> We took ChatGPT offline earlier this week due to a bug in an open-source library which allowed some users to see titles from another active user’s chat history. It’s also possible that the first message of a newly-created conversation was visible in someone else’s chat history if both users were active around the same time.
I don't mean to do Twilio's work of defending them, but in my experience it's possible they actually don't know how much to bill the customer. What they may know is the generalized per-minute or per-session rate they've agreed with another operator alongside a general "premium rate numbers will be settled at a later date" kind of clause.
My employer got bit by this several years ago, purely on calls within the +1 country code. Before this practice was largely banned, some small carriers were allowed to designate certain rate centers as higher cost. So our VoIP carrier would say that a call to a given area code was $0.003/minute but the calls would later settle out at $0.25/minute because of a 1,000s block of numbers being (unknowing to us our our carrier) as higher cost and being settlement billed back at the higher rate.
Twilio could agree to carry some or all of this risk for its customers as part of their value-add and fees. That way, Twilio has the incentive to make the proper changes for its customers and would have the experience of looking at all of the return billed rates for all of the calls or messages across its entire customer base to help prevent toll fraud.
This is the case, the telephone billing system is perhaps the most complicated pile of softwareshit you have ever seen in your LIFE - and some of it is insane.
When I was an intern, I was working for a big company on a project to optimize some call center management. Basically put mainframe reports on an intranet.
The company had made a change of some sort where whatever EDI connection between the telco and the company stopped working. I learned this when and angry facilities guy came up looking for my boss’s boss to sign for a delivery. I was the only person there, so I did. 15 minutes later, two pallets of bankers boxes came up - thousands of single sided pages of itemized call details.
My favourite was getting charged for an sms my iPhone sent which was a phone home to an Apple headquarters short code for iMessage. iOS hides these from the user. Most providers don’t charge for this, but some do.
Really sucks when you carefully load 10 EUR of credit to buy a 10 EUR prepaid plan for the month and see 0,05 deducted despite being incredibly careful to not do anything that would incur a charge before buying the plan.
Apple DOES say that, when you set up FaceTime and iMessage!
There is a pop up that says "Your carrier may charge for the messages used to activate iMessage and Facetime" You can choose to not activate and do it later.
That warning actually depends on the “carrier profile”, a configuration file the phone silently fetches (or has cached in firmware builds) based on certain attributes of the SIM like the ICCID or MCC/MNC.
There’s a field in there that configured whether that warning should be shown.
Correct, and it didn't appear for carriers which were whitelisted (who zero-rated the iMessage activation SMS).
My memory, which may be wrong, is telling me that the first major version of iOS which included iMessage did not include the warning at all, and that it was added for non-whitelisted carriers (aka those which did not sell the iPhone) to prepare the user for the possibility that they will be billed, based on user feedback precisely like the comment to which I was replying.
Fun fact: +1 is not a country, but all of North America. For a long time it was entirely possible to dial a perfectly ordinary looking +1 258 xxxxxxx number and get charged up the wazoo because (258) is Antigua and Barbuda, not New Jersey.
Pissed me off how American Airlines wouldn't send me SMS updates to my Canadian number, even though it should cost only slightly more than than a USA number. I guess they got burned sending updates to some caribbean island number in the past.
Surely they can aggregate this across all customers though.
If Twilio cops an unexpectedly high settlement for sending an SMS to +1234567890 in January, can they assume that a separate customer sending an SMS to that number in February will end up in the same boat?
I'd be very surprised if the toll fraudsters weren't using the same numbers to hit multiple Twilio accounts.
Yes, but other queries (any aggregate queries that don't join the soft deleted table, any joins to other tables) will now return rows that would have been deleted under hard deletion with cascade.
This is definitely something to watch out for, but in practice (as someone that migrated a system without soft deletes to one that had them) I found that it doesn't tend to come up nearly as much as you might think - usually the table being transitioned to support soft deletes is a relatively core table (since ancillary tables usually aren't worth the complexity to transition) so a lot of your reporting queries will already be pulling in that table. You definitely need to check to make sure you're not missing anything - and sometimes CRUD interfaces will need to be completely revamped to include the table in question - but it's usually not that hard.
You could use a trigger to cascade soft-delete flag toggles, provided all the relevant tables have such a column. Still have to factor that into your other queries, but at least you wouldn't have to make potentially-impossible-to-exhaustively-check joins to figure out if a given row was "deleted".
