# Monitoring Gaps Analysis

**Tags:** #note-type/research #domain/technical #status/in-progress #priority/high

## What We Captured

- **Duration:** ~20 minutes
- **Nuke state:** Already running, normal use
- **Connections observed:**
  - api.honeycomb.io (17KB HTTPS - encrypted)
  - learn.foundry.com (HEAD requests HTTP - unencrypted)
  - crashpad_handler process (found but not active)

## What We Likely Missed

### 1. Startup Telemetry (HIGH PRIORITY)

**What could be sent:**
- Initial system scan (registry, hardware, OS)
- License validation and user identification
- Geographic location determination (IP geolocation)
- Email domain from license credentials
- Software environment enumeration

**Why we missed it:**
- Nuke was already running when we started monitoring
- Startup telemetry likely happens during Nuke launch

**How to capture:**
```bash
# Start monitoring BEFORE launching Nuke
sudo tcpdump -i any -w nuke_startup.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
sleep 2
# NOW launch Nuke
# Wait for it to fully load
# Stop capture
```

### 2. Shutdown Telemetry (HIGH PRIORITY)

**What could be sent:**
- Session summary (duration, tools used, errors)
- Final usage statistics
- Cached telemetry that wasn't sent during session
- License check-out confirmation

**Why we missed it:**
- We didn't capture Nuke closing
- Shutdown often triggers "flush" of cached data

**How to capture:**
```bash
# While Nuke is running, start capture
sudo tcpdump -i any -w nuke_shutdown.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Close Nuke normally
# Wait 30 seconds after Nuke closes
# Stop capture
```

### 3. Crash Reporting (MEDIUM PRIORITY)

**What could be sent:**
- Memory dumps (could include project data!)
- Stack traces
- System state at crash time
- User information
- Active projects/files

**Why we missed it:**
- No crashes occurred during monitoring
- crashpad_handler was idle

**How to capture:**
```bash
# Start capture
sudo tcpdump -i any -w nuke_crash.pcap 'host sentry.foundry.com' &
# Force kill Nuke to simulate crash
kill -9 $(pgrep -f Nuke)
# Wait 60 seconds (crash report upload)
# Stop capture
```

### 4. Periodic Check-ins (MEDIUM PRIORITY)

**What could be sent:**
- Heartbeat signals
- License validation pings
- Usage statistics batched from previous sessions
- Update checks

**Why we missed it:**
- 20 minutes might not cover the full interval
- Common intervals: 15min, 30min, 1hr, 4hr, 24hr

**How to capture:**
```bash
# Run monitoring for extended period
./monitor_nuke_telemetry.sh
# Leave Nuke idle for 4+ hours
# Check logs for periodic patterns
```

### 5. Specific Event Triggers (LOW-MEDIUM PRIORITY)

**Events that might trigger telemetry:**

**Help Menu Usage:**
- Accessing online documentation
- Checking for updates
- Viewing learning resources

**Rendering:**
- Large render jobs might report performance metrics
- Could include project complexity data

**Plugin/Script Usage:**
- Third-party plugin loads
- Python script execution
- Gizmo usage

**License Events:**
- License checkout/checkin (floating licenses)
- Seat availability checks
- License server connections

**Project Operations:**
- Opening certain project types
- Using specific nodes/features
- Render farm submissions

**How to capture:**
```bash
# Monitor while performing specific actions
sudo tcpdump -i any -w nuke_events.pcap 'host foundry.com or host honeycomb.io' &
# In Nuke:
# - Check for updates (Help menu)
# - Access online help
# - Render a complex scene
# - Use various nodes/tools
# Stop capture
```

## 3. Methodology Gaps

### Gap A: Local Data Collection

**The problem:**
- System registry access happens LOCALLY
- Data collection ≠ data transmission
- Could be cached and sent later

**Evidence of local caching:**
From earlier investigation:
```
~/Documents/nuke/15.2.375648/sentry-db/
```

**How to investigate:**
```bash
# Check what's in those Sentry database files
ls -lah ~/Documents/nuke/15.2.375648/sentry-db/
file ~/Documents/nuke/15.2.375648/sentry-db/*

# Monitor file changes during Nuke use
inotifywait -m ~/Documents/nuke/15.2.375648/sentry-db/

# Check for other telemetry databases
find ~/Documents/nuke ~/.nuke ~/.cache -name "*.db" -o -name "*.sqlite" -o -name "*telemetry*" -o -name "*analytics*"
```

### Gap B: DNS-Based Identification

**The problem:**
- Geographic location can be determined from DNS queries
- Doesn't require sending location data explicitly
- Foundry sees your IP address in connection logs

**What Foundry already knows from network metadata:**
- Your public IP address (from all connections)
- Geographic location (IP geolocation databases)
- ISP information
- Approximate physical location

**This is unavoidable** unless you use VPN/proxy

### Gap C: Different Protocols/Ports

**What we monitored:**
- TCP connections to known Foundry domains
- Ports 80, 443 (HTTP/HTTPS)

**What we might have missed:**
- UDP traffic (less common but possible)
- Different ports (custom license servers, etc.)
- DNS queries themselves (can leak info)
- IPv6 connections (if using dual-stack)

**How to capture everything:**
```bash
# Capture ALL external traffic (not filtered)
sudo tcpdump -i any -w nuke_full.pcap 'not net 10.0.0.0/8 and not net 127.0.0.0/8'
# Much larger file, but catches everything
```

### Gap D: System Registry Access

**The problem:**
- On Linux, "registry" means different things
- Could be checking:
  - `/proc/` - Process and system info
  - `/sys/` - Hardware information
  - Environment variables
  - Config files in `~/.config/`, `~/.local/share/`
  - `/etc/` system files

