Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.security.misc > #1397 > unrolled thread

Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently

Back to article view | Back to comp.security.misc

Contents

  Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently "!!Credit" <payroll@qi3.com> - 2019-01-26 04:56 +0000
    Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-01-26 10:54 +0000
      Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently outlook shitemail <microsuck@msn.com> - 2019-01-26 13:14 +0000
      Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently snipeco.2@gmail.com (Sn!pe) - 2019-02-01 00:25 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Eli the Bearded <*@eli.users.panix.com> - 2019-02-01 00:37 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-02-01 00:58 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently snipeco.2@gmail.com (Sn!pe) - 2019-02-01 11:48 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Roger Blake <rogblake@iname.invalid> - 2019-02-01 14:10 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-02-01 00:54 +0000
          Pi-hole (Was: Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently) snipeco.2@gmail.com (Sn!pe) - 2019-02-01 11:48 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-02-01 07:59 +0100
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently snipeco.2@gmail.com (Sn!pe) - 2019-02-01 11:48 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Doug McIntyre <merlyn@dork.geeks.org> - 2019-02-01 09:00 -0600
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently not@telling.you.invalid (Computer Nerd Kev) - 2019-02-02 02:05 +0000
      Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently tom <tom@0.0.0.0> - 2019-02-17 11:42 -0800
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-02-17 20:24 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Pabst Blue Ribbon <pabst@blue.ribbon> - 2019-02-18 11:27 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-02-18 11:35 +0000
            Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently not@telling.you.invalid (Computer Nerd Kev) - 2019-02-18 21:57 +0000
              Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-02-18 22:33 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently not@telling.you.invalid (Computer Nerd Kev) - 2019-02-18 21:46 +0000
    Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-01-26 17:58 +0100
      Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Rich <rich@example.invalid> - 2019-01-26 23:15 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Dan Purgert <dan@djph.net> - 2019-01-26 23:22 +0000
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Huge <Huge@nowhere.much.invalid> - 2019-01-27 11:09 +0000
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-01-28 08:01 +0100
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-01-28 07:56 +0100
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Rich <rich@example.invalid> - 2019-01-28 11:26 +0000
            Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-01-28 15:11 +0100
      Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently "Dirk T. Verbeek" <dverbeek@xs4all.nl> - 2019-01-27 19:58 +0100
        Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently Juergen Nieveler <Juergen.Nieveler@gmail.com> - 2019-01-28 08:03 +0100
          Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently not@telling.you.invalid (Computer Nerd Kev) - 2019-01-30 22:01 +0000
            Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently The Real Bev <bashley101@gmail.com> - 2019-01-30 15:34 -0800
    Re: Wow, fancy that. Web ad giant Google to block ad-blockers in Chrome. For safety, apparently suge0025@gmail.com - 2019-06-18 15:53 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1438

In comp.misc Pabst Blue Ribbon <pabst@blue.ribbon> wrote:
> tom <tom@0.0.0.0> wrote:
>> On 26 Jan 2019 10:54:20 GMT
>> Huge <Huge@nowhere.much.invalid> wrote:
>> 
>>> Get a PiHole.
>> No, stop using Chrome and any other google products and services
> 
> Well, actually, it's not entirely Google product. It's based on Chromium,
> which is "an entirely free and open-source software project. The
> Google-authored portion is released under the BSD license.

The Google-authored portion is presumably a large majority, so it is
a Goole product. How well scrutinised the Open-Source code is by
people with an eye to privacy, is something that I'd like to know.

> Other parts
> are subject to a variety of licenses, including MIT, LGPL, Ms-PL, and an
> MPL/GPL/LGPL tri-license.[10]"

Like most other software that deals with lots of different file
formats and protocols.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#1400

On 26.01.2019 05:56, !!Credit wrote:
> Google engineers have proposed changes to the open-source Chromium
> browser that will break content-blocking extensions, including ad
> blockers.

It will also break data-stealing malware extensions though - which is
the point of the change

> If the overhaul goes ahead, Adblock Plus and similar plugins that
> rely on basic filtering will, with some tweaks, still be able to
> function to some degree, unlike more ambitious extensions, such as
> uBlock Origin, which will be harder hit. The drafted changes will
> limit the capabilities available to extension developers, ostensibly
> for the sake of speed and safety. Chromium forms the central core of
> Google Chrome, and, soon, Microsoft Edge.

