1 पॉइंट द्वारा GN⁺ 18 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Sign in with Apple और iCloud+ Hide My Email aliases अब आगे से @private.icloud.com subdomain के तहत जारी किए जाएंगे
  • इस बदलाव से services के लिए iCloud के सामान्य mailbox को प्रभावित किए बिना सिर्फ relay aliases को block करना आसान हो जाएगा
  • पहले Apple के support और कुछ हद तक plausible deniability की वजह से iCloud aliases को block करने की लागत ज्यादा थी
  • कई services इन email addresses को वैसे ही स्वीकार न करें, जैसे वे मुफ्त temporary mailboxes को नहीं स्वीकार करतीं
  • iCloud+ और Hide My Email users के पास यह बदलाव लागू होने से पहले और @icloud.com aliases बनाने का समय है, और alias generation limit कम से कम 30 प्रति घंटा है

मुख्य बदलाव

  • Apple developer news में Sign in with Apple और iCloud+ Hide My Email का नया डोमेन की घोषणा पोस्ट की गई है
  • आगे से Sign in with Apple और Hide My Email aliases दोनों @private.icloud.com subdomain के तहत जारी किए जाएंगे
  • इस structure में iCloud Mail के non-relay mailbox को प्रभावित किए बिना सभी aliases को block करना आसान हो जाएगा

गोपनीयता और user impact

  • यह बदलाव iCloud privacy के लिए बड़ा झटका हो सकता है
    • पहले Apple के support और कुछ हद तक plausible deniability की वजह से iCloud aliases को block करने की लागत ज्यादा थी
    • नया subdomain aliases को ज्यादा साफ़ तौर पर अलग दिखाएगा, जिससे services के लिए इन्हें reject करना आसान हो जाएगा
  • कई services @private.icloud.com email को वैसे ही स्वीकार न करें, जैसे वे मुफ्त temporary mailboxes को reject करती हैं
  • यह राय सामने रखी गई है कि Apple को इस फैसले पर फिर से विचार करना चाहिए
  • iCloud+ और Hide My Email users के पास अभी और @icloud.com aliases बनाने का समय है, क्योंकि बदलाव अभी लागू नहीं हुआ है
    • alias generation rate limit कम से कम 30 प्रति घंटा है

