What's new

pixelserv pixelserv - A Better One-pixel Webserver for Adblock

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I have tried the method above, and the slu count is now minimal. However I am now seeing adds where they had been blocked, specifically those delivered via www.googleadservices.com, even though if I click on the add I get 'Hmmm... cannot reach this page' and pinging www.googleadservices.com gets
'Ping request could not find host www.googleadservices.com. Please check the name and try again.' which is what I would expect with www.googleadservices.com is sitting in hosts.add.

I am guessing that as the ads are using redirect and www.googleadservices.com is in my whitelist, diversion/pixelserv are allowing the ads to show. For this sort of ad redirect, do I need to remove the site from the whitelist & hosts.add (and get the slu errors) or is there another way to do this?
Post the contents of hosts.add.
 
Post the contents of hosts.add.
Code:
0.0.0.0     addelivery-engine-api.voodoo-ads.io
0.0.0.0     ads.mopub.com
0.0.0.0     ads.samsungads.com
0.0.0.0     analytics.query.yahoo.com
0.0.0.0     api.gameanalytics.com
0.0.0.0     api2.branch.io
0.0.0.0     app.adjust.com
0.0.0.0     app-measurement.com
0.0.0.0     browser.pipe.aria.microsoft.com
0.0.0.0     cdn.optimizely.com
0.0.0.0     cdp.cloud.unity3d.com
0.0.0.0     cfg.cml.ksmobile.com
0.0.0.0     cmdts.ksmobile.com
0.0.0.0     config.uca.cloud.unity3d.com
0.0.0.0     cprd1.samsungcloudsolution.net
0.0.0.0     data.flurry.com
0.0.0.0     ds.samsungads.com
0.0.0.0     e.crashlytics.com
0.0.0.0     front-logs.voodoo-ads.io
0.0.0.0     gate.hockeyapp.net
0.0.0.0     googleads.g.doubleclick.net
0.0.0.0     lcprd1.samsungcloudsolution.net
0.0.0.0     m.yap.yahoo.com
0.0.0.0     mobile.launchdarkly.com
0.0.0.0     mobile.pipe.aria.microsoft.com
0.0.0.0     nexus.officeapps.live.com
0.0.0.0     nexusrules.officeapps.live.com
0.0.0.0     p.presage.io
0.0.0.0     pp-measurement.com
0.0.0.0     reports.crashlytics.com
0.0.0.0     rt.applovin.com
0.0.0.0     rt.applvn.com
0.0.0.0     rubick.gameanalytics.com
0.0.0.0     sb.scorecardresearch.com
0.0.0.0     sdk.hockeyapp.net
0.0.0.0     securepubads.g.doubleclick.net
0.0.0.0     settings.crashlytics.com
0.0.0.0     sourcepoint.vice.com
0.0.0.0     ssl.google-analytics.com
0.0.0.0     telemetry.dropbox.com
0.0.0.0     track.tenjin.io
0.0.0.0     ups.ksmobile.net
0.0.0.0     vortex.data.microsoft.com
0.0.0.0     www.googleadservices.com
 
I don't use anything, Diversion's blocking via 0.0.0.0 does enough!

Hey Jack,

As I understand it, the logic behind pixelserv-TLS was that redirecting traffic to a real http/https site was "faster" for Web Browsers to deal with, rather than a 0.0.0.0 blackhole. The author had posted some benchmarks to prove that point.

What are your thoughts - were you able to do any benchmarking to determine if 0.0.0.0 is actually not that bad in terms of performance?
 
Hey Jack,

As I understand it, the logic behind pixelserv-TLS was that redirecting traffic to a real http/https site was "faster" for Web Browsers to deal with, rather than a 0.0.0.0 blackhole. The author had posted some benchmarks to prove that point.

What are your thoughts - were you able to do any benchmarking to determine if 0.0.0.0 is actually not that bad in terms of performance?
The thing about this whole issue is that the facts and realities that relate to it are ever evolving. In prior years, the scenario was generally that pointing to 0.0.0.0 would result in some slowdowns because the browser would hang because it was waiting for such and such thing to reply, which wasn’t happening because of the redirection. This is where ps-tls came in. Rather than leave the browser in the lurch, ps-tls would “elegantly” reply to the request with a dummy/placeholder pixel, resulting in the speedier experience you were referencing.

However, as the cat and mouse game evolves, ad servers have become wise to that approach and now are coding checks into things and when they detect that it’s a dummy rather than the real ad server that was reached, there are consequences. What consequences, varies from situation to situation. Anecdotally, I’ve noticed that some things when the handshake fails (detects the ps-tls dummy response rather than the real thing) it will just keep spamming connection requests, resulting in a less smooth user experience. So the times, they are a changin’.

In short, because of that coupled with the effects of a changing landscape (stricter certificate requirements for one example) and lack of apparent support from its majority author in the recent months/year, many folks at least as it pertains to this SNB community (read @thelonelycoder / Diversion specifically) are moving away from ps-tls because it’s starting to cause as many or more problems than it solves. This isn’t anyone’s fault in particular, just the truth of the matter in trying to stay ahead of professional ad servers.
 
In short, because of that coupled with the effects of a changing landscape (stricter certificate requirements for one example) and lack of apparent support from its majority author in the recent months/year, many folks at least as it pertains to this SNB community (read @thelonelycoder / Diversion specifically) are moving away from ps-tls because it’s starting to cause as many or more problems than it solves. This isn’t anyone’s fault in particular, just the truth of the matter in trying to stay ahead of professional ad servers.

Thanks for the detailed response. According to your signature, you still use ps-tls though?

I wonder at what point can we reach a general consensus that Diversion is best used without ps-tls ...
 
