# TRO-M04: Risk assessment for obfuscation
**Area:** Widget.js Telnyx Obfuscation
**Model:** minimax/minimax-m2.5
**Tokens:** 4,477
**Cost:** $0.0045
**Time:** 2310ms
**Timestamp:** 2026-02-16T12:18:32.913768

---

# Risk Assessment: Vendor Name Obfuscation in Sunaiva Talking Widget

**Document Version:** 1.0  
**Prepared For:** Sunaiva Product & Engineering Teams  
**Assessment Scope:** Client-side obfuscation implementation and operational implications  
**Classification:** Internal — Technical & Legal

---

## Executive Summary

This assessment evaluates the risks associated with obfuscating Telnyx vendor branding and references within the Sunaiva Talking Widget. Obfuscation of third-party vendor names is a legitimate commercial practice intended to protect competitive positioning and reduce customer churn risk. However, incomplete or inconsistent obfuscation introduces significant operational, legal, and reputational risks that must be systematically addressed.

**Key Findings:**

- Incomplete obfuscation creates a false sense of security while exposing the business to the exact competitive risk it seeks to mitigate
- Debugging complexity increases substantially, potentially extending incident resolution times
- Support interactions with Telnyx become complicated when internal terminology diverges from vendor documentation
- Legal exposure is minimal but not zero; misrepresentation could constitute a breach of contractual terms
- Detection of leaks requires a layered approach combining automated scanning, manual review, and customer feedback mechanisms

**Overall Risk Rating:** MEDIUM-HIGH (requiring structured mitigation before broad deployment)

---

## 1. What Breaks If Obfuscation Is Incomplete

### 1.1 Competitive Differentiation Erosion

**Risk Level:** HIGH

**Scenario:** Partial obfuscation leaves visible Telnyx references in console errors, API response headers, or third-party scripts that customers can easily discover.

**Consequences:**

- Customers identify the underlying telephony provider within minutes of using the widget
- Competitors can replicate the stack by inspecting network traffic or debugging tools
- Price comparison becomes straightforward — competitors can position against Telnyx pricing directly
- Agency partners may bypass Sunaiva and contract directly with Telnyx, particularly on the Growth plan where volume discounts make this economically attractive

**What Breaks:** The entire value proposition of the Pro and Growth tiers, which rely on the perception of a proprietary, integrated voice solution.

### 1.2 Customer Trust and Perception Issues

**Risk Level:** MEDIUM

**Scenario:** A technically savvy customer or agency partner discovers Telnyx branding and interprets it as evidence that Sunaiva is "just a wrapper" around Telnyx.

**Consequences:**

- Undermines perceived value of Sunaiva's Australian support, business hours, and integration work
- Agency partners may feel misled if they have positioned Sunaiva as a proprietary solution
- Customer retention risk increases, particularly among Pro and Growth accounts who expect enterprise-grade differentiation

**What Breaks:** Brand positioning as a premium, Australian-owned solution purpose-built for tradies.

### 1.3 Contractual and Reseller Relationship Risks

**Risk Level:** MEDIUM

**Scenario:** Telnyx discovers systematic obfuscation of their brand and interprets it as a violation of acceptable use policies or partnership terms.

**Consequences:**

- Potential review of Sunaiva's reseller or partnership status
- Risk of service suspension pending clarification
- Damage to the business relationship that could affect pricing, support priority, or service terms

**What Breaks:** The commercial relationship with Telnyx, which is foundational to the product offering.

### 1.4 Technical Failures in Production

**Risk Level:** LOW-MEDIUM

**Scenario:** Obfuscation code contains bugs that cause runtime errors when Telnyx SDKs or APIs return unexpected responses that reference Telnyx by name.

**Consequences:**

- Widget failures on specific call flows (hold music, call recording retrieval, conference calling)
- Customer-facing errors that appear as "Sunaiva" failures but originate in Telnyx integration points
- Confusing error messages that reference both Sunaiva and Telnyx, exposing the underlying stack anyway

**What Breaks:** The user experience and the supposed "black box" nature of the widget.

---

## 2. How to Detect Leaks

### 2.1 Automated Detection Methods

| Method | Coverage | Implementation Effort |
|--------|----------|----------------------|
| **Network Traffic Scanning** | Identifies visible Telnyx domains, headers, and API endpoints in outgoing requests | LOW — Burp Suite or similar proxy integration for QA testing |
| **Source Code Scanning** | Detects hardcoded Telnyx references in JavaScript, HTML comments, and CSS | LOW — Regex patterns added to build pipeline |
| **Console Output Monitoring** | Catches error messages, warnings, and debug logs that expose vendor names | LOW — Browser automation capturing console output |
| **Bundle Analysis** | Examines minified JavaScript for Telnyx-specific variable names or strings | MEDIUM — Custom build script integration |
| **DOM Inspection** | Reviews rendered HTML for hidden elements, tooltips, or alt text containing Telnyx | LOW — Automated Selenium/Playwright tests |

