Security Features

Hologram implements multiple layers of security to protect users while enabling powerful dApp functionality. This page explains the security model and how each layer works.

Defense Layers

Hologram protects users through four concentric security layers:

┌───────────────────────────────────────────────────────┐
│  Layer 1: Blockchain Immutability                     │
│  ┌─────────────────────────────────────────────────┐  │
│  │  Layer 2: Iframe Sandboxing                     │  │
│  │  ┌───────────────────────────────────────────┐  │  │
│  │  │  Layer 3: Permission System               │  │  │
│  │  │  ┌─────────────────────────────────────┐  │  │  │
│  │  │  │  Layer 4: Local Execution           │  │  │  │
│  │  │  │  ┌───────────────────────────────┐  │  │  │  │
│  │  │  │  │       Protected User          │  │  │  │  │
│  │  │  │  └───────────────────────────────┘  │  │  │  │
│  │  │  └─────────────────────────────────────┘  │  │  │
│  │  └───────────────────────────────────────────┘  │  │
│  └─────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────┘

Layer 1: Blockchain Immutability

TELA content is stored on the DERO blockchain and served through the TELA Browser, providing:

Layer 2: Iframe Sandboxing

All TELA content runs in a sandboxed iframe:

<iframe 
  sandbox="allow-scripts allow-same-origin"
  ...
>

Restrictions:

• No direct network requests (except through telaHost)
• No access to parent window DOM
• No local storage or cookies
• No form submission to external URLs
• No popups or new windows

Layer 3: Permission System

User approval required for sensitive operations:

Layer 4: Local Execution

All content executes locally on your machine:

• No remote code execution
• No external JavaScript loading
• All assets fetched from blockchain
• No CDN or third-party dependencies

Content Security Policy

Why CSP is Relaxed

Traditional web browsers use Content Security Policy (CSP) to prevent cross-site scripting. However, TELA apps:

1. Are fetched from blockchain (not remote servers)
2. Run in sandboxed iframes
3. Have no external network access
4. Are cryptographically verified

Hologram's reverse proxy system strips CSP headers because:

• The iframe sandbox provides equivalent protection
• CSP would break legitimate TELA functionality
• Content is already verified from blockchain

Security Mitigations

XSWD Security

Permission Scopes

Smart Detection

Hologram analyzes what methods an app actually calls:

• Read-only apps (only DERO.* methods) → Minimal permissions shown
• Wallet apps (wallet methods) → Full permission dialog

Rate Limiting

Per-app rate limiting prevents abuse:

RATE_LIMIT_WINDOW    = 10 seconds
RATE_LIMIT_MAX_CALLS = 100 per window

Privacy Mode

Privacy Mode provides network-level isolation, blocking all non-DERO connections when enabled.

How It Works

When Privacy Mode is enabled:

• All outbound network connections are blocked by default
• Only connections to allowed hosts are permitted
• DERO daemon connections continue to work normally
• TELA content loads from blockchain (unaffected)

Allowed Hosts

These hosts are always allowed, even with Privacy Mode enabled:

You can add additional allowed hosts in Settings > Privacy Mode.

Use Cases

• Maximum privacy: Block all external connections except DERO
• Network isolation: Prevent any data leakage to non-DERO hosts
• Testing: Verify your TELA app works without external dependencies

Active Connections

The Privacy Mode panel shows all current network connections used by Hologram, allowing you to monitor exactly what connections are active.

Privacy Protections

Zero Tracking

Hologram does not:

• Collect usage analytics
• Track browsing history
• Send data to external servers
• Use cookies or fingerprinting
• Log wallet addresses

Local-Only Data

All data stays on your machine:

Network Privacy

• Direct daemon connection (no proxy servers)
• No DNS leaks for TELA content
• Optional Tor support (via daemon configuration)

Daemon Download Security

When Hologram auto-downloads the DERO daemon (derod), it performs SHA256 checksum verification to ensure the binary hasn't been tampered with.

Checksum Verification

1. Download checksum file — Fetches checksum.txt.signed from GitHub releases
2. Parse signed message — Extracts checksums from DERO-signed message format
3. Calculate local hash — Computes SHA256 of downloaded archive
4. Compare — Fails download if checksums don't match

// Verification is mandatory for auto-downloads
// If checksum fails, the downloaded file is deleted
VerifyFileChecksum(filePath, expectedChecksum) -> error

Privacy Setting

If you prefer not to contact GitHub, you can disable auto-download:

1. Go to Settings > Privacy
2. Disable Allow GitHub Check
3. Manually download derod from GitHub Releases (opens in a new tab)
4. Place the binary in ~/.dero/hologram/derod/

Wallet Security

Integrated Wallet

• Keys stored in encrypted wallet files
• Password required to open wallet
• No keys transmitted over network
• Transaction signing happens locally

XSWD Server

When acting as XSWD server:

• Only accepts connections from localhost
• Per-app permission management
• User approval for all transactions
• Session-based authentication

External Wallet (XSWD Client)

When connecting to external wallet (e.g., Engram):

• No keys stored in Hologram
• Transactions signed by external wallet
• Hologram acts as dApp bridge only

Best Practices

For Users

1. Review permissions — Check what apps request before approving (see telaHost API)
2. Verify transactions — Always review amount and recipient in the Wallet
3. Use strong passwords — Protect your wallet files
4. Keep backups — Store wallet seed phrases securely
5. Use Offline-First — Cache trusted apps for enhanced privacy
6. Enable Privacy Mode — Block all non-DERO connections
7. Check ratings — Use community ratings via Explorer as trust signal

For Developers

1. Request minimal permissions — Only ask for what you need via telaHost API
2. Don't specify permissions — Let Hologram auto-detect what your app needs
3. Handle rejections gracefully — Users may decline
4. Validate all input — Never trust user data
5. Test in Simulator — Before deploying to mainnet using Studio tools

Reporting Security Issues

If you discover a security vulnerability:

1. Do not disclose publicly
2. Contact the development team privately
3. Provide detailed reproduction steps
4. Allow time for fix before disclosure

Comparison