hiimkeks

Huh, that would make it easy to provoke forks by just backdating a second commit.

Congratulations on the release!

As someone who used to be in the Secure Scuttlebutt community an now works on OpenMLS, I wonder how they (you?) deal with concurrency of Commit messages. I spent quite some time thinking about ways to detect and resolve forks, and the current iteration of MLS doesn't really have good answers here.

> You don't need developers with 20 years of experience in a specific language.

You may in trivia quiz languages that have more features than anyone can learn in a lifetime

At the same time, monasteries have a long history of producing beer, wine, liqeur (think Chartreuse) and liqour (think Klosterfrau Melissengeist).

At the same time - having a glass of wine for stimulation while contemplating the divine might not be the same as drunkenness? And is the different the dose ("a glass of wine") or the purpose ("stimulation while contemplating the divine")?

The first time zoom announced E2EE, they didn't actually have it and then said something like "well the server is the end, and then there is another end...". IIRC In the end they acquihired keybase so they fix the crypto for them.

Ah, the Zoom Gambit

I appreciate the evidence-based approach, but it would be nice if the evidence was linked.

The USA are freeriding the benefits of EU's regulation, sounds like they (EU) should raise tariffs for that!

(if you can't tell whether that is sarcasm that might be because I also don't know)

Oh yeah, it also did that for me recently when I asked how I would go about designing a PCB that takes M.2 daughterboards. It recommended stems and threads I should buy. Unfortunately all the product links were dead.

> Slotted pages are composed of three components: a header (containing metadata about the page), cells (variable-sized “slots” for data to be stored in), and offset pointers (an array of pointers to those cells). The benefit of this layout is that you can store variable sized data, since the cells can be of variable size, and you don’t need to move that data to logically reorder it. Reordering the positions of the pointers in the pointer array is sufficient. This is inexpensive since the pointers are small, and in a well-known position at the beginning of the page. In other words, as long as the offset pointers are ordered in key-sorted order, it doesn’t matter where in the actual page the keys are stored.

Does that really make a difference if we have to re-write the entire tree node anyway, even if it's just for reordering the pointers (because node == page)?

I think the first three items are "add effects, and do it right":

Capabilities to IO can be done by letting IO functions interrupt and call an effect handler, and the caller can specify the effect handler and do access control in there.

The whole Pin situation only exists because async/await was an afterthought and didn't work well with the existing language. async/await is an instance of effects.

I'm excited to start playing with a language that has a good effect system. I am hoping on Ante, but would also like to try Roc at some point.

I general I agree, but we are also in the paradoxical situation that generic associated constants in traits are stable, but you can't actually use them as constants. You can't use them as const generics for other types, and you can't use them for array lengths.

I'd argue that this makes them pretty useless: if you just want a value that you can use like any other, then you can define a function that returns it and be done with it. Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly.

If the support would actually be good, we could just get rid of all the support crates we have in cryptography libraries (like the generic_array and typenum crates).

That said, I agree that the Rust team should be careful about adding features.

I think the desire to do something meaningful can easily exist outside of a "competitive dynamic", which was the thing that felt off for me.

A bit of a nitpick, but...

> The system that derives truth from experiments - the actual scientific system...

Yes!

> ... is the competitive dynamic between scientists who are trying to tarnish each others' legacies and bolster their own.

Hm. To some degree, sure, that is one dynamic, but (a) this leads to/presupposes a truckload of perverse incentives and (b) this is not inherent in the system if we rearrange incentives

Aljoscha initially built the macro framework for the specs on willowprotocol.org

> “every man hates women” (literally in the second paragraph!)

(from parent)

In case anybody wondered, the article says nothing of the sorts:

> Kate defines misogyny as the enforcement branch of the patriarchy. While sexism is a set of beliefs, misogyny is a set of actions. As such, it is much more damaging to women. Worse, misogyny enforces a patriarchical worldview that the majority of the world holds as the morally correct one. Thus, when women break this norm (i.e., by demanding authority, recognition, space and not providing goods that men feel entitled to like domestic, emotional and mental labor), they are in the wrong. The men are seen as the victims, while the women enduring the misogyny are the bad actors. This viewpoint leads to justification of a number of vile behaviors perpetuated by men – even those men that claim to support and love women.

(second paragraph from TFA)

Get you quantifiers straight, Tom.

> drop virtual memory mapping support from CPUs, making them faster.