Actually, Adblock Plus was among the first to protest - because the new 
system would only allow 30000 filter list entries, which is not enough 
to even use Easylist

> The webRequest API allows browser extensions, like uBlock Origin, to
> intercept network requests, so they can be blocked, modified, or
> redirected. This can cause delays in web page loading because Chrome
> has to wait for the extension. In the future, webRequest will only be
> able to read network requests, not modify them.

Not only that - they can do some nasty stuff as well if you happen to 
install a malware extension. Which you might not even notice - in some 
cases benign extensions were sold off by their developers, and updated 
to include new "features" to manipulate web traffic, show ads, steal 
data, etc...

> "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 documentation explains.

Actually they ARE telling the truth here... the old API had way too much 
rights. The adblocker issue is a side effect - an unfortunate one, but 
it was apparently not the main goal (otherwise, Google could have kicked 
them out of the app store ages ago)

Worst case, you can still use a proxy server to filter out the ads. And 
in your own LAN you should be running PiHole already anyway.

[toc] | [prev] | [next] | [standalone]

#1401

In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
> On 26.01.2019 05:56, !!Credit wrote:
>> Google engineers have proposed changes to the open-source Chromium
>> browser that will break content-blocking extensions, including ad
>> blockers.
> 
> It will also break data-stealing malware extensions though - which is
> the point of the change

The solution there, however, is not to remove the API, but to add a 
"grant only" permissions system such that the end user has to grant an 
extension the right to use the API.

Those installing uMatrix or uBlockOrigin will naturally want to "allow" 
both to access the API.  But if some other extension, that does not 
need such access, asks to be granted, then the user has the choice of 
denying such access.

[toc] | [prev] | [next] | [standalone]

#1402

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rich wrote:
> In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
>> On 26.01.2019 05:56, !!Credit wrote:
>>> Google engineers have proposed changes to the open-source Chromium
>>> browser that will break content-blocking extensions, including ad
>>> blockers.
>> 
>> It will also break data-stealing malware extensions though - which is
>> the point of the change
>
> The solution there, however, is not to remove the API, but to add a 
> "grant only" permissions system such that the end user has to grant an 
> extension the right to use the API.
>

Yes, but then how can minitrue ensure that all people are properly
indoctr^h^h^h^h^h protected from malicious plugins?

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxM68oACgkQjhHd8xJ5
ooFjhAgAr32Wi2dHlxJ6uV9kwPnCqfLlRadq3pYWkoFzfJox6xH7i9ZRT2DANjOh
WkeUZr8iCTaDmFgHVh2GMyfigxQTkLB19VcZt7f1HNIvS4YiRCq3lYc5iwqtdrHf
0zsx4Wc6GlbaySYahXvC0T9m3yN8K8yVJDVebMbVpFJmPlQg0RSP5Bv/uTyMZdf3
LcY4etUSDQgznyHL3xcMICJ9cG1gMOjyCQnYZNOhj7IF76fF02d58OMDK6WZKxEb
3Fw7iL96o6MQMVeZdzeuzYB3Xez/LCG4yE4PbE3nHJbLY961dh5/vmuPOgOzpUob
8bz+kkVc596RRNJ8WnUC9B2EK7Geow==
=ydkg
-----END PGP SIGNATURE-----

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#1403

On 2019-01-26, Rich <rich@example.invalid> wrote:
> In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
>> On 26.01.2019 05:56, !!Credit wrote:
>>> Google engineers have proposed changes to the open-source Chromium
>>> browser that will break content-blocking extensions, including ad
>>> blockers.
>> 
>> It will also break data-stealing malware extensions though - which is
>> the point of the change
>
> The solution there, however, is not to remove the API, but to add a 
> "grant only" permissions system such that the end user has to grant an 
> extension the right to use the API.
>
> Those installing uMatrix or uBlockOrigin will naturally want to "allow" 
> both to access the API.  But if some other extension, that does not 
> need such access, asks to be granted, then the user has the choice of 
> denying such access.

And of course that works *so* well in all the other cases when something
pops up. [User clicks 'Yes' without reading or understanding.]


-- 
Today is Boomtime, the 27th day of Chaos in the YOLD 3185
                      ~ Stercus accidit ~

[toc] | [prev] | [next] | [standalone]

#1405

