Google သည် ကြော်ငြာပိတ်ဆို့သူများ တောင်းဆိုသော API ကို ကန့်သတ်ရန် ဆက်လက်တောင်းဆိုနေပါသည်။

Chrome အဖွဲ့ရှိ တိုးချဲ့ဆော့ဖ်ဝဲရေးသားသူများနှင့် အပြန်အလှန်ဆက်ဆံရေးအတွက် တာဝန်ရှိသည့် Simeon Vincent (Extensions Developer Advocate)၊ မှတ်ချက်ပေးခဲ့သည် Chrome manifesto ၏ တတိယမြောက်ထုတ်ဝေမှုနှင့်ပတ်သက်၍ Google ၏ လက်ရှိအနေအထား၊ ချိုးဖောက်ခြင်း။ အလုပ် မသင့်လျော်သောအကြောင်းအရာများကို ပိတ်ဆို့ရန်နှင့် လုံခြုံရေးသေချာစေရန် add-ons အများအပြား။ ကုမ္ပဏီသည် သင့်အား လက်ခံရရှိထားသော အကြောင်းအရာများကို အမြန်ပြောင်းလဲနိုင်စေမည့် webRequest API ၏ ပိတ်ဆို့ခြင်းမုဒ်ကို ရပ်တန့်ရန် ၎င်း၏မူလအစီအစဉ်ကို စွန့်လွှတ်ရန် ရည်ရွယ်ထားခြင်းမရှိပါ။ Chrome ၏ လုပ်ငန်းထုတ်ဝေမှုအတွက်သာ ခြွင်းချက်တစ်ခု ပြုလုပ်လိမ့်မည် (လုပ်ငန်းအတွက် Chrome) ၎င်းတွင် webRequest API အတွက် ပံ့ပိုးမှုကို ယခင်အတိုင်း ဆက်လက်ထားရှိမည်ဖြစ်သည်။

ပုံမှန် Chrome API အသုံးပြုသူများအတွက် ဝဘ်တောင်းဆိုချက် ဖတ်ရန်သာမုဒ်တွင် ကန့်သတ်ထားမည်ဖြစ်သည်။ အကြောင်းအရာ filtering အတွက် webRequest API ကို အစားထိုးရန် declarative API ကို အဆိုပြုထားသည်။ declarativeNetRequestခေတ်မီကြော်ငြာပိတ်ဆို့ခြင်းများတွင်အသုံးပြုသောစွမ်းရည်များ၏ကန့်သတ်ချက်အစိတ်အပိုင်းတစ်ခုသာပါဝင်သည်။ အခြေခံအားဖြင့်၊ ကွန်ရက်တောင်းဆိုမှုများကို အပြည့်အဝဝင်ရောက်ခွင့်ရှိသော မူပိုင်ကိုင်တွယ်သူများအစား၊ အဆင်သင့်လုပ်ထားသော universal built-in filtering engine ကို စည်းမျဉ်းများကိုယ်တိုင်ပိတ်ဆို့ခြင်းများကို လုပ်ဆောင်ပေးပါသည်။ ဥပမာအားဖြင့်၊ declarativeNetRequest API သည် သင့်ကိုယ်ပိုင် filtering algorithms များကို အသုံးပြုရန် ခွင့်မပြုဘဲ အခြေအနေများပေါ်မူတည်၍ တစ်ခုနှင့်တစ်ခု ထပ်နေမည့် ရှုပ်ထွေးသောစည်းမျဉ်းများကို ဖန်တီးခွင့်မပြုပါ။

ကြော်ငြာပိတ်ဆို့ခြင်း အပိုပရိုဂရမ်များကို ဆော့ဖ်ဝဲရေးသားသူများ ပူးပေါင်းပြင်ဆင်ထားသည်။ မှတ်ချက်များစာရင်းdeclarativeNetRequest API ၏ ချို့ယွင်းချက်များကို ဖော်ပြထားပါသည်။ Google သည် မှတ်ချက်များစွာဖြင့် သဘောတူပြီး declarativeNetRequest API သို့ ထည့်သွင်းခဲ့သည်။ အထူးသဖြင့်၊ ဒိုင်းနမစ်ပုံစံပြောင်းလဲခြင်းနှင့် စည်းမျဥ်းများပေါင်းထည့်ခြင်းအတွက် ပံ့ပိုးမှုကို ပေါင်းထည့်ထားပြီး HTTP ခေါင်းစီးများကို ဖျက်နိုင်သော်လည်း အဖြူရောင်စာရင်း (ကိုးကားသူ၊ Cookie၊ Set-Cookie) မှသာလျှင် ဖျက်နိုင်သည်။ HTTP ခေါင်းစီးများကို ပေါင်းထည့်ခြင်းနှင့် အစားထိုးခြင်း (ဥပမာ၊ Set-Cookie အစားထိုးခြင်းနှင့် CSP လမ်းညွှန်ချက်များအတွက်) နှင့် တောင်းဆိုမှုဘောင်များကို ဖျက်ခြင်းနှင့် အစားထိုးခြင်းဆိုင်ရာ ပံ့ပိုးကူညီမှုတို့ကို အကောင်အထည်ဖော်ရန် ကျွန်ုပ်တို့ စီစဉ်ထားပါသည်။