In the video, his argument was that the browsers are single-process anyway, and if everything runs in that process, we don't need that separation. However, since then, we've learned that single-process browsers are a security nightmare, so these days browsers are actually not single-process anymore to provide proper sandboxing.

But I love how close to correct that video is, and it's interesting to see in what ways it turned out to be wrong.

Not really. Godwin's law points to inadequate comparisons to Hitler and the "classic Nazis", whereas your parent points out that he supports real, alive Nazis today.

It's a not a Nazi comparison, it's stating facts. Just two days ago he recommended voting for the German fascist party AfD, in the process regurgitating white supremacist conspiracy theories.

> So if you're ever doing this for a UART or network stream or something, always do the delimiter approach!

I'm confused. I mean for UART, sure. But network streams is usually sent over a protocol that recovers lost data. Am I reckless for sending length-prefixed data chunks over TCP?

The link you posted promotes Speedometer, where Firefox reportedly already surpassed Chrome.

https://news.ycombinator.com/item?id=36770883

Apparently they didn't learn much, given that MTProto 2.0 still uses IGE. Or still derives the IV from a hash of the message.

The article you link does not mention "cloud encryption". What is that? TLS?

> The cloud and E2EE encryption of Telegram have already been audited by independent researchers.

Yes, and they all agree it's crap. Just look at this thread https://news.ycombinator.com/item?id=6915741 (Feel free to ignore Moxie, but listen to tptacek). In addition, it doesn't even matter since (a) it's not turned on by default and (b) it can't be turned on for group chats.

That said, I agree that Durov probably is not closely collaborating with the Russian state.

In less than a year, you will have less than 10% of a year's worth of pay stacked up that way

FTFY

  You won't ever make mistakes
  'Cause you were never taught
  How mistakes are made

Francis by Sophia Kennedy

> Adding more PBKDF2 rounds is a nearly free way to make bruteforcing harder, whereas switching to Argon2 or scrypt or bcrypt or any other KDF requires more effort

The way I see it it's the other way around. The only complexity cost that lives here is that you need to distinguish between different derivation configurations. Whether that configuration tells you to use PBKDF2-200000 or Argon2-64M-4-1 doesn't matter, and you'll have to add a clause to the code either way. On the flipside, the memory-hardness allows you to increase the cost for the attacker a lot more than for the user.

> WASM Argon2 implementations are at least multiple times slower than native IIRC

I haven't looked this up, but my suspicion is that it's still better than a WebCrypto PBKDF2 configuration taking the same time for the user, measured in Wh for the attacker.

They shouldn't be using PBKDF2 for new installations at all. It's been nearly a decade since the Password Hashing Competition, and you should just use the memory-hard Argon2.

Also, W3C should finally get it into the WebCrypto API, but it seems like whoever is responsible for it just let's that API rot. There are fast wasm implementations, though.

No they wouldn't. Smoking gives a little protection against infection, but once you have it it's likely much worse. Vaccines give you a little protection against infection and also reduce the probability of severe courses of illness.

They already have them.

You can also use .get(idx), which gives you either Some(data) or None in case of out-of-bounds access.

The e2e encryption protocol is the definition of "let someone who has just learned about Diffie-Hellman roll their one crypto". It's called MTProto, and version 2 mostly updates padding and uses SHA256 instead of SHA1. Yes, SHA1 was deprecated before Telegram even existed. No, version 2 is not better.

Cryptographers praise Signal because the protocol makes sense and because it's not run by someone as data-hungry as Meta or Alphabet (though I think it's hosted on AWS).

Threema is a good alternative if you want username/password, but has less users (probably since it's a paid app) and less neat security properties (not even forward secrecy).

I agree Signal is not perfect and has never played the Open Source game very well (even under Moxie reports from the community were largely ignored) and the MobileCoin move is weird. I also have not followed the direction the project has taken since Moxie left. However, the _entire_ code is open source (which iirc is not the case with Telegram) and the protocol makes sense (and has been extensively studied), and there is a lot of eyes on the development. I remember code changes that suggested a pivot to not using phone numbers as identifiers (i.e. maybe requiring them for registration but not showing it to everyone you talk to).

I wonder whether MLS will go anywhere and actual projects will adopt it. Last time I checked it did require consensus on message ordering, which seems to make it less well-suited for non-centralized protocols like Matrix, but we'll see.