Because the modern system is that the parenting has been offloaded onto the school. The reason we have sex-ed is because we can't trust parents to do that.
The notion that the school board would simply ask a parent, then deal with the parents from kid A complaining that they read a book checked out by kid B is out there.
We run our schools to a lowest common denominator system.
I don’t want to use a “separate but equal” Internet. Screen readers support very specific situations that don’t apply to me. I see using them as the equivalent of tweaking my knee and having to sit in a wheelchair so that I can just use wheelchair accommodations and call it a day. Nah. I don’t want to use a wheelchair or a screen reader because those devices weren’t made for my own needs and don’t suit me.
Screen readers do not skip ads! If they're there, they still get in the way. There are commands you can use to make things more efficient to navigate, but if the ads take up most of the page, it's just going to be an exercise in ridiculousness!
Understandable, but my point was that the ADA is not a “I get whatever I want” law. It has specific requirements. IANAL but I do not believe that just declaring something desirable for yourself and your needs makes it legally required under ADA.
One can come up with plenty of criticisms of Kodak. But they did sell off their chemical business when the selling was reasonably good and they did do a fair number of things that anticipated digital.
But you can't just yank out the carpet from a massive consumables business that basically underpinned a company's revenue and profits almost overnight and reasonably expect them to deal with it.
Mixnet would be a solution. Like what you described, have inbound packets held for some period of time and released as a group so that you cannot as easily correlate the inbound and outbound traffic.
The downside is that it gets much slower, and feels 'bad' as an end user. Each packet takes longer.
Why do all of these new VPN solutions want some form of Crypto payment that has to go through KYC regulations to acquire... doesn't that somewhat defeat the purpose?
Mullvad with cash seems like a super ideal way to go. Why can't I just mail you $20 and call it a day?
There are a couple of options for acquiring crypto without KYC. One might sell goods and services for crypto (I have done it myself, sold a videogame console P2P through a local libertarian group chat), or buy crypto with cash via P2P or in a country with looser KYC laws, and lastly they could just mine it themselves. Having significant money through mining might seem improbable, but we can't forget the market dynamics, someone might have mined a lot of some altcoin before a big boom (e.g. dogecoin) and ended up rich overnight.
Also, let's not forget Monero. Even if you buy Monero in a KYC exchange, the letterbois can only track if you've bought, but can't track where you send it to next. You could then exchange it for bitcoin with someone or using a non-KYC service, and there you have it, an anonymous BTC reserve. Or you could just bypass BTC altogether and use the much superior Monero to buy whatever you want.
That whole comment is "With a way harder method than going to the ATM".
I understand that it's possible to get crypto through obscure methods. However if you're selling a privacy focused solution, ideally you shouldn't have to spend 3-4 weeks to acquire the funds to purchase it.
I agree cash is currently king, but we need a crypto (or even better, Monero) economy if we are going to maintain financial privacy in the long run. In the event of a full transition to a Central Bank Digital Currency, like the EU is discussing and Brazil has already announced, cash will not be private anymore, as any physical bills will be just tokens for the underlying digital currency, which is tracked by the government.
Nope, certificates are issued for CNs(Common Name), also known as FQDNs (Fully qualified domain names). Something such as *.google.com, not IP addresses.
If they were issued for IP addresses they would have to reissue the certificate every time they spun up a new server. Also it's why if you spin up another server and make DNS point google.com to that server, it would not pass verification since the certificate you will be using on that server is not issued to *.google.com, but rather some other domain you own. The IP address plays no role in certificates.
Nit: a CN (stored in the Subject field of a cert) is not an FQDN, though historically web browsers treated them as such. This practice is now deprecated. Modern practice is for the domain name(s) to be placed in the Subject Alternative Name (SAN) field.
The Subject field is not consulted so long as the SAN field is present, and can in theory be any X.500 Distinguished Name, of which Common Name is one possible attribute, which may be any freeform string of a limited length (though it is typically set to the primary domain the cert is issued for, for easy identification).
Certificates can be issued to IP addresses (at least on SAN level, not sure if they are allowed in CN in CA/B baseline requirements), like https://crt.sh/?id=15492507462
