Chromium बग बाउंटी देने वाला Money Tree Browser

 (lyra.horse)
2 पॉइंट द्वारा GN⁺ 2024-01-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Chromium Money Tree Browser का परिचय

  • Chromium Money Tree Browser एक वेबसाइट है जो Chrome VRP (बग बाउंटी प्रोग्राम) के इनाम को खास फ़ाइलों में हुए बदलावों (modifications) से जोड़ती है.
  • यह साइट बहुत ही साधारण तरीके से बनाई गई है, और बेहतर है कि user experience या data accuracy को लेकर बहुत अपेक्षा न रखें.
  • बग बाउंटी को फ़ाइल के हिसाब से बांटा जाता है; उदाहरण के लिए, अगर $1000 के बराबर किसी बग को ठीक करने में 5 फ़ाइलों में बदलाव किया गया, तो हर फ़ाइल को $200 आवंटित किया जाता है.
  • डेटा 2023 के नवंबर की शुरुआत तक की जानकारी पर आधारित है.

GN⁺ की राय

  • Chromium Money Tree Browser डेवलपर्स और security researchers के लिए एक दिलचस्प टूल है, जो विज़ुअल तरीके से दिखाता है कि Chrome के बग बाउंटी प्रोग्राम में किन फ़ाइलों में बदलाव हुए और उसके अनुसार इनाम कैसे बांटा गया.
  • यह साइट इस बात की समझ देती है कि bug fixes के लिए इनाम कैसे गणना किए जाते हैं, और security community में उपयोगी जानकारी साझा करने में मदद कर सकती है.
  • user experience या data accuracy को लेकर अपेक्षाएँ कम रखनी चाहिए, लेकिन यह साइट open source projects में security vulnerabilities के प्रति जागरूकता बढ़ाने और डेवलपर्स को security को अधिक महत्व देने के लिए प्रेरित करने में योगदान दे सकती है.

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

1 टिप्पणियां

 
GN⁺ 2024-01-07
Hacker News राय

  • ऐसी चीज़ के प्रति दिलचस्पी जो एक फीचर जैसी है, जिसे डेवलपर लंबे समय से बनाना चाहते थे

    • किसी फ़ाइल या फ़ाइल के किसी खास हिस्से में अतीत में हुए बदलावों के आधार पर, यह गणना करने के तरीके की उपयोगिता पर विचार कि कोई दिया गया बदलाव समस्या पैदा करने की कितनी संभावना रखता है।
    • हर बदलाव को एक risk score देना, और इस score को PR(Pull Request) से जोड़कर code reviewer को यह बताना कि किस code पर अतिरिक्त ध्यान चाहिए, तथा deployment के समय risky बदलावों को highlight करने वाले signal के रूप में इसका उपयोग करना।
    • जब code insert/delete होने की वजह से ऊपर-नीचे खिसकता है, तब उसी code हिस्से को track करना कठिन होता है। केवल line number पर आधारित algorithm समस्याग्रस्त हो सकता है।
    • यह संकेत कि केवल file-level पर किया गया काम भी काफ़ी उपयोगी हो सकता है.

  • यह इंगित करना कि कुछ third-party library fixes छूट गए हैं

    • ऐसा लगता है कि third-party library (उदाहरण: ffmpeg) में हुए कुछ fixes छूट गए हैं। ऐसे fixes अक्सर upstream में पहले ही handle हो जाते हैं, इसलिए उन्हें track करना मुश्किल हो सकता है।

  • Chrome browser UI के कई bugs को देखते हुए, ऐसे data में manual memory management के use-after-free मुद्दों पर विचार जहाँ performance महत्वपूर्ण नहीं है

    • "फ़ाइल चुनें" dialog के lifecycle जैसे code में, जहाँ manual memory management की performance महत्वपूर्ण नहीं है, फिर भी होने वाले use-after-free मुद्दों पर अवलोकन।
    • यह संकेत कि ऐसे code में हमेशा ज़्यादा smart और धीमे pointers का उपयोग करना बेहतर हो सकता है।
    • raw_ptr<T> जैसे type मदद के इरादे से दिखते हैं, और संभव है कि वास्तव में [2] में हुई crash से बचाव करने में सफल रहे हों।
    • यह अफ़सोस कि project के भीतर performance-sensitive code और ऐसे code जहाँ performance को ज़्यादा महत्व देने की ज़रूरत नहीं, उनके बीच अलग dialect में switch करने का कोई तरीका नहीं है।
    • इस पर विचार कि performance-sensitive हिस्सों और उन हिस्सों को, जहाँ asynchronous state बहुत अधिक है और गड़बड़ी की संभावना भी अधिक है, साफ़ तौर पर अलग करने के लिए दो अलग भाषाओं का मिश्रण करना लगभग सार्थक होगा या नहीं।

  • visualization के प्रभाव की प्रशंसा और CPU उपयोग पर टिप्पणी

    • बहुत साफ़-सुथरी visualization है, हालांकि area expand करते समय CPU उपयोग कुछ ज़्यादा होने का उल्लेख।
    • यह अपेक्षा कि Chrome team अंदरूनी तौर पर ऐसा मिलता-जुलता tool इस्तेमाल कर रही होगी, और यह attack surface को समझने में उपयोगी होगा।

  • idea और execution की प्रशंसा तथा raw data के बारे में पूछताछ

    • idea शानदार है और execution भी अच्छा हुआ है, ऐसी प्रशंसा।
    • raw data तक पहुँच की उपलब्धता, और sunburst या tree map आज़माने के मूल्य के बारे में उल्लेख।

  • कुछ विशेष file types को शामिल न करने का सुझाव

    • DEPS, AUTHORS, BUILD.gn files को शामिल न करने का विस्तृत सुझाव।

  • बदली गई code lines की संख्या के अनुसार weight देने का सुझाव

    • यह राय कि बदली गई code lines की संख्या के हिसाब से bug को दिए गए 'पैसे' को weight देना दिलचस्प होगा।
    • यदि file A की 10 lines और file B की 1 line बदली गई हो, तो file A bug के अधिकांश हिस्से के लिए ज़िम्मेदार होने के कारण उसे 1/11 'पैसा' आवंटित करने के तरीके का सुझाव।

  • प्रति-file average reward दिखाने वाले फीचर का अनुरोध

    • हर node पर प्रति-file average reward दिखाने वाले फीचर की मांग।

  • code line count के अनुसार normalized amount display करने का idea

    • code line count के अनुसार amount को normalize करके दिखाने वाले version का सुझाव।

  • कहाँ effort केंद्रित करना है, इस पर visual insight की प्रशंसा

    • यह मूल्यांकन कि कहाँ effort केंद्रित करना चाहिए, इस पर visual insight देना बहुत शानदार है।