The majority of major, targeted hacks (rather than just sweeping the net for vulnerabilities) - aka, the kind of stuff that the US military cares about - involves sending emails or making phone calls and introducing yourself as Bob from IT, and sorry to bother you but there's a problem that we need to discuss with you, but first a couple questions...

They don't need script kiddies, they need social engineers. Question number one in the job interview should be "Is your native language Russian, Chinese, Farsi, Korean or Arabic?" And even as far as the more traditional "hacking" goes, rather than script kiddies they're going to need people who are going to custom analyze a given system and assess it's individual vulnerabilities, people with real in-depth understanding. One would presume that in most cases that the sort of targets that the US military wants to hack are going to keep themselves pretty well patched to common vulnerabilities.

AIs doing hacking? What are you talking about? This is the real world, not Ghost In The Shell.

This is correct but also wrong.

For example, one thing the NSA can't do now is simply get a court to order the company to bend over, hand over the data, and then stick a gag order on it so the company isn't allowed to even resist.

By moving it outside the company, yes the NSA is now free to target them without restraint, but they are also free to talk about any attacks, and they are free to actively resist the NSA.

Also:

Not really.

Which they can get, from a secret court, that rubber stamps warrants. And they can also broadly interpret various legislation (patriot act, etc) to grant them all sorts of priviledges to collect data without a warrant...

And again, if they have a warrant, with a silence gag on it, you cannot resist. In any other country, the NSA can attack you all they like - but you can defend yourself. They don't get to just order you around.

The "people here who do not understand a topic" is aimed at the poster up above - "Richard_at_work" who got things so stupidly wrong that he suggested it would cost "billions".
For some reason I didn't catch that he was not the one that replied to my comment on his comment.

Sorry - another poster "Richard_at_work" wrote the utterly ridiculous "billions".

So does that Escomarine do it for "billions" as you suggest or a hell of a lot less as your link suggests?

PCB's ... and no doubt lead and mercury are also present.

So? People do work with dangerous materials you know.

in India and Bangladesh

That's right, the places that are now training engineers about as good as anywhere else. You've also given a link to an example of how dirt cheap it is.

my understanding is that the steel often gets rolled into rebar

The scrap gets melted first. Say goodbye to anything that's a gas at around 1500C - so no lead, no PCBs, no mercury - they go somewhere but not where the steel goes.

There's an informative show out there

I really do not get why people here who do not understand a topic take it upon themselves to "educate" people with real-world experience in a topic.

I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.

But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.

True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.

So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.

In the meantime, QUIC will be widely deployed, making your work irrelevant.

As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).

Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.

There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly better than what's in TCP (so I'm told, anyway; I haven't actually looked into that part).

I'm not saying the approach you prefer couldn't work. It probably could. In ten to twenty years. Meanwhile, a non-trivial percentage of all Internet traffic today is already using QUIC, and usage is likely to grow rapidly as other browsers and web servers incorporate it.

I think the naysayers here have forgotten the ethos that made the Internet what it is: Rough consensus and running code first, standardization after. In my admittedly biased opinion (some of my friends work on SPDY and QUIC), Google's actions with SPDY and QUIC aren't a violation of the norms of Internet protocol development, they're a return to those norms.

You might be able to solve the problem(at the expense of a great deal of additional workload) by larding the caseload with samples specifically constructed to be non-matches; but then blinded and packaged the same as any other sample, to identify people who just lean positive; but that would probably require a lot of additional work to do in enough quantity to counteract the obvious pressure.

Why on parity?

In their capacity as (ostensibly) trustworthy, neutral, expert testimony, they both victimize the defendant and betray the public's trust in the criminal justice system and the duties of their office.

Punishment-on-parity seems like the absolute bare minimum, with no acknowledgement of the aggravating circumstances of abuse of authority, the corrosive effects on rule of law and public trust in the existence of rule of law, and so on. I am sympathetic to arguments that mounting their heads on spikes outside the courthouse might constitute a public nuisance, because of the smell of decay; but that would bring the requisite gravity to the situation.

Is there any reason, aside from the reflexive deference to allegedly legitimate authority figures, why they use the phrases 'gave flawed testimony' and 'overstated forensic matches in ways that favored prosecutors' rather than the more honest 'committed a fuckton of perjury'?

I don't know why anyone bothers, given that DJ spew is one of the most insufferable aspects of radio, without even the crass-but-compelling monetary justification of ads; but odds are good, on many channels, that there isn't even necessarily a DJ specific to that station. Once you can their obnoxious chatter, you can programmatically sprinkle it into the playlists of multiple stations in different markets. You only really need to be more specialized if the chatter is supposed to have some 'local' flavor, in which case you do need recordings matched to the appropriate market.

If you want to be pedantic about acceptable variations choosing something with such a long history and such wide use in various disciplines is a terrible plan.

"Percent" is probably the most common flavor currently; but 'per cent', 'per cent.', 'pct', 'pc', and likely others are still within the realm of accepted use. Hell, the '%' sign isn't even entirely settled, unicode has something like four defined variants. And that doesn't count the archaic, but historically used and still recognizable, specimens that cropped up between Latin and the present day.

I take it that you were exposed to basic literacy and only basic literacy, none of that messy intermediate stuff.

I'm becoming more convinced that Police are often too lazy to do police work and now reviews of the cases shows evidence procedures stacked in favour of the prosecution. If the Court systems do not have mechanisms to self correct evidence procedures how can there be any trust that policing will lead to outcomes that protect society.

Justice is impossible if the system is not Just.

The trouble is usually that the broadcasters just hear 'extra channels!' and zone out. You can have higher quality and redundancy; but using those bits to squeeze in a bunch of extra channels and then pretend that the results are acceptable has a tendency to win out.

It also doesn't help that digital transitions are when broadcasters usually give in to the temptation to squeeze in a bunch of extra channels. When they get really greedy, the results are so bandwidth starved that they sound like horribly compressed crap(because they are) even under ideal circumstances. Even if they don't push it that hard, they haven't typically been very conservative about building in a lot of margin for degradation.