Skip to content

Repository files navigation

ScreenBridge Support

ScreenBridge is a consent-based browser support room for helping a friend, family member, or customer. A guest creates a short-lived room, privately sends the technician link, and chooses a screen, window, or browser tab to share.

What it includes

  • Private guest and technician links with separate cryptographic access keys
  • Explicit browser screen-sharing permission on every session
  • Peer-to-peer WebRTC screen and system-audio streaming
  • Optional two-way microphone audio
  • Text chat and technician pointer cues
  • Durable two-hour room records and WebRTC signaling through ChatGPT Sites D1
  • Responsive guest and technician interfaces
  • Automatic opportunistic cleanup of expired rooms and signaling records

ScreenBridge is view-only. A normal browser page cannot remotely control the guest's mouse or keyboard.

The guest view deliberately does not render a live local preview. That prevents the hall-of-mirrors effect when the support page is part of the shared surface. When testing both roles on one computer, share a separate application window rather than the entire display.

Privacy and security model

Room access keys are carried in the URL fragment, so browsers do not send them in ordinary page requests. The API receives a key only in an authorization header and compares its SHA-256 hash with the D1 record. Screen and voice media travel through WebRTC and are not recorded by the app. Chat and connection-signaling records live in D1 until expired records are cleaned up.

Anyone who receives a private room link can use that role until the room expires or is ended. Treat the links like temporary passwords. This project is a useful starting point, not a substitute for a security review before handling regulated or highly sensitive support sessions.

Deploy with ChatGPT Sites

The easiest route is to download this repository as a ZIP, attach it to ChatGPT Work, and paste the prompt in DEPLOY_WITH_CHATGPT.md. The release ZIP intentionally contains no Site project_id, so every person deploys an independent Site and database.

The required Sites binding is already declared:

{
  "d1": "DB",
  "r2": null
}

For real guests, publish the resulting Site with public access. ChatGPT should ask the owner to approve that audience change.

Local development

Requirements: Node.js 22.13 or later on Linux.

npm run install:ci
npm run db:generate
npm run dev

Production checks:

npm test
npm run lint

Local D1 data is managed by the Cloudflare/Vinext development runtime. The committed migration under drizzle/ creates the production schema when Sites publishes the app.

Optional TURN relay

The default configuration uses a public STUN server. Direct WebRTC works on many networks, but restrictive corporate firewalls, VPNs, and symmetric NAT may require a TURN relay. Configure these optional Site environment variables:

  • TURN_URLS — comma-separated turn: or turns: relay URLs
  • TURN_USERNAME — relay username
  • TURN_CREDENTIAL — relay credential

Do not commit TURN credentials to GitHub. Add them through the Site's environment-variable settings.

Browser support

Screen capture requires a secure HTTPS context and a current desktop browser. The guest must initiate sharing from a button click and approve the browser's native picker. Mobile browsers usually cannot share the entire device screen through getDisplayMedia().

License

MIT — see LICENSE.

About

An example of using ChatGPT sites for phishing and C2

Resources

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages