s_tec

If your team has invested a lot of time & energy into mastering the Javascript ecosystem (including things like Typescript), it makes sense to use the same language on the server side as well. Server machines are cheaper than good developers, especially if you can share resources between the backend & frontend.

As for Deno specifically, it's definitely closer to the "browser" way of doing things than Node is, which is super attractive. The main reason to stick with Node is the huge library ecosystem, but Node itself feels kinda weird & old, since the language has moved in a different direction while Node has remained stagnant (poor support for promises & ES modules, for instance).

I think it's basically a weird-looking RV.

Which ones? I think I would like to try your setup, since it sounds like a good compromise between having my data harvested and being kicked off of sites for blocking their ads.

I know, right? What's with all these people, expecting their personal computers to respect their privacy? If you want cool features, just be quiet and let Apple send whatever data they want to their servers. It's fine!

The human eye is really good at dividing things in half, so it's easy to make power-of-two divisions without special tools. Just divide whatever it is in half, then divide it in half again, and so forth until you have a sixteenth.

The US system has lots of power-of-two factors in it, which suggests that it was born in the marketplaces and workbenches of people who did most things by hand, rather than our modern world where we design everything on paper first.

The US uses different bolt threads than the rest of the world. Just today I had to buy an 1/4 inch long 8-32 threaded screw to fix our stroller. The 8 refers to a standard diameter in the US system, and the 32 means "32 threads per inch".

As a long-time Arch user, I can say that the switch is not for the faint of heart. Arch won't do anything automatically, including installing basic things like a window manager or a browser - Arch is more of a "build your own OS" experience.

On the flip side, this is incredibly empowering. If something breaks, you can just fix it, since you were the one who put it together in the first place. That's a big jump from Ubuntu, where everything just works, but you have less control. Arch is worth it if you think of it as a future investment, rather than a short-term easy fix.

Sattelites are always falling to the ground, but they are also going sideways really fast. Imagine tossing a pebble off of a bridge onto a boat - if the sideways velocity is too high, the pebble will miss the boat and land in the water instead. Sattelites are like that. They are going sideways so fast that they miss the Earth entirely as they fall to the ground. If you want a sattelite to come back to earth, you need to get rid of that sideways velocity, which takes fuel.

The basic intuition behind symmetric cryptography is that once your input bits are "thoroughly mixed", there's no way to un-mix them besides brute-force.

On the other hand, we don't have a solid theory of computational complexity yet. Even basic questions like P = NP are still unanswered, so we have no idea what "thoroughly mixed" actually means, how to measure it, how to achieve it, or even if it exists.

Whatever it is, a single round of BLAKE certainly isn't "thoroughly mixed". Is 10 rounds enough? Nobody knows. On the other hand, we suspect that a thousand rounds are no better than a hundred - there's probably a plateau of "maximum entropy", and once you get there, extra mixing doesn't help.

So, since we don't actually know what we are doing, we pick a safety margin, like 1.4x or 2x, and just use that. It's all just guesswork until the theoretical side catches up, so your opinion is as good as mine. On the other hand, picking a safety margin of 1 seems rash. If you have practical attacks in the round before, you probably aren't anywhere near the plateau of maximum entropy!

It looks like the speedup is coming from two main changes.

The first change is reducing the number of rounds from 10 to 7. Think of it like making a smoothie - you add bits of fruit to the drink (the input data), then pulse the blades to blend it up (making the output hash). This change basically runs the blades for 7 seconds instead of 10 seconds each time they add fruit. They cite evidence that the extra 3 seconds aren't doing much - once the fruit's fully liquid, extra blending doesn't help - but I worry that this reduces the security margin. Maybe those extra 3 rounds aren't useful against current attacks, but they may be useful against unknown future attacks.

The other change they make is to break the input into 1KiB chunks, then hash each chunk independently. Finally, they combine the individual chunk hashes into a single big hash using a binary tree. The benefit is that if you have 4KiB of data, you can use 4-way SIMD instructions to process all four chunks simultaneously. The more data you have, the more parallelism you can unlock, unlike traditional hash functions that process everything sequentially. On the flip side, modern SIMD instructions can handle 2 x 32-bit instructions just as fast as 1 x 64-bit instructions, so building the algorithm out of 32-bit arithmetic doesn't cost anything, but gives a big boost to low-end 32-bit CPU's that struggle with 64-bit arithmetic. The tree structure is a big win overall.

