(Note: I've been doing a similar home-rolled version of this, where I have a mail server under my couch that opens a reverse ssh tunnel and forwards port 25 and 465 from whichever transient EC2/Azure/DigitalOcean/Hertzner/CloudAtCost VPS Ive got listed as my MX records. A little bit of Route53 API automation, some Ansible to set up the ssh tunnelling, and some "canary" gmail and live.com email addresses to check outbound deliverability when I go to switch VPSs... It's been running pretty much untouched since 2014 or so...)
It can be argued that using a browser or any other client violates that language by sending responses to requests.
The ISP won’t do squat if it’s encrypted; they have no idea who is being connected to and what’s being sent.
A TOS is as broad and vague as they can make it. A good lawyer could undermine such language if it went to court.
> To build a plug and play solution, we knew that our server could not require listening for inbound connections on a residential internet connection. So we set about looking into how we could route traffic to and from a home server but we needed to do this in a way that prevented us from being able to spy on traffic. We investigated solutions like sshuttle and eventually settled on the combination of a simple iptables configuration combined with a VPN connection. Helm establishes an outbound VPN connection to a dedicated EC2 instance with an iptables configuration that routes packets to and from the connected Helm server. The EC2 instance also has a static IP address associated with it.
> It's important to stop here and explain that the only way this architecture is viable while adhering to our design tenet of knowing as little about our customers as possible is because of the Let's Encrypt project. Every Helm server has a unique domain associated with it and trusted certificates for that domain are fetched from Let's Encrypt. We strive to ensure that all inbound and outbound traffic routed through the EC2 instance is using TLS with these certificates from Let's Encrypt. This way, our EC2 instance is effectively just an extra hop on the Internet.
> I hope that answers your question, let me know!
This doesn't seme to address the question of whether this violates the ToS, regardless of whether this is technically feasible.