FTC पर सॉफ़्टवेयर अपडेट या paywall के ज़रिए हार्डवेयर खराब करने वाली कंपनियों पर कार्रवाई का दबाव

 (techdirt.com)
1 पॉइंट द्वारा GN⁺ 2024-09-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उपभोक्ता समूहों, कार्यकर्ताओं और सांसदों के गठबंधन ने FTC से smart device manufacturers द्वारा खरीद के बाद फीचर घटाने, सपोर्ट बंद करने और subscription में धकेलने जैसी प्रथाओं पर कार्रवाई करने की मांग की है
  • मुख्य मुद्दे हैं firmware updates के ज़रिए बाद में हार्डवेयर को बेकार या कम उपयोगी बना देना यानी “software tethering”, और अहम फीचर्स को अचानक paywall के पीछे डाल देना
  • Consumer Reports, iFixit, US PIRG समेत 17 संगठनों के पत्र में Peloton की सेकंड-हैंड bike पर 95 डॉलर fee और SNOO के लोकप्रिय फीचर्स को paywall के पीछे डालने के उदाहरण दिए गए हैं
  • connected devices खरीदने के बाद भी निर्माता की नीतियों और server support पर निर्भर रहते हैं, जिससे उपभोक्ता बिना स्पष्ट सूचना के उन फीचर्स को खो सकते हैं जिनके लिए वे पहले ही भुगतान कर चुके हैं
  • FTC ने पहले Google Revolv shutdown की जांच की थी, लेकिन उससे कोई ठोस कार्रवाई नहीं हुई; smart hardware के लिए अधिक स्पष्ट guidelines और warnings की ज़रूरत बताई जा रही है

क्या खरीदा हुआ डिवाइस आगे भी वही प्रोडक्ट रहेगा?

  • smart home hardware तब पूरी तरह बेकार हो सकता है जब निर्माता बंद हो जाए या support खत्म कर दे
  • खरीद के बाद firmware updates डिवाइस के फीचर्स घटा सकते हैं, जिससे यह भरोसा करना मुश्किल हो जाता है कि आज खरीदा गया प्रोडक्ट कल भी उसी तरह काम करेगा

FTC से कार्रवाई की मांग करने वाला गठबंधन

  • उपभोक्ता समूहों, कार्यकर्ताओं और सांसदों के गठबंधन ने FTC पर smart device manufacturers की anti-consumer प्रथाओं को निशाना बनाने का दबाव डाला है
  • मांग उन निर्माताओं पर कार्रवाई की है जो अचानक product support बंद कर देते हैं, फीचर्स हटा देते हैं, या मौजूदा फीचर्स को नई subscription paywall के पीछे छिपा देते हैं
  • यह पत्र FTC के प्रमुख अधिकारियों को भेजा गया था, और इसमें Consumer Reports, iFixit, US PIRG सहित 17 संगठन शामिल थे

“software tethering” और subscription paywall

  • पत्र में “software tethering” को ऐसी प्रथा बताया गया है जो बाद में हार्डवेयर को बेकार या कम उपयोगी बना देती है
  • मुख्य फीचर्स को अचानक subscription के पीछे लॉक कर देना भी इसी समस्या का हिस्सा बताया गया है
  • दोनों प्रथाएँ डिवाइस की software dependency का फायदा उठाती हैं, जिससे उपभोक्ताओं के लिए खरीदे गए प्रोडक्ट पर पूरा मालिकाना महसूस करना मुश्किल हो जाता है
  • स्पष्ट guidelines और enforcement की कमी से ऐसा ecosystem मजबूत हो सकता है जिसमें उपभोक्ता connected products की उम्र पर भरोसा न कर सकें

