Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
"LLM-assisted code review won't be a huge disruptor" is quite the prediction. Because it already is in a very big way. The take on LLMs seems incredibly out of date and out of touch with reality. (Which of course, has moved/advanced very fast the past months/year)
Unfortunately 1 - as a _user_ you cannot opt-in or out. I wish Apple would take the next step and let us select which sites an app is not allowed to communicate with. Or ideally even globally for all apps.
Unfortunately 2 - the list of sites the app wants to communicate with is not clearly communicated upfront like before you install.
Unfortunately 3 - the list can also contain wildcard domains
Small steps - they really need to push this to the next phase IMO.
There is no excuse. GitHub runs a great program on HackerOne and it should just have been submitted there.
Also note that the person who found this was pissed because they had a difficult experience with submitting a bug for VSCode THREE YEARS AGO through MSRC which is _completely different_ than the GitHub H1 program and no doubt much more challenging with a different experience.
There is really no excuse for this irresponsible disclosure. They could have at least tried instead of holding a grudge for three years.
“we” are all different and i can tell you from experience that there are also many people and teams who use go and prefer ORMs and frameworks and do not build everything from scratch …
The privacy angle here is wrong, or at least incomplete.
The reason for that is that your ISP is most likely capturing all your unencrypted DNS traffic (port 53) to build that exact profile of you.
And unlike CloudFLare or Google, your ISP, which often is also the company from which you get your mobile phone subscriptions, now knows where you live, who you are, what your family looks like and which specific websites you visit.
Cable/Fiber modem manufacturers are also known to do exactly this kind of data collection. There was a recent example of this where it happened with firmware directly on the cable modem for a Dutch provider.
Running your own DNS server does not change this at all. From a network perspective this is the same: unencrypted DNS that anyone in the middle can see and record.
The only way to work around companies upstream from you is actually to use a DNS forwarder combined with some form of DNS privacy (encryption). A very good way is to have a local DNS Server that forwards to a outside trusted DNS server over DoT or DoH. Both of which are encrypted. Your ISP can see the traffic, but they can't see inside it and find out what DNS queries you do.
That means your devices on your local network can just talk "plain" DNS port 53 like they always do, to your self hosted DNS server. But your self hosted DNS server will then forward those queries to a trusted server _outside of your and the ISP network_ over an encrypted channel.
Note that I do not trust my ISP (Bell Canada) but I do feel ok with using Google and CloudFlare. That is my personal choice and not a recommendation. You can probably find better options - they do need to support DoT or DoH though.