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!

We're off-topic, so if there's anything wrong with this please point me at another thread: each of my two AC86Us has a LAN-only OpenVPN server to allow my remote access to it, and the .OVPN files are identical -- same keys -- except for the "remote" field, i.e., DDNS domain name specific to that router.
Slightly off topic, yes, but in the same spirit as what @thelonelycoder was pointing out. If you have two 86Us each with diversion/pixelserv running, it is convenient to generate one certificate and use it for both. My experience with Chromebooks is that importing two certificates with the same name will cause the first to be overwritten. I have one 86U with two servers running, and they would otherwise have two different certs, so I have to copy them over so that I can connect to either using the same certificate. I think your experience must be similar, in that with a Chromebook if your cert was different you could only connect to one of the LANs.
 
OK, if I understand correctly, I'm all set even though there are currently no Chromebooks in my life. I am using the same cert on both AC86Us for pixelserv-tls, and the same cert on both for OpenVPN server.
 
OK, if I understand correctly, I'm all set even though there are currently no Chromebooks in my life. I am using the same cert on both AC86Us for pixelserv-tls, and the same cert on both for OpenVPN server.
That's my view, except for the part about no Chromebooks. Off topic, I say that 7 days without power or internet and just back.
 
On my mobile phone, I now get the net:err_cert_validity_too_long error with a chromium 85 browser. Can we get a configurable cert validity length option?
 
On my mobile phone, I now get the net:err_cert_validity_too_long error with a chromium 85 browser. Can we get a configurable cert validity length option?
Have you recreated your cert? Any cert trying to go over 39 months will cause this.
 
Have you recreated your cert? Any cert trying to go over 39 months will cause this.
Since September 1 it's now down to 13 months. Apple started it. Google and Mozilla followed.

 
Since September 1 it's now down to 13 months. Apple started it. Google and Mozilla followed.

Thats what I get for "googling" the error and clicking first URL...from 2017. :oops:
 
^^^ 99% of computer users have NO CLUE about certificates, what they enable or how powerful they are when in the wrong hands. We might as well get used to regenerating these yearly to stay ahead of this mess.. Apple is creating. While I understand the reasoning, it's going to cost a pretty $$$. Just maintaining cert generation at large companies will be a full-time job - especially since most do not like to use "wildcard" certs due to their own security rules. All those devices.. wow.. makes my head really ache.

Jack if you do "spring into action", 12 months should become the default for all the AMTM tooling. Just my .02. If the community decides it's time to sunset PixelServlTLS then that's OK too. I think the community should determine how effective it will be and how many people will actually re-gen certs properly yearly now.
 
Last edited:
Or maybe it's time to retire pixelserv-TLS?

I used to be a big proponent of using pixelserv-TLS, and defended its use over the spring/summer in the Diversion thread. I even tried to help a few people creating exemptions so that apps like "Amazon" would work on their mobile devices. (if you route certain problematic domains to 0.0.0.0 instead of the pixelserv IP, you can get the Amazon app to work properly, for the most part).

HOWEVER:

I spent the last 3 weeks with pixelserv-TLS disabled, with my household essentially running in Diversion "Lite" mode. I have not noticed any difference in "performance" of adblocking, and neither have my other household members. Therefore, I'll be keeping pixelserv-TLS disabled for the foreseeable future.
 
Or maybe it's time to retire pixelserv-TLS?

I used to be a big proponent of using pixelserv-TLS, and defended its use over the spring/summer in the Diversion thread. I even tried to help a few people creating exemptions so that apps like "Amazon" would work on their mobile devices. (if you route certain problematic domains to 0.0.0.0 instead of the pixelserv IP, you can get the Amazon app to work properly, for the most part).

HOWEVER:

I spent the last 3 weeks with pixelserv-TLS disabled, with my household essentially running in Diversion "Lite" mode. I have not noticed any difference in "performance" of adblocking, and neither have my other household members. Therefore, I'll be keeping pixelserv-TLS disabled for the foreseeable future.
While I have not abandoned hope and still run pixelserv-tls on my devices, I see the end coming of this being effective in the long run with requirements for (self) generated certificates increasing and/or being accepted in devices/apps or browsers.
 
While I have not abandoned hope and still run pixelserv-tls on my devices, I see the end coming of this being effective in the long run with requirements for (self) generated certificates increasing and/or being accepted in devices/apps or browsers.
Though the certificate requirements being a moving target does have its own considerations, the actual issue reducing the usefulness of pixelserv-tls is that advertisers and developers are increasingly becoming wise to the blocking mechanism and are coding apps/etc to check for a valid server handshake using included certificate payloads. The amount of things that need to be whitelisted to work is growing and becoming not worth the effort, in my opinion. I use ps-tls still, but without the certificate setup.
 
I use ps-tls still, but without the certificate setup.

so essentially you use it as "pixelserv" rather than pixelserv-TLS?

is that really an improvement over 0.0.0.0 host blocking though?

When I disabled pixelserv-TLS and went back to plain 0.0.0.0 host blocking via Diversion, I did not notice any web page performance differences.
 
so essentially you use it as "pixelserv" rather than pixelserv-TLS?

is that really an improvement over 0.0.0.0 host blocking though?
Yes, that would be generally accurate. Performance wise it’s the same, but I use pixelserv for some logging, troubleshooting and statistics purposes.
 
Need some help, please... just noticed this issue with pixelserv on my router:

AX88 with 384.19 - and htop is reporting pixelserv-tls at 39% to 49% CPU utilization. - GUI shows running up of all 4 cores... Also, uiDivStats is displaying Percent-Blocked at 99.2%...

Seems all was normal until I applied entware update of a few days ago - but that's just observation on my part...

up until that entware update, I had over 21 days of stable 384.19 on the AX88... any insight or thoughts would be appreciated...

Thanks in advance...
 
Last edited:
Yes, that would be generally accurate. Performance wise it’s the same, but I use pixelserv for some logging, troubleshooting and statistics purposes.
I thought there was a performance boost just from the fact that pixelserv returned a response, instead of the request timing out.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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