# Privacy और data handling

Local build कुछ नहीं भेजती। Cloud build memory में obfuscate करती है और कुछ नहीं रखती, सिवाय उस Protection Map के जिसे store करने को आपने कहा, और जिसे आप बंद कर सकते हैं। Telemetry डिफ़ॉल्ट रूप से चालू है, तब रिपोर्ट करती है जब कोई build error-स्तर का diagnostic रिपोर्ट करती है, साफ़ build पर कभी नहीं, और एक env var से बंद हो जाती है।

Source: https://www.afterpack.dev/hi/docs/privacy

AfterPack का obfuscation product आपके code और account data को नीचे बताए अनुसार संभालता है। इस site की cookies और analytics अलग से, [Privacy Policy](https://www.afterpack.dev/hi/privacy) में कवर किए गए हैं।

> **संक्षेप में**
>
> एक [local (Free) build](https://www.afterpack.dev/hi/docs/deployment-modes) आपका source कभी कहीं नहीं भेजती। एक cloud (Pro) build memory में obfuscate करती है और request के अंत में source को हटा देती है। एक artifact store होता है: [dashboard](https://www.afterpack.dev/hi/docs/dashboard) के लिए **[Protection Map](https://www.afterpack.dev/hi/docs/protection-map)**। यह [workspace](https://www.afterpack.dev/hi/docs/dashboard/workspaces) तक सीमित है, expire होता है, और आप इसे प्रति project बंद कर सकते हैं। Telemetry डिफ़ॉल्ट रूप से चालू है, तब रिपोर्ट करती है जब कोई build error-स्तर का diagnostic रिपोर्ट करती है (इनकार की गई या आंशिक build), साफ़ build पर कभी नहीं, और [`AFTERPACK_telemetry_enabled=false`](https://www.afterpack.dev/hi/docs/config#telemetry-enabled) से बंद हो जाती है। DPA और sub-processors की पूरी सूची अनुरोध पर उपलब्ध है।

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

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

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

जब कोई [Pro build](https://www.afterpack.dev/hi/docs/pro) 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`](https://www.afterpack.dev/hi/docs/config#key) सेट करके [CLI](https://www.afterpack.dev/hi/docs/cli) के ज़रिए, या किसी [framework plugin](https://www.afterpack.dev/hi/docs/frameworks) के ज़रिए। ये सभी [Cloud API reference](https://www.afterpack.dev/hi/docs/cloud-api) में बताया गया protocol बोलते हैं।

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

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

| दर्ज होता है | कभी दर्ज नहीं होता |
| --- | --- |
| Timestamps (request प्राप्त हुई, response बंद हुआ) | फ़ाइल contents |
| HTTP status codes | Identifier names |
| Build id, फ़ाइलों की गिनती, input/output bytes का योग | Constant values, जिनमें source में संयोग से मौजूद secrets भी शामिल हैं |
| [Diagnostic codes](https://www.afterpack.dev/hi/docs/diagnostics) (`DIAG_*`) | Telemetry से आया diagnostic *message text* |
| Client IP, rate limiting के लिए | Source map के `sources` / `sourcesContent` |
| Workspace tier, metering के लिए | ऐसी कोई भी चीज़ जो आपका business logic उजागर कर सके |

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`](https://www.afterpack.dev/hi/docs/config#telemetry-enabled) से बंद करें**, CLI पर [`--telemetry.enabled=false`](https://www.afterpack.dev/hi/docs/config#telemetry-enabled) से, या अपने integration की config में [`telemetry: { enabled: false }`](https://www.afterpack.dev/hi/docs/config#telemetry-enabled) से। बस इतने ही तरीके हैं।
- **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](https://www.afterpack.dev/hi/docs/presets), या raw [`complexity`](https://www.afterpack.dev/hi/docs/config#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](https://www.afterpack.dev/hi/docs/protection-map) *आपका मूल source ही है*, जो इस आधार पर रंगा होता है कि हर token पर कितना transformation हुआ। Cloud build पर, AfterPack इसे उसी server पर बनाता है जिसने obfuscation किया और इसे रख लेता है, ताकि आप [dashboard](https://www.afterpack.dev/hi/docs/dashboard/builds) से किसी भी हाल की build का map खोल सकें।

> **यही एक जगह है जहाँ आपका source at rest रहता है**
>
> Protection Maps को store करना **डिफ़ॉल्ट रूप से चालू है, प्रति project**, और stored map को **उस project के मालिक [workspace](https://www.afterpack.dev/hi/docs/dashboard/workspaces) का हर member** पढ़ सकता है। अगर आपका source पूरे workspace में पढ़ने योग्य नहीं होना चाहिए, तो कोई workspace admin उस project की settings में [यह setting बंद करे](https://www.afterpack.dev/hi/docs/protection-map#turning-it-off)।

- **क्या store होता है:** हर build का map data, यानी आपका मूल source और रंगों के पीछे के प्रति-token metrics, compact और gzip करके Cloudflare R2 में, at rest encrypted, साथ में dashboard के लिए summary संख्याओं की एक row। आपका obfuscated output store नहीं होता।
- **एक project तक सीमित**, वही project जिससे build की [key](https://www.afterpack.dev/hi/docs/dashboard/api-keys) 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/` में लिखती है](https://www.afterpack.dev/hi/docs/cli#files), वह कभी आपकी machine से बाहर नहीं जाता।
- **इसके बंद होने पर भी क्या दर्ज होता है:** build की संख्याएँ (coverage, inflation, complexity, timings), ताकि project के [dashboard charts](https://www.afterpack.dev/hi/docs/dashboard/builds) काम करते रहें। ये किसी build से निकाले गए aggregates हैं। इनमें कोई code नहीं होता, और इनमें से कुछ भी वापस code के रूप में पढ़ा नहीं जा सकता।

## Sub-processors

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

| Sub-processor | भूमिका |
| --- | --- |
| **Cloudflare** | Workers / R2 / D1: edge compute, routing, Protection Map storage, और account database |
| **Creem** | केवल [billing](https://www.afterpack.dev/hi/docs/dashboard/usage), merchant of record के रूप में; कभी source प्राप्त नहीं करता |
| **Email / auth providers** | Account और key-lifecycle events के लिए magic-link और transactional email; कभी source प्राप्त नहीं करते |
| **Anthropic** (Cloudflare AI Gateway के ज़रिए) | Site के भीतर के assistant ("Ask AfterPack") को चलाता है; आप उसमें जो type करते हैं और जवाब देने के लिए वह जो documentation पेज पढ़ता है, वही प्राप्त करता है, आपका source code कभी नहीं |

## 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](https://www.afterpack.dev/hi/docs/deployment-modes) इस्तेमाल करें।** AfterPack पूरी तरह आपके अपने infrastructure पर चलता है, इसलिए residency का कोई प्रश्न ही नहीं उठता।

## DPA और compliance

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

## आगे

- [Cloud API reference](https://www.afterpack.dev/hi/docs/cloud-api): वह wire protocol जिस पर ये गारंटियाँ लागू होती हैं।
- [Deployment modes](https://www.afterpack.dev/hi/docs/deployment-modes): local बनाम cloud, और हर एक क्या भेजता है।
- [Protection Map](https://www.afterpack.dev/hi/docs/protection-map): stored map क्या दिखाता है, और प्रति-project switch कहाँ है।
- [Pro](https://www.afterpack.dev/hi/docs/pro): cloud में चलाने से वास्तव में क्या मिलता है।
- [Workspaces और projects](https://www.afterpack.dev/hi/docs/dashboard/workspaces): कौन क्या पढ़ सकता है, और key का scope कैसे तय होता है।
- [Dashboard](https://www.afterpack.dev/hi/docs/dashboard): जहाँ stored map और उसकी build का record दिखाया जाता है।