On 27.01.2019 12:09, Huge wrote:
>> Those installing uMatrix or uBlockOrigin will naturally want to "allow"
>> both to access the API.  But if some other extension, that does not
>> need such access, asks to be granted, then the user has the choice of
>> denying such access.
> 
> And of course that works *so* well in all the other cases when something
> pops up. [User clicks 'Yes' without reading or understanding.]

Indeed, the concept of "informed consent" simply doesn't work with endusers.

[toc] | [prev] | [next] | [standalone]

#1407

On 27.01.2019 00:15, Rich wrote:
> In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
>> On 26.01.2019 05:56, !!Credit wrote:
>>> Google engineers have proposed changes to the open-source Chromium
>>> browser that will break content-blocking extensions, including ad
>>> blockers.
>>
>> It will also break data-stealing malware extensions though - which is
>> the point of the change
> 
> The solution there, however, is not to remove the API, but to add a
> "grant only" permissions system such that the end user has to grant an
> extension the right to use the API.

Indeed, that would be the far better choice

> Those installing uMatrix or uBlockOrigin will naturally want to "allow"
> both to access the API.  But if some other extension, that does not
> need such access, asks to be granted, then the user has the choice of
> denying such access.

I wouldn't leave the decision with the users... I'd allow it depending 
on the category the extension was put in in the app store. That way, all 
extensions that want to use such elevated priviledges would be far more 
obvious, AND could be subject to more scrutiny without overloading the 
review system.

