I remember when I was doing pixel art, there were some purists that insisted that using layers and transparency/opacity to create windows for your buildings is more or less cheating. According to them, one should manually figure out what the color palette should be for things seen through a window.
Anyway, I continued using layers and transparency/opacity. Pixel art was hard enough already for me, so I didn’t feel that it made sense to artificially make it even more difficult for myself at the time. I had enough other aspects of pixel art to work out already in order to try to get better at it.
And create single-pixel images. My most used application of Paint by far is creating single-pixel PNG files to work around the fact that "solid color" is not an option for lock/login screen backgrounds.
There's some suggestion there that shapes (including lines) are separate entities from pixels. Wikipedia references a now-deleted answers.microsoft.com version of the first question https://web.archive.org/web/20250203164656/https://answers.m... with a couple of people saying that resize is useless. Wiki also says "re-copied" images blur, which is why I wondered if that meant pasting. Also this: https://learn.microsoft.com/en-us/answers/questions/5673783/... a complaint that the tool for drawing pixels doesn't indicate exactly which pixel it will draw to.
I can't reproduce any of those issues. When drawing the indicator snaps to a pixel, so it's perfectly clear where it's going. When I draw a line, it's pixel-perfect when moving the control points, likewise after it finalises. And when I copy a section of the image and paste it back in, it's pixel-perfect as I move and when I finalise. There doesn't seem to be a true resize; all I seem to be able to do is change the size of the canvas, which doesn't add any kind of aliasing.
But I've only used the program for less than 5 minutes, so maybe it's configured differently?
Paint’s image decoding engine is a shared system component and during thumbnail and visual preview generation it gets called automatically without opening the GUI. Ergo it’s enough for a malformed image file to exist on your device to get pwnd.
Do you have details on this? Given that this is classified as a network vulnerability of the Paint application itself rather than any shared system components, I assumed it had to do with the recently-introduced Copilot features which AFAIK are the only part of the application that directly interact with the network.
While I understand your phrasing getting downvoted, I agree with what I assume you mean:
1. Telemetry as implemented is usually sloppy. Even though intuitively one could think that telemetry means “data gets collected locally and fired off to a remote server”, we have seen time and time again that they also build a return path to make the telemetry gathering more powerful. That return path can be a vector.
2. Web browsers have a _huge_ surface and they connect to remote servers constantly. The industry does very well at being proactive and at addressing CVEs but the whole premise makes that very difficult and so we cannot absolutely claim that browsers don’t have RCE(s).
What return path could possibly lead to a RCE? That's crazy, no telemetry requires "backend could return any command that gets run on the client", you're doing telemetry in a very non-standard way if this is even possible.
At worst, the telemetry backend might first send the client a config, but none of that would contain executable commands because again, that'd be crazy.
> we cannot absolutely claim that browsers don’t have RCE(s).
Of course, you can never prove the absence of bugs (and/or security issues), but given that browsers aren't wildly exploited at this very moment, nor have been for quite some time, we can pretty confidently claim there are no browser RCEs in wide use today.
It's true that browsers have pretty big attack surface, but it's also true that it's the class of software that gets the more pentesting, since the payoff would be so great when you manage to find holes.
API protocol says “return value is either “OK” or “ERR””, attacker sends “Floccinaucinihilipilification”, overflowing the 3-byte response buffer allocated on the stack.
I'm sorry, but I still find it hard to believe you work with other professionals that when they implement telemetry in client applications, that usually ends up exposing a RCE on the client because of the telemetry implementation.
I'd go out on a limb here perhaps, but I'd claim that if your telemetry means that the one SENDING the data gets a RCE by default by it, you're doing telemetry very wrong. Maybe look into different libraries/services than the ones you use today, please.
If I had to guess, without diffing old/new, it's probably related to the generative erase/ai shit.
To stack assumptions, I'd reach for something like using the recent certificate circus to present as there being an updated version of whatever model it uses on the PCs that can run it locally to give it a fucked up model that does the out of bounds shit as part of whatever verification/checks it does after its downloaded/installed.
Either the description or the impact is wrong. You can't trigger MS Paint in a '0-click' attack, and OOB read are not sufficient to directly obtain code execution. So I'll let you guess which one is wrong.
It's quite common with vulnerabilities found by IA, there might be less hallucination, but the impact/score is often completely wrong.
These days games are about 20GiB, you can't put the entire data in the cartridge while having the same price with the digital one.
Also, even before GKC you didn't have a physical ownership because games now have a online update. You only have a physical ownership for v1.0.0; newer versions required online connection anyways.
Interesting project, but why didn't they just run the test for every input that is less than 64MB?
I bet it is cheaper (and way more understandable) than generating 180 million lines of proof with frontier AI...
"Safe Rust" being closer to "optimized C++".
And those "optimized C++" usually incldues assembly code, so it's a huge improvement.
Of course, Rust is not a magic, so just porting to Rust wouldn't make this performance improvement.
It seems their AI overfitted code to Rust compiler to find safe Rust code that compiles to efficient assembly.
Either Muse somehow bypassed the MacOS's security or Muse was able to access Messages without explicit permission.
It is Muse's fault, but I also agree that it is MacOS's fault too.
Clearly the Antrophic don't even look at the single line of the code, so I'm curious why do they even need a Javascript (+ engine) for the Claude Code.
They can just refactor it into C or Rust so they can ship a real binary instead of a script and a runtime.
If I take ownership of the Linux kernel and refactor it into Rust with a "thorough test" using Astra/Fable, will you use it?
reply