पत्र में दिए गए हालिया उदाहरण

  • Peloton ने सेकंड-हैंड bike मालिकों से 95 डॉलर fee लेने का फैसला किया, और इस कदम की बिना स्पष्ट कारण के होने पर आलोचना हुई
  • smart baby bassinet SNOO ने अपने कई लोकप्रिय फीचर्स को paywall के पीछे रखने का फैसला किया
  • ये उदाहरण दिखाते हैं कि उपभोक्ताओं द्वारा महंगे दाम पर खरीदे गए डिवाइस बाद में फीचर्स खो सकते हैं या कम उपयोगी हो सकते हैं
  • कई बार ये बदलाव end users तक स्पष्ट रूप से पहुंचाए भी नहीं जाते

FTC की पिछली प्रतिक्रिया और सीमाएँ

  • FTC ने Google के Revolv smart home hardware को बेकार बना देने वाले फैसले की जांच की थी, लेकिन उससे कोई ठोस कार्रवाई या सार्थक consumer reform नहीं निकला
  • FTC लगातार दबाव में है और उसके पास budget तथा staff की कमी है
  • agency को व्यापक monopolization और privacy violations जैसे अधिक तात्कालिक मुद्दों से निपटने में भी कठिनाई होती है
  • फिर भी cloud computing के दौर में smart hardware के क्षेत्र में federal स्तर की guidelines और कुछ warnings भी काफी असर डाल सकती हैं

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

