It's technically quite impressive - it's a large scale thing and it works really well. I can think of maybe one or two times in these years where I saw downtime, and in both cases it was working again after a few minutes. The usual experience with the government building technical solutions is to have something that makes little sense, is slow, and goes down frequently with even the most predictable usage peaks, but with Pix they really seem to have nailed it.
It does feel a bit weird to have so many payments go through the government's systems, and it definitely feels like it puts them in a position of having more information than they should. There's a lot of Orwellian surveillance potential there, as any transfers are necessarily tied to both users' real identities. I don't think there's a realistic way around this, though.
Another concern is that people can expose some of their information without necessarily being aware of it. You can register e.g. emails and phone numbers as Pix "keys", and then anyone can initiate a transfer to those keys and your full name will pop up so you can confirm or cancel the transfer. I've seen some clever advice around this - "When using a carpooling app (often details are arranged off the platform using WhatsApp), put the driver's phone number on Pix. If a name comes up and it doesn't match the name or gender of the driver's profile, something is up". Obviously though there's potential for misuse and I'm sure the vast majority of people don't think about this when registering their Pix keys. You can, however, just use randomly generated uuids as keys as well, a different one for each transaction if you so desire, so this one can be a non-issue with more awareness.
Overall though it's a very convenient thing which works surprisingly well, and the downsides are theoretical at this point. IMO it's a rare case of our government nailing something.
- Dev infra, observability database (open telemetry spans)
- Logs of course contain chat data, because that's what happens with logging inevitably
The startling rocket building prompt screenshot that was shared is meant to be shocking of course, but most probably was training data to prevent deepseek from completing such prompts, evidenced by the `"finish_reason":"stop"` included in the span attributes.
Still pretty bad obviously and could have easily led to further compromise but I'm guessing Wiz wanted to ride the current media wave with this post instead of seeing how far they could take it. Glad to see it was disclosed and patched quickly.
As I understand, the finish reason being “stop” in API responses usually means the AI ended the output normally. In any case, I don't see how training data could end up in production logs, nor why they'd want to prevent such data (a prompt you'd expect to see a normal user to write) from being responded to.
> [...] I'm guessing Wiz wanted to ride the current media wave with this post instead of seeing how far they could take it.
Security researchers are often asked to not pursue findings further than confirming their existence. It can be unhelpful or mess things up accidentally. Since these researchers probably weren't invited to deeply test their systems, I think it's the polite way to go about it.
This mistake was totally amateur hour by DeepSeek, though. I'm not too into security stuff but if I were looking for something, the first thing I'd think to do is nmap the servers and see what's up with any interesting open ports. Wouldn't be surprised at all if others had found this too.
1. Enable SQL-driven access control and account management for the default user.
2. Log in to the default user account and create all the required users. Don’t forget to create an administrator account (GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION).
3. Restrict permissions for the default user and disable SQL-driven access control and account management for it.
[0] https://chistadata.com/knowledge-base/allow-clickhouse-to-ac...Ah, this reminds me of the Tuya app.
I've done some ssl unpinning and mitm to see requests going in and out of my phone, it's pretty fun and there's often really nice and easy to use restful APIs underneath. Among them I've also done a couple of banking apps and they weren't particularly defensive either. That's great; as a user I'm empowered by it and like TFA says, it's totally fine from a security standpoint if you just don't trust the client to do anything they shouldn't be able to do. It shouldn't be your form validation that stops me from transferring a trillion dollars, and though I haven't tried, I'm sure that's not the case for those apps. All it does is allow me to get my monthly statements with a for loop rather than waiting for a laggy UI and clicking through each month.
Now, Tuya is a Chinese company offering a bunch of cheap IoT devices like smart power switches and IR motion detectors. You can interact with everything through their app. That app for some reason has spent by far the most resources on anti-RE of any apps I've seen. I already bought your hardware, mate. Please let me use it on my local network. My smart home infrared motion sensors were meant to turn lights on when I enter a room. But they don't feel very smart when I'm standing in the dark for 4 seconds while they check with a server in China. I don't even need a clean API; just let me see what you do, and I'll do something similar, no support or documentation necessary. But they go through extensive measures to prevent you from interacting with the hardware you bought and which is sitting in your home.
This was a while ago, but I think for the motion sensing in particular, I managed to just put them in a subnetwork with blocked internet access, and snooped on the network to catch their DHCP requests when they tried to call home. This would happen every once in a while presumably for settings/update checks, but crucially also when there was motion detected, and I didn't mind a few false positives. So in the end they were very quick, locally functioning, privacy-friendly little devices!
My first thought, looking at the webpage: "Huh, that's neat. I didn't know that painting software didn't even attempt to do color mixing beyond naive interpolation, though I guess it figures; the physics behind all the light stuff must be fairly gnarly, and there's a lot of information lost in RGB that probably can't be just reconstructed."
Scrolling down a bit: "Huh, there's some snippets for using it as a library. Wait, it does operations in RGB? What's going on here?"
Finally, clicking the paper link, I found the interesting bit: "We achieve this by establishing a latent color space, where RGB colors are represented as mixtures of primary pigments together with additive residuals. The latents can be manipulated with linear operations, leading to expected, plausible results."
That's very clever, and seems like a great use for modern machine learning techniques outside the fashionable realm of language models. It uses perceptual color spaces internally too, and physics based priors. All around very technically impressive and beautiful piece of work.
It rhymes with an idea that's been floating in my head for a bit - would generative image models, or image encoder models, work better if rather than rgb, we fed them with wavelength data, or at least a perceptually uniform color space? Seems it'd be closer to truth than arbitrarily using the wavelengths our cone cells happen to respond to (and roughly, at that).
It's hard to avoid thinking of a pink elephant, but easy enough to consciously recognize it's not relevant to the task at hand.
In this manner, the model makes use of the rich semantic information encoded at the last hidden layer while informing the user via an extraction of that hidden layer specifically tuned to generate human-legible concepts such as, "I'm considering the impact of converting the units from kilograms to pounds," or whatever.
Nitpicking a bit: it's not as much _rendering_ markdown as it's _syntax highlighting_ it. Another interesting approach there could be to use the CSS Custom Highlight API [0]. Then it wouldn't need the preview div, and perhaps it'd even be possible to have non-mono fonts and varying size text for headers.
[0] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Custom_...