Privacy और data handling

AfterPack का obfuscation product आपके code और account data को नीचे बताए अनुसार संभालता है। इस site की cookies और analytics अलग से, Privacy Policy में कवर किए गए हैं।

Local build कुछ नहीं भेजती

एक local build AfterPack को एक native binary के रूप में आपकी machine पर चलाती है। आपके filesystem से कुछ बाहर नहीं जाता, इसलिए नीचे के cloud वाले sections उस पर लागू नहीं होते। Local build जो एकमात्र network call कभी करती है, वह नीचे बताई गई telemetry report है, जो केवल तब चलती है जब कोई build error-स्तर का diagnostic रिपोर्ट करती है (इनकार की गई या आंशिक build), कोई source नहीं ले जाती, और बंद की जा सकती है।

Cloud build memory में obfuscate करती है और कुछ नहीं रखती

जब कोई Pro build obfuscation के लिए api.afterpack.dev को source भेजती है, तो वह उस एक request की अवधि तक केवल memory में process होता है, फिर हटा दिया जाता है:

• Request एक sandboxed Cloudflare Worker isolate के भीतर चलती है, जो request की सीमा पर नष्ट हो जाता है। Response के बाद कुछ नहीं बचता।
• Logging में कभी source नहीं होता। Log lines में एक build id, फ़ाइलों की गिनती, bytes का योग, diagnostic codes, और विफल हुई फ़ाइल का path होता है। उनमें कभी फ़ाइल contents, identifier names या constant values नहीं होते।

यह बिल्कुल एक जैसा लागू होता है, चाहे आप API को सीधे call करें, AFTERPACK_key सेट करके CLI के ज़रिए, या किसी framework plugin के ज़रिए। ये सभी Cloud API reference में बताया गया protocol बोलते हैं।

एक artifact store होता है: Protection Map, जिसका वर्णन नीचे है, और जो obfuscation पूरा होने के बाद लिखा जाता है। Obfuscation के लिए upload किया गया source फिर भी request के अंत में हट जाता है।

Logs में क्या होता है और क्या नहीं

Aggregated metrics (प्रति दिन requests की गिनती, प्रति workspace meter हुए bytes, build timings) counters के रूप में रखे जाते हैं और उनमें कोई code नहीं होता।

Telemetry डिफ़ॉल्ट रूप से चालू है, और केवल build के error-स्तर के diagnostics रिपोर्ट करती है

Client anonymous build diagnostics रिपोर्ट कर सकता है ताकि engine bugs मिलें और ठीक हों। यह तब तक चालू है जब तक आप इसे बंद न करें। साफ़ build के पास रिपोर्ट करने को कुछ नहीं होता:

• केवल वही build कुछ भेजती है जो error या critical diagnostic emit करती है। साफ़ build बिल्कुल कुछ नहीं भेजती: कोई periodic ping नहीं, कोई phase timings नहीं, ठीक से चली build के लिए कोई usage stats नहीं।
• इसे AFTERPACK_telemetry_enabled=false से बंद करें, CLI पर --telemetry.enabled=false से, या अपने integration की config में telemetry: { enabled: false } से। बस इतने ही तरीके हैं।
• CI में यह बिल्कुल एक जैसा चलता है। कोई TTY या CI check default को नहीं बदलता या reporting को नहीं छोड़ता; payload बस ci: true दर्ज करता है, जो उसी CI variable से पढ़ा जाता है जिसे आपकी pipeline पहले से सेट करती है।
• कभी कोई prompt नहीं। Install के बाद पहली build एक बार का notice छापती है (क्या इकट्ठा होता है, क्या नहीं, इसे कैसे बंद करें) और आगे बढ़ जाती है। यह कभी जवाब के इंतज़ार में नहीं रुकती। State (एक random install id जो हर 30 दिन में rotate होता है, और यह कि notice छप चुका है या नहीं) ~/.afterpack/telemetry.json में रहती है।
• Test runs को छूट है। NODE_ENV=test और Vitest का अपना VITEST marker telemetry को बंद कर देते हैं।

जब कोई build error-स्तर का diagnostic रिपोर्ट करती है, तब क्या इकट्ठा होता है

• विफल diagnostic का code, severity और byte-offset span, साथ में हर diagnostic kind के लिए चुने गए typed fields की एक छोटी सूची, कभी उसका free-text message नहीं
• Engine, client और Node के versions, OS/arch, और पहचाना गया framework
• Build CI में चली या नहीं
• Complexity स्तर: एक नामित preset, या raw complexity के लिए custom
• फ़ाइलों की गिनती और build की अवधि, सटीक के बजाय buckets में (5-20, 1-5s); सटीक संख्या किसी विशेष project का fingerprint बन जाती है
• एक random install id जो हर 30 दिन में rotate होता है, कभी आपकी machine या project से नहीं निकाला जाता

