Live Updates: COVID-19 Cases
  • World 18,456,665
    World
    Confirmed: 18,456,665
    Active: 6,068,560
    Recovered: 11,690,670
    Death: 697,435
  • USA 4,862,285
    USA
    Confirmed: 4,862,285
    Active: 2,255,829
    Recovered: 2,447,525
    Death: 158,931
  • Brazil 2,751,665
    Brazil
    Confirmed: 2,751,665
    Active: 744,644
    Recovered: 1,912,319
    Death: 94,702
  • India 1,858,689
    India
    Confirmed: 1,858,689
    Active: 588,005
    Recovered: 1,231,682
    Death: 39,002
  • Russia 861,423
    Russia
    Confirmed: 861,423
    Active: 185,601
    Recovered: 661,471
    Death: 14,351
  • South Africa 516,862
    South Africa
    Confirmed: 516,862
    Active: 150,286
    Recovered: 358,037
    Death: 8,539
  • Mexico 443,813
    Mexico
    Confirmed: 443,813
    Active: 100,124
    Recovered: 295,677
    Death: 48,012
  • Peru 433,100
    Peru
    Confirmed: 433,100
    Active: 115,198
    Recovered: 298,091
    Death: 19,811
  • Chile 361,493
    Chile
    Confirmed: 361,493
    Active: 17,810
    Recovered: 333,976
    Death: 9,707
  • Spain 344,134
    Spain
    Confirmed: 344,134
    Active: 315,662
    Recovered: ?
    Death: 28,472
  • Iran 312,035
    Iran
    Confirmed: 312,035
    Active: 24,402
    Recovered: 270,228
    Death: 17,405
  • UK 305,623
    UK
    Confirmed: 305,623
    Active: 259,413
    Recovered: ?
    Death: 46,210
  • Pakistan 280,461
    Pakistan
    Confirmed: 280,461
    Active: 25,065
    Recovered: 249,397
    Death: 5,999
  • Saudi Arabia 280,093
    Saudi Arabia
    Confirmed: 280,093
    Active: 35,089
    Recovered: 242,055
    Death: 2,949
  • Italy 248,229
    Italy
    Confirmed: 248,229
    Active: 12,474
    Recovered: 200,589
    Death: 35,166
  • Bangladesh 242,102
    Bangladesh
    Confirmed: 242,102
    Active: 101,013
    Recovered: 137,905
    Death: 3,184
  • Turkey 233,851
    Turkey
    Confirmed: 233,851
    Active: 10,607
    Recovered: 217,497
    Death: 5,747
  • Germany 212,320
    Germany
    Confirmed: 212,320
    Active: 8,388
    Recovered: 194,700
    Death: 9,232
  • France 191,295
    France
    Confirmed: 191,295
    Active: 79,501
    Recovered: 81,500
    Death: 30,294
  • Canada 117,031
    Canada
    Confirmed: 117,031
    Active: 6,487
    Recovered: 101,597
    Death: 8,947
  • China 84,464
    China
    Confirmed: 84,464
    Active: 800
    Recovered: 79,030
    Death: 4,634
  • Netherlands 55,470
    Netherlands
    Confirmed: 55,470
    Active: 49,321
    Recovered: ?
    Death: 6,149
  • Australia 18,728
    Australia
    Confirmed: 18,728
    Active: 7,874
    Recovered: 10,622
    Death: 232
  • S. Korea 14,423
    S. Korea
    Confirmed: 14,423
    Active: 770
    Recovered: 13,352
    Death: 301
  • New Zealand 1,567
    New Zealand
    Confirmed: 1,567
    Active: 22
    Recovered: 1,523
    Death: 22

Google would block third-party ad blockers in Chrome for security, privacy and speed

Author at TechGenyz Google
Google Ad Block

Google Chrome would now block certain ad blockers and destroy content-blocking extensions as per the changes to the open-source Chromium browser proposed by Google engineers for the sake of speed and safety. It seems like Adblock Plus would be an exception to this change, though similar third-party plugins would be affected. The drafted changes would also restrict the capabilities available to developers of extensions.

Content blockers aid users to control the processes of presentation and interaction of their browser with remote resources.

Manifest v3, in a bid to improve security, privacy, performance and even enhance user control, comprises a specification for browser extension manifest files enumerating resources and capabilities available to browser extensions. The design document Stated: “Users should have increased control over their extensions… A user should be able to determine what information is available to an extension, and be able to control that privilege.”

To reach these goals, Google plans to replace the webRequest API with the new declarativeNetRequest API.

The webRequest API allows the interception of network requests by browser extensions so as to block, modify or redirect them, and this delays web page loading. So, this API will now be able to only read, and not modify, network requests.

The declarativeNetRequest API would allow the Chrome browser itself to handle network requests, but risks removing a possible source of bottlenecks and a potentially useful mechanism for changing browser behavior.

The declarativeNetRequest API provides better privacy to users because extensions can’t actually read the network requests made on the user’s behalf – Google’s API document

Raymond Hill, the developer behind uBlock Origin and uMatrix posted on the Chromium bug tracker that changes suggested by the Manifest v3 proposal would wreck his ad and content block extensions while simultaneously restricting content control by users.

In the case of the user preferring to allow a third-party developer to filter network requests in place of Google, these drafted changes would interfere with webpage functionality.

Hill adds that “If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin and uMatrix, can no longer exist.”

While the proposed changes would reduce the efficacy of content blocking and blocking extensions, all ad blocking would not be necessarily knocked out. Google and other internet advertising networks allegedly pay Adblock Plus to whitelist their online advertisements, and thus their preference for this particular plug-in. However, in comparison to Adblock Plus, uBlock Origin and uMatrix offer much more wide-ranging controls without bothering about placating publishers through ad whitelisting.

Furthermore, there are other facilities such as blocking media elements larger than a specified size, disabling JavaScript execution by injecting Content-Security-Policy directives, and removing the outgoing Cookie headers, that would no longer be available under the new declarativeNetRequest API.

Apparently, Hill is awaiting a response from the Google software engineer overseeing this issue.

I understand the point of a declarativeNetRequest API, and I am not against such API. However I don’t understand why the blocking ability of the webRequest API – which has existed for over seven years – would be removed (as the design document proposes). I don’t see what is to be gained from doing this – Raymond Hill, the developer behind uBlock Origin and uMatrix

He argues against the utility of Chromium should these changes come into being:  “Extensions act on behalf of users, they add capabilities to a ‘user agent’, and deprecating the blocking ability of the webRequest API will essentially decrease the level of user agency in Chromium, to the benefit of websites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render… With such a limited declarativeNetRequest API and the depreciation of blocking the ability of the webRequest API, I am skeptical ‘user agent’ will still be a proper category to classify Chromium.”

Several other extension developers have conveyed dismay over the drafted changes, some even surmising that Google’s policy is to use privacy as a pretext for boosting its ad business.

Google has not finalized the changes yet and may be willing to address the concerns of extension developers. As per the email of a Google spokesperson to The Register, “Things are subject to change and we will share updates as available.”

Career

Subscribe