Thanks for the detailed response. According to your signature, you still use ps-tls though?
I do. However, I use it in, for lack of a better way of explaining it, non-tls mode. That is, certificates not imported in any devices. I won't drag out the entire rant/explanation for why, but the gist is that a completed ps-tls handshake was crashing some apps that the family informs me are required, and curiously they work fine redirected to ps-tls so long as the tls handshake isn't attempted. So for me, this is the best of both worlds. To be frank, from where I sit I think the most desirable future might be with unbound, but that's a whole can of worms I don't want to open at the moment honestly. What I will say, is that even as early as well over a year ago, a handful of people originally from this forum were experimenting with it and the initial results were noticeably better than the current dnsmasq/ps-tls solution. Since that time I've seen a lot of unbound activity pop up here, so I remain waiting and watching, planning the next move. At the present time, ps-tls with no tls is serving me well.
I wonder at what point can we reach a general consensus that Diversion is best used without ps-tls ...
I don't wish to put words into anyone's mouth, but I suspect based on things I've read here that in the long term that decision will probably be made for you, eventually.
 
I have temporarily disabled pixelserv mainly due to problems with the Amazon app (it's mainly for the wife haha). We'll continue to monitor ...
 
I run Diversion without ps-tls for many of the reasons here. I did some tests yesterday with Unbound and Adblock, and cannot load the Large list, much less run it.

For users with more complex and performance in mind, Diversion with Large list without ps-tls wins for blocks (both ads dn youtube) on my Merlin built devices.

cheers
 
@Jack Yaz

So, have you just disabled PixelServ (1, ep, 1) and Diversion running as before?
Any other cleanup needed other than this disabling?

I am having issues with my AppleTV; continuously giving error on Amazon Prime Video...
When disabling pixelserv-tls with ep, 1, Diversion puts itself into a state as if the Diversion Lite Edition were installed.
The blocking IP auto-changes to the null IP 0.0.0.0. and that's all one has to do.
 
I don't use anything, Diversion's blocking via 0.0.0.0 does enough!
that was what put the nail in the coffin for me!
Code:
aan.amazon-adsystem.com
aan.amazon.com
aax.amazon-adsystem.com
aax-eu.amazon-adsystem.com
aax-us-east.amazon-adsystem.com
aax-us-pdx.amazon-adsystem.com
amazonaws.com
amazon.com
amazon.co.uk
amazon.in
amzn.com
amzn.to
cognito-identity.us-east-1.amazonaws.com
completion.amazon.co.uk
det-ta-g7g.amazon.com
device-messaging-na.amazon.com
device-metrics-us-2.amazon.com
device-metrics-us.amazon.com
fls-eu.amazon.com
fls-eu.amazon.de
fls-na.amazon-adsystem.com
fls-na.amazon.com
images-na.ssl-images-amazon.com
ir-na.amazon-adsystem.com
ir-uk.amazon-adsystem.com
kinesis.us-east-1.amazonaws.com
mads.amazon-adsystem.com
mads.amazon.com
mas-sdk.amazon.com
ocsp.rootg2.amazontrust.com
s3.amazonaws.com
s3.ap-northeast-2.amazonaws.com
s3.ap-south-1.amazonaws.com
s3-ap-southeast-1.amazonaws.com
s3-eu-west-1.amazonaws.com
s3-us-west-2.amazonaws.com
s.amazon-adsystem.com
smile.amazon.com
spectrum.s3.amazonaws.com
sqs.us-east-1.amazonaws.com
unagi-na.amazon.com
us-east-1.amazonaws.com
this was my magic pill whitelist for amazon. (the wife hasn't complained- proud amazon prime household). i suspect regionally each user would see a couple of more that i don't have listed.
 
Code:
aan.amazon-adsystem.com
aan.amazon.com
aax.amazon-adsystem.com
aax-eu.amazon-adsystem.com
aax-us-east.amazon-adsystem.com
aax-us-pdx.amazon-adsystem.com
amazonaws.com
amazon.com
amazon.co.uk
amazon.in
amzn.com
amzn.to
cognito-identity.us-east-1.amazonaws.com
completion.amazon.co.uk
det-ta-g7g.amazon.com
device-messaging-na.amazon.com
device-metrics-us-2.amazon.com
device-metrics-us.amazon.com
fls-eu.amazon.com
fls-eu.amazon.de
fls-na.amazon-adsystem.com
fls-na.amazon.com
images-na.ssl-images-amazon.com
ir-na.amazon-adsystem.com
ir-uk.amazon-adsystem.com
kinesis.us-east-1.amazonaws.com
mads.amazon-adsystem.com
mads.amazon.com
mas-sdk.amazon.com
ocsp.rootg2.amazontrust.com
s3.amazonaws.com
s3.ap-northeast-2.amazonaws.com
s3.ap-south-1.amazonaws.com
s3-ap-southeast-1.amazonaws.com
s3-eu-west-1.amazonaws.com
s3-us-west-2.amazonaws.com
s.amazon-adsystem.com
smile.amazon.com
spectrum.s3.amazonaws.com
sqs.us-east-1.amazonaws.com
unagi-na.amazon.com
us-east-1.amazonaws.com
this was my magic pill whitelist for amazon. (the wife hasn't complained- proud amazon prime household). i suspect regionally each user would see a couple of more that i don't have listed.

I believe, I already half of these WL...let me try those new ones and I'll enabled pixelserv again and will report back. Wish me luck...

is this an easy copy and paste using WinSCP?
 
I believe, I already half of these WL...let me try those new ones and I'll enabled pixelserv again and will report back. Wish me luck...

is this an easy copy and paste using WinSCP?
Yes, but you must process the list in el after.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top