Leaving the decision just with the enduser means just another exercise 
in social engineering - you already got the user to want to install your 
extension anyway (manual extension installs were already disabled a 
while ago, weren't they?), so you just need a convincing argument to 
explain to the user why you want those permissions that Google is 
warning you could do bad things.

[toc] | [prev] | [next] | [standalone]

#1408

In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
> On 27.01.2019 00:15, Rich wrote:
>> In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
>>> On 26.01.2019 05:56, !!Credit wrote:
>>>> Google engineers have proposed changes to the open-source Chromium 
>>>> browser that will break content-blocking extensions, including ad 
>>>> blockers.
>>>
>>> It will also break data-stealing malware extensions though - which 
>>> is the point of the change
>> 
>> The solution there, however, is not to remove the API, but to add a 
>> "grant only" permissions system such that the end user has to grant 
>> an extension the right to use the API.
> 
> Indeed, that would be the far better choice
> 
>> Those installing uMatrix or uBlockOrigin will naturally want to 
>> "allow" both to access the API.  But if some other extension, that 
>> does not need such access, asks to be granted, then the user has the 
>> choice of denying such access.
> 
> I wouldn't leave the decision with the users...  I'd allow it 
> depending on the category the extension was put in in the app store.  
> That way, all extensions that want to use such elevated priviledges 
> would be far more obvious, AND could be subject to more scrutiny 
> without overloading the review system.

That is an interesting twist.  Prevents the current situation of 
blocking every extension due to a subset of bad extensions.

> Leaving the decision just with the enduser means just another 
> exercise in social engineering - you already got the user to want to 
> install your extension anyway (manual extension installs were already 
> disabled a while ago, weren't they?), so you just need a convincing 
> argument to explain to the user why you want those permissions that 
> Google is warning you could do bad things.

A fair point.  I was thinking from a standpoint of a technically 
competent, and appropriately security skeptical, end user.  But the 
same users whom years ago had 17 different IE tool bars simultaneously 
installed in IE6 would also simply authorize all the bad extensions to 
use the API.  And google is likely trying to protect those users from 
themselves.  Their protection at the moment is, unfortunately, the 
nuclear option, which does harm the technically competent and 
appropriately security skeptical users as part of the fallout.

[toc] | [prev] | [next] | [standalone]

#1409

On 28.01.2019 12:26, Rich wrote:
>> Leaving the decision just with the enduser means just another
>> exercise in social engineering - you already got the user to want to
>> install your extension anyway (manual extension installs were already
>> disabled a while ago, weren't they?), so you just need a convincing
>> argument to explain to the user why you want those permissions that
>> Google is warning you could do bad things.
> 
> A fair point.  I was thinking from a standpoint of a technically
> competent, and appropriately security skeptical, end user.  But the
> same users whom years ago had 17 different IE tool bars simultaneously
> installed in IE6 would also simply authorize all the bad extensions to
> use the API.

Yep. I've been working in IT for over 20 years, mostly in enduser-facing 
areas. The only thing more dangerous than a user without a clue about 
computers is those who THINK they have a clue... ;-)

>  And google is likely trying to protect those users from
> themselves.  Their protection at the moment is, unfortunately, the
> nuclear option, which does harm the technically competent and
> appropriately security skeptical users as part of the fallout.

Nothing is set in stone yet. Google at least acknowledged the responses 
from the community, so there's still some hope. Maybe they'll just make 
it a setting in Chrome://flags for example. I'd be perfectly OK with that.

[toc] | [prev] | [next] | [standalone]

#1404

Op 26-01-19 om 17:58 schreef Juergen Nieveler:
> Worst case, you can still use a proxy server
Normal case, you use a good browser.

[toc] | [prev] | [next] | [standalone]

#1406

On 27.01.2019 19:58, Dirk T. Verbeek wrote:
> Op 26-01-19 om 17:58 schreef Juergen Nieveler:
>> Worst case, you can still use a proxy server
> Normal case, you use a good browser.

If only there was one... Chrome and Edge will soon be frontends for the 
same engine, Opera too, Safari never was a good browser to begin with, 
and Firefox, while having the potential, pisses off users on a frequent 
basis by adding suspicious stuff without warning. Remember when they 
added advertising for "Mr Robot" by labeling it as "experiment"?

[toc] | [prev] | [next] | [standalone]

#1410

In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
> On 27.01.2019 19:58, Dirk T. Verbeek wrote:
>> Op 26-01-19 om 17:58 schreef Juergen Nieveler:
>>> Worst case, you can still use a proxy server
>> Normal case, you use a good browser.
> 
> If only there was one... Chrome and Edge will soon be frontends for the 
> same engine, Opera too, Safari never was a good browser to begin with, 
> and Firefox, while having the potential, pisses off users on a frequent 
> basis by adding suspicious stuff without warning. Remember when they 
> added advertising for "Mr Robot" by labeling it as "experiment"?

I can think of a few "good" browsers, to my definition. The one I
choose is Dillo, and it doesn't need any ad-blocker extensions.

The problem is that the web in general is only designed for Chrome
and Firefox (with the latter possibly under threat as well given
its usage share), so the problem isn't finding good browsers, but
finding a good web.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#1411

On 01/30/2019 02:01 PM, Computer Nerd Kev wrote:
> In comp.misc Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:
>> On 27.01.2019 19:58, Dirk T. Verbeek wrote:
>>> Op 26-01-19 om 17:58 schreef Juergen Nieveler:
>>>> Worst case, you can still use a proxy server
>>> Normal case, you use a good browser.
>>
>> If only there was one... Chrome and Edge will soon be frontends for the
>> same engine, Opera too, Safari never was a good browser to begin with,
>> and Firefox, while having the potential, pisses off users on a frequent
>> basis by adding suspicious stuff without warning. Remember when they
>> added advertising for "Mr Robot" by labeling it as "experiment"?
>
> I can think of a few "good" browsers, to my definition. The one I
> choose is Dillo, and it doesn't need any ad-blocker extensions.
>
> The problem is that the web in general is only designed for Chrome
> and Firefox (with the latter possibly under threat as well given
> its usage share), so the problem isn't finding good browsers, but
> finding a good web.

I'm noticing more and more websites that I've used for a long time 
having inoperative parts with Firefox but not with Chrome.  I hate 
Chrome, but I'm forced to use it.  Like the bad old days when everything 
was aimed at Internet Explorer.

Most recent annoyance is being unable to sort ebay results by price (or 
anything else) rather than 'best match'.


-- 
Cheers, Bev
    "Not everyone can be above average so why
     shouldn't we be the ones to suck?"
              --Anonymous School Board Member

[toc] | [prev] | [next] | [standalone]

#1460

On Saturday, January 26, 2019 at 7:57:12 AM UTC+3, !!Credit wrote:
> How many ad blocks could an ad slinger block if an ad slinger could block blocks?
> 
> <https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/>
> 
> Google engineers have proposed changes to the open-source Chromium browser that will break content-blocking extensions, including ad blockers.
> 
> If the overhaul goes ahead, Adblock Plus and similar plugins that rely on basic filtering will, with some tweaks, still be able to function to some degree, unlike more ambitious extensions, such as uBlock Origin, which will be harder hit. The drafted changes will limit the capabilities available to extension developers, ostensibly for the sake of speed and safety. Chromium forms the central core of Google Chrome, and, soon, Microsoft Edge.
> 
> In a note posted Tuesday to the Chromium bug tracker, Raymond Hill, the developer behind uBlock Origin and uMatrix, said the changes contemplated by the Manifest v3 proposal will ruin his ad and content blocking extensions, and take control of content away from users.
> 
> Content blockers may be used to hide or black-hole ads, but they have broader applications. They're predicated on the notion that users, rather than anyone else, should be able to control how their browser presents and interacts with remote resources.
> 
> Manifest v3 refers to the specification for browser extension manifest files, which enumerate the resources and capabilities available to browser extensions. Google's stated rationale for making the proposed changes, cutting off blocking plugins, is to improve security, privacy and performance, and supposedly to enhance user control.
> 
> "Users should have increased control over their extensions," the design document says. "A user should be able to determine what information is available to an extension, and be able to control that privilege."
> 
> But one way Google would like to achieve these goals involves replacing the webRequest API with a new one, declarativeNetRequest.
> 
> The webRequest API allows browser extensions, like uBlock Origin, to intercept network requests, so they can be blocked, modified, or redirected. This can cause delays in web page loading because Chrome has to wait for the extension. In the future, webRequest will only be able to read network requests, not modify them.
> 
> The declarativeNetRequest allows Chrome (rather than the extension itself) to decide how to handle network requests, thereby 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 documentation explains.
> 
> Whose privacy exactly?
> 
> But "better privacy" here means privacy as defined by Google rather than privacy defined by a third-party extension developer. That's fine in scenarios where Google is more trustworthy than a third-party developer; but if Google and its ecosystem of publishers and advertisers are the problem, then users may prefer allowing a third-party to filter network requests, even to the extent such intervention interferes with webpage functionality.
> 
> "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," said Hill.
> 
> The proposed changes will diminish the effectiveness of content blocking and ad blocking extensions, though they won't entirely eliminate all ad blocking. The basic filtering mechanism supported by Adblock Plus should still be available to some degree. But uBlock Origin and uMatrix offer more extensive controls, without trying to placate publishers through ad whitelisting, and thus have a little more to lose.
> 
> Don't forget, Google and other internet advertising networks pay Adblock Plus to whitelist their online adverts. Meanwhile, Google has bunged its own basic ad blocking into its browser.
> 
> Several other developers commenting on the proposed change expressed dismay, with some speculating that Google is using privacy as a pretext for putting the interests of its ad business over those of browser users.
> 
> Hill, who said he's waiting for a response from the Google software engineer overseeing this issue, said in an email to The Register: "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."
> 
> Hill observes that several other capabilities will no longer be available under the new API, including blocking media elements larger than a specified size, disable JavaScript execution by injecting Content-Security-Policy directives, and removing the outgoing Cookie headers.
> 
> And he argues that if these changes get implemented, Chromium will no longer serve users.
> 
> "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 web sites which obviously would be happy to have the last word in what resources their pages can fetch/execute/render," he said.
> 
> "With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical 'user agent' will still be a proper category to classify Chromium."
> 
> Google, however, may yet be willing to address developers' concerns. "These changes are in the design process, as mentioned in the document and the Chromium bug," a Google spokesperson told The Register via email. "Things are subject to change and we will share updates as available." ®
> 
> Updated to add
> 
> Following a huge outcry from plugin developers and netizens, Google has reiterated that the proposed changes are not set in stone, and are subject to revision. While the internet goliath wants to rein in the level of access granted to Chrome browser extensions, it is prepared to work through the messy matter with third-party coders – who will have to rewrite parts of their software if this all goes ahead.
> 
> Also, we're happy to clarify that while Adblock Plus is affected by the draft changes, it will not be whacked quite as hard as other more featureful extensions, such as uBlock Origin.
> 
> Indeed, the proposed API appears to promote ABP's simple filtering mechanism, rather than support the advanced content blocking other extensions offer. The sticking point is whether or not the proposed limit of 30,000 filter rules will be enough for the likes of Adblock Plus. ADP developers say it won't: their filter list has more than 70,000 entries.
> 
> "Adblock Plus is, of course, affected by this proposed change, because it would replace the main API that we (and almost all other content blockers) use to block requests with something a bit watered down," a spokesperson said.
> 
> "Even though we don't know the exact plans for this proposed change, should it get implemented we'll make sure ABP is available for Chrome users."

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.security.misc

csiph-web