From Newsgroup: comp.security.misc

On 2019-01-26, !!Credit <payroll@qi3.com> 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.

Get a PiHole.

https://pi-hole.net/

--
Today is Sweetmorn, the 26th day of Chaos in the YOLD 3185
~ Stercus accidit ~
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

Huge <Huge@nowhere.much.invalid> wrote in news:gb2sisF6n6dU1@mid.individual.net:

On 2019-01-26, !!Credit <payroll@qi3.com> 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_cont >>ent_block_change/>

Google engineers have proposed changes to the open-source Chromium
browser that will break content-blocking extensions, including ad
blockers.

Get a PiHole.

https://pi-hole.net/

google won't be happy till they control your entire life. Google is a totalitarian nightmare.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

-----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
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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 ~
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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"?

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--
__ __
#_ < |\| |< _#
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

Huge <Huge@nowhere.much.invalid> wrote:

On 2019-01-26, !!Credit <payroll@qi3.com> 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.

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? <https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

--
^�^ My pet rock Gordon just is.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

In comp.misc, Sn!pe <snipeco.1@gmail.com> wrote:

Get a PiHole.
<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? <https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

Does your hosts file solution work for everything on your network?
Usually it is difficult to implement that sort of thing on phones and
tablets.

Of course, if you only have the one network connected device, adding in
a second just to do DNS is overkill.

Elijah
------
pi-hole also advertises it works for "smart" TVs
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-01, Sn!pe <snipeco.2@gmail.com> wrote:

Huge <Huge@nowhere.much.invalid> wrote:

On 2019-01-26, !!Credit <payroll@qi3.com> 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.

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS?
<https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

I'll let you know definitively soon, since my PiHole hardware arrived
a couple of days ago, and I already run a fairly large hosts file (incorporating the MVPS one), presently [tap, tap, tap] some 18,000
hosts. The PiHole one is larger and it has the ability to blackhole
entire domains, without having to add individual machines, saving
pain like having to add;

0.0.0.0 a.spammingfucks.com
0.0.0.0 b.spammingfucks.com
0.0.0.0 c.spammingfucks.com
0.0.0.0 d.spammingfucks.com
0.0.0.0 e.spammingfucks.com

And so on. Also, the PiHoles lists are automatically updated, saving
me having to do it.


--
Today is Boomtime, the 32nd day of Chaos in the YOLD 3185
~ Stercus accidit ~
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-01, Eli the Bearded <*@eli.users.panix.com> wrote:

In comp.misc, Sn!pe <snipeco.1@gmail.com> wrote:

Get a PiHole.
<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS?
<https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

Does your hosts file solution work for everything on your network?

Yes. Well, everything that uses local DNS. At present, my DHCP
server refers everything that asks for a DNS server to my local
server (dnsmasq) which has an 18,000 line file I made from as many
places as I could find blocklists, plus any I've come across since.
So, if you attach to my network (actually, networks, plural) you
get my DNS.

Usually it is difficult to implement that sort of thing on phones and tablets.

Using the DNS approach, it doesn't matter what the client hardware
is.

Of course, if you only have the one network connected device, adding in
a second just to do DNS is overkill.

Indeed, but there are probably around ~20 hosts on my home networks,
and don't forget about the Internet-of-Chinese-tat stuff that's spying
on you, which can also be blocked this way.


--
Today is Boomtime, the 32nd day of Chaos in the YOLD 3185
~ Stercus accidit ~
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 01.02.2019 01:25, Sn!pe wrote:

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? <https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

Much better, as it protects ALL devices in your network. Try editing the
hosts file on an iPad ;-)

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

Eli the Bearded <*@eli.users.panix.com> wrote:

In comp.misc, Sn!pe <snipeco.1@gmail.com> wrote:

Get a PiHole.
<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? <https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

Does your hosts file solution work for everything on your network?
Usually it is difficult to implement that sort of thing on phones and tablets.

Of course, if you only have the one network connected device, adding in
a second just to do DNS is overkill.

Elijah
------
pi-hole also advertises it works for "smart" TVs

Indeed. I have it set up for each computer and it's true that
this solution doesn't work for my Apple phones or tablets.

--
^�^ My pet rock Gordon just is.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

Juergen Nieveler <Juergen.Nieveler@gmail.com> wrote:

On 01.02.2019 01:25, Sn!pe wrote:

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? <https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

Much better, as it protects ALL devices in your network. Try editing the hosts file on an iPad ;-)

Indeed!

--
^�^ My pet rock Gordon just is.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-01, Eli the Bearded <*@eli.users.panix.com> wrote:

Does your hosts file solution work for everything on your network?
Usually it is difficult to implement that sort of thing on phones and tablets.

I don't have any smartphones or tablets.

Of course, if you only have the one network connected device, adding in
a second just to do DNS is overkill.