**This happens in-process** - no network traffic!

**How to monitor:**
```bash
# Use strace to see what files Nuke accesses
sudo strace -f -e trace=open,openat,read,stat -p $(pgrep -f Nuke) 2>&1 | tee nuke_file_access.log

# Look for suspicious reads
grep -E '/proc|/sys|/etc|\.config' nuke_file_access.log
```

### Gap E: Email Domain Collection

**How they could get it:**

1. **From license credentials** (most likely)
   - You logged in with email to activate license
   - Email domain already known to Foundry

2. **From system username**
   - If username is email format: `user@domain.com`

3. **From hostname/network**
   - SMTP server domain
   - Email client configuration files

**This might not require transmission** - they already have it from license registration

### Gap F: Third-Party Services (Honeycomb, Sentry)

**The problem:**
- Even if we block Foundry domains, third-party services collect metadata:
  - Honeycomb sees: IP address, timing, data volume
  - Sentry sees: IP address, user-agent, system info
  - Both can geolocate your IP

**Honeycomb/Sentry also have access to:**
- All data Foundry sends them (obviously)
- Their own usage analytics
- Cross-customer correlation

## 4. How to Fill the Gaps

### Comprehensive Monitoring Plan

**Phase 1: Startup/Shutdown Capture (1 day)**
```bash
# Morning: Capture startup
sudo tcpdump -i any -w startup.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Launch Nuke, wait for full load, stop capture

# Evening: Capture shutdown
sudo tcpdump -i any -w shutdown.pcap 'host foundry.com or host honeycomb.io or host sentry.foundry.com' &
# Close Nuke, wait 60 seconds, stop capture

# Analyze differences
tshark -r startup.pcap -q -z io,stat,0
tshark -r shutdown.pcap -q -z io,stat,0
```

**Phase 2: Local File Monitoring (ongoing)**
```bash
# Install inotify-tools
sudo pacman -S inotify-tools

# Monitor Nuke directories for file changes
inotifywait -m -r ~/Documents/nuke ~/.nuke ~/.cache/nuke 2>&1 | tee nuke_file_changes.log
```

**Phase 3: System Call Tracing (1 session)**
```bash
# Trace file access during Nuke session
sudo strace -f -e trace=open,openat,read,readv,connect -p $(pgrep -f Nuke) -o nuke_strace.log

# After session, analyze
grep -E 'open|connect' nuke_strace.log | grep -vE '(ENOENT|EAGAIN)' > nuke_access_summary.txt
```

**Phase 4: Long-Duration Monitoring (1 week)**
```bash
# Start ongoing monitoring
./monitor_nuke_telemetry.sh

# Leave running during normal Nuke usage
# Check logs daily for patterns
ls -lh telemetry-logs/
grep "NEW CONNECTION" telemetry-logs/*.log
```

**Phase 5: Event-Triggered Capture (as needed)**
```bash
# While monitoring is running:
# - Check for updates (Help menu)
# - Trigger an error/warning
# - Access online help
# - Large render job
# - Use various plugins
# Note timing in log
```

### Ultimate Test: Compare with Block Enabled

```bash
# 1. Capture baseline (telemetry allowed)
sudo tcpdump -i any -w baseline.pcap 'host honeycomb.io or host foundry.com' &
# Use Nuke normally for 30 min
# Stop capture

# 2. Block telemetry
./block_nuke_telemetry.sh

# 3. Capture with blocking
sudo tcpdump -i any -w blocked.pcap 'host honeycomb.io or host foundry.com' &
# Use Nuke normally for 30 min
# Stop capture

# 4. Compare
tshark -r baseline.pcap | wc -l   # Should have packets
tshark -r blocked.pcap | wc -l    # Should be zero or connection failures

# 5. Check if Nuke still functions
# If features break, that tells us what relied on telemetry
```

## Summary: What We're Probably Missing

### Definitely Missing:
1. **Startup telemetry** - System scan, initial check-in
2. **Shutdown telemetry** - Session summary, cached data flush
3. **Content of encrypted payloads** - Everything in that 17KB to Honeycomb

### Probably Missing:
4. **Crash reports** - No crashes occurred
5. **Periodic check-ins** - 20 min might not cover the interval
6. **Local data collection** - Registry/system scans happen locally first

### Possibly Missing:
7. **Event-triggered telemetry** - Help menu, updates, specific features
8. **Alternative protocols** - UDP, different ports, IPv6
9. **License server traffic** - If using floating licenses
10. **Cached/batched data** - Stored locally, transmitted later

### Already Captured (But Can't Decrypt):
11. **Email domain** - Likely in Honeycomb payload or already known from license
12. **Geographic location** - Determined from IP address (unavoidable)
13. **Usage profiling** - Likely in Honeycomb payload
14. **System information** - Likely in Honeycomb payload

## Next Steps

**Immediate (to fill critical gaps):**
1. Capture Nuke startup telemetry
2. Capture Nuke shutdown telemetry
3. Check local Sentry database contents
4. Run `strace` to see file/registry access

**Short-term (deeper investigation):**
1. Monitor for 24+ hours to catch periodic check-ins
2. Force a crash and capture Sentry traffic
3. Test specific events (Help menu, updates, etc.)
4. Compare traffic with telemetry blocked

**Long-term (ongoing):**
1. Run monitoring service continuously
2. Build timeline of telemetry patterns
3. Correlate with Nuke usage events
4. File GDPR/CCPA request to see what Foundry actually has

---

**Bottom Line:** We're definitely missing startup/shutdown telemetry and can't see inside encrypted payloads. The EULA-permitted data (email, location, registry, usage) is almost certainly being transmitted - we just can't see it because it's encrypted inside the Honeycomb connection.