1 टिप्पणियां

 
GN⁺ 2024-09-10
Hacker News की रायें

  • उन कंपनियों पर कार्रवाई होनी चाहिए जो निर्माता द्वारा आखिरी cloud server बंद करते ही hardware को खराब कर देती हैं
    किसी appliance का निर्माता की remote कार्रवाई की वजह से brick हो जाना या functionality खो देना किसी भी तरह जायज़ नहीं है। डिवाइस खरीदने का मतलब यह नहीं कि मैं निर्माता के साथ हमेशा के लिए बंधा रिश्ता रखना चाहता हूं, और न ही मैं रोज़ चलाने की अनुमति लेना, account बनाना, server में login करना, या अपना IP और घर का पता बताना चाहता हूं।
    Hardware को 10,000वें दिन भी पहले दिन की तरह काम करना चाहिए, और अगर कोई कंपनी ऐसा नहीं कर सकती तो उसे बिक्री की अनुमति नहीं मिलनी चाहिए, या कम से कम उस पर साफ़-साफ़ “निर्माता server पर निर्भर” लिखा होना चाहिए।

    • हाल की मिसाल के तौर पर, किसी ने HP G2 जैसा 1,600 dollar का virtual reality headset खरीदा, लेकिन कुछ साल बाद निर्माता ने support बंद कर दिया और Microsoft ने WMR functionality disable कर दी, जिससे एक बिल्कुल ठीक-ठाक महंगा device brick हो गया।
      निजी तौर पर मुझे लगता है कि repair का अधिकार software तक भी बढ़ाया जाना चाहिए। पुराने phone पर नया operating system डालना, hardware drivers को modernize करके पुराने devices को फिर से चलाना, या पुराने video games को revive करना संभव होना चाहिए।
      यह सही है कि source code intellectual property है, लेकिन medicines की तरह expiry व्यवस्था होनी चाहिए, ताकि किसी product/service का official support खत्म होने पर regulators drivers और service source को सार्वजनिक करने के लिए मजबूर कर सकें।
    • “निर्माता server पर निर्भर” label लगाने पर भी average consumer के लिए उसका मतलब और परिणाम समझना मुश्किल होगा, और smart doorbell जैसे products पर तो ऐसे सभी labels लगे होंगे, इसलिए वास्तविक choice पर शायद ज्यादा असर नहीं पड़ेगा।
      यह California के cancer warning label के बगल में एक और label चिपकने जैसा बन जाने की काफी संभावना है।
    • ऐसी dependency तभी अनुमति योग्य होनी चाहिए जब server essential functionality दे रहा हो।
      हालांकि garage door opener जैसे कुछ devices में firewall पार करने के लिए company server practically जरूरी होता है। App company server से बात करता है, और opener भी उसी server से connect होकर commands का इंतज़ार करता है।
      Remote shutoff functionality gray area है, इसलिए इसे पहले से disclose करना चाहिए, और company को FTC के पास एक छोटा “survival server” bond जमा कराना चाहिए। अगर company service बंद कर दे, तो FTC की ओर वाली copy चालू की जा सकती है, ताकि जो devices अभी blocked नहीं हुए हैं वे चलते रहें।
    • इसके उलट, company को product और support की minimum lifespan साफ़-साफ़ define करनी चाहिए।
      अगर product उस अवधि से पहले बंद हो जाता है, तो partial refund या disposal जैसी end-of-life services शामिल होनी चाहिए, ताकि consumer जानकारी के साथ choice कर सके। अगर यह ऐसा subscription वाला कचरा है, तो लोग दूसरा product ढूंढेंगे।
    • मुद्दा यह नहीं कि company service बंद करती है या नहीं; बल्कि device product और software service product को bundle करके बेचने की practice से antitrust enforcement के जरिए निपटना चाहिए।
      दोनों offerings स्वतंत्र markets के अलग products होने चाहिए, device में कौन-सा server/service इस्तेमाल करना है यह आसानी से configure किया जा सके, और protocol भी publicly documented होना चाहिए।

  • पूरे तौर पर regulation लगाने के बजाय FTC द्वारा enforce की जाने वाली कई certification schemes चाहिए।
    ऐसे stickers हों जिन्हें सिर्फ conditions पूरी करने वाले products ही लगा सकें, और non-compliant products द्वारा उन्हें लगाना illegal हो। उदाहरण के लिए open source, cloud की जरूरत नहीं, firmware rollback, telemetry नहीं, end-to-end encryption, 10 साल replacement parts जैसी certifications हो सकती हैं।
    हर व्यक्ति के लिए अलग चीज़ें महत्वपूर्ण होती हैं, इसलिए FTC के गलत judgment से किसी पूरी product category के market से गायब हो जाने की तुलना में unused certifications का मौजूद रहना बेहतर है।

    • अगर regulation नहीं होगा, तो मुझे डर है कि consumer-hostile features से मुक्त products ढूंढना ही असंभव हो जाएगा।
      अगर competitors के पास भी sticker नहीं है या शुरुआत में ही कोई viable competitor नहीं है, तो companies को stickers की कमी से डरने की जरूरत नहीं होगी।
    • Stickers के लिए भी आखिरकार regulation चाहिए।
      Europe में CE mark है, जो बताता है कि product EU की safety, health और environmental requirements को पूरा करता है, लेकिन China ने लगभग वैसा ही दिखने वाला “CE”(China Export) mark बना दिया, और इसका कोई regulation वाला अर्थ नहीं है।
      इसलिए जब आप Chinese power supply खरीदते हैं, तो “fake” CE mark की वजह से उसे safe समझने की गलती कर सकते हैं।
      1: https://www.kimuagroup.com/news/differences-between-ce-and-c...
      2: https://en.wikipedia.org/wiki/CE_marking
    • ऐसा तरीका बोझ फिर से consumer पर डाल देता है।
      पहले से ही कई product packagings पर stickers या logos भरे पड़े हैं, और ज्यादातर decoration जैसे ही होते हैं। यह भी आसानी से कल्पना की जा सकती है कि politicians पूछेंगे कि tax के पैसे से “anti-innovation” (telemetry नहीं) या “crime-enabling” (end-to-end encryption) products को promote क्यों किया जा रहा है।
    • अच्छा idea है। इसे electronics के लिए nutrition facts label जैसा समझा जा सकता है।
      इसे वैसे ही सख्ती से manage करना चाहिए जैसे FDA nutrition facts label को करता है।
    • FTC के गलत हो सकने की चिंता समझ में आती है, लेकिन rules सिर्फ बहुत obvious situations के लिए बनाए जा सकते हैं।
      सरकारी regulation की कमियों की बात करते समय भी यह मानना चाहिए कि कुछ problems बाकी problems की तुलना में कहीं ज्यादा आसान होती हैं।
      हर चीज़ “शायद consumer ने जानबूझकर खराब हो जाने वाला hardware ही चाहा हो” जैसी libertarian-style, पूरी तरह rational actor वाली बहस नहीं है।
      Consumer किसी magical certification mark या लंबे terms का मतलब जाने बिना product खरीद सकता है और पूरी तरह फंस सकता है। ऐसे argument को सिर्फ बेहद स्पष्ट मामलों में लागू करना भी पर्याप्त रूप से reasonable है।

  • Sony द्वारा अपडेट के जरिए आधिकारिक रूप से समर्थित OtherOS फीचर को निष्क्रिय करने वाली घटना याद आती है
    इस फीचर से Linux जैसे दूसरे operating systems को dual-boot किया जा सकता था, लेकिन अगर अपडेट नहीं करते तो Sony Store का access बंद हो जाता था और नए PS3 firmware की मांग करने वाले गेम भी नहीं चलते थे

    • उस मामले में class-action lawsuit हुआ और करीब 7 साल चला: https://en.wikipedia.org/wiki/OtherOS
      आखिरकार वे users जिन्हें यह फीचर इस्तेमाल करते हुए खोना पड़ा, उन्हें 10.07 डॉलर मिले
    • Sony ने PS3 Slim hardware revision में बिना किसी स्पष्ट तकनीकी आधार के OtherOS support हटा दिया, और बाद में मौजूदा consoles से भी इसे निकाल दिया
      इसके बाद कई researchers ने device पर third-party code चलाने के तरीके खोजे और सफल हुए। [1] जवाब में Sony ने DMCA आदि के तहत कुछ लोगों पर मुकदमा चलाने की कोशिश की [2], और देश व प्रतिवादी के हिसाब से नतीजे अलग-अलग रहे
      [1] https://media.ccc.de/v/27c3-4087-en-console_hacking_2010
      [2] https://en.wikipedia.org/wiki/Sony_Computer_Entertainment_Am...
    • मुझे भी तुरंत वही याद आया। क्या PS3 पहला जबरन downgrade था?
    • उसके बाद से मैंने Sony का एक भी product नहीं खरीदा। उम्मीद है वह company डूब जाए

  • सच कहूं तो ऐसे संभावित जोखिमों और dependencies की वजह से मैंने बहुत सारे devices नहीं खरीदे
    झंझट उठाने लायक नहीं है
    इसी तरह की वजहों से मैं नई cars से भी लगभग बचता हूं। मेरी car में परेशान करने वाली screen नहीं है, बस factory radio या आसानी से लगाए गए radio में Bluetooth connection कर लेना काफी है। ज्यादातर repairs मैं खुद कर सकता हूं, dealer से बात करने की जरूरत नहीं पड़ती, और खरीदने के बाद से 100k–200k miles चल चुकी है और mileage भी अच्छा है। नई car खरीदना लगभग पागलपन होगा
    बाकी जो चाहिए उसके लिए phone काफी है। जरूरत पड़े तो मौजूदा phone hotspot के साथ पुराना car phone भी अच्छी तरह काम करता है
    music के लिए storage device में सारे जरूरी गाने हैं और CD भी लगा सकता हूं। मुझे CD media पसंद है, और इस साल यह digital downloads से आगे रहा। vinyl भी पसंद है
    मैं देखता हूं कि इन चीजों की वजह से लोग परेशान होते हैं, लेकिन मैं नहीं लेना चाहूंगा। cost और risk के मुकाबले मेरी जिंदगी उतनी बेहतर नहीं होती

  • मैं घर के सभी Wi-Fi IoT devices हटाने की कोशिश करता रहा हूं
    कुछ साल पहले उन्हें अलग guest network/VLAN में रखा था और bandwidth भी सिर्फ 5Mbit दी थी
    अब सिर्फ कुछ IP cameras और Roborock vacuum बचे हैं। ऐसे devices को local Wi-Fi पर 100% काम करने के लिए बाध्य करने वाला local-first कानून सच में जरूरी है

    • बात यह नहीं होनी चाहिए थी कि “device smart-things.com से connect होकर कुछ कर सकता है”, बल्कि यह होनी चाहिए थी कि “यह device Bluetooth पर Protocol 1.2.3 बोलता है, इसलिए आप इसे smart-things.com या किसी दूसरी service से जोड़ सकते हैं”
      phone में home management app होता है, और बिना internet connection के Bluetooth या किसी अन्य protocol से IoT devices को सीधे manage न कर पाने की कोई खास वजह नहीं है
    • मैंने कई Shelly wall switches और अमेरिकी-style outlets खरीदे, वे काफी सस्ते हैं, और ESP32 जैसा दिखने वाले chip पर open-source operating system चलाते हैं, जिससे Bluetooth और Wi-Fi संभव है
      app से जुड़ा IoT cloud भी है, लेकिन cloud बंद किया जा सकता है या अपना cloud URL इस्तेमाल किया जा सकता है, और HTTP या UDP RPC, MQTT, switch के अंदर local web server, सीधे code लिखना आदि support करते हैं। outlet सिर्फ relay है, लेकिन load current और voltage भी measure करता है
      app से initial registration की जरूरत नहीं है और browser या curl के जरिए HTTP calls से सब संभाला जा सकता है, इसलिए कोई भी operating system इस्तेमाल किया जा सकता है और scripting भी संभव है
      हालांकि wall switch को stairway/corridor lighting में आम 3/4-way configuration में modify करके लगाने का कोई तरीका नहीं है, यही शिकायत है
      reference के लिए dimmer API: https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen2/Shell...
    • अगर cloud हटाना चाहते हैं तो शायद Roborock पर Valetudo install कर सकते हैं
      तब webpage या free/open-source app से local control संभव होता है
      https://valetudo.cloud/pages/general/supported-robots.html
    • Tasmota या ESPhome support करने वाले products देखें
      ये open-source software इस्तेमाल करते हैं, Home Assistant के साथ अच्छी तरह integrate होते हैं, और सचमुच local-first हैं
    • Wi-Fi IoT भी कुछ conditions पूरी हों तो ठीक हो सकता है
      एक पक्ष वे devices हैं जिनमें local API हो, चाहे binary हो या HTTP, और ESPhome जैसी systems उनमें शीर्ष स्तर की हैं
      दूसरा पक्ष अच्छा router और Wi-Fi infrastructure है जो इसे संभाल सके। ज्यादातर consumer routers करीब 30 devices के बाद टिक नहीं पाते
      पहले मैं Wi-Fi IoT का कड़ा विरोधी था, लेकिन नए घर को setup करते समय hybrid तरीके से बना रहा हूं। lighting loads को Lutron से control करता हूं, और non-lighting loads के लिए Z-Wave, Zigbee और ESPhome चलाने वाले Wi-Fi devices का mix इस्तेमाल करता हूं। network infrastructure Unifi है और लगभग बिना समस्या के चलता है

  • devices में eFuse जलाने की कार्रवाई को illegal किया जाना चाहिए
    device अब manufacturer की property नहीं रहता, इसलिए manufacturer को उसे physically damage करने का अधिकार नहीं होना चाहिए, न ही usage terms के जरिए मुझे वह damage स्वीकार करने पर मजबूर करने का अधिकार होना चाहिए
    eFuse firmware downgrade रोकने, leaked crypto keys को blacklist करने, remote bricking जैसी भयानक anti-consumer features को संभव बनाता है

    • यह इस पर निर्भर करता है कि manufacturing से पहले है या बाद में। manufacturing के बाद हो तो सहमत हूं, लेकिन manufacturing से पहले तक ban नहीं करना चाहिए
      आधुनिक CPUs ज्यादातर इसी तरह काम करते हैं। chip में कई features एक साथ डालकर उसी तरीके से बनाया जाता है, लेकिन defects की वजह से कुछ chips में कुछ features काम नहीं करते, इसलिए internal eFuse जलाकर खराब हिस्सों को disable कर दिया जाता है और बिना उस feature वाले variant के रूप में बेचा जाता है
    • eFuse Tesla जैसी cars में resettable fuse जैसी functionality भी संभव बनाता है
      fuse box में बेवकूफी भरा fuse उड़ जाने पर replacement खरीदने में time और पैसा खर्च करने के बजाय, fault ठीक करने के बाद software से reset करने योग्य बनाने पर cost कम होती है और system efficiency भी बढ़ती है

  • Microsoft ने Windows 11 24H2 में Mixed Reality support हटा दिया, जिससे Microsoft headset को छोड़कर सभी Windows VR headsets बेकार हो गए
    सोच रहा हूं कि क्या यह उसी तरह के मामले में आता है

    • कानून शायद मंशा नाम के एक ही शब्द से जवाब देगा
      मुद्दा यह होगा कि Microsoft ने जानबूझकर planned obsolescence के इरादे से इसे design किया था, या फिर इसे टालना व्यावहारिक रूप से बहुत मुश्किल था

  • ऐसी practices को रोकने वाले कानून की मांग कम से कम 20 साल से होती आ रही है
    शुरुआती उदाहरणों में PS3 का Linux support बंद कर उसे brick कर देना और HP printer modules शामिल हैं। अब जब cloud-connected IoT devices इतने बढ़ गए हैं, तो बदलाव खास तौर पर जरूरी है
    कानून को सिर्फ remote features के खत्म होने या bricking तक ही नहीं, बल्कि उन components को भी cover करना चाहिए जो cloud के बिना भी local तौर पर चल सकते हैं

  • ज्यादा सरकारी खर्च या enforcement लगाए बिना समाधान कानूनी बदलाव है
    जो कंपनी अपनी service से connection मांगने वाला product launch करती है, उसे उस hardware product के आखिरी बार retail store में बिकने के बाद कम से कम 7 साल तक वही या बेहतर उपयोगिता और features बनाए रखने चाहिए
    जैसे ही वह features घटाती है या cost को inflation से तेज बढ़ाती है, उसे product के सभी features इस्तेमाल करने लायक बनाने के लिए जरूरी मौजूदा source code, comments, documentation, test suites आदि को public domain में जारी करना चाहिए
    उस समय से सभी पक्षों को source code और firmware को reverse engineer या hack करने के सभी तरीकों का पूरा इस्तेमाल करने की अनुमति होनी चाहिए
    सीधे शब्दों में, maintain करोगे तो चीज कंपनी की बनी रहेगी, maintain नहीं करोगे तो सभी को उसके बदले maintain करने दो। इस महीने खर्च घटाने की कोशिश कर रहे accountant और सब कुछ हमेशा छिपाए रखना चाहने वाले intellectual property lawyer को आपस में लड़ने दो

    • अगर source code ऐसा दूसरा proprietary software इस्तेमाल करता है जिसे सार्वजनिक नहीं किया जा सकता, तो मामला पेचीदा हो जाता है
      असल में open-source करना विकल्प नहीं हो सकता
      OpenAI जैसी कई third parties के साथ जटिल integration वाली आम स्थिति भी ध्यान में आती है, जिसे users के लिए खुद संभालना आसान नहीं हो सकता
    • यह हैरानी की बात है कि काफी अच्छा सुझाव है, और मुझे fair लगता है
      जो product कंपनी अब बेचती भी नहीं और maintain भी नहीं करती, उसे वह बंधक क्यों रख सके? customer जीतता है और कंपनी को असल में लगभग कुछ नहीं खोना पड़ता। आखिर वह product वैसे भी बेच या maintain नहीं कर रही होती