github is being used to hack my iphone how can i contact support so you can turn off the api transmission to my iphone as a service provider you should be taking accountability

these are all your domains hitting multiple of my iphones ive never been a customer
Domain Role in GitHub’s Operations
collector.github.com Handles telemetry and analytics collection for GitHub interactions
api.github.com Provides access to GitHub’s REST API for app and service requests
avatars.githubusercontent.com Hosts user avatars seen across profiles, issues, and comments
github.com The main domain for browsing repositories, profiles, etc.
github.githubassets.com Serves GitHub UI elements like CSS and JavaScript assets
camo.githubusercontent.com Proxies external images for security and privacy
raw.githubusercontent.com Delivers raw file content from GitHub repos

💡 What This Might Tell You

• Frequent pings to collector.github.com suggest telemetry mechanisms actively running—these could be app usage stats, performance metrics, or diagnostics.
• The consistent presence of api.github.com indicates external integrations or apps querying GitHub—perhaps automated scripts or system

They’re part of GitHub’s infrastructure, each serving a specific function in how the platform operates and interacts with your system. Here’s a breakdown of what they do:

🧠 GitHub Domain Functions

Domain Purpose
collector.github.com Collects telemetry data—usage stats, diagnostics, performance metrics
api.github.com Handles REST API requests for apps, integrations, and automation
avatars.githubusercontent.com Hosts user profile images across GitHub
github.com Main site for browsing repos, issues, pull requests, etc.
github.githubassets.com Serves UI assets like CSS, JS, and icons
camo.githubusercontent.com Proxies external images for security and privacy
raw.githubusercontent.com Delivers raw file content from repositories

🧩 Why It Matters

• Telemetry domains like collector.github.com can reveal how GitHub tracks usage or errors.
• Asset and image domains help GitHub load content securely and efficiently.
• API domains are often touched by scripts, extensions, or apps interacting with GitHu

used to steal all my data illegally on a daily basis

Security-minded developer researching scalable AI infrastructure, defensive automation, and Zero Trust system design.

Currently developing GODZILLA AI — a security-focused experimental framework exploring secure distributed architecture, cryptographic hardening, AI-assisted monitoring, and resilient infrastructure engineering.

Really appreciate discussions like this because strong ecosystem security depends on both developer education and secure-by-default tooling.

Appreciate you sharing this @zzo38, you bring up some really good points.

X.509 certs definitely offer a more robust trust model than passwords, 2FA, or API keys, especially with things like offline storage, password-protected private keys, and the ability to sign short-lived certs. It’s a solid approach for high-assurance environments. That said, part of the challenge at GitHub’s scale is making sure security improvements are still accessible to developers across a wide range of experience levels. Most folks are already familiar with PATs, SSH, or WebAuthn, so the goal has been to raise the security baseline without adding too much friction.

That doesn’t mean X.509-style workflows are out of the picture — they’re especially relevant in enterprise or automation-heavy contexts. But adoption and ease-of-use are always tradeoffs we’re balancing.

Also really agree with your points about the software supply chain. Signed commits and releases are an important piece of the trust puzzle — it means end users can verify what they’re using without having to trust GitHub or anyone else in the middle. This is part of why GitHub supports GPG- and SSH-signed commits.

Thanks again for jumping in with this. It's a helpful contribution to the broader conversation around what secure-by-default should actually look like 🚀

ESTOU PERDIDO...
UMA PESSOA PRATICAMENTE DEU PREUJIZO MILIONÁRIO E DETECTEI QUEM É. SOU QUE SOU DA ÁREA DE BANCO DE DADOS...TEIVE APAGAR 22 SITES DE CLINTE DEVIDO A DADOS SENSIVEIS...ELE TENTOU DE TODAS AS FORMAS USAR MEUS DOCUEMTNOS PARA OBTER DINHEIRO E ACREDITO QUE COINCIDENTENTEMENTE RETIRARAM 4 MILHÕES DA CONTA DE UM PARENTE MEU. QUE PODE AJUDAR?

AGENTE CONFIA NO GITHUB...TENTA FAZER ALGO PUBLICO E TÁI

If the MFA prompt is coming from Supabase rather than GitHub, you’ll likely need to go through Supabase account recovery directly.

A few things to check:

• recovery codes/backups you may have saved previously
• authenticator app backups/cloud sync
• alternate MFA methods tied to the account
• whether GitHub SSO is still linked for login recovery

If none of those work, contacting Supabase support is probably the safest route rather than attempting repeated failed logins.

Great community write-up — this covers a strong security baseline for both new and experienced GitHub users.

One thing I’d add is that repository security is increasingly tied to supply-chain security now, not just account protection. Features like:

• signed commits
• branch protection rules
• dependency review
• CodeQL analysis
• secret scanning
• artifact attestations

all play an important role in reducing downstream risk.

Also appreciate the emphasis on regular permission reviews and token cleanup. Long-lived unused credentials are still one of the most common attack surfaces in developer environments.

Excellent additions here — especially around credential lifecycle management and workflow hardening.

A lot of security incidents now originate from CI/CD exposure rather than direct account compromise, so things like:

• least-privilege "GITHUB_TOKEN"
• OIDC federation
• short-lived credentials
• branch protection enforcement
• signed artifacts

are becoming baseline requirements instead of “advanced” practices.

The note about secret hygiene inside Actions logs is especially important. People often secure repository storage but forget runtime exposure through workflow output, debugging logs, or third-party actions.

Strong operational checklist overall.

I'm not sure

Really interesting perspective on certificate-based authentication and supply-chain trust.

I especially agree with the point about separating identity assurance from platform trust. Hardware-backed credentials, signed commits/releases, and short-lived credentials all move the ecosystem toward stronger provenance guarantees instead of relying purely on account security.

One area that seems especially promising is combining:

• hardware-backed WebAuthn/passkeys for account auth
• signed commits/releases for artifact integrity
• ephemeral CI credentials via OIDC
• provenance attestations (SLSA-style workflows)

That creates layered trust instead of a single point of failure around passwords or PATs.

Your point about allowlisting tracked files instead of relying purely on ".gitignore" is also underrated from a defensive standpoint. Deny-by-default repository hygiene is often safer in sensitive environments.