### 2.2 Manual Detection Methods

**Customer Support Triage:**

- Train support staff to log any customer mentions of "Telnyx," "Twilio," or other vendors
- Include vendor detection as a standard field in support ticket metadata
- Weekly review of tickets for vendor reference patterns

**Sales and Agency Feedback:**

- Add a field in CRM for "vendor awareness" — whether the customer or agency already knows the underlying stack
- Track how customers discovered vendor information (debugging tools, network inspection, industry knowledge)

**Competitive Intelligence:**

- Monitor public discussions (LinkedIn, tradie forums, review sites) for mentions of Telnyx in context of Sunaiva
- Set up Google Alerts for "Sunaiva Telnyx" and similar combinations

### 2.3 Detection Confidence Levels

**HIGH Confidence Leaks:**

- Telnyx domain names visible in network traffic (api.telnyx.com, webrtc.telnyx.com)
- Telnyx logo, branding, or trademarked terms in UI elements
- Telnyx SDK initialization code in source or network requests

**MEDIUM Confidence Leaks:**

- Error messages containing "Telnyx" in text
- Console warnings about deprecated Telnyx APIs
- Network request payloads that include Telnyx-specific field names

**LOW Confidence Leaks (Requires Context):**

- Australian phone numbers associated with Telnyx number blocks (requires vendor lookup)
- Latency patterns consistent with Telnyx infrastructure
- Known Telnyx audio hold music or TTS voices (requires audio fingerprinting)

---

## 3. Legal Considerations of Hiding Vendor Names

### 3.1 Contractual Compliance

**Telnyx Terms of Service:**

- Review current Telnyx API Terms of Service for provisions regarding branding, attribution, or rebranding
- Most VoIP/API vendors prohibit removing legal attribution from billing statements or regulatory disclosures
- **Action Required:** Legal counsel review of Telnyx agreement for specific rebranding restrictions

**Australian Consumer Law (ACL):**

- Misleading conduct provisions (s18, s29) could apply if Sunaiva makes representations about the origin of the voice service that are materially false
- However, simply not disclosing the vendor is generally not considered misleading — businesses are not required to disclose their supply chain
- Risk increases if marketing materials explicitly claim "proprietary" or "exclusive" technology that relies on Telnyx
- **Risk Level:** LOW if marketing claims are carefully worded; MEDIUM if explicit false claims are made

### 3.2 Liability and Warranty Implications

**Scenario:** A customer experiences a service failure, discovers the Telnyx dependency, and claims they would not have subscribed had they known the service was powered by a third party.

**Legal Analysis:**

- This is generally not a strong claim unless there was an explicit misrepresentation about ownership or origin
- Customer contracted with Sunaiva, not Telnyx — Sunaiva remains fully liable for service delivery regardless of underlying vendors
- **Mitigation:** Ensure Terms of Service clearly indicate that Sunaiva uses third-party infrastructure without specifically naming competitors

**Scenario:** A customer's data flows through Telnyx infrastructure, and a data breach occurs at Telnyx.

**Legal Analysis:**

- Sunaiva's liability depends on whether it met its obligations under its own Privacy Policy and Terms
- If Sunaiva represents it operates its own telephony network when it does not, this could be problematic
- **Risk Level:** LOW-MEDIUM — review Privacy Policy language to ensure accurate description of data handling

### 3.3 Intellectual Property Considerations

**Trademark Usage:**

- Sunaiva must not use Telnyx trademarks in a way that suggests affiliation or endorsement unless such a relationship exists
- Obfuscation itself is not a trademark violation; actively claiming to be Telnyx would be
- **Risk Level:** LOW — provided Sunaiva does not use Telnyx branding in marketing materials

**Patent and Licensing:**

- Some VoIP features may be licensed from Telnyx with restrictions on sublicensing or rebranding
- Review any licensing agreements for restrictions on representing the technology as proprietary Required:** Legal review of Telnyx
- **Action API licensing terms

### 3.4 Practical Legal Recommendations

1. **Terms of Service:** Include language stating Sunaiva uses "selected third-party infrastructure providers" without naming specific vendors
2. **Privacy Policy:** Describe data flows accurately without naming Telnyx specifically (acceptable: "voice traffic is processed through encrypted channels"; problematic: "voice traffic is processed by Telnyx")
3. **Marketing Review:** Ensure no marketing materials make explicitly false claims about proprietary technology — use "powered by" language cautiously or avoid it entirely
4. **Agency Partner Agreements:** Ensure agency partners understand and accurately represent the relationship (do not provide them with misleading talking points)

