- Chrome के Related Website Sets(RWS) थर्ड-पार्टी कुकी हटने के बाद भी संबंधित साइटों के बीच जानकारी साझा करने की असाधारण अनुमति देते हैं, जिससे वेब privacy सुरक्षा कमजोर हो सकती है
- यह feature इस धारणा पर निर्भर करता है कि यूज़र साइटों के बीच ownership संबंध पहचान सकते हैं, लेकिन 30 लोगों पर हुई study में कुल निर्णयों में से लगभग 42% गलत थे और लगभग 73% ने कम से कम एक बार गलती की
- Chrome ने जिन्हें “संबंधित साइट” के रूप में classify किया, उन मामलों में भी यूज़र्स ने लगभग 37% को असंबंधित माना, जिससे यूज़र की उम्मीद के बाहर साइटों के बीच tracking संभव हो सकती है
- संबंध की पुष्टि करने के लिए पहले साइट खोलनी पड़ती है, इसलिए shared branding या logo देखते ही जानकारी साझा करने और tracking का मौका पहले ही बन जाता है
- Brave, Firefox, Safari ने RWS या इसके पुराने नाम First-Party Sets का विरोध किया था, और यह proposal W3C Privacy Community Group से भी हटा दिया गया
RWS वेब privacy की धारणा कैसे बदलता है
- Related Website Sets(RWS) वह feature है जिसे Google ने थर्ड-पार्टी cookies खत्म करने से पहले Chrome में पेश किया है
- Google का दावा है कि RWS साइट compatibility समस्याएं कम करता है और संबंधित domains के बीच login state बनाए रखने में मदद करता है
- Brave की आलोचना है कि RWS यूज़र हितों से ज्यादा advertisers के हितों को प्राथमिकता देता है, और थर्ड-पार्टी cookies हटने के बाद भी साइटों के बीच connection जारी रखने देने वाला mechanism है
- इसकी मुख्य धारणा यह है कि अगर दो साइटें एक ही संगठन द्वारा संचालित हैं, तो यूज़र information sharing की उम्मीद कर सकते हैं, और browser को थर्ड-पार्टी cookie स्तर की blocking लागू करने की जरूरत नहीं है
- उदाहरण के तौर पर Meta द्वारा संचालित instagram.com और facebook.com दिए गए हैं
- यह धारणा केवल एक ही संगठन की ownership के आधार पर साइटों के बीच tracking की अनुमति देने की दिशा में वेब privacy model को कमजोर करती है
यूज़र study: साइट संबंध पहचानना कठिन है
- इस study ने RWS की मुख्य assumption—“क्या वेब यूज़र दो साइटों के संबंध को सही ढंग से judge कर सकते हैं”—की जांच की
- researchers ने social media से recruit किए गए 30 वेब यूज़र्स को प्रत्येक को 20 वेबसाइट pairs दिखाए
- वेबसाइट pairs Chrome की RWS list और popular websites की list Tranco से random रूप से चुने गए
- participants ने तय किया कि क्या उन्हें लगता है कि दोनों साइटें एक ही संगठन द्वारा संचालित हैं
- कुछ participants ने सभी सवालों के जवाब नहीं दिए, इसलिए कुल 430 unique site-pair judgments collect हुए
- यूज़र expectations अक्सर RWS list से मेल नहीं खाईं
- लगभग 73% participants ने कम से कम एक बार दो साइटों के संबंध का गलत आकलन किया
- कुल judgments में से लगभग 42% गलत थे
- RWS criteria के अनुसार वास्तव में संबंधित site pairs में भी यूज़र्स ने लगभग 37% को असंबंधित माना
- यह result दिखाता है कि RWS उन स्थितियों में भी थर्ड-पार्टी cookies जैसा व्यवहार फिर से संभव बना सकता है जिनकी यूज़र उम्मीद नहीं करते
- पूरा paper arXiv paper के रूप में public है, और 2024 Internet Measurement Conference में प्रस्तुत किया जाना है
निर्णय से पहले ही बनने वाला tracking मौका
- RWS की intuition यह है कि यूज़र साइट A और साइट B के संबंध को समझने के बाद, जब वह संबंध स्वीकार्य लगे तभी साइट B पर जाते हैं
- वास्तव में, यूज़र को साइट B की shared branding या logo देखने के लिए पहले साइट B को load करना पड़ता है
- page load होते ही information sharing और cross-site tracking का मौका पहले ही बन जाता है
- इसलिए RWS यूज़र के दो साइटों के संबंध पर निर्णय लेने से पहले ही privacy harm पैदा कर सकता है
समान संगठन की ownership tracking की अनुमति का आधार नहीं है
- RWS इस विचार पर आधारित है कि अगर दो साइटें संबंधित हैं, तो browser द्वारा दोनों साइटों के बीच privacy protection कम करना harmless या acceptable है
- Brave इस धारणा को गलत मानता है
- अगर कोई यूज़र Facebook account और Instagram account को अलग-अलग email और information से register करता है, तो modern browsers Meta को यह जानने से रोक सकते हैं कि दोनों accounts एक ही व्यक्ति के हैं
- Brave, Firefox, Safari जैसे mainstream browsers और Tor Browser, Icefox जैसे special-purpose browsers भी इस protection को default behavior के रूप में दे सकते हैं
- कुछ कंपनियां link decoration या bounce tracking के जरिए browser की privacy protections को bypass करने की कोशिश करती हैं
- मुख्य अंतर यह है कि privacy-focused browsers cross-site tracking blocking techniques पर प्रयोग कर रहे हैं, जबकि Chrome साइटों के बीच connection allow करने वाला feature design करता है
browsers और standardization community की प्रतिक्रिया
- RWS को एक सामान्य web proposal की तरह पेश किया गया था, लेकिन web ecosystem के कई stakeholders इसे पहले ही review करके reject कर चुके हैं
- Brave, Firefox, Safari ने publicly कहा है कि RWS या इसका पुराना नाम First-Party Sets यूज़र्स और web के लिए अच्छा नहीं है
- यह proposal W3C Privacy Community Group से हटा दिया गया, और W3C के privacy-focused groups में अब इसकी समीक्षा नहीं हो रही है
ownership change और language barrier
- RWS list में शामिल domains बाद में किसी दूसरे owner को transfer हो सकते हैं
- आज A, B, C domains एक ही संगठन द्वारा संचालित हैं, इसका मतलब यह guarantee नहीं है कि कल भी उनकी ownership उसी संगठन के पास होगी
- इसमें वैसा ही risk है जैसा browser extensions के trusted entity से malicious entity को बेचे जाने, या popular software libraries और dependencies के hijack होने के मामलों में होता है
- भले ही कोई site list में शामिल होते समय अर्थपूर्ण रूप से related हो, ownership चुपचाप बदल जाने पर उसे हटाने का mechanism न होने की चिंता बनी रहती है
- language और perception की समस्या भी है
- English users द्वारा English sites evaluate करने की स्थिति में भी, यूज़र्स ने उन sites की उम्मीद नहीं की जिन्हें Google ने related माना था
- जब यूज़र ऐसी भाषा की site पर जाते हैं जिसे वे नहीं जानते, तो relationship judgment और कठिन हो सकता है
निष्कर्ष
- RWS तीन तरीकों से वेब privacy के लिए नुकसानदेह हो सकता है
- यह धारणा कि यूज़र predict कर सकते हैं कि कौन-सी sites एक-दूसरे से related हैं, वास्तविक यूज़र behavior से मेल नहीं खाती
- यूज़र के यह judge करने से पहले ही कि दो sites एक ही संगठन द्वारा संचालित हैं या नहीं, cross-site tracking का मौका बन जाता है
- यह assumption web platform में स्थायी कर देता है कि अगर sites एक ही संगठन की हैं, तो वह संगठन sites के बीच users को track कर सकता है
- privacy का सम्मान करने वाले browsers ownership organization की परवाह किए बिना सभी sites की tracking रोकने की दिशा में आगे बढ़ रहे हैं
1 टिप्पणियां
Hacker News की राय
हालांकि Encrypted Client Hello को support करने वाली websites बहुत कम हैं। memory तो बस और खरीद लेना बेहतर है, Apple products इस्तेमाल करने की किस्मत हो तो बात अलग हो सकती है
Browser को user के पक्ष में खड़ा होना चाहिए और marketing companies के साथ सहयोग नहीं करना चाहिए। इससे आगे, उसे user tracking और fingerprinting को मुश्किल बनाना चाहिए। Users की browsing history track करने की जरूरत नहीं; बस competitors से बेहतर product बनाइए, reviews और comparisons में नंबर 1 बनिए, फिर influencer ads खरीद लीजिए
अच्छा होगा अगर browser canvas data पढ़ना, GPU name पढ़ना, audio card enumerate करना, installed extensions detect करना आदि रोककर fingerprinting को और कठिन बना दे। नए Web APIs को यह guarantee करनी चाहिए कि fingerprint data नहीं बढ़ेगा, या उन्हें permissions के पीछे छिपाया जाना चाहिए
Third-party cookies के लिए RWS जैसी संदिग्ध lists के बजाय, browser उन पुराने websites पर exception allow करने वाला button दे सकता है जो उन पर निर्भर हैं। हालांकि जोखिम यह है कि newspapers, blogs और Q&A sites content देखने के लिए button दबाने को मजबूर कर सकते हैं
Chrome के अस्तित्व की वजह data collection है, और Firefox को कम-से-कम अभी user के पक्ष में hardening settings से configure करके काफी fingerprinting रोकी जा सकती है। लेकिन Mozilla भी अब ad-tech company बन गई है, और Firefox को default रूप से users पर निगरानी करने वाला बनाकर वह data marketers को बेचने लायक करने से यह दिखा है कि Firefox users के प्रति सम्मान की कमी है
फिलहाल
about:configमेंdom.private-attribution.submission.enabledकोfalseसेट करके उस निगरानी को बंद किया जा सकता हैhttps://news.ycombinator.com/item?id=41311479 और https://web.archive.org/web/20240827185708/https://make-fire... देखें। यह option कितने समय तक रहेगा, या updates के बाद इसे कितनी बार फिर से
falseपर लौटाना पड़ेगा, पता नहींसचमुच users के हित में काम करने वाले नए browser की जरूरत है
इसलिए अक्सर कहा जाता है कि इस समस्या का एकमात्र समाधान regulation है, और उस दृष्टिकोण में काफी वजन है
यह सब मिलीभगत जैसा दिखता है, और browser का उस operating system से भी अधिक complex हो जाना जिस पर वह चलता है, एक ऐसी जानबूझकर बनाई गई संरचना भी लगता है जिससे छोटी teams खेल न बदल सकें। जिद्दी समाधान यह है कि जहां तक हो सके web से बचा जाए और human-scale computing पर focus किया जाए
Cookies से जुड़ी news और policy discussions सभी limited hangout जैसी लगती हैं
तो क्या इसका मतलब यह है कि website खुद third-party cookie blocking को bypass करने के लिए “blessed” domains declare कर सकती है? बड़ी websites users के खुद को protect करने की कोशिशों को bypass करके exploit करने के तरीके लगातार ढूंढ रही हैं। हम कैसे भरोसा करें कि ये sites इसका misuse नहीं करेंगी
लेकिन article में बताए अनुसार, preliminary list की contents ही पहले से चिंता पैदा करती हैं। “ads से जुड़ी हर चीज के arbiter के रूप में Google” वाला idea विफल है
फिर भी alternatives भी अच्छे नहीं हैं। मौजूदा third-party cookie system इससे कहीं ज्यादा खराब चीजों की अनुमति देता है। हमें बेहतर ideas चाहिए
उनका implementation बेहतर लगता है
लेकिन legitimate use cases भी हैं। उदाहरण के लिए Stack Exchange की sites साफ तौर पर related हैं और उनका integrated brand भी है, लेकिन वे अलग domains इस्तेमाल करती हैं। Firefox में, जो third-party cookies block करता है, हर domain पर अलग से login करना पड़ता है, इसलिए
stackoverflow.comमें login करने के बादsuperuser.comपर जाने पर भी आप पहले से logged in नहीं होते। First Party Sets जिस समस्या को हल करना चाहता है, वह यही हैकहा जा सकता है कि बेहतर होता अगर ये sites एक unified domain के subdomains होतीं। लेकिन जब ये sites बनी थीं, तब third-party cookies ठीक से काम करती थीं, इसलिए ऐसा करने की कोई मजबूत वजह नहीं थी। किसी app को अलग domain पर move करते हुए users के लिए समस्या न पैदा करना सचमुच दर्दनाक और महंगा हो सकता है
इसका मतलब यह नहीं कि First Party Sets को जैसे का तैसा स्वीकार कर लेना चाहिए, लेकिन यह एक वास्तविक समस्या हल करने की कोशिश है। Users की privacy की रक्षा करते हुए सच में related sites का अच्छा experience बनाए रखने वाला solution ढूंढना मुश्किल, या शायद असंभव हो सकता है
stackoverflow.comमें login करने के बादsuperuser.comपर भी automatically login होने के लिए ऐसा permission popup अपेक्षित है: “यह sitestackexchange.comके साथ cookies share करना चाहती है। login करने के लिए allow दबाएं, permanent reject के लिए reject दबाएं, और बाद में तय करने के लिए ignore दबाएं”एक क्लिक में दोनों तरफ़ के फायदे मिल सकते हैं। भ्रम कम करने के लिए, हर वेबसाइट के पास एक ही “first-party domain” होना चाहिए जो पूरी sub-site में साझा हो, और वह first-party domain अपने अलावा किसी भी site के साथ cookies साझा न कर सके
अगर कई domains पर unified login की अनुमति देना उनके लिए महत्वपूर्ण था, तो उन्हें बहुत पहले subdomain model पर migrate कर जाना चाहिए था। क्योंकि Firefox, Safari users लंबे समय से नकारात्मक असर झेलते आ रहे हैं
अगर वे इसे इतना महत्वपूर्ण नहीं मानते, तो वह भी ठीक है, लेकिन फिर Chrome की third-party cookie blocking या First Party Sets पर चर्चा भी उनके लिए बहुत प्रासंगिक नहीं होनी चाहिए
signin.foo.comपर पहुँचते तो हैं, लेकिन user experience में बिना फिर से login किए authenticated दिखते हैंया developers को related domains हर browser में submit करने होंगे, और हर browser अपनी list maintain करेगा
यह HSTS जैसा सुनाई देता है
[0]: https://github.com/GoogleChrome/related-website-sets/blob/ma...
/.well-known/related-website-set.jsonको block करना शुरू करने का समय हैCookie policies और defaults को वे जैसे चाहें develop और ship कर सकते हैं
हमने Google के Privacy Sandbox जैसे projects पर कई papers और analyses भी https://privacysandstorm.com/proposals/ पर इकट्ठा करना शुरू किया है, और datasets व tools जैसे दूसरे resources भी public कर रहे हैं। अगर दिलचस्पी हो तो contributions welcome हैं
Yohan (https://yohan.beugin.org/)
[1] Interest-disclosing Mechanisms for Advertising are Privacy-Exposing (not Preserving) https://petsymposium.org/popets/2024/popets-2024-0004.php
[2] A Public and Reproducible Assessment of the Topics API on Real Data - https://arxiv.org/abs/2403.19577
https://arxiv.org/html/2403.19577v1