जारी करने वाली तरफ Anti-quishing। संग्रहण की तरफ Data residency।
हर Pro लिंक जारी होने पर, हर destination बदलने पर, और एक rolling schedule पर सात-परत के anti-quishing pipeline से गुज़रता है। Scan log में केवल देश और device-class होता है, कोई IP नहीं, कोई user agent नहीं, कोई cookie नहीं, कोई behavioral profile नहीं। Single-region D1 Agency और Custom Enterprise पर उपलब्ध है।
हम क्या डेटा एकत्र करते हैं
हमारे सर्वर पर आने वाला हर byte चार में से एक श्रेणी में होता है:
Account data
Email, plan tier, plan status, Stripe customer + subscription IDs, वैकल्पिक team name + workspace label। बस इतना। कोई फ़ोन नहीं, कोई पता नहीं (billing address Stripe पर रहता है), कोई behavioral profile नहीं।
Code data
Destination URL, एक 7-char Base58 shortcode, आपका दिया label + tags, वैकल्पिक QR design (colors / logo / frame), वैकल्पिक password gate, वैकल्पिक schedule। यह आपका डेटा है; किसी भी समय CSV के रूप में export करें।
Scan data
UTC day-bucket + देश (CF-IPCountry से) + device class (mobile / tablet / desktop / unknown)। Raw User-Agent को classification के तुरंत बाद हटा दिया जाता है। IP कभी database में नहीं जाता। Redirect hot path के लिए KV में cache होता है, ctx.waitUntil के ज़रिए D1 में aggregate होता है। 5 से कम scans वाले देश के aggregates re-identification रोकने के लिए "Other" में मिला दिए जाते हैं।
Audit / billing metadata
Mutations का append-only log (किसने क्या किया, कब, किस scope में), 180 दिन की retention। Stripe webhook events idempotency के लिए deduplicate होते हैं, Stripe customer ID से आगे कोई customer PII नहीं। GDPR request log (export / delete / restore), समय पर पूर्ति का प्रमाण देने के लिए account deletion के बाद भी retain होता है।
पूरे schema के लिए, हमारे source repo में docs/SCHEMA.md देखें; हर column retention policy के साथ documented है।
डेटा कहाँ रहता है
| Surface | Provider | Region | Single-region विकल्प? |
|---|---|---|---|
| Dashboard + API | Cloudflare Pages Functions | Global edge (निकटतम PoP) | हाँ, केवल Agency+ |
| Code records (D1) | Cloudflare D1 (SQLite) | Provisioning पर assigned primary region (आज: ENAM) | हाँ, Agency+ per-tenant shard |
| Redirect hot path (KV) | Cloudflare Workers KV | <50ms p99 के लिए globally edge-replicated | उपलब्ध नहीं (replication ही product है) |
| Encrypted backups | Cloudflare R2 | Bucket create पर assigned primary region | हाँ, request पर EU / APAC jurisdictional bucket |
| Payments | Stripe | US, Stripe की अपनी residency के ज़रिए regional PII handling | Stripe contract के ज़रिए |
| Transactional email | ZeptoMail (Zoho) | IN (Zoho की EU region request पर उपलब्ध) | हाँ, Zoho EU region |
वास्तव में क्या सीमा पार जाता है
- Scans कभी किसी नुकसानदेह तरीके से सीमा पार नहीं करते। Lisbon से आया scan Lisbon Cloudflare PoP पर पहुँचता है, worker edge पर KV में day/country/device लिखता है, और async अपने primary region में D1 में aggregate होता है। Original scanner का IP Cloudflare की ephemeral request state में HTTP request की अवधि तक रहता है और हमारे database में कभी persist नहीं होता।
- Dashboard requests निकटतम Cloudflare PoP पर terminate होते हैं और Cloudflare के private network पर D1 को call करते हैं। हमारे Pages Functions अपने assigned region में D1 read/write करते हैं; edge PoP global static-asset cache से HTML + JS bundle serve करता है।
- Stripe webhooks एक बार सीमा पार करते हैं, Stripe (US) हमारे Cloudflare Pages endpoint पर POST करता है, जो HMAC verify करता है, idempotency के लिए एक minimal (event_id, type) row लिखता है, और downstream events dispatch करता है।
- Transactional email (Zepto) हर send पर एक बार सीमा पार करता है, हमारा worker Zepto के API को एक rendered template देता है; Zepto recipient के mailserver पर deliver करता है। Content में invite links, billing-lifecycle notifications, और scan-cap alerts हैं, कोई customer scan data नहीं।
Anti-quishing pipeline
QR phishing Q1 2026 में 146% बढ़ी। सामान्य short-link vendor customer complaint के बाद react करता है। हम हर link को जारी होने पर, हर बार destination बदलने पर, और एक rolling schedule पर check करते हैं क्योंकि एक customer हमारे API को बिना call किए अपने सर्वर पर अपना URL खुद repoint कर सकता है। वही threat-intel pipeline जो हमारे public scanner check.qr.abundera.ai को चलाती है, हमारे हर जारी link पर चलती है।
सात detection layers, प्रत्येक पर US patent application pending है। हर layer एक unified verdict को feed करती है; किसी एक पर hit create को block कर सकती है, destination change को refuse कर सकती है, या पहले से live link को suspend कर सकती है।
| Layer | क्या पकड़ता है | कब चलता है |
|---|---|---|
| Redirect-chain mutability | हमारे short link और final page के बीच path पर कितने independent parties का control है। किसी और के redirector से two-hop chain, direct destination से एक अलग risk class है। | Create, destination change, rolling re-check |
| Multi-modal payload analysis | WiFi, contact, telephony, mail, calendar, geolocation, cryptocurrency, Android intent, और inline-data payloads, हर एक को type-specific analyzer मिलता है। Hard-blocked schemes submit पर refuse होते हैं। | Create, destination change |
| Crawler-vs-browser cloaking | ऐसे pages जो scanners को clean content और इंसानों को phishing serve करते हैं। Controlled fingerprint variance और divergence score के साथ parallel fetches से detect होता है। | Create, rolling re-check |
| Destination-server mutability | नए registered domains, बिल्कुल नए certificates, high-churn TLDs, गायब HSTS, और transport-scheme degradation। Redirect chain से स्वतंत्र; एक संदिग्ध TLD पर छह दिन पुराने cert तक static one-hop chain भी flag होती है। | Create, destination change, rolling re-check |
| Physical-instance provenance | Decoded payload द्वारा keyed crowd-sourced hash ledger। एक QR का थोड़े समय में कई disparate regions में scan होना sticker-attack candidate के रूप में सामने आता है। हमारा हर जारी link creation पर clean provenance entry पाता है, इसलिए legitimate Pro codes पर overlay attacks पकड़ी जाती हैं। | Continuous |
| Visual-brand divergence | अगर कोई code ऐसे brand logo के साथ है जिसके canonical-domain set में decoded destination शामिल नहीं है, तो code brand-divergent है। हमारे center-logo feature वाले हर Pro code पर लागू; phisher Chase-logoed code को non-Chase domain की तरफ point नहीं कर सकता। | Create, logo change, destination change |
| Sensor / venue topology | Venue-bound codes (parking meters, hotel check-in, restaurant menus, museum exhibits) के लिए, scanning device के ambient RF context को उस venue की registered topology से check किया जाता है। Mismatch fraudulent sticker के पहले scan पर भी sensor-context anomaly return करता है। Enterprise tier; venue operator code creation पर expected topology register करता है। | Every scan |
Customer-side change की समस्या
Pro link का destination URL customer के सर्वर पर रहता है, हमारे नहीं। Customer बिना Abundera API call किए example.com/promo को real promo से phishing page पर repoint कर सकता है। हम इसे edge case नहीं, primary abuse path मानते हैं। Active destinations के खिलाफ rolling re-checks schedule पर चलते हैं, और हमारी cloaking-detection layer specifically ऐसे pages को target करती है जो submit के बाद flip होते हैं। जब creation के बाद कोई destination checks में fail होने लगता है, तो link auto-paused हो जाता है, owner को specific verdict के साथ email जाता है, और audit trail में event log होता है।
False-positives और appeals
Threat intel कभी-कभी गलत होती है। नए cert पर एक legitimate brand, एक real promo जिसका page legitimately बदला, एक moved domain। हर block और हर auto-pause में specific verdict layer शामिल होती है जो fire हुई, उसका input जिसने trigger किया, और एक one-click appeal जो एक business day के भीतर किसी इंसान के पास escalate होती है। हम delete की बजाय pause की तरफ झुकते हैं; appeal clear होने पर paused link seconds में re-enable होता है।
Single-region residency (Agency+ और Custom Enterprise)
केवल EU या केवल APAC के buyers के लिए, Agency-tier customers request कर सकते हैं:
- D1 एक single jurisdiction में (EU: EEUR या WEUR; APAC: APAC)। Cloudflare database creation पर
locationhint honor करता है; हम requested region में per-tenant D1 shard spin up करते हैं (ADR-0010)। - R2 bucket उसी jurisdiction में, nightly encrypted D1 → R2 backups matching region में जाते हैं।
- Transactional email के लिए Zepto EU region, service level पर configure, कोई code change नहीं।
- KV global रहता है, edge replication <50ms redirect guarantee का मूल है। अगर single-region KV hard requirement है, तो हमसे बात करें; हम evaluate कर सकते हैं कि आपके campaign के लिए regional-only Worker variant feasible है या नहीं।
Single-region add-on की pricing flat rate (कोई per-seat markup नहीं) है और specific combination पर निर्भर करती है। अपनी target jurisdiction + projected scan volume के साथ enterprise@abundera.ai पर email करें और हम quote देंगे।
Compliance posture
- GDPR, minimum-data-by-design (केवल country + device-class, कोई IP नहीं, कोई UA नहीं, कोई cookies नहीं) साथ ही one-click export और 30-day hard-delete। सभी paying tiers के लिए DPA + EU SCCs उपलब्ध।
- CCPA, उसी export + delete surface से covered। "Data की बिक्री" हम नहीं करते: कोई third-party sharing नहीं, कोई ad partners नहीं, कोई retargeting नहीं।
- SSO + SCIM provisioning, SAML 2.0 + OIDC single sign-on और SCIM 2.0 user & group lifecycle (Agency + Custom Enterprise tiers)। RFC 7643/7644 compliance verified (PingIdentity-derived test suite पर 20/20)। Per-connection feature flag का मतलब है SCIM off-by-default है और per customer enable होता है; प्रति token 50 RPS तक rate-limited; audit-logged। Okta/Entra/JumpCloud आज custom-SCIM apps के रूप में काम करते हैं जबकि partner-catalog listings in progress हैं।
- SOC 2 Type II, scoping में। 6-9 महीने की प्रक्रिया। अगर यह आपके लिए hard requirement है, enterprise@abundera.ai पर email करें; हम current status + projected timeline share कर सकते हैं।
- PCI-DSS, हमारे लिए directly out of scope; payments Stripe द्वारा end-to-end handle होते हैं (PCI Level 1 certified)।
Security disclosure
कोई vulnerability मिली? security@abundera.ai पर email करें। Coordinated disclosure, हम 24h (business days) के भीतर acknowledge करेंगे, 72h में triage करेंगे, और आपके साथ fix + disclosure timeline coordinate करेंगे। अभी कोई bug bounty program नहीं है; fix ship होने पर हम researchers को abundera.ai/security/thanks/ पर publicly acknowledge करते हैं।