Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 17:57 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: Memory Safe Languages in Android 13 (Google security blog) by pawel44
Parent article: Memory Safe Languages in Android 13 (Google security blog)

While I certainly don't claim expertise to the level necessary for such things in the languages in question (C and C++), I do work with the day-to-day and I *highly* doubt that there is any team with enough collective attention to not continue hitting problems on a regular basis. Even the Linux kernel doesn't get this right often enough for my tastes (given how prevalent the project is) and I don't think anyone is saying that the (regular) Linux kernel developers are less than excellent on the whole. I suspect the only balancing point that makes sense is:

- narrow scope
- single developer
- easily fits in said developer's head

Of course, that last part tends to fade away with time.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 19:37 UTC (Mon) by pawel44 (guest, #162008) [Link] (5 responses)

Of course, I agree. I believe factors such as developer experience and proper quality control are even more important than the language used. With memory safety languages, it may be easy for some to write a 'secure' application (or any other), but not so reliable. Messenger is a good example in my opinion. It's bloated and very buggy on my Android phone. Had there been proper quality control, it would never have made it to the Google Play Store.

Regards.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 20:09 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

There are a number of Google products that feel very incomplete and half-assed (and not the right half either). My pet theory is that they are on-boarding projects to sink new hire teeth on before they're shuttled off to somewhere more "useful".

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 0:06 UTC (Tue) by atnot (guest, #124910) [Link] (1 responses)

It is kind of the opposite. Google has in the past, out of fear of missing out on the next big thing, heavily internally incentivized "launching" new "products". To the point of it being the only real way of receiving promotions.

It's not that they don't have the skills to make good products. It's just that you get further by launching more bad products into the shredder instead.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 2:41 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Unfortunately, one of the worst is now a flagship product in the main lineup (Google Chat). FWIW, I also consider GMail to bottom-of-the-barrel these days. The HTML view for "slow internet" is *way* faster than the standard interface and all I go there to do is change filter settings.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 6, 2022 5:58 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I believe factors such as developer experience and proper quality control are even more important than the language used.

This argument comes up regularly in discussions about memory safety despite overwhelming evidence.

I've always wondered what kind of fantasy workplaces can afford to do this. Does any exist for real?

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 16, 2022 3:31 UTC (Fri) by njs (subscriber, #40338) [Link]

> I believe factors such as developer experience and proper quality control are even more important than the language used. With memory safety languages, it may be easy for some to write a 'secure' application (or any other), but not so reliable.

Of course you can believe what you like, but the facts we have in front of us in this article are:

- Google made absolutely massive investments in C/C++ quality – sanitizers, fuzzing, language extensions, the MiraclePtr effort, ... – and they still shipped apps with lots of security (and other) bugs. All that stuff has benefits for sure, but none of it moved the needle on these metrics

- They started intentionally using Rust/Kotlin/etc in places where they had previously used C/C++, and this *did* reduce security (and presumably other) bugs.

At this point, arguments that C/C++ are fine if you're just careful/skilled enough are like believing that bad things never happen to good people. People only believe it because it makes them feel good, and let their emotions override objective data or rational judgement.