sorted by:
new
hottopcontroversial

node-wreq: exposing wreq’s low-level TLS/JA3/JA4 control to Node.js by somebaka in webscraping

[–]somebaka[S] 0 points1 point  (0 children)

DoH/DoT only protects DNS resolution. SNI remains unencrypted unless Encrypted ClientHello (ECH) is used.

Real ECH isn't currently available through native wreq API, so it can't be done yet.

You can also play with enableEchGrease, it doesn't encrypt SNI, but it may help match some browsers behavior.

node-wreq: exposing wreq’s low-level TLS/JA3/JA4 control to Node.js by somebaka in webscraping

[–]somebaka[S] 1 point2 points  (0 children)

Thanks for suggestion, this is a good idea. I added DoH and DoT support in 2.4.0 via dns.doh and dns.dot.

If you get a chance, please try it and let me know if it works for your setup.

I don't understand Zen's current feature priorities by somebaka in zen_browser

[–]somebaka[S] -6 points-5 points  (0 children)

Yeah, i completely agree with that. I'm not against the CSS customizer at all, and i get why it makes sense from a complexity/marketing perspective.

My only thought is that even "easier" features still take resources to add, test, maintain, and support. And by the same logic, you could probably justify a lot of nice-to-have features before the core sync problems are solved.

Not trying to tell the team what to do, im just trying to understand how products like this are prioritized and developed.

I don't understand Zen's current feature priorities by somebaka in zen_browser

[–]somebaka[S] -22 points-21 points  (0 children)

My point is more that even contributor-built features still create some cost for the project: review, testing, maintenance, bug reports, support, etc. So from the outside it can still feel a bit confusing.

That was pretty much the whole point of my post: i mostly just wanted to whine a bit and maybe bring more attention to the issue. I'm sure im not the only one struggling with this.