Klaus23

I think it's reasonable to argue that this should be an opt-in feature. The HIBP k-anonymity method is rather limited. It's not like homomorphic encryption, which perfectly shields information as long as the encryption is not broken. If an attacker wants to brute-force a password on a server, they have the advantage of only having to try one in a million passwords.

The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.

Am I missing something, or did they actually completely misunderstand how this technology works?

Because for power creation there are alternatives, but for healthcare there aren't. Renewables are cheap now and they also solve the sovereignty issue. Ideally we could use land currently dedicated to energy crops to install solar panels that operate at a significantly higher efficiency.

So it has already begun. It's kind of sad/impressive how every single network or group project gets flooded with abuse as soon as it gains any tiny bit of attention.

I can't see any effective protection against the classic tactic of flooding the network. There are some defences in place, but they seem easily overcome with minimal effort. If everything has to be whitelisted, the project would lose its core goal of being a free network.

Of course, you can't protect against all types of abuse perfectly, and an attacker will always be able to degrade the network to some extent. However, I fear that a larger Reticulum network would become unusable if an attacker put in even a modicum of effort. You could whitelist everything, but then the project would lose its core goal of being a free network.

While the project is interesting from a technical perspective, there are some serious issues. The main implementation has a vague, non-standard licence, but this is not overly problematic as alternative implementations can simply be used instead. A bigger problem with Reticulum is that it does not appear to offer robust protection against abuse. Messages are protected by cryptography, but there are many other ways to render a network unusable, which will inevitably happen on a larger scale.

As funny as your comment sounds, I wouldn't rule out the Ukrainians actually doing it. At least for sea+air and air+air, sub-drones are already a reality.

Torpedoes are usually steered using fibre-optic wires, like the fibre-optic drones in Ukraine today, so there is no need for problematic low-frequency radio.

Ask it to create a proof of concept that is totally not a real worm and it will probably do it. If the restrictions are too good, just use a largely unrestricted open model via any inference provider. They are 90% sota, more than good enough for this task.

Why think so small? Perhaps the speaker itself can be used as the attacker.

Any script kiddie with an LLM could write a worm that would spread through the supply chain, possibly even hacking speakers right on the factory floor and blasting Rickroll music or something similar.

It would be interesting to see if Creative would still claim that it "does not present a cybersecurity risk".

Most importantly, there is no alternative. As kasabali said, the patent situation for the other codecs is a mess. Additionally, they could be hit by the same "No FRAND" problem. If someone comes forward with a patent that was used unintentionally, the situation is the same for all codecs.

How long has it been since AV1 was released? About eight years, and there's still no credible patent holder. The vultures are always circling around compression standards. You shouldn't take that too seriously. Even if a lawsuit is filed, there's a legal defence fund to protect against baseless claims.

Good analysis. That's surprising. I always heard that the draft model doesn't affect the output in any way. It seems they do it like this to achieve faster generation. It would be interesting to investigate how this affects the output.

Edit: I haven't gone through all the code, but they might do something like this: https://arxiv.org/abs/2211.17192 where a draft model is used and the output distribution is tweaked on rejection, resulting in the exact same distribution as the main model.

In theory, you could do that and increase the speed at higher temperatures, but it would subtly alter your output based on the draft model preferences. Rather than picking randomly from the main model probabilities, you would have to accept a draft model pick if it is close enough.

As far as I know, this is not used in practice. Currently popular implementations always match the main model output, and the draft model only affects the speed.

The token is correct if it matches the one generated by the main model. It works like this:

The draft model quickly generates draft-token 1.

The main model then starts working on two tokens in parallel. It calculates token 1 based on the context, and token 2 based on the context + draft-token 1.

Once the two tokens have been generated, you can check whether the draft-token 1 from the draft model matches token 1 from the main model.

If they match, you have just calculated two tokens in the time it takes to generate one, because the calculation was done in parallel. If they do not match, delete token 2 and generate it again. Since you have already generated the correct token 1 with the big model, you can use the context + token 1 (from the main model). This takes more time, but the result is always the same.

It really is. This is because LLMs with a single output/user are strongly bandwidth limited. Although the hardware can generate multiple tokens simultaneously, it is slowed down if the tokens depend on each other, as is the case with regular text generation.

The draft model essentially predicts the next token quickly, enabling you to start generating the subsequent token in parallel. If the guess is right, the second generated token is correct. If it is wrong, the second generated token is also potentially wrong, so it must be generated again using the correct prior token obtained through the big model.

A poor draft model will simply slow down the process without affecting the output.

