The devlog is the very first place changes get written about when they land in Zig's master branch (and sometimes even before!), so presumably zig.guide will mention this change once it actually makes it into a release.
Yeah, Android's sandbox deals with low-level file access and socket APIs and stuff. But Android also, intentionally, allows apps to expose their data and functionality to other apps via the higher-level "intent" system.
Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.
Similarly, apps are also allowed to collude to share data with each other if they want; that's how stuff like Google Play Services works.
> Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.
You might as well blame the phone for not being encased in concrete and thrown into a well. You might not want your text message application to have the internet permission, but you'd certainly want to be able to open links from it.
Unity includes its own video player implementation ( https://docs.unity3d.com/Manual/Video.html ), so presumably you'd mainly want to use VLC for wider range of supported codecs?
Basically. Unity video player is fine if you control the content. The other very reasonable option is to funnel shared content through a synced web browser interface. I've developed a few collaborative XR applications, and have used a blend of things to support sharing.
> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)
I think there's maybe a disconnect here that people are largely concerned with the contents of their private repos, while you're maybe more familiar with how AI interaction data is handled. (After all, the original topic of the thread was X.ai allegedly going above and beyond interaction data to exfiltrate entire repos.)
I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.
Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.
I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)
That’s fair, and I appreciate the more constructively critical feedback! Also worth noting that I’m solidly on the platform service side, and the article here is largely focused on malicious client behavior.
Copilot has a lot of different clients between IDEs, agentic integrations, and GitHub apps. I don’t have awareness of the implementation details of all of them, but I can assure you that we don’t provide APIs like those mentioned in the article being used for data exfiltration.
Clients are responsible for context building, and all go through the same service that does auth, policy and quota enforcement, request routing to the underlying providers all of which have zero data retention enabled unless very specifically excluded from that (looking at you, Fable 5).
This is a nice answer to the question "how is GitHub preventing rogue employees at Microsoft from stealing my private repositories?". Like, it's good to know I'm covered if Microsoft accidentally hires a North Korean spy or something.
But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.
Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.
(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)
I’m one of the people directly responsible for ensuring that those terms are properly enforced. Presently I’m arguably the person for Copilot data specifically.
Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.
Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at taywrobel@github.com!
(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)
Still in my bubble! I am not involved in the human review or automated analysis portions of the safety pipeline for CSAM/TVEC harms, but my team is responsible for the data handling around identifying and responding to such content.
As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.
If you think about how much time a single developer has to invest to create all the assets for such a massive game, 11 years doesn't sound like a lot of time...
(assuming he did all the assets himself and didn't use AI, which might be a bit naive)
reply