iOS 18 और macOS 15 में Apple Photos का रिमोट डेटा ट्रांसफर फीचर

 (lapcatsoftware.com)
2 पॉइंट द्वारा GN⁺ 2024-12-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • iOS 18 और macOS Sequoia के Photos में Enhanced Visual Search जोड़ा गया, और लेखक के iPhone और Mac पर यह डिफ़ॉल्ट रूप से चालू था
  • यह फीचर फोटो में मौजूद landmarks और points of interest को Apple सर्वर के global index से निजी तौर पर match करके search में मदद करता है
  • Apple बताता है कि homomorphic encryption, differential privacy और OHTTP relay के जरिए वह फोटो की जानकारी नहीं जान पाता, लेकिन server communication अपने आप में privacy debate का मुख्य मुद्दा बन गया है
  • आलोचना का फोकस Apple की दुर्भावना नहीं, बल्कि software bugs की संभावना है; इसके आधार के तौर पर Apple security release notes में vulnerabilities का लगातार आना बताया गया है
  • macOS पर Little Snitch से communication को कुछ हद तक रोका जा सकता है, लेकिन iOS पर ऐसा विकल्प नहीं है, इसलिए users के लिए खुद को बचाना मुश्किल है

Enhanced Visual Search का डिफ़ॉल्ट रूप से चालू होना

  • iPhone की Photos settings में Enhanced Visual Search नाम का नया item जोड़ा गया था और यह डिफ़ॉल्ट रूप से enabled था
  • यही setting macOS Sequoia के Photos में भी नई जोड़ी गई, और Mac पर भी डिफ़ॉल्ट रूप से चालू थी
  • लेखक ने screenshot लेने से पहले इस setting को manually disable किया था

Apple दस्तावेज़ में बताया गया काम करने का तरीका

  • Apple का Photos & Privacy दस्तावेज़ बताता है कि Enhanced Visual Search photos को landmarks या points of interest के आधार पर search करने देता है
  • device, photo में मौजूद जगहों को Apple server के global index से निजी तौर पर match करता है
  • Apple का कहना है कि privacy protection के लिए वह ये technologies इस्तेमाल करता है

    • Homomorphic encryption

    • Differential privacy

      • IP address छिपाने वाला OHTTP relay
      • Apple दस्तावेज़ के अनुसार यह setting iOS·iPadOS में Settings > Apps > Photos, और Mac में Photos > Settings > General से बंद की जा सकती है
      • Apple Machine Learning Research का Combining Machine Learning and Homomorphic Encryption in the Apple Ecosystem 24 अक्टूबर 2024 को प्रकाशित हुआ था, जबकि iOS 18 और macOS 15 की public release date 16 सितंबर 2024 थी

Privacy protection पर आलोचना

  • आलोचना की शुरुआत इस बात से होती है कि users ने मांगा नहीं था, फिर भी Apple ने device के अंदर के experience को server communication से बेहतर किया
  • लेखक के मानक के अनुसार, computation पूरी तरह device के अंदर ही खत्म हो तभी वह private है; अगर data manufacturer के server तक जाता है, तो उसे पूरी तरह private मानना मुश्किल है
  • लेखक ने कहा कि वह खुद यह सीधे evaluate नहीं कर सकते कि Apple का implementation तकनीकी रूप से सुरक्षित है या नहीं
  • हालांकि Apple के security release notes में vulnerabilities लगातार आती रहती हैं, इसलिए Apple के privacy claims पर ज्यों का त्यों भरोसा करना मुश्किल है
  • आलोचना यह है कि दुर्भावना या साज़िश न भी हो, सिर्फ software bugs से ही users vulnerable हो सकते हैं, और Apple bug-free software की guarantee नहीं दे सकता

User choice और blocking tools

  • लेखक को Enhanced Visual Search में रुचि नहीं है, इसलिए उनके हिसाब से feature पूरी तरह सही काम करे तब भी risk लेने का कोई फायदा नहीं है
  • users की अनुमति के बिना feature चालू करना users और उनकी preferences का सम्मान न करने वाला व्यवहार बताया गया है
  • लेखक का कहना है कि Apple की advertising line “What happens on your iPhone, stays on your iPhone.” इस मामले से मेल नहीं खाती
  • macOS पर Little Snitch से Apple software के remote communication को काफी हद तक रोका जा सकता है
  • iOS पर Little Snitch जैसे tools की अनुमति नहीं है, इसलिए लेखक को लगता है कि Apple users को खुद की सुरक्षा करने से रोक रहा है