Chrome အပိုပရိုဂရမ်များသို့ ပံ့ပိုးပေးသည့် စွမ်းရည်များနှင့် အရင်းအမြစ်များစာရင်းကို သတ်မှတ်ပေးသည့် manifest ၏ တတိယဗားရှင်း၏ ပဏာမဗားရှင်းကို လာမည့်လများတွင် Chrome Canary ၏ စမ်းသပ်တည်ဆောက်မှုများတွင် စမ်းသပ်ရန်အတွက် အသုံးပြုရန် စီစဉ်ထားပါသည်။

တစ်ချိန်တည်းမှာပင်၊ webRequest API မှတစ်ဆင့် လက်ခံရရှိထားသော အကြောင်းအရာပြောင်းလဲမှုများကို တားမြစ်ရန် လှုံ့ဆော်မှုသည် ရှင်းရှင်းလင်းလင်းမရှိပေ။ webRequest API ၏ ပိတ်ဆို့ခြင်းမုဒ်သည် လုပ်ဆောင်ချက်အပေါ် အပျက်သဘောဆောင်သည့် အကျိုးသက်ရောက်မှုရှိသည်ဆိုသော် ဘရောက်ဆာသည် စာမျက်နှာကို မတင်ဆက်မီ ၎င်း၏လုပ်ဆောင်မှုကို အပြီးသတ်ရန် အပိုပရိုဂရမ်ကိုင်တွယ်သူကို စောင့်ဆိုင်းနေသောကြောင့် ဝေဖန်မှုများကို မခံမရပ်နိုင်ဖြစ်ခဲ့ရသည်။ ယခင်က ပြုလုပ်ခဲ့သည်။ စမ်းသပ်မှု ကြော်ငြာပိတ်ဆို့ခြင်း အပိုပရိုဂရမ်များ၏ စွမ်းဆောင်ရည်သည် ၎င်းတို့မိတ်ဆက်သည့် နှောင့်နှေးမှုမှာ အားနည်းကြောင်း ပြသထားသည်။ ပျမ်းမျှအားဖြင့်၊ blocker ကိုအသုံးပြုခြင်းသည် တစ်ခုလုံး၏နောက်ခံနှင့် နှိုင်းယှဉ်ပါက အားနည်းသည့် မီလီစက္ကန့်အနည်းငယ်မျှသာရှိသော တောင်းဆိုချက်အား အကောင်အထည်ဖော်မှုကို နှေးကွေးစေသည်။

အသုံးပြုသူများအား အကြောင်းအရာသို့ အပိုပရိုဂရမ်များ မထိန်းချုပ်နိုင်ဝင်ရောက်ခြင်းမှ ကာကွယ်လိုသောဆန္ဒနှင့် ပတ်သက်သည့် ဒုတိယအငြင်းအခုံမှာ သက်တမ်းရှည်ကြာစွာတည်ရှိပြီး ကျယ်ပြန့်သောလုပ်ဆောင်နိုင်စွမ်းကို ဖယ်ရှားမည့်အစား တရားဝင်အပိုပရိုဂရမ်အသစ်တစ်ခုကို ထပ်ထည့်ရန် ဖြစ်နိုင်သည်။ အခွင့်အာဏာအမျိုးအစားနှင့် ကွန်ရက်တောင်းဆိုမှုများကို အပြည့်အဝဝင်ရောက်ခွင့်ရှိနိုင်သည် သို့မဟုတ် မပါဝင်သည့် အပိုပရိုဂရမ်တစ်ခုကို ထည့်သွင်းခြင်းအတွက် သုံးစွဲသူအား နောက်ဆုံးရွေးချယ်မှုအား ပေးဆောင်ပါ။ ထို့အပြင်၊ Google သည် အဆင့်နိမ့်ဝင်ရောက်စွက်ဖက်မှုမရှိဘဲ အသွားအလာအားလုံးကို စောင့်ကြည့်ခြင်းအား ဖတ်ရှုရန်သာမုဒ်တွင် webRequest API အသုံးပြုမှုအတွက် ပံ့ပိုးမှုကို ချန်ထားခဲ့သည်။
အပိုပရိုဂရမ်များသည် အခြား API များမှတစ်ဆင့် တင်ထားသော ဝဘ်စာမျက်နှာများ၏ အကြောင်းအရာများကို ပြောင်းလဲနိုင်သည် (ဥပမာ၊ အန္တရာယ်ရှိသော အပိုပရိုဂရမ်များသည် ၎င်းတို့၏ ကြော်ငြာများကို ပေးပို့နိုင်ဆဲ၊ မိုင်းတွင်းလုပ်သားများကို စတင်ခြင်းနှင့် ထည့်သွင်းပုံစံများ၏ အကြောင်းအရာများကို ခွဲခြမ်းစိတ်ဖြာနိုင်သည်)။

