isilofi

Nobody in power in industry and almost nobody from the consumer side cares about working conditions in any typical outsourcing country. Quite the opposite, "less regulation", "lower cost" and things like that are directly caused by ignoring worker rights and human rights (as well as a few other things).

China is not alone in this, just more present in the HN-relevant IT/tech sector. But clothing in southeast asia, mining in africa and south america, logistics/trucking in eastern europe are relevant examples from other regions and industries.

I don't intend to disperse responsibility here or distract, quite the opposite: One of the main reasons the aforementioned abuses can continue is that "the civilized west" systematically ignores those problems on all levels. There are some EU regulations coming up to improve this situation, but we'll have to wait and see on those...

Yes, but to make this "self-consistent" 0 * 0 = 1 would need to hold. And I'm totally sure that they don't have that...

Upon a closer look, do not trust the numbers on https://rust-random.github.io/book/guide-rngs.html in any way, they are clearly bogus and implausible. Their figure for their "StepRNG" which is just a counter is 51GB/s. Their XorShift RNG at 5GB/s, which is just a XOR and a shift is slower than Xorshiro at 7GB/s, which is a xor, shift and rotate, 1 op more. Both XorShift and Xorshiro should actually be of comparable performance to a counter of the same width because with modern CPUs, all those trivial bit operations like shift, rotate and XOR are sub-cycle microops. And all three of those should either be memory-bound and therefore of the same performance, or quite a bit faster than memory-bound if they just measure the in-register performance.

> Your 4000x factor speed up for a linear-congruential generator is just a completely false number. > Yes I did pick ChaCha20 for its speed -- it's designed for speed!

1 Chacha20 block takes 20 rounds, each of which consists of 4 QR (quarter round) operations. A QR is 4 additions, 4 XORs and 4 ROTLs, so 12 instructions on 32bit values. Multiply that together and you arrive at 960 operations per block (actually a handful more for the counter, maybe the round loop and stuff like that, but not a lot), each block gives you 16 uint32 values. So 60 instructions per uint32 or 15 instructions per byte.

