181–190 of 396 posts
Earlier quoted context omitted.
but sadly Group Policy is not available on Windows Home edition
In most cases, you can get group policies like these to work if you manually create the registry keys that GPO would create for you. It's more complicated, but it can work.
To anyone saying "just use Firefox", I would think again. I think Firefox is (marginally) better than Chrome, but they are also pulling some of the same bullshit: https://github.com/mozilla-mobile/fenix/issues/20736
Calling firefox marginally better than chrome is just dishonest, and frankly ridiculous.
While a good message that does have actual merit if you know what's happening already, I don't see how this is a legitimate consideration of MV3. The entire argument regarding security doesn't mention any of the reasons Chrome developers cite its security improvement, instead it brings up that Firefox "does good enough already" and that malicious extensions can still get past the review process. the review process is…
[1] I am well aware that was not the original context of the quote, but it's a nice rallying cry of the sentiment behind the movement.
Earlier quoted context omitted.
Yes. Next you'll have to MiTM the DNS over HTTPS. Next in the arms race comes certificate-pinning. Controlling your name resolution will probably remain possible on Linux, but I expect most other platforms will make it exceedingly difficult for "normal" users. Embedded devices are already "game over". You don't own them (even if you paid for them). Controlling name resolution on your own network (and MiTM'ing HTTPS)…
> Embedded devices are already "game over". You don't own them (even if you paid for them). Ugh, seriously. I have a Chromecast, and couldn't figure out why it wouldn't play things on my local network (via DNS names set up in my router's resolver). Turns out Google hard-codes their own DNS servers and doesn't allow you to change them. The fix was to give the Chromecast a reserved IP address, and then set up some ipta…
Earlier quoted context omitted.
Google has not provided any reason to not include "block request" functionality. And that the super bad faith underlying fact that poison their "reasoning".
There is still "block request" functionality, the change is that it's now declarative. This is the same way it works in Safari, and is (a) more efficient because you don't need to execute JS to evaluate each request and (b) more private because an ad/content blocker doesn't need to be given such broad permissions. There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and…
This is somewhat debunked in the article of this post.
> the change is that it's now declarative.
In the App MANIFEST. To my understanding, each update of those lists will require an app update (going through Store approval process).
If only it would have been dynamic, the end result would have been much better.
And again, there is no reason to disable dynamic updates if they are only lists of blocked URLs.
Earlier quoted context omitted.
Google has not provided any reason to not include "block request" functionality. And that the super bad faith underlying fact that poison their "reasoning".
There is still "block request" functionality, the change is that it's now declarative. This is the same way it works in Safari, and is (a) more efficient because you don't need to execute JS to evaluate each request and (b) more private because an ad/content blocker doesn't need to be given such broad permissions. There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and…
Thank you for letting us know you have a giant material conflict of interest and we shouldn't trust anything you say.
Earlier quoted context omitted.
There is still "block request" functionality, the change is that it's now declarative. This is the same way it works in Safari, and is (a) more efficient because you don't need to execute JS to evaluate each request and (b) more private because an ad/content blocker doesn't need to be given such broad permissions. There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and…
I’m sure you are an honest person working in good faith. But we saw very similar behavior from Google around AMP. They had a very narrow reasonable sounding explanation, and just ignored all criticism and requests from both users and publishers that didn’t fit their narrative. This went on for years. Today we know AMP was also a anticompetitive plot to kill off header bidding. Why should we to believe a word of what…
I completely disagree, and I think this will become clear as information continues to come out.
Earlier quoted context omitted.
There is still "block request" functionality, the change is that it's now declarative. This is the same way it works in Safari, and is (a) more efficient because you don't need to execute JS to evaluate each request and (b) more private because an ad/content blocker doesn't need to be given such broad permissions. There are serious tradeoffs (no request time js makes it less flexible) but it's still very capable and…
The safari change absolutely kneecapped content blockers. Ublock dropped it[0], and the remaining few providers, like AdGuard, have to do all sorts of trickery[1] to get even close to the same performance. If you're going to argue this is better, don't point us to such a clearly worse result. [0]: https://github.com/el1t/uBlock-Safari/issues/158 [1]: https://adguard.com/en/blog/safari-adblock-extensions.html
While a good message that does have actual merit if you know what's happening already, I don't see how this is a legitimate consideration of MV3. The entire argument regarding security doesn't mention any of the reasons Chrome developers cite its security improvement, instead it brings up that Firefox "does good enough already" and that malicious extensions can still get past the review process. the review process is…
I didn't see dissecting the security details as the point they were trying to make. Instead it was to partially undermine the reasons Google said they were doing this.
Basically "here's why it's bad for privacy, and here are why Google's stated reasons for the update are insufficient to justify that"