မလိုလားအပ်သောအကြောင်းအရာများကိုပိတ်ဆို့ရန်အတွက် uBlock Origin နှင့် uMatrix စနစ်များကိုရေးသားသူ Raymond Hill သည် အလွန်တင်းကျပ်သည် မှတ်ချက်ပေးခဲ့သည် Google မှ ကိုယ်စားလှယ်တစ်ဦးမှ တုံ့ပြန်ပြီး အခွင့်အလမ်းကောင်းတစ်ခုအဖြစ် Google သည် အင်တာနက်ကြော်ငြာနယ်ပယ်တွင် ၎င်း၏စီးပွားရေးစိတ်ဝင်စားမှုကို တိုးတက်စေရန်၊ ၎င်း၏ filtering ယန္တရားများကို ထိန်းချုပ်ရန်နှင့် တရားမျှတစေရန် ကြိုးပမ်းနေသည့် demagoguery နှင့် နောက်ကွယ်ရှိဂိမ်းများကို အရိပ်အမြွက်ဖော်ပြခဲ့သည်။ ဤလုပ်ရပ်များသည် အများသူငှာ မျက်စိကျနေပါသည်။

အပိုပရိုဂရမ်ဆော့ဖ်ဝဲရေးသားသူများကြားတွင် ကျယ်ပြန့်ပြီး ရေပန်းစားသော API ကို ရပ်တန့်ရန် လိုအပ်မှုအတွက် ယုံကြည်စိတ်ချရသော အကြောင်းပြချက်များကို သူဘယ်သောအခါမှ မရရှိခဲ့ပါ။ Raymond ၏ အဆိုအရ၊ စာမျက်နှာများသည် ဖောင်းပွမှုကြောင့် နှေးကွေးစွာ တက်လာပြီး မှန်ကန်စွာ အကောင်အထည်ဖော်ထားသော အပိုပရိုဂရမ်များတွင် webRequest ပိတ်ဆို့ခြင်းမုဒ်ကို အသုံးပြုခြင်းကြောင့် မဟုတ်ဘဲ စွမ်းဆောင်ရည် ကျဆင်းသွားခြင်းမှာ အငြင်းအခုံတစ်ခုမဟုတ်ပေ။ အကယ်၍ Google သည် စွမ်းဆောင်ရည်ကို အမှန်တကယ် အလေးထားပါက၊ ၎င်းတို့သည် ယန္တရားအပေါ်အခြေခံ၍ webRequest ကို ပြန်လည်ဒီဇိုင်းထုတ်မည်ဖြစ်သည်။ ကတိဥဒါဟရုဏ်အားဖြင့်၊ အကောင်အထည်ဖော်ခြင်း။ Firefox တွင် web Request

Raymond ၏အဆိုအရ Google ၏မဟာဗျူဟာသည် Chrome ၏အသုံးပြုသူအခြေခံကိုတိုးချဲ့ခြင်းနှင့် content blockers များအသုံးပြုခြင်းကြောင့်စီးပွားရေးပျက်စီးမှုအကြားအကောင်းဆုံးချိန်ခွင်လျှာကိုဆုံးဖြတ်ရန်ဖြစ်သည်။ Chrome တိုးချဲ့ခြင်း၏ပထမအဆင့်တွင်၊ Google သည် သုံးစွဲသူများကြားတွင် ရေပန်းအစားဆုံး add-ons တစ်ခုအဖြစ် ကြော်ငြာပိတ်ဆို့ခြင်းများကို ထည့်သွင်းခိုင်းစေခဲ့သည်။ သို့သော် Chrome သည် ကြီးစိုးလာပြီးနောက် ကုမ္ပဏီသည် ၎င်း၏မျက်နှာသာပေးသော ချိန်ခွင်လျှာကို ညွှန်ပြရန် ကြိုးစားကာ ပိတ်ဆို့ခြင်းအပေါ် မြှင့်တင်ခြင်းဖြင့် ထိန်းချုပ်မှုရယူခဲ့သည်။ အစပျိုးမှု မသင့်လျော်သောကြော်ငြာပိတ်ဆို့ခြင်းလုပ်ဆောင်ချက်ကို Chrome တွင်ပေါင်းစပ်ရန်။ အကြောင်းအရာပိတ်ဆို့ခြင်းအပေါ် ထိန်းချုပ်မှုသည် ပြင်ပကုမ္ပဏီ ကြော်ငြာပိတ်ဆို့သူဆော့ဖ်ဝဲရေးသားသူများ၏လက်ထဲတွင် ဖြစ်သောကြောင့် webRequest API သည် ဤရည်ရွယ်ချက်ကို ရှုံးနိမ့်သွားပါသည်။

source: opennet.ru