1 टिप्पणियां

 
Hacker News की राय
  • अगर आप iCloud+ और Hide My Email इस्तेमाल करते हैं, तो बदलाव अभी तक लागू नहीं हुआ है और alias बनाने की सीमा भी कम से कम 30 प्रति घंटा है, इसलिए अभी भी कुछ और @icloud.com alias पहले से बनाकर रखे जा सकते हैं
    Hide My Email इस्तेमाल करने की एक वजह यह थी कि यह privacy को बिना झंझट आसान बना देता था, लेकिन values पहले से generate करके बाद में इस्तेमाल के लिए उनकी सूची बनाना काफ़ी झंझट वाला काम है

    • मेरे पास पहले से ही दर्जनों हैं, इसलिए शायद मैं उन्हें बार-बार इस्तेमाल करता रहूँगा, लेकिन हर site के लिए एक रखने से जब किसी Hide My Email address पर spam आना शुरू हो जाए तो यह पता चलना काफ़ी अच्छा है कि किस site से leak हुआ
    • अगर आप email forwarding किसी दूसरी company पर भरोसा करके छोड़ सकते हैं, तो वैसी ही service खुद सेट करना निश्चित रूप से कम झंझट वाला है
    • फिर भी एहतियात के तौर पर मैंने कुछ बना लिए हैं, और दूसरे hackers भी चाहें तो ऐसा ही कर सकते हैं
      iCloud+ महीने के 1 dollar में custom domain email, email alias, और 100GB end-to-end encrypted cloud drive देने वाली बेहतरीन service थी
      अगर इसे बिना किसी खास वजह के खराब किया जाता हुआ देखूँ, तो जाहिर है अफ़सोस होगा
    • अब मुझे एक script चाहिए जो अगले 10 सालों के लिए तारीख़-आधारित alias बना दे ताकि मैं रोज़ एक email इस्तेमाल कर सकूँ
  • अगर कोई site सिर्फ इसलिए मुझे block करती है कि मैंने privacy-friendly email इस्तेमाल किया, तो मैं उस site से कोई लेना-देना नहीं रखना चाहता

    • सही है, लेकिन दुर्भाग्य से यह ऐसा सिद्धांत नहीं है जिसे हर बार लागू किया जा सके
      कुछ समय पहले इटली में मुझे नगरपालिका को भुगतान वाली public parking इस्तेमाल करनी पड़ी थी, और 30 मिनट पैदल दूरी के भीतर कोई दूसरा parking lot, चाहे paid हो या free, नहीं था
      यह इटली government app नहीं थी, लेकिन मुझे partnered third-party app डाउनलोड करके sign up करना पड़ा, और ऐसी स्थिति में “मैं उस site या app से जुड़ना नहीं चाहता” कहने का मतलब था कि आप parking ही नहीं कर पाएँगे
    • अक्सर ऐसे मामले आते हैं जहाँ कोई ठीक-ठाक alternative नहीं होता और आपको किसी खास provider पर निर्भर होना ही पड़ता है
    • मैं अक्सर मज़ेदार लगने वाले domain खरीद लेता हूँ और उन पर आने वाले सारे mail अपने मुख्य email account पर forward कर देता हूँ
      Cloudflare पर इसे सेट करना बहुत आसान है, और एक साल बाद जब domain खत्म हो जाता है तो spam भी उसके साथ खत्म हो जाता है
    • एक MVNO mobile carrier के साथ मेरे साथ ऐसा हुआ था
      उन्हें personal email domains, जैसे कई .net और .org addresses, पसंद नहीं थे, इसलिए मैंने customer support से बार-बार कहा और आख़िर में उन्होंने manually जोड़ दिया
      एक बार जुड़ने के बाद marketing team मेरे personal domain पर खुशी-खुशी mail भेजने लगी। आगे चलकर यह समस्या बन सकती है, लेकिन वैसे भी अंतिम लक्ष्य phone को ही खत्म करना है
    • पूरी तरह सहमत। जिज्ञासा है कि क्या किसी ने सच में ऐसा होते देखा है
      Gmail का plus-sign alias वाला trick बहुत समय से व्यापक रूप से जाना जाता है, और मेरी जानकारी में आज भी ठीक काम करता है
      किसी website के लिए Gmail address में + को block करना या असली email निकाल लेना काफ़ी आसान होना चाहिए
  • Apple के बिना ऐसा ही कुछ करना हो तो कोई सस्ता domain खरीद या हासिल कर लें, एक subdomain बना लें, और उस subdomain पर आने वाले सारे mail receive करके forward कर दें
    उदाहरण के लिए, nytimes@mailsub.example.com -> jono@gmail, anything-else@mailsub.example.com -> jono@gmail की तरह इस्तेमाल किया जा सकता है, और वास्तव में alias पहले से बनाने की भी ज़रूरत नहीं पड़ती

    • समस्या तब होती है जब कोई आपके setup को समझ ले और {random}@domain.tld पर spam भेजना शुरू कर दे
      तब आपको बैठकर हर पहले से इस्तेमाल किए गए email address के लिए असली alias बनाना पड़ेगा और catch-all forwarding बंद करनी पड़ेगी
      और अपना domain इस्तेमाल करने से privacy कमज़ोर होती है, जिससे targeted fraud या phishing की संभावना बढ़ती है। targeted fraud वही प्रकार है जिसके लिए हम सबसे ज़्यादा vulnerable हैं
      मैं यह नहीं कह रहा कि यह तरीका बुरा है, मैं खुद भी इस्तेमाल करता हूँ, लेकिन मामला इतना simple नहीं है
      iCloud इस्तेमाल करने पर वह समस्या हल हो जाती है, लेकिन फिर account suspend हो जाने और उन emails तक पहुँच खो देने का risk आता है
      शायद सबसे अच्छा तरीका यह होगा कि दोस्तों के साथ मिलकर एक dedicated email domain लिया जाए और उसे SimpleLogin जैसी किसी service से जोड़ा जाए, लेकिन चीज़ें जल्दी ही complex हो जाती हैं
    • मैं भी ऐसा ही करता हूँ
      बस दिक्कत यह होती है कि जब आमने-सामने या phone पर किसी customer को बताना पड़े कि customer-facing email [their_business_name]@my_weird_domain.tld है, तो थोड़ा अजीब लगता है
      आमतौर पर लोग बस सिर हिला देते हैं
      एक और कमी यह है कि यह सिर्फ incoming forwarding है। अच्छा होता अगर बिना पूरा नया inbox और sent mailbox बनाए replies को भी proxy किया जा सकता
    • अगर forwarding mail server SRS support नहीं करता, तो Gmail SPF/DMARC alignment fail होने वाले messages को block कर देता है
    • SPF/DMARC/DKIM की वजह से अब यह कुल मिलाकर थोड़ा ज़्यादा complex हो गया है
      काफ़ी सारे mail transfer agents ऐसे messages भेजते ही नहीं जिनमें सारी settings सही न हों
    • मैं कई सालों से ऐसा कर रहा हूँ और यह ठीक काम करता है, साथ ही यह देखना मज़ेदार होता है कि कौन मेरा email बेच रहा है
      लेकिन records ज़रूर अच्छे से रखने चाहिए
      account recover करने की कोशिश करते समय अगर याद ही न रहे कि कौन-सा custom email इस्तेमाल किया था, तो सच में बड़ी परेशानी हो जाती है
  • संक्षेप में कहें तो अब Sign in with Apple और Hide My Email, दोनों के alias @private.icloud.com subdomain के तहत जारी होंगे
    ऐसा होने पर iCloud mail के सामान्य non-relay mailbox पर असर डाले बिना सभी alias को ban करना कहीं आसान हो जाएगा
    लेकिन अगर Sign in with Apple और Hide My Email एक ही domain पर हैं, तो bulk block करना और आसान क्यों हो जाएगा, उल्टा मुश्किल नहीं होना चाहिए, यह मुझे ठीक से समझ नहीं आता

    • पहले email me@icloud.com जैसे रूप में होता था, जो सभी Apple users के लिए default था
      सामान्य email और generated private email में फर्क करने का कोई तरीका नहीं था
      अब यह blah@private.icloud.com होगा, इसलिए services के बीच login linking को मुश्किल बनाने वाले generated private emails को आसानी से block किया जा सकता है
      Apple खुद अपने लिए ऐसा नुकसानदेह फैसला क्यों करेगा, यह स्पष्ट नहीं है। उम्मीद है Ternus privacy के खिलाफ दिशा में चीजों को align नहीं कर रहे होंगे
    • पहले इस service का उपयोग करने पर Apple (something)@icloud.com बनाता था
      अब (something)@private.icloud.com इस्तेमाल होगा, इसलिए इस service के जरिए default रूप से “छिपने” वाले लोगों को target करके पूरे subdomain को block करना तुरंत संभव हो जाएगा
      यह कुछ-कुछ anondaddy या simplelogin को block करने और protonmail को न block करने जैसा है
    • मेरा अंदाज़ा है कि पहले alias account और non-alias account दोनों ही @icloud.com इस्तेमाल करते थे
      जैसे Gmail account बनाते हैं, वैसे सामान्य iCloud email address reserve किया जा सकता था, इसलिए अगर पूरे iCloud address को ban किया जाता तो non-alias Apple customers भी साथ में block हो जाते
      हालांकि, जो जगहें alias block करना चाहती थीं, वे पहले से ऐसा नहीं कर पा रही थीं या नहीं, इस पर मुझे पूरा भरोसा नहीं है। Alias email दिखने में काफी unusual थे, इसलिए थोड़े false positives स्वीकार करके उन्हें पहले भी block किया जा सकता था
  • “बेकार” कहना कुछ ज़्यादा हो जाएगा
    private relay emails को block करने वाली sites तो वैसे भी मेरा disposable email स्वीकार करतीं
    Private relay का उपयोग उन sites के लिए है जिनसे updates लेना चाहते हैं, लेकिन बाद में उनके hack हो जाने की स्थिति में safety net भी चाहिए

    • सही है। कोई भी समझदार company इस subdomain के emails को ban नहीं करेगी
  • दूसरी ओर, जो जगह private.icloud.com को block करेगी, वह Apple से SSO करने की क्षमता भी block कर देगी, यानी खुद को Apple ecosystem से काट लेगी

    • ज़रूरी नहीं
      सिर्फ Apple SSO इस्तेमाल करते समय private.icloud.com को allow किया जा सकता है
      Apple SSO के बिना account बनाते समय private.icloud.com email address को allow न करने का तरीका अपनाया जा सकता है
  • जिस site में इच्छा हो, वह यह पहले से आसानी से कर सकती थी। बस इस्तेमाल होने वाला pattern पहचानना होता
    फिर भी मैं मानता हूँ कि यह बेकार बदलाव है
    उदाहरण के लिए heave_balks_0g@icloud.com जैसे रूप
    Sign in with Apple पर इसका खास असर नहीं होना चाहिए, क्योंकि sites पहले से ही उस feature को explicitly support कर रही हैं
    Email alias मुश्किल मामला है। आप user crowd में घुल-मिलकर privacy बचाना चाहते हैं, लेकिन तब आप उस ecosystem से बंध जाते हैं; और अगर अपने control वाले domain का उपयोग करें तो lock-in नहीं होता, लेकिन भीड़ में गुम anonymity भी नहीं मिलती

    • सभी generated alias ऐसे नहीं दिखते; कुछ viods01crew@icloud.com या methyl.brick1h@icloud.com जैसे भी होते हैं
      वैसे भी, कुछ services alias ban करती हैं, यह बात इसे बेहतर बनाने के बजाय पूरी तरह बेकार कर देने की वजह नहीं होनी चाहिए
      Apple उन गिनी-चुनी companies में से है जो market share के दम पर इस समस्या को push back कर सकती हैं
    • जिन sites में इच्छा है, वे पहले से वास्तव में ऐसा कर रही हैं
      अभी वे किस तरीके से पहचानती हैं, यह मुझे नहीं पता
  • मैं लगभग हर जगह Proton alias इस्तेमाल करता हूँ
    बेशक हर जगह नहीं, क्योंकि काफी जगहें passmail.net address स्वीकार नहीं करतीं
    इसलिए यह सोचना पूरी तरह संभव है कि कम से कम कुछ sites पर यह feature बेकार हो सकता है
    वैसे मैं ऐसे alias सिर्फ उन्हीं sites पर इस्तेमाल करता हूँ जिनका login खो जाए तो फर्क न पड़े। नहीं तो यह सबसे खराब lock-in बन जाएगा
    अच्छा होता अगर मैं अपने secondary domain पर alias चुन पाता। तब कम से कम wildcard या exported list के जरिए migrate तो किया जा सकता था

    • आप अपने domain पर custom alias बना सकते हैं
      मैं अपने सभी logins के लिए ऐसा ही करता हूँ, और पुराने emails को भी custom domain alias पर migrate कर रहा हूँ
  • मेरे ज़्यादातर iCloud relay address पहले से ही @privaterelay.appleid.com हैं, और वे पूरी तरह ठीक काम करते आए हैं
    इसलिए अभी कुछ समय तक इसके बदलने की संभावना नहीं लगती

    • वह domain सिर्फ Sign in with Apple के लिए इस्तेमाल होता है
  • निजी तौर पर Hide My Email, iMessage से भी ज़्यादा मुझे Apple ecosystem में बांधे रखता है। हालांकि मैं यूरोप का user हूँ

    • क्या सच में? मैं तो Apple ecosystem integration के बिना भी Hide My Email मुख्य रूप से इस्तेमाल करता हूँ
      icloud.com पर नया email बनाता हूँ, उसे login form में copy-paste करता हूँ, फिर 1Password में save कर लेता हूँ
    • यह अस्थिर व्यवस्था है
      या तो जीवनभर iCloud customer बने रहो, या फिर सैकड़ों login टूट सकते हैं