Sure
"back then"
3711 publicly visible posts • joined 23 Jan 2015
The problem is that really none of the incentives that got us hear have really changed. If anything, they are intensifying. Certainly, there is some low-hanging fruit out there which likely will be caught in the next quarter or two.
The problem is, that relying on LLMs means that the supply of fruit is going to be increasing.
Remember XKCD on the nerd-geek relationship? My daughter hates it when I bring that one up whenever she starts waxing lyrical about the differences between the two.
Clear communication is not just something that hr puts in every job description. It forms the very basis of scientific and mathematical advancement.
You're expecting scientists to abandon a core part of their personality, and one of the parts that makes them good scientists.
Now I agree that if research were not done by squishy things with emotions, that this subject could and should be put off, if it weren't for my own experience.
I was researching an almost-century-old topic one day, and came across a strange term, one that had fallen into disuse after a couple of decades of debate. This change in term usage was rather distressing because it meant that any research I was doing from that period, I would have to use context to determine what was actually meant for a particular, related term.
Same thing here. TODAY, I doubt that there is any scientific reason to bother with the distinction between planet & dwarf planet. But maybe there will be in thirty years. And there is scientific value in clearly communicating across the decades.
As I understand it (from someone who served on a federal grand jury), each member of the jury can bring a complaint to the attention of the prosecutor.
Note also that it is not rare for prosecutors to prosecute cases of domestic violence against the wishes of the victim.
So it can be done. No bets on if, however.
This is an excellent observation, except for the following point: crackers tend to start with an initial access point, and then worm their way through a network. In particular, while getting root on the database server would allow a database dump, which would not do much if the data were encrypted in the database, that's not how I expect a cracker to get to the data. More likely, they manage to gain control over the database application. This application has legitimate access to the database, and the need to be able to decrypt whatever comes back.
Best practice might be to have the decryption key for the data generated as part of the session. In this fashion, the application would only be able to decrypt data for the current client. Sadly, I've yet to see it done that way. Possibly because doing so might break password recovery.
I am NOT saying that there is no value to encrypting at rest. Indeed, this has been best practice for a decade. But, sadly, it's a pretty limited block.
NO IT WAS NOT. I was there. On the cypherpunks list. In the 1990s.
There are two reasons to increase mining difficulty. The first is, you want there to be easy adoption and a finite total supply. Deflation is therefore built in. Some might consider this to be a Ponzi scheme. While there are similarities, there is nothing hidden or dishonest for anyone willing to read the technical specification, which not particularly opaque.
The second reason is, especially 20-30 years ago, the cost of work goes down with time. You need to make the hashing more difficult to avoid the bad effects of this.
You obviously have not had training in reaction times. And the article is about social engineering. Someone intending to trigger some sort of *interesting* response from whatever the bag is holding might do EXACTLY what you did. That TSA agent did the right thing.
You do NOT make a move like that unless you enjoy Russian Roulette.
NO. The fault here is the #$*&$# 0-terminated string type. It was mildly criticized when it came out because academics did not understand that the next batch of programmers to be decanted would NOT hold advanced degrees in mathematics and therefore would make errors of this sort. If they did, Ritchie would have been denounced in every CS 201 course. What is really strange to me is that, even with the superabundance of buffer overflow errors that happened in the 80's, that there was no push to eliminate this datatype in the 90's.
"again suggesting that star wars - or at least orbital ones - are rapidly looking inevitable" Really? How many comparable exercises have we had with our nuclear assets, and how many DECADES have we gone without a nuclear war?
What is inevitable is that if you appear to be weak and/or unprepared that hostile powers will treat this as an invitation to aggressive behavior.
Demonstrating our ability to carry out operations in this theater discourages adventurism on the behalf of China and Russia.
If we define a "bug" as a "failure of some subset of the code to perform as expected", then a finite-sized code has a finite number of subsets. If we require that the expectations be specified in advance, these will be finite, then there are only a finite number of fails available for any fixed codeset.
"99 bugs in the codebase, 99 bugs in the code!. Write one down, send fix around, 100 bugs in the codebase!"
Experientially, we'll run out of money long before the bugs are all fixed in many, many codebases.
And BB(432) is unprovable in ZF & ZFC.
You should probably check a mirror, because a lot of news articles describing overflow attacks go into some detail as to what actually happened.
Without checking, I'll bet you 100-to-1 that there WAS checking going on. It simply was inadequate because C doesn't make such checks easy, and to this day no one seems to understand that no, really, you need an advanced degree in mathematics if you want to prove that code is correct. (Nevermind the compiler, linker, and OS.) For a fun example, checkout StageFright I & II. Even when you KNOW there is an issue, someone without the proper training will get it wrong.
As for C, I DO blame the language here. Such errors are unheard of in asm because the flag register is immediately available, and EVERYONE knows to do the proper check. I mean, some fool might check O for unsigned operands, but what can you do?
Do we go through this again? Suppose you become fed up. AWS has failed at it's supposed only reason to keep your business. What do you do?
Azure with Office 360? (We only schedule outages on days ending in "Y")
GCP with Gmail? (G as in "you account is GONE because resilience is someone we built for ourselves only")
Oracle? (We don't hire devs who want to talk about testing)
IBM (India)?
Well, just bring it in house, then. Is there even ONE member of your organization that has worked on a service delivering five nines? Are you ready to hire ops teams in three geographically dispersed areas to make sure that the lights are always on somewhere?
Getting the boring stuff right is HARD. It's also rather pricey. And very few organizations have the ability, let alone willingness, to identify the right talent to make it happen.
AWS is loosing to Azure because Microsoft it targeting the decision makers, not the coal faces. Technical merits haven't been the issue, or Azure never would have gotten off the ground.
I worked at Google a decade ago, and that 23 minutes sounds suspiciously close to another number I know. Updates to the config service (Spanner?) had to be made 20 minutes before they were to go into effect.
HOWEVER, we also knew that that was only for global data. The golden data center cleared a LOT faster.
We made a point of partitioning our config data by region. In a pinch, we would effect a global change fast by pushing in every affected DC. I don't think I ever had to do that personally.
----
But for auth? I don't believe this "infeasible" nonsense for a single second, let alone 1380 of them. The trick is to view auth as an limiting case of quota--and G MUST enforce quota to state functional. A revoked access token has it's quota dropped to 0. That system will almost certainly clear in seconds.
TL;DR: AWS has it done in seconds. G absolutely can as well.
My city has a very nice freeway system looping around it. Six months ago, maps would make regular use of it. Now? Not so much. Too much compute to look too far "out of the way", and not enough computer science to identify & at least quickly try use of the freeways.
Ten years ago, it was the other way--freeways were way over preferred.
This seems to me to be the most thoughtful post along these lines. Let me put it this way:
Resilience is hard. You just won't believe how vastly, hugely, mind-bogglingly hard resilience is.
Of course, I've not seen the particulars, but $10MM/yr doesn't get you very far down the road for a business like that. Maybe 99.97% uptime. Probably not.