Indeed. (Actually I have a few Linux PCs. It's easy enough to implement the hosts file solution on them but I can see the DNS black hole would be convenient.)

-- -----------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

NSA sedition and treason -- http://www.DeathToNSAthugs.com
Don't talk to cops! -- http://www.DontTalkToCops.com
Badges don't grant extra rights -- http://www.CopBlock.org ----------------------------------------------------------------------------- --- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

snipeco.2@gmail.com (Sn!pe) writes:

Huge <Huge@nowhere.much.invalid> wrote:

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? ><https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

The pi-hole will work for every device in your network. Ie. your
smartphone, tablet, smarttv, etc. etc. whatever you have connected and
is setup to show ads.
The hosts file will be just the single machine you put it on.

While I don't have any numbers on if a huge hosts file slows down your
network activity, I'd expect that the lookup using a huge hosts file is probably a bit slower than the DNS lookup purpose built algorithms.
If that is noticible enough or not is questionable.



--
Doug McIntyre
doug@themcintyres.us
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

In comp.misc Doug McIntyre <merlyn@dork.geeks.org> wrote:

snipeco.2@gmail.com (Sn!pe) writes:

Huge <Huge@nowhere.much.invalid> wrote:

Get a PiHole.

<https://pi-hole.net/>

Is that better than a hosts file such as is offered by MVPS? >><https://mvpshostsnews.blogspot.com>
I find it works well, is easy to set up and needs no extra hardware.

The pi-hole will work for every device in your network. Ie. your
smartphone, tablet, smarttv, etc. etc. whatever you have connected and
is setup to show ads.
The hosts file will be just the single machine you put it on.

Yes, though on my network all the devices are PCs with easily
writable hosts files anyway. Plus the software running on all
of them is set up not to show ads. But I just don't like
networked devices running software that I can't control in the
first place. I pay for those bytes, so I'll decide how my money
is spent!

While I don't have any numbers on if a huge hosts file slows down your network activity, I'd expect that the lookup using a huge hosts file is probably a bit slower than the DNS lookup purpose built algorithms.
If that is noticible enough or not is questionable.

Looking into it back in the FF 3.6 days, there was a rumour that a
huge hosts file caused Firefox to at least be slower to load because
it builds its own cache of the file at start-up. I decided that it
wasn't worth finding out given that script blockers and lightweight
web browsers got me where I want to be anyway.

I do have some entries on most computers blocking Facebook and
Twitter domains to stop them loading the stupid social media
icons on pages from their servers (which is a stupid way to
design a website anyway). Plus there are some on certain computers
put in when a particular service really annoys me for some reason,
it makes me feel better at least.

--
__ __
#_ < |\| |< _#
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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

--
_____________________________________
/ "Today, of course, it is considered \
| very poor taste to use the F-word |
| except in major motion pictures." |
| |
\ -- Dave Barry, "$#$%#^%!^%&@%@!" /
-------------------------------------
\
\
/\ /\
//\\_//\\ ____
\_ _/ / /
/ * * \ /^^^]
\_\O/_/ [ ]
/ \_ [ /
\ \_ / /
[ [ / \/ _/
_[ [ \ /_/

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-17, 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,

Sigh.

stop using Chrome and any other google products and services

As well as ...


--
Today is Pungenday, the 48th day of Chaos in the YOLD 3185
'O you who turn the wheel and look to windward, Consider Phlebas,
who was once handsome and tall as you.'
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-18, 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.[9] Other parts
are subject to a variety of licenses, including MIT, LGPL, Ms-PL, and an MPL/GPL/LGPL tri-license.[10]"

<https://en.m.wikipedia.org/wiki/Chromium_(web_browser)>

And even if it were, the point is dumb, since Google isn't the only
company spying on you. Only four of the top blocked domains on my
PiHole (using the default blocklists) belong to Google. The other
six are other companies, so "stopping using Chrome" just gives
you a false sense of security.


--
Today is Prickle-Prickle, the 49th day of Chaos in the YOLD 3185
'O you who turn the wheel and look to windward, Consider Phlebas,
who was once handsome and tall as you.'
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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.

--
__ __
#_ < |\| |< _#
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

In comp.misc Huge <Huge@nowhere.much.invalid> wrote:

On 2019-02-18, 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.[9] Other parts
are subject to a variety of licenses, including MIT, LGPL, Ms-PL, and an
MPL/GPL/LGPL tri-license.[10]"

<https://en.m.wikipedia.org/wiki/Chromium_(web_browser)>

And even if it were, the point is dumb, since Google isn't the only
company spying on you. Only four of the top blocked domains on my
PiHole (using the default blocklists) belong to Google. The other
six are other companies, so "stopping using Chrome" just gives
you a false sense of security.

Seems wise enough if you then switch to a browser that really does
protect your privacy by design, giving up access to many popular
websites in the process.

--
__ __
#_ < |\| |< _#
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

On 2019-02-18, Computer Nerd Kev <not@telling.you.invalid> wrote:

In comp.misc Huge <Huge@nowhere.much.invalid> wrote:

On 2019-02-18, 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.[9] Other parts >>> are subject to a variety of licenses, including MIT, LGPL, Ms-PL, and an >>> MPL/GPL/LGPL tri-license.[10]"

<https://en.m.wikipedia.org/wiki/Chromium_(web_browser)>

And even if it were, the point is dumb, since Google isn't the only
company spying on you. Only four of the top blocked domains on my
PiHole (using the default blocklists) belong to Google. The other
six are other companies, so "stopping using Chrome" just gives
you a false sense of security.

Seems wise enough if you then switch to a browser that really does
protect your privacy by design,

Precisely.


--
Today is Prickle-Prickle, the 49th day of Chaos in the YOLD 3185
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.security.misc

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

--- Synchronet 3.17c-Linux NewsLink 1.110