They are allowing it to run on Intel and NVIDIA and Google chips meeting certain requirements now too instead of just Apple silicon because they think they’re secure enough now, but I suspect this decision might have been pushed by the need for Siri to be useful.

I still definitely think it’s better than what every other company is trying to do (like running a variant of OpenClaw 24/7 forwarding data to Anthropic, OpenAI, Google, and every other provider they can support).

[0] https://security.apple.com/blog/expanding-pcc/

I think what is concerning is that they are expanding into Google Cloud and NVIDIA to run with it too with their versions of confidential compute, which if I remember correctly are not as well verified as Apple PCC and a little harder for researchers to get their hands on.

Apple uses a key ceremony process where no single party has access to all the keys required to sign hardware, meaning in theory they can’t just sign malicious hardware. However, I’m not sure how Google and NVIDIA play into this and I don’t think they’ve provided much detail on it. I think it seems a little rushed to get the features out since they fucked up with initial Apple Intelligence release.

App developers can already access the on-device foundational models through an API, but I don't think many developers want to do that because there are better models.

Comments URL: https://news.ycombinator.com/item?id=48390231

Points: 2

# Comments: 1

Based on what I've seen so far, Meta AI Support Assistant (they call it "MAISA") had tool calls that a) start an email verification to any specific email, phone number, or the contact points linked to an account and b) allow generating a password reset link for an account based on an email verification attempt. I don't think it had any access to the actual codes themselves, but rather think a handle or ID for an email verification attempt (along with the user provided verification code based on user input) was provided to the "generate reset password link" tool call, and the tool call failed to properly validate the actual email used in that attempt belonged to the account allowing the ATO.

The tool call for MAISA to generate a password reset link should have failed with an email verification attempt that corresponds to an email not linked to the account (and I believe I even tested this at one point on Facebook and encountered an error that successfully prevented it), but I suspect they tried making a change to this tool call for Instagram where slightly older, recently unlinked emails could be used to recover an account that got hijacked by an attacker, which added the need to allow emails not currently linked to the account to be used and set to the user's primary email.

I also suspect that the MAISA tool call change called a wrong API or something that unintentionally allowed any email verification attempt that was successful to be used, but the engineers did not add a sufficiently thorough e2e test case to test the tool call against unrelated email verification attempts being provided to the tool call. This is the part I think should be focused on the most. Tool calls for agents that have their output potentially influenced by an attacker should be treated like external APIs that anyone can reach, and they should be tested as such.

This is all obviously a guess, doesn't take into account the many signals they use to determine if an account recovery attempt is valid, and could be very inaccurate, but it's the closest to what I (someone who deals with Meta security a lot) think could have allowed this to happen.

Comments URL: https://news.ycombinator.com/item?id=48281027

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48240679

Points: 61

# Comments: 11

It can make requests but only with no CORS, which could be useful for accessing some weakly secured HTTP resources behind a corporate VPN or something (in the same way any other site can but over a much longer period). It could also potentially be used for tracking user IP address activity, crypto mining, building a botnet, etc.

Comments URL: https://news.ycombinator.com/item?id=48123027

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48107213

Points: 2

# Comments: 0

Any public instance should update immediately though, it's not very hard to put together how to repro the vulnerability on your own from what they provide in the article and the fact that GitHub Enterprise source is publicly available.

It doesn't look like it's very hard to reproduce or find the bug now (especially with the details they mention in their blog post) but I assume they did not want to publish the actual command line. It looks like it affected both GitHub.com and GitHub Enterprise, and it does look like it literally took one git push command.