This is controversial because they are “big bad” companies. But in some cases I think that is a plus because they have some responsibility to do as they say.

1. Use a resolver that is a part of Mozilla’s Trusted Recursive Resolver Program. Mozilla makes them agree to a solid privacy policy: https://wiki.mozilla.org/Security/DOH-resolver-policy#Conforming_Resolvers
2. Google DNS. Obviously controversial but their privacy policy is very good. They keep “full” logs for at most 48 hours and only for debugging purposes.

The major concern for all of these is that they are allowed the keep anonymized logs forever. This means that if the hostname itself it sensitive then it can be recorded forever. (For example if you have “secret” subdomains).

The other option is running your own recursive resolver, this mostly nullifies the private subdomain issue as only the authoritative server will see it (other than network snoopers) however this has very real downsides.

1. It exposes your IP address to many authoritative servers with no guarantees about the logs they keep.
2. It can be slow as there is no shared cache.
3. Requests from your resolver to the internet are not encrypted.

Disclaimer: I used to work at Google (but not on Google Public DNS) and have no affiliation with other named or referenced companies.

Just because it is not the advice that is expected does not make it bad advice. Obviously these names have some questionable behaviours but in this case they often have separate privacy policies for their DNS services (or the Mozilla endpoint for their DNS services) which makes it much better than the other Google products which are lumped behind a single privacy policy which isn’t very privacy friendly.

Unfortunately it is impossible to know for sure they are complying with the privacy policy, but this applies to all providers, no matter how large or what businesses they have other than providing DNS. So while you shouldn’t blindly follow some random post on the internet you should may give these providers a second look-over and consider that these large companies have some privacy benefits if their privacy policy is accurate.

This really needs a comparison chart. Also I really wish they just made a Matrix client instead of starting their own protocol. They claim that they will implement a Matrix bridge but that seems like a lot of effort compared to just using Matrix.

And most importantly. I want security information. Is this end-to-end encrypted?

I’m not sure what your point is about iPhone security. The problem in this case wasn’t any iPhone security but the fact that the password was removed before sending the device for repair.

I can’t believe that Apple suggests this approach. I would never send an unlocked phone to repair. But most people aren’t thinking in a security-minded way.

I’m not an Apple fan either. But focusing on the correct points is important.

• Apple security is not complete as shown by their terribly insecure repair procedure.
• Apple regularly blames users instead of admitting mistakes.

I agree with both of these points. However just shouting “iPhone security? LOL!” isn’t going to convince anyone because your argument is trivially dismissed. iPhones are competing with the best in class for security and this doesn’t show any flaw there.

I never said that iPhones are flawless. However I consider them in a very similar security class to the Pixel. Remember that those numbers are very small and heavily biased towards what is being researched as well as other factors such as the cost of those vulnerabilities on the black market. Try looking at other metrics as well such as CVEs which are also imperfect but show that iPhones and Pixel phones offer similar levels of security. And most importantly the article that this was shared in context two doesn’t imply any level of insecurity of the device itself.

But why? It seems weird to choose your tools based on the language they are implemented in. I love Rust (it is my goto language) but I choose my tools based on what they do, not how they were implemented.

That seems like a big leap. I have seen many performant and buggy Rust tools.

But either way, if your goal is to find tools that are performant and correct why not call it fastreliableyour.life? Focus on the actual direct benefits rather than implying them and excluding other tools that may fit your needs.

This is sort of a confused article. blob: URLs (not blob in the url) are references to local data. They can’t really be downloaded (well if they are still live you probably can) and typically only contain a small slice of the video (timewise).

What this is doing is finding the playlist file that describes this video and playing this (or using a player like VLC to stitch these chunks together).

Then it has other instructions to use different tools for specific sites.

So really the only reason blob: is relevant at all is because it is what you might see if you try the “simple” solution of right-click save. The actual article doesn’t deal with the blob: URL at all.

So guess the more accurate title is “Are you trying to download a video but it has a blob: URL? There is a decent chance that this is using DASH or HLS under the hood. You can try to find the playlist like this: $find_m3u8 and then stitch that into a single video like $vlc”.

Capitalists love monopolies. The closer they can get the better. Third-party apps compete with their own.