A multiply-add generator takes only 2 instructions (you could use fused-multiply-add if available, but i'll leave that out as I left out sub-microop-rotate before, just to not overcomplicate things) per uint32 or half an instruction per byte. Yes, that is not yet a hyperbolic factor of 4000.

But then you'll have to use your random values. Since your Chacha20 random number stream only comes in blocks, on many CPU architectures, you will have all your registers full with your resulting block. Meaning that for the subsequent calculation, you have to store those random numbers somewhere or throw them away, do your other calc, then load the randomness again, etc. So you will always pay a penalty for cache and memory accesses and you will always have unnecessary register pressure. Even a L1 cache access will cost you about 4 cycles of access latency, other cache levels are far worse. Which means that it probably won't be 4000 yet, but a lot more.

Now we'll arrive at "yes, but somebody said ChaCha20 is roughly 1 cycle per byte!". Which isn't wrong, but you have to read carefully: 1 _cycle_, not 1 _instruction_. That benchmark relies on calculating multiple ChaCha20 blocks in parallel, because a modern CPU has multiple execution units and thus can execute multiple independent instructions within one cycle. There is also SIMD, where one instruction can operate on multiple pieces of data. But to be fair, we also need to do this with our multiply-add-RNG. And where I can have 16 registers of 32bits calculating one ChaCha20 block, I can also have 16 of the same 32bit registers calculating 16 multiply-add random numbers in parallel.

Thus giving us 60 cycles per ChaCha20 uint32 vs. 0.125 cycles (2/16) per multiply-add uint32. That is a factor of 480, not taking possible memory or cache penalties into account, because that really depends on the computation between the randomness steps. Still not 4k, I admit, that was hyperbole.

For many kinds of Monte Carlo algorithms, CSPRNGs are stupidly slow. The author compares two handpicked examples of a fast CSPRNG and a very slow PRNG, arriving at a factor of 4. In practice, e.g. comparing to very simple stuff like multiply-add RNGs, it is more like a factor of 4000. Only to then claim that "But that would only be true if generating random bits was the hot spot, the bottleneck of your program. It never is in practice."

E.g. for the usual example of Monte Carlo integration, you pick a point randomly, usually by running your RNG for both coordinates. Then you evaluate your characteristic function with that point as an input. Very often, the function will have a runtime that is in the range of a few hundred FPU instructions or less. Comparable to the evaluation of your CSPRNG. So in the end, you usually get a 40 to 50% faster runtime by just using a slow PRNG instead of a CSPRNG. Not to mention the few extra percent you will gain with a fast PRNG.

And it doesn't stop there. CSPRNG libraries are often optimized to be side-channel free and cryptographically safe. Even if you were to use a CSPRNG, you are leaving performance on the table by using stuff with security properties you will never ever need, that can easily be optimized out for a 30% gain in the CSPRNG parts.

And yes, for simulations a few percent points are relevant. Thoses "few" percents are maybe days in runtime, thousands of currency units in power and hardware cost and tons of CO2 in pollution.

Yes. Welcome to the hell of "No debugging, no fixing anything. Call vendor support and hope for the best"

Well. I was in the "analytics is mostly bad" camp anyways. But the things that you just told me are more of the "analytics are far worse than you think" kind. Like "how the hell aren't those people in jail right now"?

Maybe the app is already modified for such use and just needs to be given a "start spying" command.

Disappointing, no proper Linux support. Just "ask on discord".

If you have something to report, usually you are somehow involved. The company might then try to pin responsibility on you for doing the bad thing and trying to verbally blackmail them.

> You report these things verbally in person, not on written media.

I think this is dangerous. If push comes to shove, you will not have anything to defend yourself with, because of no documentation.

I don't know. I just know that they left the company, to everyone's surprise, shortly after something was reported, to work on something completely different two towns over.

Maybe, maybe not. But his main fault was pointing out the possible legal problem. As soon as he pointed to it, simple negligence and a possible Chewbacca defense became intent. Which is a huge difference in legal interpretation and penalties.

I don't know about Jim Rutt, but my overall impression is that most, if not all, companies are supposedly encouraging this culture of giving "bad news" and non-retaliation. Also reinforced by the usual compliance voodoo about supposedly anonymous reporting opportunities.

I've never gained the impression that that was anything more than lip-service. The two people I know of who dared to say something were shown the door. Quietly, discreetly, done in a way so they wouldn't dare to sue.

Therefore, imho, if you do report anything, make sure it cannot be traced back to you. Or just don't, it usually isn't worth it.

dupe: https://news.ycombinator.com/item?id=38345858

(also dupe, but already moved: https://news.ycombinator.com/item?id=38353937)

In technical circles, yes. But those things trickle down over time, through the media, marketing drones, bureaucrats and politicians even sometimes down to the rest of the population. So when things are already dead with our kind, e.g. the politicians or the news might still be full into "blockchain something something".

"Blockchain" is one of the current buzzwords that has to be slapped on everything. Not long before they do a v2 with "AI".

Yes. Almost none of those get i18n, hotkeys, shortcuts, taborder, screenreaders and other accessibility right.

- It allows a user to easily extend their current work environment (i.e. MS Office applications). Other languages and IDEs could do that, too, but not so easily. This allows users to somewhat more gracefully extend their documents/data and knowledge instead of starting all over again with a "proper" programming language/environment.

- I would not call it fast or resource-efficient, but fast enough and efficient enough for most unsophisticated purposes.

- No red tape for installation, IT cannot (easily) disable it, isn't an extra line item on any bill

The catholic church in general is kind of a counterexample in certain aspects, but only because of reasons. The Maltese Order is just one aspect of the general weirdness of the church organisation overall, there are also the separate international legal entities "Holy See" and the Vatican state. Of those three, only the Vatican state actually has any sovereign land area, but of a rather symbolic size. The Vatican also has a kind of citizenship, but it is only awarded for the duration of being part of the churches government. But in all those things you only see shadows and fragments of the past that are in slow and steady dissolution. The dissolution would be far quicker if e.g. Italy were hostile to them, but the opposite is true, probably because of the popular support and gain in international influence for Italy.

It pretty much is. A government does govern two things, a population and a corresponding land area. You may try to have one without the other, but that would lead to massive problems because of the way humans and their home area interact.

If you govern a population without a land, you are practically instantly at war with some other population because both populations will want their way of life as well as their property rights enforced around the place they call "home". For a current example, see the palestinian exile population, who have a government but no land of their own, thus leading to constant conflict with their host countries.

If you govern a land without a population, you are lacking any kind of compass and attachment to values. Land alone is a dead thing, and a government cannot just be recruited from land, it has to be people doing the governing. Basically, there is nothing to govern without a society.

Citizenship can have a number of definitions, but the loosest one is something like "currently inhabiting the land area of that corresponding government". You may change those definitions, introduce various classes of citizenships, modify the ways in which it can be obtained. But for the aforementioned reasons, any definition that doesn't involve something like "a citizen is strongly associated with a land area and comes from a corresponding populace (governed by a corresponding government)" is a weak and fragile definition that will not last the test of time and human interactions. Note that the government part is in parentheses, because actually governments are far more interchangeable than population and land area.

We shouldn't. TPM-based security is only sufficient against unsophisticated attackers such as a common thief stealing your laptop from your backpack.

You may even kill civilians on purpose to hit a military target, if on balance the military objective justifies the civilian loss of life.

The legitimate and legal (under international law and the articles of war) way is to weigh the military objective against the civilian damage and casualties and decide if this is still a viable target. E.g. it might be legitimate to flatten a house with one civilian and a hundred soldiers in it. It would be grossly out of proportion to kill a hundred civilians just to kill one soldier. Everything between those extremes will be decided by maybe a war crimes tribunal, public international opinion, the conscience of the warfaring parties, circumstances, propaganda, etc.

And there is no possible comparison between the usual peace-time internal court system and international law and wartime law. Those work in completely different ways. International law and articles of war are basically only applicable if some party makes them applicable by force. E.g. if the victor or a sufficiently mighty third party creates a war-crimes tribunal. In all other cases, those are mere "guidelines".

No, manually distrusting will probably be considered illegal. "Browsers shall ensure", no exceptions: https://news.ycombinator.com/item?id=38109691

I would also urge you to refrain from using terminology such as "baseless assumptions" when your own assumptions are so easily refuted by directly reading the text of the proposal.

You can manually distrust hardcoded CAs in all common browsers. But even now, this is rarely used because it is tedious, there are roughly a hundred active CAs.

And depending on how that law will be interpreted by courts, manually distrusting might be considered illegal.

Webapps are also vulnerable because the Javascript can be manipulated in a MitM attack.

The only way around this would be a "real" app.

It is "easily", because current commercially available "firewall" appliances include that kind of capabilities. Just a few clicks, install a CA certificate, add a logging endpoint, done. Certain regulated industries like finance and medicine are required to use those. All chats are instantly intercepted and logged.

And the way to spy on people via a certificate authority is exactly as described, you get a CA that signs your man-in-the-middle certificate for a website you do not own. Then you MitM that traffic using that certificate, while still getting a green "lock" icon.

With current WebCA certificates, certificate transparency does help a little to detect such MitM certificates, and some CAs have actually been caught red-handed. There are processes to punish or remove such CAs. However, this law would also prevent such actions, thus making it impossible to prevent any future malfeasant CAs.

About an example MitM certificate case and removal, see the DigiNotar case: https://blog.mozilla.org/security/2011/08/29/fraudulent-goog...

For more about how certificate transparency works see http://nil.lcs.mit.edu/6.824/2020/papers/ct-faq.txt

Website-based end-to-end encryption isn't usually. In most cases, the "e2e-encrypting" website will deliver the Javascript that does the "e2e-encryption", which can easily be manipulated to provide a copy of all messages to some convenient third location.

A warrant will maybe warn the site and the user that something is going on.

A man-in-the-middle attack without a warrant delivered to either party is more likely to go undetected.

There is no way for e2echat.com to make sure that the client will insist on a certain safe CA. Sure, in case e2echat.com controls all clients this would be possible, but this is a rare case.

In the general case, any CA can sign any website certificate. So all those new government CAs can sign all the man-in-the-middle certificates they like, and browsers are obliged to accept them. Nothing the website can do about that.

There are ways to pin certain CAs via DNSSEC and TLSA resource records in DNS. But browsers ignore those, and even if they didn't, the same EU proposal also specifies government DNS manipulation.

So the gist is: EIDAS must die.

I suppose this is the first step towards a stricter kind of the German "Impressumspflicht". Currently, if you are operating a website in any kind of (even most remotely) commercial function, you need an imprint. Lacking one, you get nasty expensive letters from lawyers and courts. At the moment, this imprint is just a text on your website.

With certificates from a government CA containing your name, address and maybe other data like tax ID, the certificate becomes that imprint, digitally signed and hard to fake. So I guess the next step after this directive is in place will be to require such government certificates for all European websites instead of the usual domain-validated WebCA ones. For a modest fee going into the pockets of some government cronies, of course.