Security

Last updated: July 22, 2026

HTTPS/TLS Local-First Storage Protected .show Files No Card Storage

1. How We Protect Your Data

1.1 Transport Security

All data transmitted between your browser and our servers is protected using:

• HTTPS (TLS 1.2+): All connections use strong encryption protocols
• HSTS (HTTP Strict Transport Security): Forces secure connections
• HSTS: Instructs supported browsers to use secure connections
• Security headers: Content Security Policy, frame restrictions, referrer policy, and permissions policy reduce common browser attack paths

1.2 Data Storage Security

Your application data (stage plots, input lists, and projects):

• Stored locally on your device in browser localStorage/IndexedDB
• Protected from unrelated websites by browser same-origin controls
• Transmitted when you choose account sync, sharing, web import/export, diagnostic upload, support, or purchase features
• Optional cloud-synced project data is stored by our Supabase-backed account service

License and payment data:

• Purchase and account records are stored in our Supabase-backed service
• App Store entitlement state is handled by Apple and RevenueCat
• Web payment details are handled by Stripe
• Operational secrets are protected by restricted production configuration

1.3 Payment Security

We use Stripe for web payment processing and Apple for in-app purchases.

• We never see your credit card number
• Web card entry occurs on Stripe's hosted Checkout page
• App Store payment entry occurs in Apple's purchase sheet
• We receive purchase status and identifiers needed to grant or restore Pro, not your full card number or Apple ID password

2. Infrastructure Security

2.1 Hosting and Infrastructure Providers

Service	Provider	Role
Hosting	Vercel	HTTPS hosting and serverless API execution
Database	Supabase (AWS)	Account, entitlement, and optional sync storage
Payment	Stripe	Hosted web checkout and payment processing
Error Monitoring	Sentry	Web-app error diagnostics; not loaded in the native iOS app

2.2 Network Security

• Rate limiting: Sensitive import, export, verification, and account endpoints enforce abuse controls
• Input validation: File type, payload size, identifiers, and request shape are checked before processing
• No-store responses: File-processing endpoints mark sensitive responses so browsers and intermediaries do not cache them
• Minimal errors: Public API errors avoid exposing implementation details or user file contents

2.3 Access Control

• Administrative credentials and API secrets are excluded from production application releases
• Server APIs verify account, license, purchase, or organization credentials where required
• Production releases exclude development artifacts and private implementation material
• Access to production services is limited to the accounts needed to operate them

3. Application Security

3.1 License Verification

Pro access is verified through platform purchase state or a server-issued web entitlement:

• Online verification: Web entitlements are checked securely before Pro access is granted
• Platform verification: iOS purchases are checked through RevenueCat's view of Apple purchase state
• Signed cache: Offline entitlement records are accepted only after signature verification where that path is available
• Rate limiting: Verification API has abuse protection
• Revocable: Keys can be deactivated if compromised

3.2 Content Security Policy (CSP)

We use Content Security Policy and related response headers to constrain browser capabilities:

• Script, connection, image, frame, and worker sources are allow-listed by route
• Frame embedding is blocked for protected application routes
• Referrer and permissions policies reduce unnecessary browser data and feature exposure
• The policy permits the specific inline and WebAssembly behavior the current app requires; it is not described as a complete XSS defense

3.3 Dependency Management

• Automated release and security gates run before release
• Native and web release audits check for development artifacts and prohibited purchase paths
• Dependencies are reviewed and updated as part of release maintenance
• Security-sensitive file import paths have size, type, and malformed-input tests

4. Privacy-by-Design

4.1 Local-First Architecture

Our applications are built with privacy as the foundation:

• Local by default: Core working data is kept in browser or app storage
• Optional cloud sync: Signed-in users can synchronize selected project data through the account service
• Explicit file processing: Web console import/export sends the selected payload to the API for transient processing; supported native formats can be handled on-device
• Protected project export: Password-protected .show files use AES-256-GCM with a PBKDF2-derived key in the app

4.2 Minimal Data Collection

We collect the absolute minimum data necessary:

• Email address when you purchase on the web, create an account, request recovery, or join a mailing list
• Purchase and entitlement identifiers needed to unlock or restore Pro
• Web analytics and technical error diagnostics; those scripts are not loaded in the native iOS app
• Project data only when you use sync, sharing, web file processing, diagnostic upload, or support features
• No precise device-location request
• No browsing history
• No cross-site tracking

See our Privacy Policy for full details.

5. Your Responsibilities

Security is a shared responsibility. Here's how you can protect your data:

5.1 Protect Your License Key

• Don't share your license key with others
• Don't post it publicly (GitHub, forums, etc.)
• If compromised, email us immediately for a replacement

5.2 Keep Backups

• Export important stage plots regularly
• Browser data can be lost if you clear cache or reinstall
• Use the export feature to save copies outside the browser

5.3 Use Secure Devices

• Keep your operating system and browser up to date
• Use antivirus/anti-malware software
• Avoid using public/shared computers for sensitive work
• Log out of shared devices after use

5.4 Recognize Phishing

• We will never ask for your full card number, Apple ID password, or device passcode
• All go·for·show domains end in goforshow.io
• Web payment happens on Stripe's hosted checkout; iOS payment happens in Apple's purchase sheet
• Suspicious emails? Forward to security@goforshow.io

6. Vulnerability Disclosure

We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.

6.1 How to Report

Email: security@goforshow.io

Please include:

• A description of the vulnerability
• Steps to reproduce the issue
• Potential impact (what an attacker could do)
• Any proof-of-concept code (if applicable)
• Your contact information

6.2 Our Commitment

• Acknowledgement: We will confirm receipt as soon as practical
• Investigation: We will reproduce the issue, assess impact, and prioritize containment
• Disclosure: We will coordinate public disclosure when appropriate
• Credit: We will credit responsible reporters when requested and appropriate

6.3 What NOT to Do

When testing for vulnerabilities, please:

• Don't access other users' data
• Don't perform denial-of-service attacks
• Don't publicly disclose the vulnerability before we've patched it
• Don't use automated scanners without permission
• Don't exploit the vulnerability beyond proof-of-concept

7. Data Breach Procedures

If we confirm a security incident involving personal data, we will:

1. Containment: Restrict the affected service or credentials
2. Assessment: Determine the scope, data involved, and likely impact
3. Notification: Notify affected users and authorities when required by applicable law
4. Remediation: Correct the underlying issue and restore service safely
5. Review: Record what happened and improve the relevant controls

8. Privacy and Provider Responsibilities

Our Privacy Policy explains the rights available in applicable regions and how to request access, correction, or deletion. Stripe, Apple, RevenueCat, Supabase, Vercel, analytics providers, and email providers operate parts of the service under their own security and privacy programs. Their inclusion here is not a claim that go·for·show itself holds their certifications.

9. General Security Practices

• Release gates: Automated checks cover malformed files, private-source leakage, client payloads, purchase paths, and supported round trips
• Least exposure: Public clients receive only the code and credentials required for their platform
• Backups: Users should keep independent copies of important .show and console files
• Updates: Security defects are prioritized according to impact and exploitability

10. Questions or Concerns?

If you have security questions or concerns:

Security issues: security@goforshow.io
General inquiries: goforshowio@gmail.com
Support: goforshowio@gmail.com

Operating as: go·for·show
Location: New York City, USA