Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
Browsers
Web Extensions
The Death of webRequest API & uBO? Not likely, at least for now.
Message
<blockquote data-quote="Windows_Security" data-source="post: 793090" data-attributes="member: 50782"><p><strong><span style="font-size: 18px">What will change?</span></strong></p><p>In chrome flags there is already a flag to control/limit execution of EXTENSION SCRIPTS, which (when enabled) requires explicit user confirmation for javascript to execute by Extensions. User has the option do enable this for all sites or on request (allowing on a site requires specific user intervention). Picture from about://flags.</p><p></p><p><strong>[ATTACH=full]206805[/ATTACH]</strong></p><p></p><p></p><p>Unlike Chrome applications, extensions are not restricted by content security policy. On installation the user currently grants the extension the necessary site access permissions. The assumption behind this 'grant once - allow always' mechanism was that Google would check all extensions in the Chrome Web Store, so all extension listed in the Web Store would be trustworthy and we all know how that assumption turned out: <a href="https://malwaretips.com/threads/fake-malicious-extensions-on-chrome-web-store.76867/" target="_blank">Extension - Fake Malicious Extensions on Chrome Web Store!</a>). To improve extension security Google had to make changes. Chrome will be implementing new SITE ACCESS permission mechanism for extensions. One of the 10 design principles of Google is that "they use what is already available", so they copied the "javascript" mechanism for extensions and applied this to "website access permissions".</p><p></p><p>[ATTACH=full]206812[/ATTACH]</p><p></p><p></p><p>As explained in [USER=71262]@oldschool[/USER] post: "<em>The user can then grant access to the extension; Chrome then prompts the user to refresh the page to allow your extension to intercept the network requests</em>." This is an elegant way to shoot extension developers in the foot. Google simply makes the current model so hard to use, that average PC users will be driven way because it is annoying in day to day usage. When faced with criticism Google can answer "users will have a choice" and when extension developers will complain, Google can simply say "the market has chosen". So in practice extension developers are forced to use this new API.</p><p></p><p><strong><span style="font-size: 18px">The good, bad and the ugly</span></strong></p><p><strong>THE GOOD</strong></p><p>The new API will have both performance, privacy and security advantages, because in stead of Chrome asking extension what to do with a request the extension can tell Chrome what to do with the request (which implicitly prevents the extension to snoop on the traffic data or misuse/redirect traffic).</p><p></p><p></p><p><strong>THE BAD</strong></p><p>The new API allows less intervention points (only onBeforerequest stage) and less intervention options (only block or redirect). This limits the control an adblocker has in terms of options and flow of event,</p><p></p><p></p><p></p><p><strong>THE UGLY</strong></p><p>Google is working hard to secure its advertising business model by enforcing stricter rules to advertising companies with its "<a href="https://developers.google.com/web/updates/2017/12/better-ads" target="_blank">better ads initiative</a>". Chrome has its own internal adblocking mechanism to enforce these guidelines (<a href="https://www.theverge.com/2018/12/5/18125972/google-chrome-71-available-public-desktop-ad-blocking" target="_blank">block intrusive ads</a>). When Google has enforced its grip on acceptable ads (sorry better ads) it would be very easy to add an internal "acceptable ads/better ads" whitelist to bypass the blocks of extension (<em>since the extension has passed over the actual blocking to the browser</em>).</p></blockquote><p></p>
[QUOTE="Windows_Security, post: 793090, member: 50782"] [B][SIZE=18px]What will change?[/SIZE][/B] In chrome flags there is already a flag to control/limit execution of EXTENSION SCRIPTS, which (when enabled) requires explicit user confirmation for javascript to execute by Extensions. User has the option do enable this for all sites or on request (allowing on a site requires specific user intervention). Picture from about://flags. [B][ATTACH=full]206805[/ATTACH][/B] Unlike Chrome applications, extensions are not restricted by content security policy. On installation the user currently grants the extension the necessary site access permissions. The assumption behind this 'grant once - allow always' mechanism was that Google would check all extensions in the Chrome Web Store, so all extension listed in the Web Store would be trustworthy and we all know how that assumption turned out: [URL='https://malwaretips.com/threads/fake-malicious-extensions-on-chrome-web-store.76867/']Extension - Fake Malicious Extensions on Chrome Web Store![/URL]). To improve extension security Google had to make changes. Chrome will be implementing new SITE ACCESS permission mechanism for extensions. One of the 10 design principles of Google is that "they use what is already available", so they copied the "javascript" mechanism for extensions and applied this to "website access permissions". [ATTACH=full]206812[/ATTACH] As explained in [USER=71262]@oldschool[/USER] post: "[I]The user can then grant access to the extension; Chrome then prompts the user to refresh the page to allow your extension to intercept the network requests[/I]." This is an elegant way to shoot extension developers in the foot. Google simply makes the current model so hard to use, that average PC users will be driven way because it is annoying in day to day usage. When faced with criticism Google can answer "users will have a choice" and when extension developers will complain, Google can simply say "the market has chosen". So in practice extension developers are forced to use this new API. [B][SIZE=18px]The good, bad and the ugly[/SIZE] THE GOOD[/B] The new API will have both performance, privacy and security advantages, because in stead of Chrome asking extension what to do with a request the extension can tell Chrome what to do with the request (which implicitly prevents the extension to snoop on the traffic data or misuse/redirect traffic). [B]THE BAD[/B] The new API allows less intervention points (only onBeforerequest stage) and less intervention options (only block or redirect). This limits the control an adblocker has in terms of options and flow of event, [B]THE UGLY[/B] Google is working hard to secure its advertising business model by enforcing stricter rules to advertising companies with its "[URL='https://developers.google.com/web/updates/2017/12/better-ads']better ads initiative[/URL]". Chrome has its own internal adblocking mechanism to enforce these guidelines ([URL='https://www.theverge.com/2018/12/5/18125972/google-chrome-71-available-public-desktop-ad-blocking']block intrusive ads[/URL]). When Google has enforced its grip on acceptable ads (sorry better ads) it would be very easy to add an internal "acceptable ads/better ads" whitelist to bypass the blocks of extension ([I]since the extension has passed over the actual blocking to the browser[/I]). [/QUOTE]
Insert quotes…
Verification
Post reply
Top