---

## 4. Impact on Debugging

### 4.1 Increased Diagnostic Complexity

**Problem:** When a widget issue occurs, support engineers and developers lose direct visibility into Telnyx's error codes, status messages, and diagnostic information.

| Issue Type | Without Obfuscation | With Obfuscation |
|------------|---------------------|-------------------|
| One-way audio | Telnyx error code directly indicates NAT/firewall issue | Must correlate Telnyx error to Sunaiva event log before identifying root cause |
| Call connection failure | Immediate visibility into Telnyx SIP response codes | Requires internal mapping document to translate Telnyx codes to Sunaiva equivalents |
| Quality complaints | DSP metrics directly visible in Telnyx dashboard | Must pull parallel logs from Sunaiva's internal Telnyx integration layer |
| Number porting issues | Telnyx portal shows port status directly | Must check Sunaiva dashboard, which may not show real-time Telnyx status |

**Impact on MTTR (Mean Time to Resolution):** Estimated 15-30% increase in diagnostic time for Telnyx-related issues.

### 4.2 Internal Knowledge Requirements

**Knowledge Debt:** The development and support teams must maintain comprehensive internal documentation mapping:

- Telnyx error codes → Sunaiva error messages
- Telnyx API responses → Sunaiva callback events
- Telnyx WebRTC states → Sunaiva connection states
- Telnyx dashboard metrics → Sunaiva analytics

**Onboarding Impact:** New engineers and support staff require additional training on the Telnyx-to-Sunaiva translation layer, extending time-to-productivity by approximately 1-2 weeks.

### 4.3 Debugging Workflow Changes

**Before Obfuscation:**

1. Customer reports issue → Support checks Telnyx dashboard
2. Identifies error directly → Provides resolution or escalates to Telnyx with evidence

**After Obfuscation:**

1. Customer reports issue → Support checks Sunaiva logs
2. If Telnyx-related, developer translates error using internal documentation
3. If Telnyx escalation required, developer uses internal ticket with Telnyx reference, maintains customer-facing anonymity
4. Resolution flows back through developer translation layer

### 4.4 Tooling and Infrastructure Requirements

**Required New Capabilities:**

- Internal error code mapping database (maintained as code, version-controlled)
- Telnyx dashboard access restricted to engineering (not customer-facing support)
- Internal Slack channel or Jira workflow for Telnyx-specific debugging
- Scheduled sync of Telnyx status page to Sunaiva status page (without revealing source)

---

## 5. Impact on Telnyx Support Interactions

### 5.1 Escalation Complexity

**Current State (No Obfuscation):**

- Customer reports issue → Sunaiva support identifies Telnyx as cause → Escalates to Telnyx with customer details and full error trace
- Telnyx support sees direct correlation between error and customer account

**Post-Obfuscation State:**

- Sunaiva must create internal reference before contacting Telnyx
- Telnyx tickets should reference Sunaiva as the customer, not the end user (to maintain obfuscation)
- Sunaiva must strip or redact any customer-facing Telnyx identifiers before internal review
- **Risk:** Telnyx support may be slower to respond if they cannot directly correlate the issue with the end customer's account

### 5.2 Account Management Considerations

**Account Visibility:**

- Telnyx will still see Sunaiva as their customer; obfuscation is at the end-user level
- Sunaiva's Telnyx account representative should be informed of the obfuscation strategy to avoid confusion during business reviews
- **Recommended:** Schedule a call with Telnyx account manager to explain the go-to-market approach and confirm it does not violate any agreements

**Pricing and Volume Discussions:**

- Obfuscation does not affect volume commitments or pricing tiers
- However, if Telnyx discovers end users are unaware of the relationship, they may approach those end users directly as potential direct customers
- **Mitigation:** Ensure Telnyx relationship terms include provisions preventing direct solicitation of Sunaiva customers

### 5.3 Technical Support Workflow Changes

| Workflow Element | Impact | Mitigation |
|------------------|--------|------------|
| **Ticket Creation** | Must use Sunaiva internal customer ID, not end-user details | Create internal mapping between Sunaiva customer IDs and Telnyx account identifiers |
| **Log Sharing** | Cannot share raw Telnyx logs with customers | Create Sunaiva-redacted versions for customer-facing communications |
| **Screen Sharing** | Cannot show Telnyx dashboard during customer calls | Create Sunaiva dashboard with Telnyx data (or accept this limitation) |
| **API Status** | Telnyx status updates must be translated | Build automated status translation or manual process |

### 5.4 Relationship Risk

**Worst-Case Scenario:** Telnyx discovers that Sunaiva is systematically hiding the Telnyx relationship from end users and interprets this as:

- A breach of trust or partnership terms
- An attempt to circumvent Telnyx's customer retention or upselling efforts
- Potential violation of trademark or branding restrictions

**Outcome:** Telnyx could revise pricing, limit API access, or terminate the relationship with minimal notice.

**Risk Level:** LOW-MEDIUM (assuming transparent communication with Telnyx about the approach)

---

## 6. Mitigation Strategies

### 6.1 Technical Mitigations

| Risk | Mitigation | Priority |
|------|------------|----------|
| **Incomplete obfuscation** | Automated build-time scanning with fail-build-on-detect; manual code review for all obfuscation changes | CRITICAL |
| **Runtime errors from bugs** | Comprehensive QA testing covering all call flows; canary release with limited traffic | HIGH |
| **Debugging complexity** | Internal error mapping database; training documentation; dedicated engineering time for diagnostic tooling | HIGH |
| **Detection by customers** | Accept that determined attackers will succeed; focus on preventing casual discovery | MEDIUM |

### 6.2 Operational Mitigations

| Risk | Mitigation | Priority |
|------|------------|----------|
| **Support MTTR increase** | Build internal dashboards mirroring Telnyx data; create escalation playbooks | HIGH |
| **Telnyx support friction** | Maintain clear internal records; communicate transparently with Telnyx account team | HIGH |
| **Leak detection** | Automated scanning in CI/CD pipeline; weekly manual review; customer feedback loops | CRITICAL |

### 6.3 Legal Mitigations

| Risk | Mitigation | Priority |
|------|------------|----------|
| **Contractual violation** | Legal review of Telnyx terms; adjust approach if restrictions found | CRITICAL |
| **ACL misrepresentation** | Review all marketing language; avoid false claims of proprietary technology | HIGH |
| **Privacy/direct liability** | Ensure Privacy Policy accurately describes data flows | MEDIUM |
| **Agency partner misrepresentation** | Provide accurate partner materials; train sales team | MEDIUM |

### 6.4 Business Strategy Mitigations

| Risk | Mitigation | Priority |
|------|------------|----------|
| **Competitive erosion** | Accelerate differentiation beyond the voice layer — Australian support, tradie-specific features, integrations with tradie software | CRITICAL |
| **Agency partner trust** | Be transparent with agency partners about the underlying stack; position Sunaiva as a "managed service" not a "proprietary product" | HIGH |
| **Telnyx relationship damage** | Proactively inform Telnyx of the strategy; ensure no direct end-user solicitation in contract | HIGH |

---

## 7. Action Items

### Immediate (Before Launch)

1. **Legal Review:** Have counsel review Telnyx API terms for rebranding restrictions
2. **Privacy Policy Update:** Ensure accurate data flow descriptions without vendor naming
3. **Marketing Audit:** Review all website, pitch deck, and sales materials for accurate claims
4. **Build Pipeline:** Implement automated scanning for Telnyx references in codebase

### Pre-Launch to Beta

5. **Error Mapping Database:** Build internal reference for Telnyx-to-Sunaiva error translation
6. **Telnyx Communication:** Brief Telnyx account manager on approach; confirm no contract violations
7. **Support Training:** Update support processes and train team on new diagnostic workflows
8. **Agency Partner Brief:** Inform partners of the managed service positioning; provide accurate materials

### Post-Launch (Ongoing)

9. **Leak Monitoring:** Weekly review of customer tickets for vendor awareness; quarterly competitive intel review
10. **MTTR Tracking:** Monitor diagnostic times; adjust tooling if increases exceed acceptable threshold
11. **Differentiation Investment:** Accelerate development of features that cannot be easily replicated by competitors

---

## 8. Conclusion

Obfuscating the Telnyx vendor relationship is a commercially reasonable strategy that introduces manageable operational complexity. The primary risks are:

- **Incomplete obfuscation** creating a false sense of security while exposing the business to the exact competitive risk it seeks to mitigate
- **Operational friction** increasing debugging time and support complexity
- **Relationship risk** with Telnyx if the approach is discovered without prior communication

These risks are all mitigable through technical automation, operational process changes, and transparent communication with both Telnyx and agency partners.

**Recommendation:** Proceed with obfuscation implementation, but prioritize:

1. Legal review of Telnyx terms before broader deployment
2. Automated scanning in the build pipeline (this is the single highest-impact technical control)
3. Transparent communication with Telnyx account management to preserve the commercial relationship
4. Investment in genuine product differentiation that reduces dependence on hiding the vendor relationship long-term

The obfuscation strategy is a tactical move to protect market position in the short term. Long-term competitive advantage must come from features, support, and integrations that are difficult for competitors or end users to replicate — not from successfully hiding the name of a VoIP provider.

---

*End of Assessment*