You’re mostly right, if not completely right. VPN is encrypted with SSL so the ISPs only see that you exchanged information with a VPN, but not what is being exchanged.
You may consider that maybe the ISPs can also figure out who else connects to the VPN and maybe deduce some information that way, but they can’t know everyone who uses the VPN, only those on their ISP that use it. So you can exchange information with somebody in Antarctica and the ISP has no way of knowing if it’s somebody outside or inside their ISP.
Also, on the point of services that are not HTTPS, don’t confuse encrypted protocols with the SSL of the VPN. Your ISP will not see your unencrypted packets either if you tunnel it through your VPN. They can’t see your DNS or ping requests (assuming you are using an IP based proxy, not using a SOCKS proxy). But your VPN provider can see those unencrypted requests. So you’re choosing to trust the VPN provider with those opaque requests over your ISP.
And last, about DNS-over-HTTP, a reverse DNS is enough for your ISP to know what domain you’re connecting to in a lot of the cases, regardless if you hide the domain name resolution. Of course, sites using shared CDNs mitigate this, but not all do.
That’s a strawman. I don’t need 1000s of lines of JS to swap a UI. I can do it in 1 line with Web Components: oldElement.replaceWith(newElement). And those modules can be lazy loaded like anything else.
This is just DX in name of UX, which is almost never a good idea.
And maybe you’re fine with throwing a server computation for every single UI change, but I’m not made of money and I much rather have stuff on a CDN.
C’mon, what’s not to like about bonding every UI action against a remote server? What’s a few milliseconds anyway? I’m sure it works fine over cellular networks. I mean, it works great on my dev machine! /s
Accessibility is horrible without JS. You should be modifying ARIA tags heavily as the user interacts with the page. I tried to write pages with no JS and realized the needs of the a11y group heavily outweighs the noScript group.
Packet loss really, and the latency and jitter said loss can contribute to.
Radio waves go faster (speed of light) than through a medium (copper). Not that it matters at such a small scale, but it’s helpful to have a good picture of the elements at work here. The further you are from the receiving point, the more obstacles (matter) that can obstruct it. But in ideal conditions WiFi is better than most people think. Replicating those ideal conditions though…
Yeah, sorry that was bumped up recently though I was grandfathered for a long while. But that was the impetus for getting it back when it was just GPM.
It’s 6 actually (1+ 5 other members). My uncle basically paid for half of it.
It’s $22.99 for me now which includes YouTube Premium. Just YouTube Music (for 6) is $16.99. Individual $10.99 and Student $5.49.
6 family members for $15 a month and no YouTube ads. Also that money was basically paid for by Google Rewards. The Web App is good too. I don’t have to deal with CEF/Electron or any install really.
I just recently worked on fixed point 8.8 and basically the way fractional values work, you take an integer and say that integer is then divided by another one. So you represent the number in question with two numbers not one. 0.3 can be presented in a number of ways, like 30 % 10, or 6 % 20.
The problem is the way 0.1 is represented and 0.2 represented don’t jive when you add them, so the compiler makes a fractional representation of 0.3 based on how 0.1 and 0.2 were expressed that just comes out weird.
That’s also why 0.3 + 0.3 is fine. When you wrote 0.3, the compiler/runtime already knew how to express 0.3 without rounding errors.