No — the victim app is code signed and the permissions and keychain access are tied to the cryptographic identity used to code sign. Replacing or wrapping or whatever here must happen with a different cryptographic identity (unless you actually exploit the victim app itself which is a whole different thing).
Not sure I understand the risk here, and seem to agree with Apple this is a non-issue. You already have code execution in order to exploit this. You don’t get the cryptographic identity of the victim app so you can’t steal keychain secrets. How is this any different than just bundling your own second-stage malware with a victim bundle ID, then using your existing code execution to remove the quarantine flag and then run the second-stage malware? Or just doing the evil things with your existing code execution?
There are a few others. “Quite” comes to mind — “I am quite hungry” or “that meal was quite good” can mean opposite things, depending on the speaker region and even voice inflexion if spoken.
My prospective co-founders and I were pitching to a VC firm that was, on paper, a really good fit for what we were trying to do. The partner we were pitching to was, 15 years ago, briefly my manager's manager -- some work relationship there, she remembered me and I her, but we didn't work super closely together and it had been a very long time. She had moved on at that company to more big-shot things and ultimately become a partner at a respectable VC firm.
About 10 minutes into the pitch, she cut us off, and basically said -- as absolutely kindly as something like this can be directly said -- "I am not going to invest in this, and furthermore I don't think what you're trying to do is investible at all". Then she took a bunch of her time to run us through why, help us understand some very fundamental things about the VC world we didn't quite have right, and generally be brutal but extremely useful in us framing what we were trying to do.
She didn't have to do that. She could have nodded along and then given us a polite "no" like everyone else. She could have cut us off and given us a rude "no". But she didn't -- she made sure to use the time we had to help us as much as she could, even if she very adamantly was not going to invest.
Not a big gesture or anything, but kind and helpful. There's a lot of that. But it doesn't make headlines.
In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault). That bug might be in some underlying library (which is itself using `unsafe`), or more rarely in the compiler, but it's a bug and not how Rust is supposed to work.
Does Haskell have any similar line? What is the property that code must have in order for it to be a bug to segfault? Must not call `unsafePerformIO`? Must not call `unsafeCoerce`? (Must not call any function with the `unsafe` prefix?)
In other words, is the segfault here to be considered a bug in the language -- or is unwrapping IO one of the things that, if you do it, you're own your own and may segfault? (Is part of the point of the article is that it is currently considered safe but should not be? Is that a bug in the language or in peoples' expectations?)
Or is a clear line like this not a notion that Haskell has? It's been a long time since I've done any Haskell, though I don't recall any clear guideline like this!
Can you elaborate on the complexity here for syscall entry on x86_64? (Or link to what you were reading?) Another commenter linked to Linux's own "nolibc" which is similar to, though simpler than, the Google project in the OP. Their x64_64 arch support is here, which looks simple enough, putting things into registers: https://github.com/torvalds/linux/blob/master/tools/include/...
I don't see any complex stack alignment or anything which reads to me like it would require "niche C compiler options", so I'm curious if I'm missing something?
Glad you liked it! My co-author and I spent some time trying to find a good spread of questions covering different aspects of LLMs. And we were also surprised by how hard it was to convince GPT-4 that Queen Elizabeth II had died a lot of the time. (We found that specifying she died in 2022 helped a lot.)
(co)-author here. It was really interesting putting this together. We had some idea what LLMs/GPT-4 would and would not do well with, but were still surprised ourselves with a number of things. In particular, we knew it would really struggle with the acrostic, but the degree to which it just completely lost the plot was pretty surprising! It was also surprisingly difficult to convince it that Queen Elizabeth II had died in a lot of cases (it takes it better some times than others).
There are a bunch of online tests that help you see if you, with your ears and equipment, can tell the difference. http://abx.digitalfeed.net/ and http://abx.digitalfeed.net/list.lame.html was on HN some time ago, for example. I'm not sure if any of them collect stats though.
League of Legends (a similar game) does this -- no booths, only noise-cancelling headphones, for its large tournaments. There have been several major tournaments where the players have complained afterwards that they could not hear anything during big late-game fights due to crowd noise (since the crowd is also super excited at the big fight). Players need to be able to hear not just the game audio but also communication from their teammates and, despite noise-cancelling headphones, the crowd just drowned everything out. I'm honestly not sure why League of Legends hasn't moved to booths like Dota uses.
I'm not sure if you've ever watched one of these tournaments, but they get super noisy, and noise-cancelling all of that is not an easy problem (as the article says).
Indeed his videos are amazing. My recommendation though would be to start with the "beginner" video -- which is completely 2D but at least gets some ideas across. Then watch https://www.youtube.com/watch?v=PGtv-dBi2wE which isn't his but introduces how you get 3D out of fragment shaders. Finally just drink from the firehose -- https://www.youtube.com/watch?v=Cfe5UQ-1L9Q is fantastic, yes it's five hours but worth it. (Definitely come into that familiar with the idea of raymarching though... the first few minutes start off super basic but it goes to eleven real quick.)
> if this was your point, the example is terrible.
Yeah, I addressed this in another comment here. I attempted in the last section to separate the ideas of "I heroically dived in" and "I took an opportunity in front of me" -- you shouldn't go looking for heroics. This didn't quite get across, and I totally understand why. Ah well.
> The more interesting one though, is that sometimes high-impact work is "just there" to be done, if you're looking.
Author here. Yes, this was exactly my point!
> But the best way I've found to detect promising junior engineers who will benefit from mentorship is to find who does bite, and more often respond "what if" instead of "but".
Indeed. I've mentored a bunch of otherwise-competent engineers trying to get to the next level, and my advice is similar: ask yourself "ok, now what's next". After doing the cool thing, there's inevitably half a dozen other things around it, and things might be obvious to you (as the now-expert in the cool thing) but not others.
Author here. For what it's worth, I (mostly) think you're right! IMO heroics were a huge problem at that company, and are a huge problem at the company I work at now too. The gruntwork is really really important.
I tried to get at this in the last section, that it's not about going out trying to be a hero, and it's unfortunate it didn't get across. That was my point that you shouldn't go look for company priorities to fix, to be a hero. Just look around you, see what's going on, and do good shit. Sometimes yeah that does involve heroics, sometimes it's just gruntwork.
I don't want to go back and edit the essay now but I think it could be much clearer indeed!
> Imagine the same story but somebody two months earlier had voiced a concern that Jabberwocky and ChaChing wouldn't play well together. Pushing for the APIs to be harmonized so that they could play together and integrate. [...]
Disagree here, though it's maybe not obvious from the bits of the story I told why. ChaChing was one of... maybe three or four dozen experiments like it. All of the others failed. There was no reason to believe ChaChing would be any different, and if it did work, even the best-case expectations were well below what it ended up doing. It really was a lightning strike. So it would have been a huge waste of time to do all of that work, delaying Jabberwocky, for a bunch of things which never ended up shipping.
Along with the above fantastic comment, I found https://apenwarr.ca/log/20170810 an interesting (if inflammatory/divisive) essay on the subject and its history.