# Disasmer Market Plan and Abuse Notes ## Positioning Disasmer is an open-source distributed Wasm runtime. Its initial primary use case is as a build system. The product promise: ```text real source file normal debugging local-first execution distributed builds when needed operator UI instead of CI YAML self-hosted nodes when users want control managed coordination when users want convenience ``` The hosted service is primarily the **control plane**: ```text identity coordinator state virtual process registry node discovery debug sessions operator panels artifact metadata optional managed nodes later ``` The coordinator should not be a free general-purpose compute platform. --- ## Open-source strategy Disasmer should be open source by default: ```text runtime SDK CLI VS Code extension node runtime local coordinator protocol specs example build programs ``` The hosted product should monetize convenience, scale, reliability, and managed infrastructure rather than hiding the core runtime. Recommended split: ```text Open source: run Disasmer locally run your own coordinator attach your own nodes debug programs use the build-system features Hosted service: managed coordinator identity/login public endpoint node rendezvous team management hosted operator panels artifact metadata/storage managed build nodes later uptime/support/compliance later ``` --- ## Community hosted tier Community tier users get: ```text 1 active virtual process zero-capability hosted Wasm control loop tiny memory/state limit tiny CPU/fuel limit tiny log limit tiny artifact/state retention operator panel access ability to attach their own node(s) so these limits don't matter ``` The hosted free Wasm process has **zero capabilities**: ```text no network no host filesystem no secrets no containers no native commands no outbound HTTP no inbound ports no arbitrary syscalls no access to other users ``` It exists only to let users try the system and orchestrate their own attached nodes. Real work in the community tier should run on user-provided nodes. --- ## Paid products Likely paid tiers: ```text Pro coordinator: more virtual processes more state/log retention private projects longer-running processes more operator panels artifact storage Team coordinator: shared nodes roles/permissions audit logs team secrets organization billing Managed nodes: Linux builders Windows builders macOS builders if feasible GPU/specialized nodes later warm caches reserved capacity Enterprise: private coordinator deployment SSO/SAML/OIDC compliance controls support/SLA custom retention on-prem/hybrid support Marketplace later: resold node capacity verified builder pools specialized environments ``` Primary revenue should come from: ```text managed coordinators managed nodes team features artifact/log retention support enterprise deployments ``` Avoid depending on community tier compute economics. --- ## Main abuse principle Assume every public input is hostile: ```text users programs nodes operator panels logs artifacts OAuth identities build files container images Git repos ``` The coordinator must coordinate untrusted systems without trusting them. --- ## Abuse paths to derisk ### 1. Community tier compute abuse Risks: ```text crypto mining brute force jobs scraping loops infinite loops account farming to multiply community tier resources ``` Controls: ```text fuel metering wall-clock limits memory limits wake-up limits per-account quotas per-IP signup/rate limits no hosted containers on community tier ``` --- ### 2. Coordinator denial of service Risks: ```text too many API calls too many virtual process events too many logs too many UI updates too many node heartbeats too many task spawn attempts huge metadata objects expensive queries ``` Controls: ```text quota every API rate-limit event streams cap log size cap UI update frequency cap metadata size cap process lifetime use backpressure everywhere admin kill switch ``` OWASP API Security lists unrestricted resource consumption as a major API risk, including CPU, memory, storage, bandwidth, and paid provider resources. --- ### 3. Network abuse Risks: ```text port scanning DDoS coordination spam/proxy behavior credential stuffing webhook abuse using Disasmer as rendezvous/C2 infrastructure ``` Controls: ```text free hosted tasks have no network node traffic requires authenticated sessions rate-limit rendezvous APIs no public inbound ports by default restrict relays monitor suspicious fan-out block known-abusive behavior ``` --- ### 4. Artifact and log abuse Risks: ```text malware hosting phishing pages illegal content oversized binaries secret leakage in logs using logs as data exfiltration using artifacts as free storage/CDN ``` Controls: ```text tiny free retention size limits download limits content reporting/removal malware scanning where practical secret redaction tools private-by-default artifacts no public hosting by default ``` --- ### 5. Secret theft Risks: ```text malicious build scripts stealing tokens operator panel phishing exfiltration through logs/artifacts self-hosted node compromise repo credentials leaking into tasks ``` Controls: ```text no secrets in free hosted tasks scoped short-lived task tokens explicit secret grants secrets never shown in UI/logs audit access to secrets separate coordinator identity from node identity ``` --- ### 6. OAuth and account abuse Risks: ```text fake account farms stolen OAuth sessions bad redirect URI handling token leakage OAuth app phishing provider token overreach ``` Controls: ```text OIDC/OAuth with PKCE strict redirect URI matching verified email where possible short-lived sessions minimal scopes anti-abuse signup checks manual suspension tools ``` OAuth security best current practice is covered by RFC 9700. --- ### 7. Malicious user-provided nodes Risks: ```text lying about results faking logs returning malicious artifacts claiming cache hits incorrectly exfiltrating inputs/secrets attacking other nodes using coordinator for discovery of targets ``` Controls: ```text never mix tenants by default explicit node sharing only signed node identity per-node capability policy artifact provenance optional reproducible/repeated builds trust labels for nodes ``` Default rule: ```text A user's work runs only on that user's nodes, managed paid nodes, or explicitly shared team nodes. ``` --- ### 8. Cross-tenant isolation bugs Risks: ```text user sees another user's process user sees another user's logs user accesses another user's node artifact metadata leak operator panel leak bad authorization check on debug endpoint ``` Controls: ```text tenant ID on every object authorization checks on every API negative tests for cross-tenant access separate storage namespaces least-privilege service tokens security review for debug APIs ``` --- ### 9. Debugger abuse Risks: ```text reading secrets through debugger modifying task state maliciously attaching to another user's process debug endpoint used as data exfiltration path huge memory reads causing DoS ``` Controls: ```text attach requires owner/team permission debug memory reads are quota-limited debug sessions are audited no cross-tenant debug access hosted free tasks have no secrets ``` --- ### 10. Operator panel phishing Risks: ```text fake login forms fake GitHub authorization prompts malicious links misleading buttons HTML/script injection ``` Controls: ```text built-in widgets only no custom HTML/JS in MVP escape all text label panels as user-provided no password fields initially restricted external links no OAuth flows inside user panels ``` --- ### 11. Container/runtime abuse Risks: ```text container escape privileged container misuse Docker socket exposure host filesystem mount abuse kernel attack surface supply-chain malware ``` Controls: ```text no free hosted containers managed containers only on hardened paid nodes rootless where practical seccomp/AppArmor/SELinux no privileged containers by default no Docker socket mounts read-only mounts where possible network egress policy ``` NIST SP 800-190 covers container security concerns; Docker documents rootless mode and seccomp profiles as important hardening tools. --- ### 12. Supply-chain abuse Risks: ```text malicious Disasmer examples malicious Containerfiles malicious flakes dependency confusion poisoned build caches untrusted public templates ``` Controls: ```text signed official examples template review cache namespace separation provenance metadata dependency lockfiles clear trust warnings before running third-party projects ``` --- ### 13. Cost amplification Risks: ```text API calls that trigger expensive work artifact sync causing storage costs log spam causing storage costs OAuth/webhook/email costs relay bandwidth costs ``` Controls: ```text hard spend caps per-user cost budgets quota before work starts paid-only expensive features separate flush from sync bulk data never routed through coordinator by default ``` --- ## Free-tier product rule Free hosted mode should prove the product, not subsidize heavy builds. It should support: ```text creating a virtual process opening an operator panel testing the SDK attaching a user's own node running tiny control logic spawning tasks onto the user's node using the debugger flow ``` It should not support: ```text hosted CI workloads hosted arbitrary containers large artifact storage public file hosting network scanning long-running compute ``` --- ## MVP commercial rollout Phase 1: ```text open-source local runtime free hosted coordinator one zero-capability hosted process attach-your-own-node flow VS Code extension operator panel basic abuse controls ``` Phase 2: ```text paid coordinator limits team projects more processes longer retention private artifacts better logs ``` Phase 3: ```text managed Linux nodes warm build caches paid artifact storage organization billing ``` Phase 4: ```text Windows/macOS builders enterprise/private coordinators SSO/audit/SLA node resale or marketplace ``` --- ## Success metric The free product should let someone do this quickly: ```text sign in create one Disasmer program (through the website, terminal or vscode for example) open its operator panel attach their own machine as a node and verify this in the coordinator UI spawn a build task onto that node debug it from VS Code see artifacts/logs in the coordinator UI ``` That proves the platform without giving away expensive compute. --- ## References ```text OWASP API Security Top 10 2023: Unrestricted Resource Consumption https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/ OAuth 2.0 Security Best Current Practice, RFC 9700 https://datatracker.ietf.org/doc/rfc9700/ NIST SP 800-190: Application Container Security Guide https://csrc.nist.gov/pubs/sp/800/190/final Docker Rootless Mode https://docs.docker.com/engine/security/rootless/ Docker Seccomp Security Profiles https://docs.docker.com/engine/security/seccomp/ ```