आगे की सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-29
Hacker News की राय

  • मेरी चाहत बहुत सरल है: ऐसा सॉफ़्टवेयर चाहिए जो स्पष्ट इरादे से पहले इंटरनेट पर कुछ भी न भेजे
    इस फीचर को विश्वसनीय रूप से निजी बनाने के लिए की गई engineering अच्छी है, और ऐसे फीचर को लागू करना अपने-आप में समस्या नहीं है, लेकिन यह अनिवार्य रूप से opt-in होना चाहिए
    जब तक सॉफ़्टवेयर अंतिम यूज़र और उनके डेटा, network connection जैसे संसाधनों को vendor के playground की तरह扱ेगा, भरोसा लगातार घटता रहेगा। local device data का wireless interface से बाहर अप्रत्याशित रूप से leak होना नहीं चाहिए, और local data को network पर भेजने वाले फीचर से यूज़र का इरादा अनिवार्य रूप से जुड़ा होना चाहिए
    Apple ने यूज़र से बस यह क्यों नहीं पूछा कि वे यह फीचर चालू करना चाहते हैं या नहीं—इसका cynic जवाब यह है कि Apple भी जानता है कि पूछने पर कुछ यूज़र तुरंत मना कर देंगे, लेकिन उसे लगता है कि वह उन यूज़र्स से बेहतर जानता है। मुझे यह रवैया पसंद नहीं है, और मुझे लगता है कि opt-out telemetry को लेकर बढ़ती नाराज़गी की वजह भी यही है

    • ऐसी सोच ने भयानक cookie banners पैदा किए
      ज़्यादातर यूज़र बिना सोचे “Allow” दबा देंगे—ऐसे dialog box और बढ़ा देने से समस्या हल नहीं होती
      समाज ने असल में तीसरे पक्षों को डेटा access देने को ठीक मान लिया है, और इसमें friction जोड़ना उन 2% लोगों के लिए 98% को सज़ा देने जैसा है जो वैसे भी ऐसी services इस्तेमाल नहीं करेंगे
      अगर जनता ज़्यादा शिक्षित होती तो संतुलन बदल सकता था, लेकिन वास्तविकता ऐसी नहीं है, और अच्छा user experience वास्तविकता को प्रतिबिंबित करना चाहिए
    • opt-in काम नहीं करता, और शुरू से कभी काम किया भी नहीं
      भारी बहुमत—95% से अधिक—यूज़र यह नहीं समझते कि popup का मतलब क्या है, वे उसे पढ़ने में भी सक्षम नहीं लगते, और हमेशा accept करते हैं, हमेशा reject करते हैं, या जो button ज़्यादा prominent हो उसे दबा देते हैं
      अपने उन परिवारजनों को देखें जो tech industry या professional managerial class में नहीं हैं, और उनसे पूछें कि उन्होंने अभी जो popup बंद किया वह क्या था और क्यों बंद किया—technology और privacy के interaction के बारे में आपको सबसे अच्छी सीख मिलेगी
    • iOS Photos में बहुत पहले से फोटो को उस address के आधार पर search किया जा सकता था जहाँ फोटो ली गई थी
      इसके लिए फोटो location के latitude/longitude को लेकर उसे मनुष्यों को समझ आने वाले address में बदलने वाली reverse geocoding lookup की ज़रूरत होती है, और यह लगभग हमेशा global reverse geocoding service से query करने के तरीके से होता है
      जिज्ञासा है कि क्या आप इस फीचर को भी privacy का उल्लंघन मानते हैं और opt-in की ज़रूरत समझते हैं। अगर नहीं, तो मुझे समझ नहीं आता कि reverse geocoding service, landmark lookup service से ज़्यादा private क्यों है
    • नतीजा https://chromewebstore.google.com/detail/i-still-dont-care-a... जैसा होता है
      व्यक्तिगत रूप से मुझे विश्वास नहीं कि ऐसे popup कोई उद्देश्य पूरा करते हैं। आखिरकार, यह तर्कसंगत रूप से साबित नहीं किया जा सकता कि website नेकनीयती से व्यवहार कर रही है। कोई app server से contact कर सकता है या नहीं, यह पूछने पर “No” दबाने से वास्तविक tracking रुक जाएगी—इसकी कोई guarantee नहीं
      यह देखकर मुझे लगातार आश्चर्य होता है कि लोग खुद को समझा लेते हैं कि बड़े पैमाने पर privacy, yes/no buttons के अलग-अलग combinations से काम करेगी। software पर भरोसा करने के सिर्फ दो तरीके हैं: 1. भोलेपन से यह देखना कि कहीं “privacy first” लिखा है या नहीं 2. यह समझना कि चल रहा software कौन-कौन से commands execute कर सकता है
      permission popup में granularity भी कम होती है। contacts list access की अनुमति देते समय वास्तव में कौन-से contacts access होते हैं? क्या सिर्फ names की अनुमति देकर phone numbers रोक सकते हैं? processing offline है या online? अगर online है, तो क्या internet access popup भी फिर से दिखाना चाहिए? फिर क्या किस तरह की internet activity हो रही है, उसे भी filter कर पाना चाहिए? इस रास्ते पर नीचे जाते-जाते अंततः हम Turing-complete permission system तक पहुँचते हैं, और अगर ऐसा न हो तो “privacy” में छेद रह जाते हैं
    • opt-in होने पर भी vendor यूज़र को तब तक परेशान करेगा जब तक किसी असावधान पल में वह “Yes” न दबा दे
      मुझे निश्चित रूप से याद है कि मैंने ऐसे boxes देखे हैं जो मैंने check नहीं किए थे, फिर भी checked थे। मैं इन्हें बंद करके फिर कभी चालू न होने देना चाहता हूँ, लेकिन vendor इसकी अनुमति नहीं देगा। इसलिए मैं Linux इस्तेमाल करता हूँ

  • मेरे मुफ़्त open source ऐप के users यह जानकर शायद हैरान होते हैं कि हमारे पास usage patterns के बारे में बिल्कुल कोई insight नहीं है
    थोड़ी-सी anonymous telemetry बेहद मददगार हो सकती है, लेकिन इसे छूने का इरादा नहीं है
    Opt-in न सिर्फ़ data की मात्रा बहुत घटा देता है, बल्कि चुने गए data में बड़ा bias भी डाल देता है, जिससे data बेकार हो जाता है। Opt-in करने वाले लोग शायद “typical user” का अच्छा sample नहीं होंगे
    Opt-out, चाहे कोई भी safeguards या guarantees दिए जाएँ, कुछ users के लिए स्वीकार्य नहीं होगा, और वे इसे बहुत स्पष्ट रूप से बताएँगे
    मैं समझता हूँ कि malicious actors के लिए telemetry का दुरुपयोग करना आसान है, और “anonymous data” आश्चर्यजनक रूप से कई तरीकों से बिल्कुल anonymous नहीं रह सकता। फिर भी ऐसा अफ़सोस होता है कि “इसीलिए हम अच्छी चीज़ें नहीं पा सकते”

    • याद नहीं कि पहले कहाँ देखा था, लेकिन एक site थी जो client side पर analytics data को circular buffer जैसी जगह में इकट्ठा करती थी, और settings menu से उसे एक बार भेजने, हमेशा भेजने, या खुद download करने का option देती थी
      error आने पर troubleshooting में मदद के लिए analytics data share करने का अनुरोध करने वाला toast दिखता था, और ज़ाहिर है, मना किया जा सकता था। शायद मैंने देखा हुआ सबसे अच्छा system था, लेकिन याद नहीं कि कौन-सी site थी
    • मूल बात यह है कि सब कुछ consent से जुड़ा है। Opt-out न हो तो consent बिल्कुल नहीं है, और अगर default opt-out हो तो consent की quality काफ़ी गिर जाती है। trust ही consent तक पहुँचने का साधन है
      1. trust बनाने के लिए opt-in, survey-style consent, और opt-out—इन तीन रास्तों की ज़रूरत है। survey, trust का active validator है और low-bandwidth communication में मदद करता है। user जब पहली बार इस्तेमाल करे, या यह feature जोड़े जाने के बाद अगली बार app start करे, तब पूछना चाहिए
      2. जो exact analytics जानकारी चाहिए, उसे end user को उपलब्ध कराना चाहिए ताकि user भी उसे parse कर सके। क्या share करने की अनुमति दी गई है, इसका खुद मूल्यांकन करने के लिए report या view देने से trust बेहतर होता है
      3. trusted permissions ज़्यादा consent की ओर ले जाती हैं। opt-in करने वाले users को features और bugs पर priority support के हिसाब से भी रखा जा सकता है। analytics history और performance जानकारी अभी-अभी report किए गए bug को हल करने में मदद कर सकती है
        Apple, Microsoft, Google आदि analytics sharing को details के बिना अस्पष्ट रखते हैं, और यह भी साफ़ नहीं करते कि उसका उपयोग और दुरुपयोग कैसे हो सकता है। अधिकांश तो opt-out भी नहीं देते। मैं ऐसे organizations पर trust नहीं करता, लेकिन ज़िंदगी में उनसे पाला पड़ता है। Facebook या Twitter का इस्तेमाल न भी किया जा सकता है, और मैं सच में नहीं करता। Steam survey मुझे स्वीकार है
        open source community को फ़ायदा देने वाली analytics जानकारी की कमी को दूर करने के लिए सहमति से बना analytics standard RFC एक कदम हो सकता है। यह ऐसा तरीका है जिसमें दोनों पक्ष agreed communication पर consent देते हैं
        मेरे नज़रिए से metadata भी personal data है। users न हों तो data भी नहीं होगा और metadata भी नहीं। end user ही metadata की entropy है, इसलिए metadata और data का मालिक user है
    • क्या ऐसा संभव नहीं होगा कि statistics collection device पर ही हो, और हर कुछ महीनों में statistics दिखाने वाला popup आए
      इससे कौन-सा bias जुड़ता है, यह मुझे ठीक से नहीं पता
      उदाहरण के लिए, “हमने यह app बनाया है और privacy को अहम मानते हैं। पिछले एक महीने के usage के दौरान इकट्ठा की गई जानकारी यह है। क्या app को बेहतर बनाने के लिए यह जानकारी हमें भेज सकते हैं?” पूछे, और collected data को human-readable रूप में दिखाए
    • यह self-evident नहीं है कि opt-in data को बेकार क्यों बना देता है। यह इस बात से भी जुड़ा हो सकता है कि opt-in को कैसे present किया जाता है
      सामान्य तौर पर मैं इसे एक practical solution मानता हूँ। भले ही opt-in group “typical user” से अलग हो, यह ईमानदार और ethical तरीके से मिल सकने वाला सबसे अच्छा data है। बिल्कुल data न होने से तो यह निश्चित रूप से बेहतर होना चाहिए, है न
      opt-in cookie consent banner दिखाने वाली सभी websites और apps में यह स्थिति पहले से ही implicitly लागू है
    • लोगों के मुख्यतः web पर बनाने के प्रमुख कारणों में से एक यही है
      desktop software को improve करना बहुत मुश्किल है, और खासकर Linux users उन patterns के प्रति विरोधी होते हैं जो improvement को संभव बनाते हैं

  • 100% पूरी तरह सहमत:
    “Computing privacy की गारंटी देने का एकमात्र तरीका है कि data को device से बाहर न भेजा जाए”
    “Privacy breach का कितना जोखिम लेना है, यह हर user को खुद तय करना चाहिए। [...] बिना पूछे ‘feature’ चालू करके Apple user और उसकी preferences का सम्मान नहीं करता। मैं कभी नहीं चाहता था कि मेरा iPhone Apple के servers से संपर्क करे।”
    Feature कितना भी obfuscated हो, “safe” हो, या अन्यथा “privacy-preserving” हो, इससे यह तथ्य नहीं बदलता कि निजी content से निकली कोई जानकारी पहले से सहमति लिए बिना transmit की जा रही है।
    जानकारी protected हो, तब भी हर network query अपने-आप में जानकारी है। किसी खास समय पर कोई खास action किया गया—इसका timestamp; जैसे नई photo जोड़ते ही अगर इस service को कुछ भेजा जाता है, तो photo लिए जाने का तथ्य, उस समय की location information से correlate किया गया कोई खास स्थान आदि उजागर हो सकते हैं, और यह तो बस हिमखंड का सिरा है। स्पष्ट सहमति के बिना user के device से जानकारी transmit करना privacy breach है।

    • तो क्या इसका मतलब है कि Signal messages भी transmit होते हैं इसलिए वे सुरक्षित नहीं हैं, और “obfuscation” data की रक्षा के लिए पर्याप्त नहीं है? जिज्ञासा है कि लेखक ने यह पढ़ा भी है या नहीं कि Apple कहता है कि transmit करने से पहले वह data के साथ वास्तव में क्या करता है—जिसे लेखक ने quote किया और बाद में माना कि वह समझ नहीं पाया।
      Metadata वाली दलील संभव लगती है, लेकिन उसमें भी कई assumptions हैं। खासकर यह assumption चाहिए कि Apple असल में OHTTP नहीं कर रहा और users ने कब photo ली, यह पता लगाने के लिए मिलीभगत कर रहा है। अगर आप मूलतः math पर भरोसा नहीं करते, तो uncertainty और शक कहां खत्म होंगे, समझ नहीं आता।
    • “मान लें कि नई photo जोड़ते ही, जैसे photo लेने पर, इस service को कुछ transmit हो जाता है” वाला premise गलत है, और उसी से conclusion पर छलांग लगाई गई है।
      यह आसानी से verify किया जा सकता है कि photo लेने के तुरंत बाद ऐसा नहीं होता। पहला, network traffic यह दिखा देगा, और असल में ऐसा नहीं है। दूसरा, homomorphic encryption महंगा है, इसलिए ऐसा किया ही नहीं जा सकता। Photos आमतौर पर तुरंत sync नहीं करता, और ज्यादातर iPhone users Photos app में sync timing बताने वाली चीज देखकर यह जानते हैं। महंगे tasks आम तौर पर तब तक queue में रहते हैं जब तक device power से जुड़ा और Wi‑Fi पर न हो।
    • दुनिया भर की सभी ज्ञात locations और common objects के models store करने के लिए कितनी storage चाहिए होगी?
      उदाहरण के लिए, मैंने bathtub में puppy की photo एक दोस्त को भेजी, तो उसके AirPods ने iPhone के जरिए बताया, “किसी ने bathtub में dog की photo भेजी है।” दोस्त ने भी इसे cool कहा और व्यक्तिगत रूप से मुझे भी यह useful feature लगता है। हालांकि, मुझे नहीं पता कि इसके लिए device के बाहर processing कितनी जरूरी होती है।
    • ये सारी समस्याएं Apple के उस blog post में address की गई हैं जिसमें इस feature के implementation की चर्चा है। Risk कम करने के लिए दो steps लागू किए गए हैं।
      1. iOS अतिरिक्त fake queries बनाता है, और सभी queries एक scheduler से गुजरती हैं ताकि lookup time के आधार पर real और fake queries में फर्क न किया जा सके या photo capture time की पहचान न हो सके।
      2. सभी queries third-party relay service का इस्तेमाल करके anonymously की जाती हैं। इसलिए Apple किसी particular query को किसी particular device या IP address से नहीं जोड़ सकता।
        इन दो mitigations को देखते हुए, इस feature से personal data पाने के लिए पहले target के phone को compromise करके fake queries बंद करनी होंगी, और फिर relay को compromise करके queries को किसी specific IP address से correlate करना होगा।
        अगर आप इतना सब कर सकते हैं, तो सच कहें तो ऐसी मेहनत बर्बाद करना मूर्खता होगी। क्योंकि iOS compromise का इस्तेमाल करके device से सीधे location data भेजवाया जा सकता है। Target के photo लेने का इंतजार करने, कई landmark lookups track करने, हर query से थोड़ा-थोड़ा extra data जमा करने और आखिर में target location identify करने जैसी झंझट की जरूरत नहीं।
        यह सब XKCD 538 की याद दिलाता है।
        https://machinelearning.apple.com/research/homomorphic-encry...

  • मुझे लगता है यह पिछली backlash के बाद CSAM scanning को धीरे-धीरे वापस लाने के लिए smoke screen है। Default-on behavior suspicious है।
    [1] https://www.wired.com/story/apple-photo-scanning-csam-commun...

    • बिल्कुल यही सोचा। ऐसा लगता है: “हमारे पास clever image fingerprinting tech है, लेकिन CSAM detection के लिए यह बहुत controversial था इसलिए launch नहीं कर पाए; तो core flow को किसी ऐसी चीज में डालते हैं जो users को useful लगे, ताकि code alive रहे, improve होता रहे और future expansion के लिए ready रहे।”
      ऐसी fingerprinting को सिर्फ public landmarks तक reliably सीमित किया जा सकता है या नहीं, यह interesting सवाल है, और यह unclear implementation details पर depend करता है।
      User-facing search भले ही ‘landmarks’ तक सीमित हो, क्या process device के अंदर ही सही, कई दूसरी चीजों के fingerprints पहले से बना रहा है? अगर ऐसा है, तो थोड़ी देर के लिए active होने वाला non-persistent malware भी रुचि की images तुरंत ढूंढ सकेगा—बिना उस व्यापक access और additional processing के, जिसकी सामान्यतः जरूरत पड़ती।
    • सही। यह harmless दिखने वाले “location matching” के बहाने server-contact element inject करने का तरीका है।
      Global index जाहिर है उन दूसरे markers से भी match करेगा जिन्हें Apple matching योग्य समझता है, भले ही उन्हें user को return न किया जाए।
    • यह बिल्कुल वैसा ही है जैसे Microsoft ने Recall से “पीछे हटने” का तरीका अपनाया था। फिर आखिर में उसे फिर से push कर दिया और undeletable बना दिया।
    • मेरा भी यही ख्याल है। वह tech इतनी expensive है कि शायद उन्हें test करने या चलाकर देखने की जरूरत थी ताकि prove कर सकें कि यह private है।
      मुझे लगता है photos में landmarks खोजने वाला model local पर भी run किया जा सकता है, लेकिन इस पर मुझे 100% certainty नहीं है।
    • नहीं। Apple में और चाहे जो flaws हों, मुझे ऐसा नहीं लगता।
      Cynical कारण दें तो इस scale का engineering feature बिना documents के plan नहीं किया जा सकता, और ऐसे documents court में जरूर सामने आएंगे।
      Surface-level कारण यह है कि Apple सचमुच server participation की जरूरत वाला useful feature देना चाहता है।

  • Apple ब्लॉग पोस्ट के ज़्यादातर तकनीकी विवरण न समझ पाने वाली बात पर: उद्धृत हिस्सा मुझे समझ आया, और माफ़ कीजिए, लेकिन यह लेख आशावादी भी हो सकता था—“देखो, यह शानदार नई तकनीक!” वाले अंदाज़ में।
    HN वाले अर्थ में हैकर-विरोधी Apple की प्रथाओं से मैं भी दूसरों जितनी ही नफ़रत करता हूँ, और इन्हीं वजहों से मेरे पास Apple डिवाइस भी नहीं हैं। लेकिन “उन्होंने privacy समस्या कैसे हल की, यह मायने नहीं रखता, मुझे यह private नहीं लगता” कहने से बात तथ्य नहीं बन जाती।
    उद्धृत शब्दों को ज़्यादातर दूसरे लोग भी नहीं समझते, और यह भी पक्का नहीं कि वे वहाँ तक पढ़े भी होंगे, इसलिए यह अनुचित आलोचना जैसी लगती है।

    • Homomorphic encryption के बारे में मैंने कुछ साल पहले research papers के ज़रिए सुना था।
      उस समय मेरी समझ के मुताबिक, SUM जैसी operations encrypted numbers की list का कुल जोड़ निकाल सकती थीं। encryption के तरीके की वजह से values को decrypt किए बिना सबको जोड़ा जा सकता था, और result भी encrypted रहता था, जिसे owner decrypt करके ज्ञात accuracy वाला number पा सकता था।
      अगर Apple homomorphic encryption का सही इस्तेमाल कर रहा है, तो Apple के पास phone से मिले data को देखने का कोई तरीका नहीं होना चाहिए। लेख में जिन बाकी चीज़ों का ज़िक्र है, वे metadata या side channels के ज़रिए information leak रोकने के उपाय हैं।
      यह feature default रूप से on होना बहुत अच्छा नहीं है। upgrade के बाद user से पूछा जाना चाहिए था कि वह इसे on करना चाहता है या नहीं।
    • मुख्य आलोचना यह है कि consent और warning के बिना private और sensitive data Apple को भेजा जाता है।
    • जिस चीज़ को आप समझते नहीं, उस पर भरोसा कैसे कर सकते हैं? आखिर भरोसा किसी ऐसे व्यक्ति या संस्था—यानी authority—से आना पड़ता है, जिस पर आप मानते हैं कि वह ऐसी समस्याओं को समझती है।
      कई लोगों के लिए वह authority Apple नहीं है। मैं Apple की privacy policy पर सावधानी से भरोसा करता हूँ, लेकिन बहुत से लोग Apple पर भरोसा नहीं करते, और इसकी वजहें हैं।
      इसलिए जब कोई Apple feature, जिसमें आपने opt in नहीं किया, personal data share करता है और Apple की technical explanation भी समझ में नहीं आती, तो privacy breach होने का एहसास बढ़ता है और इससे और ज़्यादा अविश्वास पैदा होता है। क्या फिर इसे अनुचित आलोचना कहा जा सकता है?
    • क्या आप खुद Apple device न रखते हुए भी ऐसे व्यक्ति की आलोचना कर रहे हैं जिसका stake है?
      मेरा blog post एक ऐसे Apple user के नज़रिए से लिखा गया है जिसका भरोसा तोड़ा गया। सुरक्षित दूरी से technology को cool समझना ठीक है और वह सच में cool हो भी सकती है, लेकिन इसका मुख्य मुद्दे—user consent की अनुपस्थिति—से कोई लेना-देना नहीं है।

  • मुझे यह कुल मिलाकर ऐसा reasonable feature लगता है जिसे user privacy का काफ़ी ध्यान रखकर implement किया गया है। हालांकि शायद मैं explanation पर बहुत भरोसा कर रहा हूँ।
    यह लेख कुल मिलाकर outrage bait जैसा दिखता है, और मुझे लगता है कि Hacker News पर आए ऐसे लेखों में “फँसने” से सावधान रहना चाहिए। यह वैसा ही है जैसे tabloids या Facebook पर outrage bait दिखने पर सावधान रहना पड़ता है।
    लेख या इस thread की कुछ चिंताओं का Apple के revenue पर बहुत असर पड़ने की संभावना कम लगती है। असल में कुछ customers की चिंता data usage हो सकती है, और मेरा अनुमान है कि Low Data Mode में यह feature शायद off रहता होगा।
    मुझे आश्चर्य है कि क्या इस तरह की समस्या privacy defaults जैसी setting से हल हो सकती है—ऐसा तरीका जिसमें journalists, activists, कुछ corporate IT departments, और मूल लेख जैसे लेख लिखने वाले लोग OS update के समय ऐसा विकल्प चुन सकें जिससे network से कम communication हो। समझने में आसान UI बनाना मुश्किल लगता है। iOS में पहले से “Lockdown Mode” है, लेकिन मुझे नहीं पता कि यह इस setting को प्रभावित करता है या नहीं।

    • Apple को सचमुच बस इतना करना था कि इसे default रूप से on न रखता। बिना पूछे network पर कुछ भेजना Apple पर भरोसा धीरे-धीरे और कम करता है।
    • यह reasonable feature है, लेकिन फिर भी user का opt-in चाहिए। परेशानी कम करने के लिए installation या upgrade के समय opt-ins को group करके पूछा जा सकता है।
    • खास तौर पर यह स्पष्ट नहीं है कि iOS phone के अंदर मौजूद सारा data scan करता है और public index के हिस्से के तौर पर भेजता है या नहीं।
      UI में feature जिस तरह काम करता दिखता है, उससे ऐसा नहीं लगता। अगर user की action से feature activate होता है, तो क्या इसे भी server contact माना जाना चाहिए, यह सोचने वाली बात है।
    • अगर कोई दूसरी company ऐसा करती, तो शायद इसे reasonable feature को reasonable तरीके से बनाने के रूप में देखा जा सकता था। समस्या यह है कि Apple ने यह advertise करने में करोड़ों से लेकर सैकड़ों करोड़ dollars खर्च किए हैं कि वह ऐसी चीज़ें नहीं करता।
      कहानी यह थी कि ऐसी चीज़ें उस अप्रिय दूसरे OS से अलग, जिसे advertising company चलाती है, iPhone के अंदर ही रहती हैं। Apple कभी data बाहर नहीं निकालता, आप product नहीं हैं, और Apple आपकी परवाह करता है।
      ऐसी घटना, अलग से देखें तो reasonable हो या न हो, उस narrative को पूरी तरह गिरा देती है। अगर वे विशाल billboards पर इतनी साफ़ झूठ बोलने को तैयार हैं, तो पता नहीं profit मांगने पर वे और क्या करेंगे।

  • मुझे लगता है कि मैंने अभी एक similar search-related setting देखी है, जो शायद iOS 18 से पहले नहीं थी।
    Settings -> Search में जाने पर “Help Apple Improve Search” option है और यह default रूप से on है।
    “Apple को Safari(!!), Siri, Spotlight में दर्ज की गई searches को ऐसे तरीके से store करने की अनुमति देकर Search सुधारने में मदद करें जो आपको उनसे link नहीं करता। Searches में general knowledge queries और music playback, directions जैसी requests शामिल हैं।”
    अगर यह पहले भी था, तो यह फिर से on हो गया है।

    • “Safari में दर्ज की गई searches को [...] ऐसे तरीके से store” करने वाली बात पर, 10 साल पहले की de-anonymization research से ही साफ़ था कि search history user को पूरी तरह expose कर देती है।
      यह भरोसा करने के लिए कि Apple का storage तरीका मेरी privacy को स्थिर रूप से protect करता है, मुझे बहुत सारे details चाहिए। बेशक, quote ऐसा दावा नहीं करता।
    • यह original post से भी ज़्यादा गंभीर है। Apple किस alternate universe में रहता है कि उसे लगता है लोगों की search history collection को बिना consent default बनाना ठीक है?
    • धत्, सही है। मेरे device पर भी यह default रूप से on था, और मुझे नहीं लगता कि मैंने कभी इसके लिए consent दिया होगा।
    • सही। यह भी default रूप से on की गई एक और setting है।

  • संदर्भ के लिए, macOS में photoanalysisd सर्विस background में चलती है और Apple Photos को एक बार भी खोले बिना photos को स्कैन करती रहती है
    इसे SIP, यानी System Integrity Protection, बंद किए बिना disable नहीं किया जा सकता, और ऐसा करने के लिए कई बार reboot करने और warnings पार करने वाली जटिल प्रक्रिया चाहिए। SIP को फिर से चालू करते ही यह फिर active हो जाता है
    किसी वजह से Apple, user चाहे या न चाहे, photo analysis को लेकर काफी उत्साही लगता है

    • यह जानकर आपको हैरानी हो सकती है कि Spotlight भी Mac की सभी files को स्कैन करता है
    • फिर भी वह Mac पर locally run नहीं होता क्या
    • सैद्धांतिक रूप से CSAM पहले से ही किसी local service का हिस्सा हो सकता है। जिस क्षण device से जुड़ा account जरूरी हो गया, privacy खत्म हो गई। सिर्फ iCloud नहीं, बल्कि device से ही जुड़ा account। Linux computer इस्तेमाल करने के लिए account जरूरी नहीं होता
    • क्या यह server से contact करता है? मेरी files scan होना मुझे समस्या नहीं लगता। मुझे चिंता इस बात की है कि मेरे private data की details device से बाहर जा रही हैं
    • “किसी वजह से Apple, user चाहे या न चाहे, photo analysis को लेकर काफी उत्साही लगता है” वाली बात end users द्वारा खराब किए जाने पर vulnerable नहीं होगी क्या
      अगर हर कोई अपनी photos से train किया हुआ local image generator चलाए, उसे थोड़ा बिगाड़ दे, और फिर Apple के photo hash collection को कचरे से भर दे तो क्या होगा
      उसके बाद क्या?
      यह बहुत अच्छा cleansing effect होगा। कौन कितना नाराज होता है, यह देखकर बहुत कुछ पता चलेगा

  • यह मामला COVID के दौर में Apple और Google के privacy-preserving Exposure Notification System पर हुए गुस्से की याद दिलाता है
    बिना tracking किए exposure की सूचना दी जा सकती है, यह बात intuitive नहीं लगती, लेकिन technology ने सच में यह संभव किया था
    यहां भी लेखक client-side vectorization, differential privacy, OHTTP relay, homomorphic encryption जैसी technologies के असर का ठीक से आकलन करने के बजाय privacy violation पर तुरंत प्रतिक्रिया पर निर्भर करता दिखता है
    हालांकि मैं 100% सहमत हूं कि ऐसी feature के लिए Apple को पहले user consent मांगना चाहिए

    • मैं इन technologies की privacy का मूल्यांकन करना चाहूंगा
      अगर कोई source code link दे दे, तो मैं internet पर किसी अनजान व्यक्ति की बात मानने के बजाय देख सकता हूं कि यह ठीक-ठीक क्या करता है
      और बेहतर तो यह होगा कि मुझे इसे खुद compile करने दिया जाए
    • वह COVID feature opt-in था। अभी लेखक इसी बात की शिकायत कर रहा है कि opt-in नहीं है

  • “Apple blog post की technical details का ज्यादातर हिस्सा समझ नहीं आता” वाली बात पर, मैं समझता हूं
    Client-side vectorization: photo को locally process करके भेजने से पहले ऐसा vector representation तैयार किया जाता है जिसे reverse नहीं किया जा सकता। इसे meaning-based hash जैसा समझ सकते हैं
    Differential privacy: भेजने से पहले vector में काफी noise जोड़ा जाता है। इतना कि vector reverse-lookup करना संभव न हो। यहां noise level ε = 0.8 है, जो privacy के लिहाज से काफी अच्छा है
    OHTTP relay: data किसी third party के जरिए भेजा जाता है, इसलिए Apple को IP address पता नहीं चलता। content encrypted होता है, इसलिए third party भी कुछ नहीं सीख पाती। “IP X Apple Photos user है” इतना expose होने का जोखिम है, लेकिन library का content नहीं पता चल सकता
    Homomorphic encryption: lookup operation encrypted data पर server में किया जाता है। Apple vector content या response content को decrypt नहीं कर सकता, और सिर्फ client ही lookup result को decrypt कर सकता है
    अच्छी privacy design ऐसी ही दिखती है। इसमें privacy protection की कई layers हैं, और पीछे की तीन में से कोई एक भी privacy protection के लिए काफी होनी चाहिए
    “privacy violation risk के लिए अपनी tolerance level individual user को तय करनी चाहिए” वाली दलील पर, लेखक Apple security researcher जैसा दिखता है, फिर भी वह यहां कह रहा है कि वह informed choice नहीं कर सकता
    सही फैसला क्या है, यह पक्का नहीं है। लेकिन “इसलिए computing privacy की guarantee देने का एकमात्र तरीका data को device से बाहर न भेजना है” वाला निष्कर्ष सच नहीं है। service इस्तेमाल करते हुए भी privacy देने वाले tools हैं, जैसे differential privacy और homomorphic encryption। ये बहुत जटिल हैं और user realistically risk का मूल्यांकन नहीं कर सकता, लेकिन अगर आप ऐसी features चाहते हैं जिन्हें disk से बड़े dataset या frequently changing content की जरूरत है, तो ये tools जरूरी हैं

    • explanation के लिए धन्यवाद, लेकिन लगता है आपने core issue को address नहीं किया। बात यह है कि मेरा data default रूप से, बिना reasonable notice के device से बाहर भेजा जा रहा है
      कई users ऐसी feature से सहमत हो सकते हैं। जैसा कहा, यह बहुत सुरक्षित भी हो सकती है। लेकिन समस्या यह है कि सबको default रूप से consent देने वाला माना जा रहा है
    • “अच्छी privacy design” यह है कि मेरी photos explicit opt-in permission के बिना किसी भी रूप में कहीं भी न भेजी जाएं
    • आप “perfect user understanding” और “user choice नहीं” के बीच false dichotomy पेश कर रहे हैं। मुद्दा यह नहीं है कि user homomorphic encryption या differential privacy को पूरी तरह समझ सकता है या नहीं, बल्कि basic consent और transparency है
      user को “यह feature बेहतर search के लिए आपकी photos के बारे में data Apple servers पर भेजती है” समझने के लिए PhD की जरूरत नहीं है
      privacy protection जटिल है, यह user choice हटाने को justify नहीं करता। उस logic से तो किसी भी technical feature के लिए user से पूछना ही नहीं चाहिए
      बहुत से privacy-conscious users एक सरल सिद्धांत मानते हैं: protection method चाहे जो हो, वे control करना चाहते हैं कि device से बाहर क्या जाता है
      “समझाना बहुत complex है” वाली दलील किसी भी privacy-invasive default को justify कर सकती है। क्या GPS technology समझाना बहुत complex है, इसलिए location services default on रखी जा सकती हैं—इस logic पर भी आप वही standard लागू करेंगे
      असली समाधान सरल है। feature को आसान भाषा में समझाएं, benefits highlight करें, privacy protections का overview दें, और user को चुनने दें। Apple पहले से ही कई अन्य features में ऐसा करता है। default off और opt-in, नीचे की protections कितनी भी मजबूत हों, privacy-respecting design के core principles हैं
    • अच्छी privacy design असल में यह है कि कोई भी जानकारी किसी को भी, कहीं भी, कभी भी न भेजी जाए
    • लेखक Apple security researcher नहीं है
      Jeff Johnson Apple platforms के लिए apps, खासकर Safari extensions, develop करते हैं और Apple को लेकर अपनी असुविधाएं अक्सर blog पर लिखते हैं, लेकिन वे security researcher नहीं हैं