ब्लॉग पर वापस जाएं
गोपनीयतातकनीक

वन टाइम लिंक सच में सुरक्षित 2026: 4 इम्प्लीमेंटेशन की तुलना

प्रकाशित10 min read
साझा करें

बहुत लोग सोचते हैं "ephemeral" = "safe" — दरअसल दोनों बिलकुल अलग हैं

Burn-after-read (one-time-view) links पिछले कुछ सालों में काफ़ी popular हो गए हैं — password भेजना हो, Aadhaar copy share करनी हो, private image किसी HR को भेजनी हो, लोग ephemeral link को "secure" का synonym मान लेते हैं।

असल में — अलग-अलग services के "burn after read" implementation ज़मीन-आसमान अलग हैं, कुछ implementations technically promise ही नहीं रख पाते कि data truly destroyed हुआ है।

ये article cryptography और system architecture के angle से तीन main implementation models dissect करता है, और हर एक के strength/weakness देखता है। भारतीय context में DPDP Act 2023, banking OTP culture, और WhatsApp forwarding habits सब relevant हैं।

Three Implementation Models

Model 1: Pure Server-Side Deletion (Token-Based)

Simplest और सबसे common approach:

  1. User content upload करता है, server raw data store करता है और unique Token generate करता है (UUID या random string)
  2. Server Token-embedded link return करता है (जैसे https://example.com/view/abc123)
  3. पहला visitor link खोलता है, server content serve करता है और Token को "used" mark करता है
  4. बाद के visitors को "expired" response

Security analysis:

इस model की root problem — server plaintext data hold करता है। "Destruction" से पहले ये roles content access कर सकते हैं:

  • Server administrator
  • Database administrator
  • Attacker जिसने server access हासिल किया
  • Backup system (regular backups हैं तो "deleted" data backup में रह सकता है)
  • Court/government request (DPDP Act 2023 के तहत valid order पर data disclosure mandatory है)

दरअसल, modern storage में "delete" अक्सर "mark as overwritable" ही होता है। Physical overwrite तक data recoverable रहता है। SSD TRIM और magnetic residue दोनों data recovery paths हैं।

Model 2: Client-Side Encryption (Zero-Knowledge)

Highest security implementation — PrivNote, पहले वाला Firefox Send जैसे services:

  1. User browser में content type करता है
  2. Browser random AES-256 key generate करता है
  3. Same browser में content encrypt
  4. Encrypted ciphertext server पर upload
  5. Server ciphertext store करता है, key कभी नहीं देखता
  6. Key URL fragment में embed (# के बाद)

Example: https://example.com/view/abc123#encryption-key-here

Key cryptographic insight: URL fragment (# के बाद का content) server को transmit नहीं होता। यानी server हमेशा सिर्फ़ ciphertext देखता है, key कभी नहीं। यही Zero-Knowledge Architecture है।

Receiver link खोलता है:

  1. Browser server से ciphertext fetch करता है
  2. URL fragment से key extract
  3. Browser में decrypt
  4. Server ciphertext delete

Security analysis:

Server compromise हो भी जाए तो attacker को सिर्फ़ ciphertext मिलेगा, जो decryption key के बिना useless है। पर अभी भी कुछ threats हैं:

  • Browser extensions: Malicious extensions complete URL पढ़ सकते हैं (fragment समेत)
  • History: Full URL (key समेत) browser history में logged हो सकती है
  • Referrer leak: अगर page external resources include करता है, कुछ browsers URL fragment Referrer header में leak कर सकते हैं (modern browsers मे यह mostly fix है)
  • Supply chain attack: अगर encryption JS tampered हुआ, key चोरी attacker के server पर भेजी जा सकती है
  • Keyloggers: Public cyber cafes और shared computers (Indian context में यह real issue है — Tier-3 शहरों के रेलवे waiting area वाले internet points)

Model 3: Hybrid

Server-side control + client-side encryption दोनों combine:

  1. Client-side encrypt (Model 2 की तरह)
  2. Server-side access restriction (one-time Token + access password + expiry)
  3. Multi-factor auth (password देकर ciphertext fetch करना)
  4. Server delete after access, audit log (content नहीं, metadata)

Security और usability का best balance।

Threat Model — ये कौन से attacks रोक नहीं सकता

Implementation कोई भी हो, कुछ attacks ephemeral links से block नहीं होते:

Screenshots & Screen Recording

सबसे fundamental limit। Content जब receiver के screen पर render होगा, कोई चीज़ screenshot, camera photo, screen recording नहीं रोक सकती। कुछ services JavaScript से right-click या PrintScreen disable करते हैं, पर ये trivially bypassable है — सिर्फ़ non-technical users के लिए barrier।

India में ख़ास risk — WhatsApp forward culture। एक screenshot लेते ही family group, college group, office group में forward। Password या Aadhaar image share कर रहे हैं तो ephemeral link "screenshot protection" नहीं देता।

CDN and Proxy Cache

Ephemeral link का content CDN से serve हुआ तो edge nodes पर content cache हो सकता है। Origin ने delete कर दिया, पर CDN copy TTL तक रह सकती है।

Proper implementation: Cache-Control: no-store, no-cache, must-revalidate और CDN-Cache-Control: no-store set करना चाहिए।

Browser Cache

Browsers decrypted content को local disk पर cache कर सकते हैं। Images especially — image cache अक्सर page cache control से independent होता है। Incognito mode से कुछ हद तक protection।

Network Monitoring (MITM)

Pure Token mode + non-HTTPS connection पर कोई भी MITM (ISP, corporate firewall, malicious Wi-Fi hotspot — airport, café, railway station free Wi-Fi) plaintext देख लेगा।

India में corporate SSL Inspection common है — IT department HTTPS traffic decrypt/re-encrypt करता है compliance के नाम पर। Client-side encryption (Model 2) से यह protection बेहतर — TLS break भी हुआ तो ciphertext ही leak होगा।

Server Logs

Content delete के बाद भी access logs में URL, IP, timestamp, User-Agent रहते हैं। Pure Token mode में logs से "कौन-कहाँ-कब-क्या access किया" correlate हो सकता है।

Legal Orders (DPDP Act context)

भारत में DPDP Act 2023 के तहत Data Protection Board और lawful authority legitimate request पर data disclosure demand कर सकती हैं। Model 1 में server data देने के लिए बाध्य है। Model 2 में server सिर्फ़ ciphertext दे सकता है — cryptographically वो भी useless attacker के लिए।

Major Services की Security Comparison

Public technical docs और source code analysis के आधार पर, April 2026 तक:

Service Encryption mode Open source Key location Server plaintext? Password option Max content
PrivNote Client-side AES No URL fragment No (zero-knowledge) No Text only
1ty.me Server-side No Server Yes Optional Text only
Snappass (Pinterest) Server-side AES Yes URL path Yes (key passes server) Optional Text
hat.sh Client-side XChaCha20 Yes URL fragment No (zero-knowledge) No Files
OnionShare Client-side + Tor Yes Locally generated No Optional Files
Yopass Client-side OpenPGP Yes URL fragment No (zero-knowledge) No Text + Files

Open source ही security का reliable indicator है। Closed-source services claim कर सकते हैं "client-side encryption" पर user verify नहीं कर सकते। Open source में तो community implementation audit कर सकती है।

Indian use cases के लिए practical recommendations

Use case 1: HR को salary slip भेजनी है WhatsApp plaintext risky, email stored forever। Yopass या hat.sh से encrypted link, password अलग channel (SMS) से।

Use case 2: College में assignment share Low sensitivity — कोई भी पासवर्ड-प्रोटेक्टेड image host ठीक है।

Use case 3: Banking OTP accidentally screenshotted OTP-level sensitivity पर ephemeral link अदूरा है। Regenerate OTP right away।

Use case 4: PAN/Aadhaar copy किसी financial advisor को देनी है DPDP Act impact! Client-side encrypted service + separate password + verbal verification। Email/WhatsApp में plain image कभी नहीं।

Use case 5: Freelancer client को mockups भेज रहा है NDA protected work, revenue impact। Password-protected image host + client email से अलग SMS channel से password।

सही ढंग से ephemeral link use करने का तरीक़ा

जब fit है

  • One-time password/credential
  • Time-sensitive sensitive info
  • Chat history में permanent रहना नहीं चाहिए

जब नहीं है

  • Highly confidential business info (end-to-end encrypted communication better है)
  • Legal non-repudiation चाहिए वो situations (destruction के बाद evidence gone)
  • National security level data (offline transfer ज़रूरी)

Strongly recommended practices

  1. Client-side encrypted service को prefer करें — server content पढ़ नहीं सकता
  2. Open source को prefer करें — security claims verifiable
  3. Password protection add करें — link leak भी हुआ तो content safe
  4. Link और password अलग channels से भेजें — link email पर, password SMS/WhatsApp पर
  5. Corporate network पर SSL Inspection को ध्यान में रखें
  6. Public Wi-Fi पर ephemeral share avoid करें — VPN use करें ज़रूरी हो तो
  7. Screenshot protection पर भरोसा नहीं — content itself को desensitize करें (e.g., Aadhaar में number का partial masking)

lpic.cc का password protection — realistic positioning

Image sharing context में lpic.cc password protection feature देता है — upload time पर password set, सिर्फ़ correct password वाला देख सकता है।

ईमानदारी से disclose करना ज़रूरी है, lpic.cc का password protection server-side access control है (Model 1 की तरह), client-side zero-knowledge नहीं (Model 2)। इसका मतलब:

  • Server के पास original image data still रहता है
  • Password का role access control है, end-to-end encryption नहीं
  • "हर कोई link से नहीं देख पाए" जैसी daily privacy needs के लिए सुविधाजनक
  • Cryptographic guarantee चाहिए उस sensitivity पर dedicated tool use करें

अगर आपकी need normal image sharing में random forwarded access prevent करना है, तो lpic.cc का password protection practical और simple है। पर अगर military-grade security चाहिए तो dedicated end-to-end encryption tools use करें।

FAQ

Q1: Ephemeral link access के बाद data truly unrecoverable है?

Depends। Pure server-side mode में data backups, CDN cache, या unerased disk blocks में रह सकता है। Client-side encrypted mode में ciphertext delete नहीं भी हुआ, अगर key destroyed है (URL anywhere मौजूद नहीं) तो ciphertext cryptographically unrecoverable है। पर receiver के screen पर जो render हुआ वो हमेशा retrievable हो सकता है (screenshot/recording)।

Q2: Incognito mode security बढ़ाता है?

हाँ, कुछ हद तक। History, cookies, cache save नहीं होते — यानी key-containing URL local पर logged नहीं। पर network-level monitoring (ISP, corporate firewall) और screenshot protection नहीं देता। Cyber café पर extra care needed है।

Q3: "Self-destruct countdown" (30 sec auto-close) काम का है?

Security value limited। Browser-side JavaScript timer है, कोई भी screenshot पहले ले सकता है, DevTools से timer stop भी कर सकता है। Main value psychological है — receiver को "sensitive content" का reminder, technical protection नहीं।

Q4: Ephemeral link forwarding रोकता है?

नहीं। Receiver access से पहले link किसी और को forward करे तो वो access कर लेगा। Password protection थोड़ा risk कम करता है (link + password दोनों forward चाहिए), पर open करने के बाद screenshot + re-forward नहीं रोका जा सकता। India में WhatsApp forward culture के कारण यह practical threat है।

Q5: Corporate network पर OTP/password भेजने में ephemeral link safe है?

Plaintext से बहुत बेहतर, पर corporate SSL Inspection का ध्यान रखें। Client-side encrypted service (Yopass, hat.sh) optimal है — TLS inspected भी हुआ तो IT को ciphertext ही मिलेगा। Open source verification add करता है।

Q6: DPDP Act के तहत ephemeral link use करना compliant है?

हाँ, अगर आप ensure करते हैं कि (1) Personal data processing को justified purpose, (2) Retention period minimized (ephemeral naturally compliant), (3) Data subject consent documented। पर ephemeral link itself DPDP compliance नहीं देता — overall data handling process audit करना ज़रूरी है।

Q7: Public Wi-Fi (airport, railway station) पर ephemeral link safe है?

Direct HTTPS links पर reasonably safe, पर MITM risk हमेशा रहता है। Critical sensitivity पर VPN use करें या 4G/5G cellular पर switch करें। Pure Token model वाले services पर avoid।

संदर्भ सामग्री

#burn-after-read#ephemeral links#cryptography#data security#privacy
K

लेखक

Kevin Wu

सुरक्षा सलाहकार

गोपनीयता और डेटा सुरक्षा विशेषज्ञ