Right, and the only solution is to audit and compile all the code running on your computer, including firmware. Otherwise, you have no idea what your computer is really running.

In the real world, most people run pre-built software, which is worse than this ideal. I agree that browser Javascript is worse still, but it's still better than sending secrets to a centralized server somewhere.

Security is a spectrum, not a binary on/off thing like this article tries to paint it. Things can still be helpful, even if they aren't perfect.

You can't roll your own TLS replacement using Javascript, because you need some way to deliver that Javascript to the browser in the first place. If you don't use TLS for that, you're doomed. Sure.

On the other hand, that's a pretty narrow definition of "Javascript Cryptography". The article overlooks a bunch of other useful cryptographic things you can do in the browser, like end-to-end encrypted messaging. You can't lose a giant database of customer data if you don't have a giant database of customer data sitting around. Javascript can encrypt stuff before it even leaves the browser.

If you build your service this way, an attacker would have to carry out an active attack that injects bad code into your Javascript bundle. That's much harder than stealing a database, and even if it works, it can only compromises the users who log in during the breach.

So, no, the right kind of Javascript Cryptography is actually quite beneficial.

It is true that async functions work similarly to the coroutines found in other languages, and that some transpilers convert async functions into Javascript generator functions under the hood. However, these are both implementation details.

On the flip side, there is a Javascript transpiler called nodent which directly converts async functions into the corresponding `Promise.then` calls, with no generators in sight. This transpiler actually generates smaller & faster output than the standard generator-based approaches, since the async/await semantics map more directly to promises.

In other words, async functions really are semantic sugar for promises, even if they have some similarities to coroutines / generators.

To try it yourself, just go to http://nodent.mailed.me.uk/ , check the "spec compliant" option, and look at the generated output.

Wow, I had not considered the deeper power shifts from this perspective.

The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their face before you tell them any secrets - they could be anybody.

Online, though, how do we know who anybody is? The current answer, for better or worse, is TLS with pay-to-play domain registration and certificate authorities. Decentralized, peer-to-peer systems like PGP have never been easy for consumers to use. You can "off-road" encrypted DNS by running your own DoH server & installing self-signed certificates on your client devices, but that's not an easy option.

"My LAN is my castle" may work for some cases, but most of us conduct business with people all over the world, thanks to the internet. This is the primary use-case for most networks & computer systems.

I'm afraid individuals will continue losing the power struggle as long as decentralized identity systems remain obscure. We need something that's as easy and compelling to use as our current centralized systems. It needs to be something consumers can use it to secure their every-day communications, as easy as visiting an HTTPS web site or chatting with a friend on Facebook. I just don't know how we get from here to there.

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.

Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), but the amount of aggression in your comment suggests that something deeper is going on. Do you feel threatened?

I suspect it's fear of change. As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption. This means you, the administrator, will have to learn more skills and do more work to keep things running. Things like `.local:` printers may break, and you may have to upgrade your internal DNS servers to RFC8484 so you can keep your split-horizon stuff working. Security is never free.

Or not. None of this is mandatory, and you can just switch it off (and Mozilla will automatically switch it off if they detect an environment like yours, as it says in TFA). The threat isn't Mozilla "deciding policy" for you (they aren't), the threat is that they are calling the industry out for running old & vulnerable DNS standards, and we all know deep inside that they are right.

> Firefox decided to stop using my DNS server

In an ideal world, your probably want some sort of encrypted connection to your own DNS server (unless your LAN is 100% trusted). Maybe something like HTTPS would work... oh wait.

Most people don't have their own DNS server, so their DNS traffic is already who-knows-what server with who-knows-what monetization in place (plus its in plaintext, so the rest of the internet gets it too).

DNS over HTTPS seems like a net win for both types of users. Power users like you get way to encrypt your DNS traffic, and non-technical users get an encrypted connection to a potentially less-hostile DNS server. It sucks that there is now a second place to configure things, but hopefully seeing this work well will put pressure on the OS to adopt DNS over HTTPS natively, bringing the experiment to its final goal (at least, I assume this is the endgame).

