[X] My Assistant

Try going to the domain again.

Yeah, I tried that again and it still just gives me the too many redirects error, this is using the https version btw.

Is the fact that alt.hentaiverse.org is still http only and incompatible with https, a feature, or something on a todo list?

edit: this answered my question, thanks

This post has been edited by uareader: Apr 10 2020, 21:16

I don't have any particular plans to add HTTPS for alt, it requires a different software stack than what it's currently using and would at least partially offset the entire point of having it (i.e. speed).

I can't see the reason why I should not use Chrome in the first place.

As others have said,Google. It is one of the biggest supporters of Big Data along with law enforcement, insurers, and lifestyle statistics aggregators. As an example of how google's automated data collection can result in a Big Data prediction, the google search results for stores (when you are moving about on the map) shows when each store, service center, or facility opens, closes, and its amount of visitors across the day. It knows when you close because there are a bunch of google android cellphones walking inside the store suddenly at 8AM and then only a few wandering android phones (of employees) after 9PM so it concludes that the facility has closed at 9PM.

Google has been mapping insides of stores too such as the aisles are even marked. I used to be a frequent reviewer on google's store/restaurant reviewer service, so I'd see all sorts of amusing things like that. Google even knew when I was inside my local Costco's food court and how long I was there eating and not just the other parts of Costco in general. I remember seeing that stat item about myself back when google did allow me to see. I have GM OnStar and for a time, GM did list in my account all sorts of things like usage of turn signals and how many hard braking situations occurred each day. I was even able to see charts of my data showing uptrends and downtrends on safety item predictions. But then GM suddenly closed off such access to me despite having registered as a member of their beta items review group.

So, you should be concerned about Big Data. There are ways to shove it down your throat too to make you the consumer pay via unforeseen consequences. For example, there are some sites that check if someone has dropped your email (anyone hate you) into a CP site. Then, if you go to a site like MYLIFE which puts together Big Data packages and summary conclusions about that person for sale, you see that if you have adverse info, you can block display of it by paying a subscription fee. During the preparation of MYLIFE data on a request, you see if a person is suspected of accessing a CP site or not and MYLIFE will stamp that flag onto data it sells. To temporarily block that flag from sold data, the person can buy an annual subscription. This is like blackmail. So, you see how even if you don't care about Google Big Data, that carelessness may come back to haunt you when you use a site like sad panda and make comments or vote on comments here and there. But eventually, you may find Big Data firms registering spider accounts at any place that has a "low lolicon" or "lolicon" tag and then it will record the account names of any user that has commented in gallery comments. It then goes to the forum sites and as well as internet headers of USENET, general ISP forum posts, or wherever to try to correlate a name to an email to an ISP. Or they can purchase the data from google since as you know, google makes most of its huge money from leveraging its big data.

If the former, only if you're behind a proxy or firewall that breaks HTTPS connections to non-standard ports.

If the latter, the short answer is that running H@H on port 443 is recommended if possible, but comes with some complications on some systems.

Seeing as Port 443 is recommended and will benefit visitors behind a restricted firewall i'd want to run my clients on this port.

But i think i might be one of an edge-case since i'm running my clients on a cluster of servers which already uses port 80/443 for other services. Is there a possibility to route traffic intended for H@H to the H@H client?

To add some context. I've just added three clients in one of my kubernetes cluster and in theory can use the kubernetes ingress controller to setup routing so requests can go over a shared port (443 in this case), but as far as i know the clients seem to use a randomly generated/assigned hostname.

Is there a possibility to extract the hostname for the assigned client(s) so clients can run on port 443 on machines who already have something running on 443?

Seeing as Port 443 is recommended and will benefit visitors behind a restricted firewall i'd want to run my clients on this port.

But i think i might be one of an edge-case since i'm running my clients on a cluster of servers which already uses port 80/443 for other services. Is there a possibility to route traffic intended for H@H to the H@H client?