जो कभी इकट्ठा नहीं होता, telemetry में या कहीं और

• Source code या फ़ाइल contents
• Telemetry में फ़ाइल names और फ़ाइल paths। Cloud build का server-side log एक path रखता है, batch के भीतर विफल हुई फ़ाइल का, जैसा ऊपर बताया गया है
• Diagnostic message text, कभी नहीं; केवल उसका स्थिर code
• API keys या credentials
• Constant values
• String encoding के चुनाव
• आपके account में पहले से मौजूद जानकारी के अलावा कोई भी user की पहचान करने वाली जानकारी

Telemetry का आकार निश्चित है।

Cloud builds के Protection Maps store होते हैं, और आप इसे बंद कर सकते हैं

Protection Map आपका मूल source ही है, जो इस आधार पर रंगा होता है कि हर token पर कितना transformation हुआ। Cloud build पर, AfterPack इसे उसी server पर बनाता है जिसने obfuscation किया और इसे रख लेता है, ताकि आप dashboard से किसी भी हाल की build का map खोल सकें।

• क्या store होता है: हर build का map data, यानी आपका मूल source और रंगों के पीछे के प्रति-token metrics, compact और gzip करके Cloudflare R2 में, at rest encrypted, साथ में dashboard के लिए summary संख्याओं की एक row। आपका obfuscated output store नहीं होता।
• एक project तक सीमित, वही project जिससे build की key bound है।
• केवल उस workspace के members ही पढ़ सकते हैं। Public नहीं, indexed नहीं, कोई shareable link नहीं।
• Retention: एक साल, और प्रति project आख़िरी 500 builds, जो पहले ख़त्म हो। एक hourly job किसी भी सीमा से आगे निकल चुकी हर चीज़ को delete कर देता है। बार-बार build होने वाले project के लिए गिनती वाली सीमा पहले लागू होती है। यह सीमित करती है कि किसी भी क्षण आपके source की कितनी copies मौजूद हैं।
• Map आंशिक रूप में store हो सकता है। जब कोई build लंबी चलती है, तो capture, obfuscation के रुकने से पहले ही रुक जाता है। Stored record बताता है कि कौन-से chunks छोड़े गए और क्यों।
• इसे बंद करने से उस project की नई builds कुछ भी store नहीं करतीं। पहले से stored maps तुरंत delete होने के बजाय ऊपर की retention के तहत समय पूरा होने पर हटते हैं। Local builds अप्रभावित रहती हैं: local build जो Protection Map .afterpack/ में लिखती है, वह कभी आपकी machine से बाहर नहीं जाता।
• इसके बंद होने पर भी क्या दर्ज होता है: build की संख्याएँ (coverage, inflation, complexity, timings), ताकि project के dashboard charts काम करते रहें। ये किसी build से निकाले गए aggregates हैं। इनमें कोई code नहीं होता, और इनमें से कुछ भी वापस code के रूप में पढ़ा नहीं जा सकता।

Sub-processors

Cloud build इन processors को छूती है। Source obfuscate होते समय केवल memory में Cloudflare से होकर गुज़रता है; Cloudflare ही एकमात्र है जो कभी source को at rest रखता है, ऊपर बताए गए Protection Map के रूप में:

Data residency

ऊपर के sections इसका जवाब देते हैं कि source store होता है या नहीं। Residency अलग प्रश्न है: request चलते समय source कहाँ process होता है, और stored map कहाँ रखा जाता है।

इनमें से कोई भी region-pinned नहीं है। Cloud build को Cloudflare किसी नज़दीकी region पर route करता है, और failover या load की स्थिति में यह कहीं और पहुँच सकती है। कोई प्रति-request region pin नहीं है, और R2 storage region-locked नहीं है। अगर आपको residency की पक्की गारंटी चाहिए, तो local build इस्तेमाल करें। AfterPack पूरी तरह आपके अपने infrastructure पर चलता है, इसलिए residency का कोई प्रश्न ही नहीं उठता।

DPA और compliance

Data Processing Agreement अनुरोध पर उपलब्ध है। आप जिस DPA पर हस्ताक्षर करते हैं, वही कानूनी, लागू करने योग्य अनुबंध है, और वह ऊपर बताई गई sub-processor सूची और residency व्यवहार का हवाला देता है।

आगे

• Cloud API reference: वह wire protocol जिस पर ये गारंटियाँ लागू होती हैं।
• Deployment modes: local बनाम cloud, और हर एक क्या भेजता है।
• Protection Map: stored map क्या दिखाता है, और प्रति-project switch कहाँ है।
• Pro: cloud में चलाने से वास्तव में क्या मिलता है।
• Workspaces और projects: कौन क्या पढ़ सकता है, और key का scope कैसे तय होता है।
• Dashboard: जहाँ stored map और उसकी build का record दिखाया जाता है।