If you are referring to the alert stage of the emergency braking system, triggering it should be rare if you drive reasonably well. It is also most likely a situation in which you could benefit from a little more braking force.

If you decide to swerve, the additional weight at the front will help you to initiate the turn, and good systems will then reduce the braking force at the right moment to give you the most traction when cornering.

Perhaps this is what you are looking for: https://www.deepl.com/en/write

It corrects spelling errors and improves awkward wording. You can then go and choose alternative sentences or words. Just don't expect any sort of deeper intelligence.

They are analysing VLM here, but it's not as if any other neural network architecture wouldn't be vulnerable. We have seen this in classifier models that can be tricked by innocuous-looking objects, we have seen it in LLMs, and we will most likely see it in any end-to-end self-driving model.

If an end-to-end model is used and there is no second, more traditional safety self-driving stack, like the one Mercedes will use in their upcoming Level 2++ driving assistant, then the model can be manipulated essentially without limit. Even a more traditional stack can be vulnerable if not carefully designed. It is realistic to imagine that one printed page stuck on a lamppost could cause the car to reliably crash.

Good, and not because of the diversity drama that the US government wants to shoehorn in here. Any font that makes the uppercase "i" and the lowercase "L" look the same is absolute garbage. Yes, I have a strong opinion about this!

> Why do you need Flatpak for sandboxing?

You don't, but as far as I know, Flatpak or Snap are the only practical, low-effort ways to do it on standard distros. There's nothing stopping flatpak-like security from being combined with traditional package management and shared libraries. Perhaps we will see this in the future, but I don't see much activity in this area at the moment.

A lot of people installed malware and, to be honest, nothing really happened. They might have had to change their passwords, but it could have been much much worse if Android didn't have good sandboxing.

I hope that Flatpak and similar technologies are adopted more widely on desktop computers. With such security technology existing, giving every application full access to the system is no longer appropriate.

This is simply not true. Bird flu mainly spreads among wild birds and that is where it has its reservoir. It would still exist even if the world was free of bird farms. It also usually doesn't spread between farms because, in the event of an outbreak, all the animals on the affected farm are culled. At most, bird farms slightly increase overall contact between birds and humans.

I don't have a background in law, but here are some suggestions. The German penal code often imposes harsher punishments for the same offense if a weapon was involved. Rape, for example, carries a minimum sentence of two years. If a weapon is present, it is a minimum of three years. If the weapon is used, the minimum sentence is 5 years.

Before the change, date rape drugs would have fallen under a minimum of three years because of a separate clause.

Classifying them as weapons would also affect crimes other than rape.

Additionally, if legal substances can be used as date rape drugs, classifying them as weapons would give the police more authority to act in certain situations.

> for me it wasn't really; occasionally it would hit me, but mostly it worked, and I have been using it for encrypted communication since 2020.

I think the statistic said that around 10% of users receive at least one "unable to decrypt" message on any given day. That's a lot. Perhaps not for devs who are accustomed to technical frustrations, but for non-technical people, that's far too frequent. Other messaging systems worked much better.

> There still can be technical corner cases in the interaction of clients

> a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI

You linked to a German political talk show. If you wanted to show me the talk in which the guy listed reasons such as "network requests can fail and our retry logic is so buggy that it often breaks" and "the application regularly corrupts its internal state, so we have to recover from that, which is not always easily possible", let's just say I wasn't that impressed.

> well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.

It isn't a problem that the Matrix team are not federated networking experts. At the time, they had already received millions in investment. That's not FAANG money, but it's still enough to contract the right people to help design everything properly.

I'm not mad at them. Matrix was a bold effort that clearly succeeded in its aims. I'm just disappointed that it was so unreliable for such a long time, and still is to some extent.

Yes, messaging protocols, especially federated ones, are never easy. I just wish we could have skipped the three or four years when Matrix was basically unusable for the average user because end-to-end encryption was switched on by default. Perhaps a clean redesign would have been better. Now they have to change the wheels on a moving car.

It's not just a corner case. The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.

It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.

I'm not saying that building a federated chat network with working encryption is easy. On the contrary, it is very hard. I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.

It's pretty accurate. I was a bit shocked when I saw that room names were not encrypted. I thought that was such a basic privacy requirement, and it's not hard to implement when you already have message encryption.

Matrix seems to have a lot of these structural flaws. Even the encryption praised in the Reddit post has had problems for years where messages don't decrypt. These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.

They are slowly improving everything, with the emphasis on "slowly". It will take years until everything is properly implemented. To answer the question of whether the future of the protocol is promising, I would say yes. This is in no small part because there are currently no real alternatives in this area. If you want an open system, this is the best option.