To add some context. I've just added three clients in one of my kubernetes cluster and in theory can use the kubernetes ingress controller to setup routing so requests can go over a shared port (443 in this case), but as far as i know the clients seem to use a randomly generated/assigned hostname.

Is there a possibility to extract the hostname for the assigned client(s) so clients can run on port 443 on machines who already have something running on 443?

With the recent (?) changes for H@H HTTPS reverse proxying has become quite easy

You can place a reverse proxy an add a vhost for *.hath.network.

With the recent (?) changes for H@H HTTPS reverse proxying has become quite easy

You can place a reverse proxy an add a vhost for *.hath.network.

Yeah, but i'm running multiple clients in the same cluster so i can't just easily drop a wildcard to route it to the correct pod/instance.


EDIT: Found a workaround in (my) kubernetes cluster which allows me to serve all clients over 443.

This post has been edited by mrprozac: May 16 2020, 16:57

EDIT: Found a workaround in (my) kubernetes cluster which allows me to serve all clients over 443.

I'm an nginx junkie so my solution would use that. i.e. another option is to have a listen directive for every IP of the server. e.g. one server with listen 1.2.3.4:443 and in there do a route to *hath.network for one client; and then another server with listen 4.3.2.1:443 and another route (server_name) to *.hath.network for the second H@H client; and so on.

But if kubernetes can do it then why not.

I'm an nginx junkie so my solution would use that. i.e. another option is to have a listen directive for every IP of the server. e.g. one server with listen 1.2.3.4:443 and in there do a route to *hath.network for one client; and then another server with listen 4.3.2.1:443 and another route (server_name) to *.hath.network for the second H@H client; and so on.

But if kubernetes can do it then why not.

I'm with you on the nginx rabu. Kubernetess can use multiple type of 'ingress' controllers, but i stick with nginx for the ingress routing. But the way kube works is that you can pass it one or more ingress routes for a deployment and it'll route all incoming traffic through the ingress controller to the assigned pod.

If you're only running one client you can go the wildcard route and route all traffic on *.hath.network to said pod. But if you're running one client on every worker node (like i have right now) this becomes a bit harder.

But setting up a floating IP for all other traffic and have the nodes serve H@H on their 443 port works for me. This way all other containers running though nginx ingress remain online with HTTPS and H@H also runs on all nodes on 443.

But if it were possible to grab the assigned hostname from the client one could relatively easily create a docker container & deployment files to easily deploy hath to kubernetes.

This post has been edited by mrprozac: May 16 2020, 18:34

how much overhead does https on image servers add exactly?

forcing https on everything especially static content is excessive...
another day, another monopoly shoving BS, sigh.

how much overhead does https on image servers add exactly?

About 4-5 kB and two roundtrips per request. Mostly because HTTPS is a poorly implemented hack instead of being fully integrated with the TCP transport layer as it should have been.

Also a bunch of CPU time, but that's mostly irrelevant on the servers we use for image hosting. For H@H, it's only really an issue on Raspberry Pi's and suchlike.

Nice Job Tenb! I hope this site will stay as long humankind exists. Even after a fallout like in the game Fallout xD.

Will there be a new h@h version in the next months?
Just asking

Maybe I will use Chromium if I want to get rid of google service.

Try Edge Chromium. Its really good. I have completely from Firefox and Chrome to this browser. Finally Micro$oft did something good. You can use every addon from Chrome in Edge Chromium. Plus it is much safer than before and respects mostly your privacy. Not like Google Chrome.

I think next update can include a function to specify cipher suites, using chacha20-poly1305 may improve encryption performance on raspberry pi, although I don't really have one.

Bad news I learned just now is that one more of my favorites was taken down by copyright claim.
Good news is that now it is reported as such, even saying who the copyright claim was from.

Good addition.
But since when is it here ? (I don't remember seeing a news about it)

Thank you
A fun day with e-hentai XD