Android does protect against malicious non-Play and sideloaded apps, and Google doesn't have a problem with those being installed.
I didn't write that very clearly. Google doesn't have a problem with non-Play and sideloaded apps being installed in general. They do have a problem with malicious apps, regardless of source.
aka Google-speak for "they haven't installed non-Play or sideloaded apps on their device."
No... I'm pretty sure it's not that. Android does protect against malicious non-Play and sideloaded apps, and Google doesn't have a problem with those being installed. (Context: From 2014 until late last year I worked on the Android security team. I have pretty good knowledge of what they do and don't care about.)
I'd like to understand exactly what this part of the Google response is talking about. Maybe it's just throwaway FUD, not referring to anything in particular, but it could also be something the EU is demanding that is actually bad for users.
Uh, that's not how tariffs work. Tariffs are paid by importers. The reduced imports would hurt the EU exporters, but the taxes would be paid by Americans.
Well that's what I said before, that I don't touch code anyway. Which means you go with the language that works best with the AI.
In my experience, that's Rust. Or maybe Haskell. The more guardrails the AI has, the better.
Given that accidents requiring evacuation on commercial jets are roughly one in a million take-offs, and accidents resulting in loss of life about one in ten million take-offs, it's unlikely that setting up practice centers would save any lives.
My latest project is a 16,000 line script done in Python. It was pretty big for one person.
16kloc is a small project.
I should soften what I said before: You can get away with seat-of-the-pants work if one or more of: (a) your projects are small, (b) your projects are non-critical or (c) you invest in massive testing and validation.
In my old job, if I made one kind of mistake it could prevent three billion Android devices from being able to boot. If I made a different kind, it could result in the same number of devices being insecure against data extraction and other attacks (of course, OEMs often made those mistakes for me). In my new job, if I make mistakes vehicles can crash and people can die.
I want all the help the tooling can give me, and I spend a fair amount of my time building additional tools to prevent mistakes. None of it eliminates the need for testing, of course, especially when lives are on the line, but bugs that get caught by the compiler cost almost nothing. Bugs that get caught by QA, or, far worse, in the field, are very expensive.
Note that there are big systems built in Python. Instagram has millions of lines of Python code. They also mandate explicit type declarations everywhere and they built their own static typechecker, Pyre. Lots of other people have built typechecking libraries and tools for Python, trying to fix that problem. Maybe the next time I write Python I should try some of those tools.
Though I probably won't ever write any Python again. I really only use it for quick and dirty scripts, and these days I tell AI to write those for me, and I don't even bother to read the code. If it works, fine. If it doesn't, I tell the LLM to figure out why, and fix it.
Also worth noting that this follows on from the earlier Northrup-Grumman "Mission Extension Vehicle", which in 2019 launched to dock and reposition Intelsat 901, a first for a telerobotically operated spacecraft.
https://en.wikipedia.org/wiki/...
Some sites:
https://www.northropgrumman.co...
https://news.northropgrumman.c...
Coincidentally, Northrup Grumman was also involved in the SWIFT reboost mission, launched the beginning of this month, tp extend the lifetime of the Swift orbital telescope by boosting it into a higher orbit. (In this case, though, they didn't build the spacecraft, just provided the launch service, on a Pegasus)
LLMs have two effects here:
1. They help the white hats find and fix bugs
2. They help the black hats find and exploit bugs
These two effects cancel each other out to some extent (depending on which "team" is more proactive in its bug-discovery and consequent activities).
Eventually all of the low-hanging-fruit will be picked, and the current deluge of AI-induced CVEs will be reduced to only those bugs that were subtle enough not to be noticeable by anyone except the latest-and-greatest AI models.
Kind of does not make the kernel much more secure in general
Ah yes. gweihir. The resident AI denialist.
This one has been lurking on any given firewalled network interface for 7 years: https://www.cve.org/CVERecord/...
This one is a subtle race in openvpn: https://www.cve.org/CVERecord/...
Two examples of either making the kernel demonstrably more secure, or identifying and correcting non-trivial problems. There are hundreds more, in case you'd like to get some of the shit out of your head.
Is there any other kind?
Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".
Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no way in hell is that actually exploitable."
Yeah I don't need help from the tools.
Sorry, but you're wrong.
I think you're right.
I'm surprised they're projecting profitability as soon as 2030, actually. That's only 3.5 years away.
I would guess they are ignoring some expenses there as well.
Maybe... if the projections are in formal filings I don't think they can do that without risking SEC penalties. They can be optimistic about revenues or falling costs or things, because who can tell? But straight up ignoring things, probably not.
This is more than the average security/IT team can...
Don't care. You've had time: this is no surprise to anyone that's been paying the least bit of attention for several years now, and isn't still stupidly indulging AI denial. The excuse window has closed: if your business is security and you didn't know at least as 18 months ago that you could expect to see exactly what is happening today, you're a seat warmer and no one cares what you think. And you're going to be obsolete soon as well.
And it's not exactly an ad for US models when HuggingFace had to rely on a Chinese model to analyze their logs because the US model they tried refused to answer.
It is if the customer is the US military.
* US model is capable enough to hack its way out.
* China's model was able to detect it.
*
Nope. You misunderstood. It's not that the US model wasn't able to detect it, it's that the US model's guardrails prevented it from explaining. This doesn't demonstrate a capability gap against Chinese models, it demonstrates a two-sided failure of the safety protections of the US models. On the one side, the safety guardrails on the OpenAI model failed to prevent the attack. On the other side the guardrails on whatever US model(s) they tried blocked the model(s) from explaining the attack (presumably to protect against the explained-to people from learning how to perform it).
Nope. I didn't misunderstand. You may have misread what I said, or attributed the previous comment to me.
You said that this creates an arms race, which implies that it's a question of capability.
Marketing? Because companies famously want to use models in their networks that just run off and commit major crimes? *eyeroll*
UNIX is many things to many people, but it's never been everything to anybody.
