- Google Cloud Fraud Defense को 2026 में “reCAPTCHA का अगला evolution” बताकर पेश किया गया, लेकिन इसका मूल 2023 में वापस लिए गए Web Environment Integrity जैसी device attestation infrastructure में है
- Fraud Defense का QR challenge इस तरह काम करता है कि उपयोगकर्ता अपने फ़ोन से कोड स्कैन करता है, फिर Play Integrity API के ज़रिए डिवाइस को authenticate किया जाता है, और उसका नतीजा मूल साइट को वापस भेजा जाता है ताकि उसे इंसान की मौजूदगी के प्रमाण के रूप में इस्तेमाल किया जा सके
- पास होने योग्य hardware सिर्फ़ Google Play Services इंस्टॉल वाले हाल के Android डिवाइस या हाल के iPhone/iPad तक सीमित है, इसलिए GrapheneOS, LineageOS for microG, Firefox for Android जैसे विकल्प मूल रूप से बाहर रह जाते हैं
- QR challenge को कैमरा स्क्रीन के सामने रखकर bypass किया जा सकता है, और compatible Android डिवाइस लगभग $30 में खरीदे जा सकते हैं, इसलिए पेशेवर bot farm के लिए यह बड़ा अवरोध बनना मुश्किल है
- हर बार challenge सफल होने पर Google तक यह सिग्नल पहुँचता है कि “एक authenticated डिवाइस ने किसी खास समय पर किसी खास साइट को access किया”, जिससे session और browser के पार जाने वाली attribution information बन सकती है
Google Cloud Fraud Defense और WEI का संबंध
- मई 2026 में Google ने Google Cloud Fraud Defense को “reCAPTCHA का अगला evolution” बताकर पेश किया और ऐसा challenge दिखाया जिसमें उपयोगकर्ता अपने फ़ोन से QR code स्कैन करके इंसान होने का प्रमाण देता है
- 2023 में Google engineer Yoav Weiss ने Chromium project में Web Environment Integrity proposal जमा किया
- इसका ढाँचा ऐसा था जिसमें browser डिवाइस hardware से cryptographic proof पर sign करवाता, ताकि यह साबित किया जा सके कि browser बदला नहीं गया है और Google-certified hardware पर चल रहा है
- वेबसाइटें इस signature को verify करके तय कर सकती थीं कि content बिना friction के देना है या अतिरिक्त challenge माँगना है
- प्रस्ताव का घोषित उद्देश्य bot और automated scraping के ख़िलाफ़ web integrity की रक्षा करना था
- Mozilla ने कुछ ही दिनों में अपना आधिकारिक रुख जारी किया और कहा कि यह प्रस्ताव “users के हित के ख़िलाफ़” है तथा “OS और device vendor द्वारा नियंत्रित gate-type internet” बनाता है
- Electronic Frontier Foundation ने इसे “Chrome की web DRM योजना” कहा, और माना कि इसके design में Android या certified hardware पर चलने वाला Chrome ही आसानी से proof पास करेगा, जिससे traffic Google ecosystem की ओर धकेला जाएगा
- Google ने सार्वजनिक होने के 3 हफ़्ते बाद WEI वापस ले लिया और Chromium GitHub thread बंद हो गया, लेकिन 2026 के Fraud Defense में वही device attestation infrastructure एक commercial product की बुनियाद बनकर सामने आया
QR code challenge का वास्तविक तंत्र
- Fraud Defense challenge इस तरह काम करता है कि उपयोगकर्ता वेबसाइट पर QR code देखता है और उसे अपने फ़ोन के कैमरे से स्कैन करता है
- फ़ोन को Google के Play Integrity API के ज़रिए authenticate किया जाता है, जो यह जाँचता है कि डिवाइस certified hardware है
- इस verification का परिणाम मूल साइट को वापस भेजा जाता है और उसे इंसान की मौजूदगी के प्रमाण के रूप में इस्तेमाल किया जाता है
- Fraud Defense requirements page पास होने योग्य hardware को “Google Play Services इंस्टॉल वाले हाल के Android डिवाइस या हाल के iPhone/iPad” के रूप में परिभाषित करता है
- Google Play Services certified Android डिवाइसों पर चलने वाली Google की proprietary software layer है, जो Play Integrity API उपलब्ध कराती है ताकि यह साबित किया जा सके कि डिवाइस बदला नहीं गया है और Google द्वारा approved है
- जिन डिवाइसों में Play Services नहीं है, वे Fraud Defense द्वारा माँगी गई Play Integrity जाँच के स्तर को पूरा नहीं कर सकते, और यही शर्त Fraud Defense के मुख्य तंत्र के रूप में काम करती है
- WEI के मामले में standards review process के दौरान Google को इस mechanism का सार्वजनिक बचाव करना पड़ा था और विरोध के बाद उसे वापस लेना पड़ा, जबकि Fraud Defense सीधे एक commercial service के रूप में जारी हुआ जिसे Google Cloud billing account वाली संस्थाएँ इस्तेमाल कर सकती हैं
QR code bypass और phishing जोखिम
- QR code challenge को bot operator स्क्रीन के सामने कैमरा रखकर मशीन की तरह bypass कर सकते हैं
- जिन कार्यों में Play Integrity proof चाहिए, वहाँ भी compatible Android डिवाइस लगभग
$30 में खरीदे जा सकते हैं; उदाहरण के लिए Walmart का $29.88 Motorola Moto g 2025
- बड़ी संख्या में डिवाइस खरीदने वाले पेशेवर bot farm के लिए यह लागत संचालन को वास्तव में रोकने वाली नहीं, बल्कि लगभग एक fixed cost जैसी है
- HN thread में एक incident response विशेषज्ञ ने चिंता जताई कि व्यवहारिक रूप से “HR की Susan” को असली Google Captcha QR code और malicious phishing QR code में फ़र्क सिखाना मुश्किल है
- QR challenge उपयोगकर्ताओं को वेबसाइट access के लिए code स्कैन करने की आदत डालता है, और phishing campaign इसी व्यवहार का तुरंत दुरुपयोग कर सकते हैं
मौजूदा QR authentication और device attestation से अंतर
- iOS App Attestation यह verify करता है कि app App Store के ज़रिए इंस्टॉल किया गया था और उसमें कोई बदलाव नहीं किया गया
- iPhone उपयोगकर्ता द्वारा चुने गए बंद ecosystem के भीतर apps को manage करना और खुले web browsing में URL access को किसी private company द्वारा certified hardware पर शर्तों से बाँधना, दोनों की प्रकृति अलग है
- खुले internet पर इस तरह का लागूकरण पहले कभी नहीं हुआ; app store स्पष्ट terms वाले optional ecosystem हैं, जबकि web hardware conditions को आधार मानकर design नहीं किया गया था
- QR-आधारित authentication पहले से मौजूद है
- Estonia का Smart ID बैंकिंग portal, सरकारी सेवाओं और health records जैसे ऐसे resources पर QR code के ज़रिए user verification करता है जिनकी सीमा और consent scope पहले से तय होती है
- वहाँ उपयोगकर्ता authentication चुनता है, सुरक्षित resource पहले से परिभाषित होते हैं और scope स्पष्ट होता है
- Google Cloud Fraud Defense खुले web पर operator द्वारा gate बनाए गए किसी भी URL पर device attestation लागू कर सकता है
- इस तरीके में समान स्तर की consent structure या purpose limitation नहीं है, और उपयोगकर्ताओं के लिए यह समझना कठिन हो सकता है कि उनकी hardware identity access credential की तरह काम कर रही है
privacy-संवेदनशील उपयोगकर्ताओं का बहिष्कार
- Google Play Integrity proof के लिए Google Play Services ज़रूरी है
- GrapheneOS एक security-hardened Android fork है जिसमें default रूप से Play Services शामिल नहीं होते; EFF इसकी सिफ़ारिश करता है और पत्रकार, वकील तथा कार्यकर्ता इसे high-risk environments में इस्तेमाल करते हैं
- GrapheneOS कुछ Play Services functions चलाने के लिए sandboxed compatibility layer को support करता है, लेकिन यह Fraud Defense द्वारा माँगे गए
MEETS_DEVICE_INTEGRITY स्तर की Play Integrity आवश्यकताओं को पूरा नहीं कर सकता
- open source विकल्प चाहने वाले उपयोगकर्ताओं के लिए बनाई गई privacy-oriented Android distribution LineageOS for microG भी इसी कारण विफल होती है
- Play Services को छोड़ने वाले सभी custom ROM Fraud Defense की requirements पास नहीं कर सकते
- Firefox for Android, Google द्वारा स्पष्ट की गई Fraud Defense browser support list में दिखाई नहीं देता
- Firefox design के स्तर पर Google Play Integrity को integrate नहीं करता, और 2023 में device attestation के ख़िलाफ़ Mozilla का रुख स्पष्ट था, जो अब भी बना हुआ है
- नतीजतन प्रमुख mobile browser के बीच privacy को प्राथमिकता देने वाले Firefox उपयोगकर्ता bot होने की वजह से नहीं, बल्कि इसलिए default रूप से verified access से बाहर हो जाते हैं क्योंकि वे ऐसा software इस्तेमाल करते हैं जो Google की certification architecture में भाग लेने से इंकार करता है
“सामान्य” tracking की समस्या
- Fraud Defense challenge हर बार सफल होने पर Google तक यह सिग्नल पहुँचता है: “इस authenticated डिवाइस ने इस समय इस साइट को access किया”
- device attestation सिर्फ़ access रोकने या देने का काम नहीं करती, बल्कि attribution information भी पैदा करती है
- स्थिर hardware identity वाले डिवाइस session, browser और private browsing mode के पार जाने वाले persistent identifier बना सकते हैं
- जो कंपनी यह परिभाषित करती है कि कौन सा hardware “सामान्य” है, वही खुले web पर उस hardware की आवाजाही का लगातार रिकॉर्ड भी इकट्ठा कर सकती है
- यह fraud defense का कोई incidental side effect नहीं, बल्कि verification को certified device identity से बाँधने का एक structural decision है
विकल्प के रूप में सुझाया गया proof-of-work तरीका
- Private Captcha और इसी तरह के proof-of-work system ऐसे cryptographic challenge जारी करते हैं जिनमें computational effort की आवश्यकता होती है
- एक उपयोगकर्ता के लिए एक single challenge हल करने की लागत नगण्य होती है
- कई concurrent session चलाने वाले bot farm के लिए हर अतिरिक्त प्रयास के साथ computational cost बढ़ती जाती है
- GPU cycles खर्च करके काम करने वाले AI agent भी, उनकी inference क्षमता कितनी भी उन्नत हो, वही cost penalty झेलते हैं
- इस तरीके में hardware identifier transmit नहीं किए जाते, proof की मांग नहीं होती, और यह तय करने वाली कोई certification layer नहीं होती कि कौन भाग ले सकता है
- यहाँ user privacy वादे के रूप में नहीं, बल्कि संरचनात्मक रूप से सुरक्षित रहती है
1 टिप्पणियां
Hacker News प्रतिक्रियाएँ
यह काफी समय से अनुमानित था। कंप्यूटर CAPTCHA हल करने में इंसानों से बेहतर हैं, और इंसानों को पैसे देकर या मना कर botnet में शामिल किया जा सकता है, इसलिए IP allowlist भी काम नहीं करती
अब fingerprint tracking और behavior analysis बहुत ज़्यादा हैं, लेकिन सरकार उस दिशा को regulate कर रही है। YouTube में भी embedded videos पर ads के background playback से बड़े पैमाने की ad fraud समस्या रही है, तो साफ है कि detection पर्याप्त नहीं था
यह साबित करने के अच्छे तरीके बहुत कम हैं कि कोई bot नहीं है, और identity verification जैसी चीज़ें शामिल किए बिना तो और भी कम। यह opt-in तरीका कुछ समय तक ज़िम्मेदारी individual web stores पर डालने में मदद करेगा, लेकिन लंबी अवधि में open human-centered internet या तो गायब हो जाएगा या ऐसे proof-based verification के पीछे बंद हो जाएगा
Apple ने कुछ साल पहले Cloudflare के साथ Safari में remote attestation डाला था, और Google अब उससे एक कदम आगे जा रहा है। Apple का तरीका उन bots पर ज़्यादा असरदार नहीं है जो script automation tools की जगह browser को सचमुच manipulate करते हैं
अच्छी बात यह है कि अभी का तरीका मुख्यतः सिर्फ stores जैसी जगहों को target करता है, इसलिए किसी दूसरे store से खरीदकर इसे bypass किया जा सकता है। लेकिन अगर stores को पता चल जाए कि click farms में सिर्फ remote content पर tap करने वाले सैकड़ों phones मौजूद हैं, तो adoption सीमित भी रह सकता है
इसे पूरी तरह फैलने में कुछ साल लगेंगे, लेकिन जब तक AI अचानक व्यापक इस्तेमाल से बाहर नहीं हो जाता, अंततः इससे बचना मुश्किल लगता है
उस समय Google ने इसे OCR models सुधारने में इस्तेमाल किया, जो चतुराई भरा था और सच में हुआ भी, लेकिन आज के प्रमाणित “काम” से क्या उपयोगिता निकलती है, यह स्पष्ट नहीं है
यह भी जानना है कि क्या अगली payment से पहले उसे निकाल लेना negotiation का हिस्सा बन सकता है। एक दोस्त की तरफ़ से पूछ रहा हूँ जो गुज़ारे के लिए plasma बेचने से बचना चाहता है
“आप school में 40-petabyte Zip Bomb तो नहीं ले जाएंगे, है ना?” वाला meme डालने का मन है
web pages पर यह करना video games की तुलना में कहीं आसान लगता है
“Don’t be evil” से बदलकर यह दुनिया की सबसे बड़ी और सबसे invasive surveillance system बनाने वाली कंपनी बन गई है
यह पहले भी सच था, लेकिन यह घटना दिखाती है कि Google के लिए tracking कभी पर्याप्त नहीं होती। Google सबकी online activity को और ज़्यादा track करना चाहेगा, और हर संभव tool का इस्तेमाल करेगा
कंपनियों को अमूर्त अस्तित्व की तरह मत देखो, बल्कि ऐसे बीमार लोगों के समूह की तरह देखो जो ये फैसले लेते हैं
लगातार क्लिक किए गए HN के तीन links शायद सभी LLM-generated posts निकले। मुझे AI से अपने आप में समस्या नहीं है, लेकिन इंसानी सोच और अभिव्यक्ति को चुपचाप replace होते देखना थका चुका है
बल्कि जो साफ़ है, वह यह कि हमारे trust systems पहले ही टूट रहे हैं। commenters का एक-दूसरे को AI कहना भी उसी का उदाहरण है
चाहे AMP हो, Manifest V3 हो, Android source के साथ छेड़छाड़ हो, cookies को FLoC जैसी बकवास से बदलने की कोशिश हो, या यह मामला, Google open internet के लिए तेज़ी से एक दुष्ट ताकत बनता जा रहा है
इसका एहसास कुछ ऐसा था: “Google आपके लेख को अपने घटिया UI में ठूँसने का बहुत शौक़ीन है, सिर्फ इसलिए कि user का थोड़ा समय बच जाए”
एक तरफ़ आपको sites को अलग दिखाने के लिए जटिल design बनाने को कहा जाता है, और दूसरी तरफ़ आप ऐसी विशाल कंपनी के आगे झुक रहे होते हैं जो पूरे web design को छोड़कर content को pre-defined UI में बहाना चाहती है
इसके खत्म होने पर सच में राहत मिली। Google के कुल track record को देखते हुए, समझ जाना चाहिए था कि यह कुछ ही सालों में मर जाएगा
ऊपर वालों को खुश करना चाहने वाले Google managers की नई लहर जल्द ही इस नई योजना की रक्षा करने आ जाएगी
https://community.qbix.com/t/increasing-state-of-surveillanc...
ये ख़तरे design से या convergence के कारण एक-दूसरे से जुड़ते हैं। identity layers (1~5) बाकी सबके लिए precondition बनाती हैं, और जब SIM/account/device स्तर पर पहचान स्थापित हो जाती है, तो politically enabling surveillance exceptions पैदा होते हैं। शक्तिशाली users छूट पा जाते हैं और सामान्य users निगरानी में आ जाते हैं
device layers (10~12, 16~19) surveillance endpoints बनाती हैं। अगर encryption से पहले device पर content scan हो, तो communication layer की cryptographic protection अर्थहीन हो जाती है
communication layers (6~9) अब तक सबसे अच्छी तरह defend की गई हैं, और mass scanning को बार-बार रोका गया है। प्रतिरोध का record इसी layer में सबसे अच्छा है
reporting layer (13~15) अभी शुरुआती चरण में है। operating system से सरकार को सीधे report करने वाले hooks अभी बड़े पैमाने पर नहीं बने हैं, और UK का December 2025 proposal इसका frontier है
platform control (20~24) तय करता है कि alternatives मौजूद रह सकते हैं या नहीं। browser diversity, app distribution diversity, और engine diversity structural safeguards हैं, और तीनों ही सिमट रहे हैं
वह समाज जिसमें ये पाँचों layers पूरी हो जाएँ, वहाँ elite exceptions के साथ full-spectrum surveillance infrastructure बन जाएगा। हम लगभग 40% बिंदु पर पहुँच चुके हैं। यह infrastructure dystopia बनेगा या नहीं, यह technology नहीं बल्कि political choice पर निर्भर है
HN हैरान करने वाली हद तक इस कसते फंदे के प्रति सुस्त है, क्योंकि बहुत से लोग token से ज़रा भी जुड़ी decentralized distributed alternatives का ज़ोरदार विरोध करते हैं। शिकायत करना तो ठीक है, लेकिन groupthink के कारण decentralized alternatives को दबाना और downvote करना, privacy और freedom के क्षरण में कुछ हद तक सहभागी बनना है। भले ही आप किसी project से सहमत न हों, उसमें डाले गए काम को upvote करने की वजह तो हो सकती है। ऐसे काम के बिना हम लगभग खत्म हैं
Google सचमुच दशकों पहले से “Open Handset Alliance” जैसे cartels बना रहा था
Chrome और Search जैसी monopolies को control करके Google के पास यह लगभग पूर्ण शक्ति है कि websites कैसे render हों और कैसे discover की जाएँ
मैं ज़ोर देकर कहूँगा कि Chrome छोड़ दें। Google ने पूरी तरह सम्मान खो दिया है
यह छोटा कदम होगा, लेकिन Chrome के पहली बार आने की तरह दूसरे players के लिए मौके खोल सकता है
Mac पर मैं ज़्यादातर Safari इस्तेमाल करता हूँ, लेकिन Windows पर वह विकल्प नहीं है, बड़े players पसंद नहीं आते, और छोटे players पर भरोसा करना मुश्किल है
यहाँ तक कि “बड़े” छोटे players भी security के मामले में खास भरोसेमंद नहीं हैं। Arc browser की “Boosts” feature जैसी घटनाएँ रही हैं, जिन्होंने remote code execution संभव बना दिया
इसलिए आख़िरकार मैं Chrome पर वापस आ गया
Google जो भी करे, मुझे पसंद नहीं, लेकिन इस लेख में भी समस्या है
“Play Integrity proof चाहिए वाले operations के लिए spec-compliant Android devices अभी market price पर लगभग 30 dollars के हैं” वाला हिस्सा मानकर चलता है कि Google की logic कुछ
if(attestationResult == "success") allow()जैसी होगी। लेकिन यह मानना मुश्किल नहीं कि device type किसी fraud score में शामिल होगी। उदाहरण के लिए, महँगे devices का fraud score सस्ते devices से कम हो सकता है, और सस्ते devices की bulk खरीद को हतोत्साहित किया जा सकता है। किसी खास site पर device mix का analysis भी हो सकता है, इसलिए अगर हज़ारों Chinese phones अचानक Anne's Muffin Shop पर signup करें तो उन्हें ऊँचा fraud score मिलेगा“Firefox for Android Google की Fraud Defense browser support list में नहीं है” वाली बात भी पूरी नहीं लगती, क्योंकि browser को सिर्फ QR code दिखाना है, तो Firefox mobile हो तो phone के Google Play Services में deep link खोल सकता है या QR code दिखा सकता है
Proof-of-Work आधारित bot defense लगभग कभी जम नहीं पाया, क्योंकि JavaScript performance खराब है और इंसानी समय कंप्यूटर समय से महँगा है। attacker को फर्क नहीं पड़ता कि server 10 seconds Proof of Work puzzle सुलझने तक इंतज़ार करे, लेकिन इंसान को पड़ता है। Hetzner में 8-core server 10 cents प्रति घंटा है। भले मान लें कि सभी के पास 8-core desktop-class CPU है, तब भी 6-minute challenge attacker को 1 cent का पड़ेगा। दूसरी ओर आम इंसान अपने 6 मिनट के समय की क्या कीमत लगाएगा?
यह सच में घिनौना है, और इसे बिना सार्वजनिक चर्चा के चुपके से आगे बढ़ाना bad faith है। उम्मीद है पिछली बार की तरह यह भी रुक जाए। कम से कम antitrust issue तो साफ़ दिखता है
वास्तव में यह Google के लिए control लागू करने का एक और mechanism था
शायद यह बेवकूफ़ी भरा सवाल है, लेकिन मुझे समझ नहीं आता कि यह iPhone users के लिए कैसे काम करेगा। वहाँ Google Play नहीं है, और यहाँ तो Android/Google Play की ज़रूरत लगती है
वे market के इतने बड़े हिस्से को बाहर नहीं कर सकते
और विवरण यहाँ है: https://support.google.com/recaptcha/answer/16609652
अगर यह सिर्फ Google Play तक सीमित होता, तो यह कितना अस्वीकार्य है, यह और स्पष्ट दिखता; लेकिन जब इसे duopoly के हिसाब से बनाया जाता है, तो यह कम साफ़ दिखता है कि इससे कितने लोग बाहर हो जाते हैं और monopoly systems पर निर्भरता बनती है
बस इसके लिए संबंधित app install करनी पड़ती है, इसलिए यह और clunky होगा
यह लेख गलत मान्यताओं से भरा है
उदाहरण के लिए इसमें कहा गया है, “bot operators off-the-shelf hardware के साथ मामूली automation लगाते हैं जो camera को screen की ओर घुमाती है। Play Integrity proof चाहिए वाले operations में 30-dollar compatible Android devices लगते हैं”
bot farms 30-dollar phones से लंबे समय तक bypass नहीं कर पाएँगे। क्या सच में लगता है कि Google अगर एक ही hardware identifier दिन में हज़ारों बार दिखे तो उसे fraud use नहीं मानेगा?
मुझे यह अच्छा लगता है कि web को अंतहीन AI कचरे में बदलने से बचाने के लिए Google ने कोई वास्तविक proposal दिया है। इस लेख ने कोई बेहतर alternative नहीं दिया, और मैं ऐसा alternative देखना चाहूँगा
ऊपर से ऐसे लोग सच में मौजूद हैं जो पूरा दिन और पूरी रात phone scroll करते रहते हैं। वे बेरोज़गार हो सकते हैं, disabled हो सकते हैं, या insomnia या mania से जूझ रहे हो सकते हैं। इसलिए बड़ा backlash पैदा किए बिना इसे अच्छा signal मानना मुश्किल है। आप सच में असीम free time वाले परेशान लोगों का backlash नहीं चाहेंगे
ऐसा तरीका पूरी तरह धोखाधड़ी-जैसी tech है, और economics के लिहाज़ से यह abuse करने वालों के लिए इस attestation तरीके की तुलना में कम से कम चार orders of magnitude ज़्यादा अनुकूल हो सकता है
इस use case में carrier lock से फर्क नहीं पड़ता। EU में unique device identifiers store करना legal है या नहीं, यह नहीं पता
क्योंकि वे second-hand market से सबसे ख़राब devices खरीद सकते हैं
device attestation पर दाँव लगाना असल में इस बात पर दाँव लगाना है कि smartphones कम आम हो जाएँगे और ownership cost बढ़ेगी। ऐसा होता नहीं दिखता
मैं समझता हूँ कि Google यह क्यों करना चाहता है, और यह भी समझता हूँ कि लोग इस खास solution का विरोध क्यों कर रहे हैं
यह भी देखना चाहिए कि इस लेख का लेखक इस समस्या के लिए Proof of Work solution बेच रहा है
मुझे काफ़ी संदेह है कि Proof of Work यहाँ सही दिशा है। web users में बहुत से लोग पुराने hardware इस्तेमाल करते हैं। ऐसी दुनिया में जहाँ लोगों के पास उपलब्ध compute resources अलग-अलग हों, computational toll जोड़ने से समस्या हल नहीं होती
दूसरी ओर botnets के पास हज़ारों computers तक पहुँच हो सकती है और उन्हें 10 seconds extra इंतज़ार से फर्क भी न पड़े। और बदतर स्थिति में वे ASIC-आधारित custom solution बना सकते हैं जो किसी दादी के laptop से हज़ारों गुना तेज़ Proof of Work puzzles हल करे