xign

You can ship macOS native games on Steam as well. People need to stop throwing conspiracy theories. Their main motivation is to make sure games are native to macOS so they can take advantage of system-native features, which Win32-translated games won't. Otherwise games running on Macs will always be kind of janky and run slower than Windows.

> - Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in.

Are there password managers that actually seamlessly do that? GitHub's official docs (https://docs.github.com/en/authentication/keeping-your-accou...) for example recommends using the GitHub CLI to cache your authentication token for you and as far as I can tell the token is stored unencrypted (https://github.com/cli/cli/issues/1773), unlike SSH keys which should be encrypted behind a password. If you don't do this you have to enter your password every single time you use you Git, which is not good even if you have a password manager (it adds steps, and passwords aren't great to begin with because you send them in plain text to the server and it is why Apple etc are moving away from password-based authentication for websites).

> - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys...

I think the key issue here is this really shouldn't have happened. There is no reason why GitHub couldn't secure their SSH private key just like their TLS key.

---

Edit: Thinking more about it, I think the situation would have been much worse if GitHub leaked a TLS key instead.

With SSH, an attacker who stole GitHub's private SSH key actually *cannot* MITM the user. They can pretend to be GitHub to the user, but they cannot pretend to be the user to GitHub, because with SSH both sides have a private/public key known to the other side. In a normal usage scenario, it would actually take some social engineering to do a real attack, because a simple Git fetch from the attacker would fail when trying to fetch a private repo (since the attacker does not have the permission to fetch it from GitHub).

With HTTPS, under current setups of username/password or an auth token, the user has no real way to protect themselves from a MITM attack. The token isn't a private key as it's shared directly to the server. That means the attack could actually MITM the server/user connection and do much much more damage.

Also, from what I can tell, the old key somehow seems sprinkled among a lot of Github-owned IP addresses in my known_hosts file as well, not just github.com. I'm not sure how that happened though.

What? This is a terrible way to reason about risks in general. If you don't know for certain, you should assume the worst case scenario, especially since it's impossible for you to calculate the probability distribution of the likelihood of a leak.

You should only keep moving along without key rotation if you know for 100% certainty a leak didn't happen and no one accessed the key (not theoretically impossible if they had the server logs to back it up), but anything minus that and you have to assume it's stolen.

The point being made here is that because there are millions of users forced to change keys now all at around the same time, and because they are doing so due to seeing an error in Git, this creates a good opportunity to strike. Normally, most users would have connected to GitHub before and a MITM attack has a high chance of failure.

I would believe it… UWP APIs can be really complicated and over-designed sometimes.

Redacting PDFs is similarly tricky. These days I use macOS Preview (they have a new-ish feature that explicitly allows for redacting) which works but I sometimes still open it in an editor to make sure the data isn't there lol.

It does matter though? /opt/homebrew is specifically used by Homebrew, whereas /usr/local is kind of a more shared location that old Homebrew hijacked.

Either way, I think bad default folders is better than bad default security practices. Most package manager forces you to use sudo to run them as root, and I think that's much much worse in terms of security practices and encourages the wrong behaviors and potentially allowing build/install scripts to wreck havoc on your system. (Note that /opt/homebrew is not world writable as you suggested. It's only writable by the user)

Instead, Homebrew prefers to run in a user account, default to yours. If you have a multi-user computer, you can install Homebrew to a local user folder to have isolation and not using a global location like /opt/homebrew, or you can make a special Homebrew user account (rather than using root), which is what the docs suggest (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).

I don't think the current solution is perfect, but I do think the motivation to prevent usage of sudo is correct in terms of security. In fact, I would argue that the other package managers that use sudo are taking the easy way out (albeit insecure).

Most packages that Homebrew install just wouldn't fit nearly into the kind of sandbox model that you suggested. Just think about command-line applications that can take in any file as input and process them, e.g. Git, ffmpeg, etc. Or like a compiler like clang. Even for GUI apps most Mac applications do not use sandbox / App Store because it's actually quite difficult to work within that framework for a lot of types of applications.

macOS also doesn't have a way to tag a command line application to have sandboxing, as sandboxing only works for an "app" bundle, not random executables.

This isn't really a Homebrew problem anyway. If there is this magical sandboxing capability that works, nothing stops a Homebrew package from using it.

I think you should re-read that article you sent out, as it describes a different situation as the one presented here.

It's kind of a frequent misconception among kind-of-informed programmers that floating points are always "inaccurate" without fully understanding why. Your linked article is mostly describing floating point arithmetic where due to various reasons (order of operations, etc) it's hard to compare arithmetic results due to precision loss.

In this case though, you have a float assigned to a constant (1.3f) that is then compared with 1.3f again. There is no arithmetic done, and in fact, 1.3f has a non-ambiguous binary representation (it's the binary float point number that's closest to 1.3, a decimal number). Doing something along the lines of "1.3f == 1.3f" should always return true. The issue here is just the annoying issue of intermediate 80-bit representation vs 32-bit storage which isn't an intrinsic issue of floating point, but rather a language/platform oddity. As the article described this isn't actually an issue under x86-64 since compiled code don't use 80-bit intermediate representation there.

Another similar issue is reading/printing float point numbers out. It's a tricky thing to do, but there are lots of research done on it (e.g. see "dtoa" by David Gay) such that you can actually accurately print out floating point numbers and read them back and get the same binary representation.

I'm very strongly against AMP but what you said isn't strictly true.

AMP itself allows for fast loading which is true, but to support opening pages in "zero loading time" you still need pre-loading since fast loading still means non-zero loading time. To get pre-loading working in HTML you need to 1) load the iframe of the page in the background, then 2) when the link is clicked, use history.pushState() in order to manipulate the URL to appear you have moved to another page. Unfortunately for (2) the Web History APIs need* both URLs to be on the same domain so Google has an excuse that they need to change the target URL to be under Google for this to work.

Also Google wants to present the scrolling UI that allows you to browse to other articles in the search results (potentially from other domains). This can't be done if you have completely switched to the original website.

See this link for more discussion https://github.com/ampproject/amphtml/issues/6210

Personally I find this misguided at best, an excuse at worst. A fully compliant minimalistic AMP website (or even just a simple site that doesn't use AMP but follow best practices) will load incredibly quickly even without pre-loading. It's disrupting a lot of security and UX best practices (by replacing the address bar with "google.com" domain) just to achieve a very minor improvement. Furthermore they control Chrome. It's not too hard for them to push forward a web preloading standard and start implementing in Chrome.

Edit: Also for the scrolling UI it seems like another way for Google to push more engagement to their site rather than the target URL. It kind of runs counter to the open web nature IMO because there are innovations that helps previewing links already (e.g. iPhone 6s/7 3D touch) and it's the kind of behavior better implemented in the browser itself.