Right, except that communication between developers is the least scalable part of running a software team. For every new member you add, there are n existing developers to communicate with, so your communication costs go up as O(n^2).

If the goal is to grow a piece of software over time (as in many startups), any architecture that relies on "better communication" is doomed to fail, simply because it limits the size of the team that can handle it (and thus growth).

And why are these build systems necessary in the first place? They mostly exist to work around the lame library ecosystem, where you never know what's installed or where to find it. Solving the "library problem" would presumably render these tools and their horrible complexity obsolete.

If there were some type of system where library A says it depends on library B (via a URL or some other non-centralized thing), and the compiler knows how to resolve this, then you don't need 90% of the features these tools provide. You still need build parallelization and maybe detection for non-standard compiler features, but this is a much smaller and simpler problem.

Do you ever wonder how crazy ideas like "the Earth is flat" or "the Moon landing never happened" get started? Well, it might look something like this. It all depends whether or not this thing collects enough followers to expand it and keep it going (hopefully not).

Bummer. The posit number system (http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf) is super-cool, and its inventors often speak of its potential performance advantages. On the other hand, their claims did seems a little "too good to be true" - variable-width fields require mux gates, and somebody needs to pay for those.

> > I realized that I couldn’t rely on the compiler to get my back when I was doing mistakes

> That's not how engineers work.

Maybe "hackers" work that way, but actual "engineers" seek and use the best tools available. Finding & fixing bugs after-the-fact is usually more expensive than writing things correctly the first time, so serious engineering organizations look for ways to eliminate problems as early and as automatically as possible.

Linters, unit-tests, and type systems are all valid approaches. By looking for a language that can help with this goal, the original author is demonstrating a true engineer's mindset.

Nice demo, thanks.

It's funny how technology go in waves. This reminds me more of programming microcontrollers than writing Web stuff, and yet this is the hot new thing!

Plus, you can solve all the issues the article points out using linting tools like ESLint. Rules like no-case-declarations, no-duplicate-case, and no-fallthrough already exist for this exact purpose.

I'm talking about the Free Software movement. I have a moral right to use ad-blocking technology, or any other software on my own computer.

Spotify can refuse me service if they have a problem with this (no free music), but they can't make me feel guilty for blocking ads.

No problem at all. Spotify has every right to do this.

The original comment seems to argue that ad-blockers are morally wrong, which I disagree with. Ad-blockers are a morally neutral technology, even if they hurt some company's bottom line. Companies that dislike this reality can deploy technical countermeasures, like Spotify is doing.

> Why should you be allowed to use a service in a way they don't intend you to use it?

The Free Software movement has been fighting against this exact mentality for decades. Digital autonomy should be a basic human right. Anyone should be able to download and execute whatever code they want on their own computer.

Spotify also has this right, of course, and is free to block users if they choose. I am not morally obliged to support their business model. At the same time, I choose to have a paid Spotify account because it's more convenient.

When somebody says "have not been updated in a couple of years," they are really just saying that the code is unmaintained. Unmaintained code is bad code, no matter what year it is from.

I get what you are saying, but the two cases are different. Typescript is a whole different language from Flow, so they can't interoperate. Every package that migrates to Typescript deprives the Flow ecosystem of compatibility and mindshare, so a win for one is always a loss for the other. Nobody wants to be a loser, so this will eventually resolve itself into a single dominant choice.

NPM and Yarn don't have this problem, since they are pretty much drop-in replacements for each other. As long as `yarn install` and `npm install` both get the job done equally well, picking one becomes a personal choice. Every project that adopts a standard package.json is a win for both NPM and Yarn. There doesn't need to be a loser in this case, and diversity is good.

Exactly. Even strongly-typed languages have this problem. In C, it looks like `void *`, while in Java, it's `Object`. The `any` keyword is just the latest in a long line of escape hatches. Pretty much every language has one.

This is supposed to be a phone Richard Stallman can use. A phone that doesn't betray your freedom is more valuable than a phone with a PDF viewer, at least according to some people.

At the same time, the whole point of free software is that you can hack on your own computer. If you need some missing feature, you can just port it over from Gnome. That can be either exciting or annoying, depending on whether you have a hacker mindset or a consumer mindset. They are banking on enough people having a hacker mindset.