There is a book about IBM's involvement in the Holocaust. Now, I have no illusion that Apple, Google, and co. would not do the same in the circumstances.
This is a good comment. There are I believe a couple more cases where HTTPS is difficult:
- You use a dynamic subsubdomain scheme. E.g. abc.xyz.example.org. A wildcard certificate for *.example.org only covers xyz.example.org, not abc.xyz.example.org. Requesting a certificate as the page is requested is possible, but will cause a lot of latency, and you will probably hit the Let's Encrypt rate limit;
- You embed resources that are only available over HTTP and cannot be proxied, either for technical or legal reasons;
- You request resources from a local IP address, e.g. a website hosted on GitLab Pages that shows you the data from your own DIY weather station which runs in your local network.
These cases are not that common, but that does not make them nonexistent. 99% of websites don't fall under one of these cases (there are probably some others I have not even considered), and should probably support HTTPS.
Do you have a source for that? Coming from a country where there are 16 different parties in parliament (the Netherlands), neighboured by two countries which each have at least five parties in parliament (Belgium and Germany), I find that statement difficult to believe.
There are many names that do not follow your rule, and generally speaking I'd find it very rude if I told you my name, and you'd go "let me fix that to the _correct_ spelling". For example a name as Angus MacGyver, or Armand de la Cour. Both don't follow your rule. I don't see why that wouldn't apply to brand names as well.
I like this, because it's beautifully simple. I have been collecting radio stations since 2016 now, and something I have noticed is that streaming URLs tend to break rather often. It might be worth putting them behind a simple redirect so you can change the streaming URL remotely.
You can still get an anonymous card [1], along with paper cards from a machine, and printed e-tickets. So I would not say that travelling anonymously is becoming impossible, but rather that the current method is a lot more convenient for most, and thus the most known one.
Exactly. My favourite programming experience so far has been Visual Studio. Setting it up is done in one installer that guides you through the process, and after that it just works.
I think a lot of people here forget that people who program no longer need to be "programmers", and understand every aspect of the system. For these people who just want to simulate a model, or do some calculations, or automate a mundane task. For them programming is a means to an end, it's about the result.
Is it really trivial to support both dark and light interfaces though? It may be for command line interfaces, but for anything with a GUI and custom colours it means creating every element twice. Things like shadow work on light interfaces, but not on dark.
In theory, yes, and I think most people here would store their backup codes properly. However, there are many people who don't store them properly, and don't think about it until it's too late. They lose their token, break their phone, or lose access in one of the many other ways.
Sure, you can say "tough luck", but then people will complain, reasonable or not, and Google probably doesn't want that to happen. I think this is a reasonable compromise when it comes to security and usability.