Hacker Newsnew | past | comments | ask | show | jobs | submit | RandomGerm4n's commentslogin

I think it would be a mistake to reject Matrix outright. Even if it's not perfect, it would still be a good starting point from which to build something better. Besides, you don't have to replace Discord with the perfect solution, just with something that's better than Discord and where there's no company behind it that can steer it in a negative direction again, as happened with Discord.

The writer of this blog is a cryptographer. They're primarily focused on security, first and foremost, and when people ask for their advice, they're probably concerned about security, too.

The Matrix devs demonstrated an alarmingly cavalier attitude towards fundamental security issues that the writer pointed out in the past, so they are naturally not going to encourage its use.


The devil is in the details on this. The core concern was that libolm (the obsolete C impl of e2ee in Matrix) used crypto primitives which don’t protect from timing attacks.

However, in practice, this was not exploitable: the only way to exercise these primitives was over the network, where network latency and request rate limiting mitigates such attacks.

Meanwhile, we had already rewritten and replaced libolm with vodozemac, a pure rust implementation using robust primitives, shipped in the major Matrix SDKs and implementations like Element and Element X.

I’m not sure this counts as alarmingly cavalier. I do regret libolm ever going into production with substandard primitives from a hygiene perspective, but we fixed it as soon as we could via vodozemac, and meanwhile included the safety warning.


The part that was "alarmingly cavalier" was when you admitted to knowing about these problems for years and not fixing them or telling the ecosystem of competing clients about them so they could mitigate their risk. https://news.ycombinator.com/item?id=41249371

You visibly deprecated Olm after my disclosures went public. When I last checked, only Element and its forks actually use vodozemac, so the rest of the ecosystem which still binds libolm was still vulnerable, and probably still is today.

That's alarmingly cavalier.


>just with something that's better than Discord

I mean, that's the entire issue. There's very little tangibly better than Discord. I like the idea of Matrix, but it's complete garbage in practice.

At least for now, the solution lies more in mass outrage and action rather than any technological migration. The post raises this and I think it's a good point.


Also, the fetishism for federation has got to stop. It's only barely workable in asynchronous environments like the Fediverse, but on a live chat service it's ruinous. It's feels like it's half of what's suffocating Matrix.

IDK, XMPP group chats have always "jest werked" for me (though admittedly I haven't used them much).

The difference between XMPP group chats and Matrix group chats is that Matrix servers replicate all the message history, whereas XMPP group chats are hosted on a single server. IMO the "bring your own account to a central server" model of XMPP is a good thing, but the "replicate all the things" model of Matrix is not.


It works fine in chat, been using it for years

Element is way better these days. Not many people know this but Matrix team upgraded synapse last year to support hundreds of simultaneous voice/video users without the need for that shitty jitsi. They aren’t advertising bullshit to you all the time. The ACLs for spaces and rooms more granular and expressive. Your data isn’t training AI models used by people that want to enslave you. You have control where your data resides for protections by jurisdiction. Element has web embeddings for links now, it has all the platforms supported, it’s easy to verify sessions and backup your key. They support SSO external auth. What more can you want?

Using Fedora Kinoite/Silverblue is not really an option if you are using an Nvidia GPU. With Bazzite, the driver is pre-installed and also signed directly with a Secure Boot Key that you can import when installing Bazzite. With normal Fedora Atomic, you have to install and sign the driver manually, and with some updates, the whole thing breaks again, so you have to fiddle around with it. In addition, Fedora Flatpak Remote has been removed, which is a “noobtrap” in normal Fedora Atomic. This allows you to install broken versions of browsers where the codecs are missing and videos don't work. In addition, Distrobox functions better than Toolbox, and in general, Bazzite's defaults are much more geared towards an immutable system. Silberblue/Kinoite's defaults are just like normal Fedora, and you have to layer dozens of things to achieve the same thing, whereas Bazzite is completely designed for a container workflow.

Even if you ignore any gaming optimizations, etc., this alone makes it a significantly better option than the official Fedora Atomic images.


I don't understand why Apple and Google don't just use biometrics as a second factor, like GrapheneOS does. When you first start up, you have to enter your real long and complicated password, and then every time you unlock it after that, a short PIN + your fingerprint is enough. If you enter the PIN incorrectly too many times or hold your finger on it at the wrong angle, it locks and you have to use the real password. There is also a duress password. If you enter this instead of the real PIN, all data is deleted. This means that even if someone threatens you and tries to force you to cooperate, you can prevent the device from being unlocked.

This does not seem to work with Fedora Atomic. Because the system is read-only, the kernel module cannot be loaded. You would have to create an RPM package for the rootkit that you can then layer. In addition, due to Secure Boot, the kernel module would have to be signed with the same key as the system itself.


With secure boot enabled, is it mandatory for kernel modules to be signed with same key so they can be loaded? I was not aware of this.


insmod can load a module from anywhere (surely /tmp is writable), even stdin. That's why you definitely want to block unknown kernel modules.


Most production OS I saw would do this on boot-up completion:

echo 1 > /proc/sys/kernel/modules_disabled

Which is supposed to block dynamic loading modules until a reboot.

It would be interesting if the PoC can get around that trick too. =3


Once you have memory write as ring0, all protections are dubious at best.

Why bother loading a module when you can inject code into any function you want.


The encrypted page memory manager hardware in some ancient Sun systems prevented a lot of these context isolation problems. However, the modern IT landscape chose consumer grade processor architecture and bodged GPUs as the cloud infrastructure foundation.

Thus, there currently is economic inertia entrenching vulnerable system design. I don't think there is a company large enough to change the situation anytime soon, as the market has spoken. =3

Rule #3: popularity is not an indication of utility.


If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot.

Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.

The Linux kernel is not really an effective privilege boundary.


So what would you recommend instead? To run workflows in VMs?


A kvm hypervisor is not perfect, as sandbox escape was demonstrated even with https://qubes-os.org/ . On modern AMD/Intel/ARM64 consumer processors it is not possible to completely prevent bleeding keys across regions.

Only the old Sun systems with hardware encrypted mmu pages could actually enforce context isolation.

If performance is not important, and people are dealing with something particularly nasty... than running an emulator on another architecture is a better solution. For example, MacOS M4 with a read-only windows amd64 backing-image guest OS is a common configuration.

https://github.com/86Box/86Box/releases

https://github.com/Moonif/MacBox/releases

Best of luck =3


I am hearing first time of a sandbox escape in QubesOS. Can you link the source?


It was a POC from shortly after Spectre CVE dropped, and I'm not sure if the source code made it into the public. I heard about the exploit in a talk by Joanna Rutkowska, where she admitted the OS could no longer completely span TCSEC standards on consumer Intel CPUs. YMMV

The modern slop-web is harder to find things now, and I can't recall specifically if it was something more than just common hypervisor guest escape. =3


Or only allow signed kernel modules. Aka secure boot.

This doesn't solve all vectors but afaics this will prevent non signed modules from loading.


KeepassXC also has the option to export passkeys


Perhaps we should simply take this as an opportunity to finally abolish copyright. Smaller artists mainly earn their money with commissions. They are paid to do a very specific thing. Whether there is a copyright on the result is irrelevant. Someone else who would "steal" the image and use it without payment would apparently have fewer requirements. The person could have simply taken any AI image. Therefore, the artist in the scenario would not receive any money from the second person anyway.

Apart from this, it is mainly large companies that benefit from copyright laws. Why should we have laws that restrict progress just so large capitalist companies can maximize their profits?


Exactly. All of these just exposes the absurdity that is copyright laws. It happened before with the Internet and online piracy too, when redistribution became free and easy, yet the corporations and copyright holders refused to budge so they can retain their profits.


Here’s what happens with no copyright:

No one will have any right to their own creations. Anything an individual makes will belong to everyone. And since no attribution is required, no one will know who made it. An average artist’s value to society goes from low to non-existent.

In this world. big corporations will take everything created, claim as their own, and profit from it.

Right now, big corporations using other peoples work unattributed or unlicensed is unethical, because copyright exists. Remove that, and it becomes expected that every thought and idea you express belongs to whoever can make the most profit from it.


Moral rights can still exist, so they can't claim that they made it. This assumes that big corporations will be able to profit to the infinite extent we have today without copyright. Law is not ethics. And finally, this is already the case; without the money to sue, you effectively already own no IP. It's either copyright for only big entities, or for nobody at all.


I think the term the author is really looking for would be free software or libre software. https://www.gnu.org/philosophy/free-sw.en.html


I tried it and after a short time I came across websites that locked me out and told me to disable my adblocker. Even at the highest block level it doesn't change anything. With the normal uBlock Origin version, most sites just work and don't even show the anti adblock notice. An ad blocker that is not able to bypass the annoying anti adblock measures is useless garbage.


Why does Proton store IP addresses in the first place? If they didn't have them, they couldn't give them out. Same with the recovery email. They should write a warning next to it, so that you can then decide for yourself whether a recovery email is advantageous or harmful for your own threat model.


Most of this metadata is kept only temporarily, including IP addresses, which you can read more about in our Threat model (https://proton.me/blog/protonmail-threat-model ), Privacy Policy ( https://proton.me/legal/privacy ) an this article (https://proton.me/blog/enhancing-protection-information-for-... ). By default, we don't retain IP addresses permanently. Your signup (account creation) IP address is temporarily kept for abuse-prevention purposes, and can be retained indefinitely if your account is found to be engaged in activities that breach our terms and conditions (spamming, DDoS attacks against our infrastructure, brute force attacks, etc). The legal basis of this processing is our legitimate interest to protect our Services against nefarious activities. If your threat model includes anonymity, we recommend that you follow the advice shared at the end of the Restore Privacy article above.

For the majority of users, it's better to have a recovery email on their account, as the risk of losing their password is higher than the risk of being targeted by a legal request. However, even in those cases you can have both, by setting up a new email address which you don't use for anything else as a recovery email.


Why is the recovery email forced? Cant this be an option if the user wants to have one saved when signing up?


For signup it seems a non-disposable recovery email or a phone number is required. After signup you can remove those (and add other ways to recover if you wish).


Recovery email is not forced, it's optional.


True for the IP addresses They do have a feature for access logs to your account though. Maybe its because of that?


This feature is off by default, and if you enable authentication logging for your Account or voluntarily participate in Proton's advanced security program, the record of your login IP addresses is kept for as long as the feature is enabled. However, the IP logs from before the feature is turned on and from after it is disabled are not kept.


Here in Germany, something similar happened to my neighbor. He always rejected the packages but sometimes they left them in the stairwell. At first, he took them to a drop-off station but at some point, he went to ignore them completely. After half a year, this led to the stairwell being full of unopened packages until someone threw them on the street. As a result, he then received a bill from the city cleaning service. I sadly don't know what happened after that because I moved away.


Fittingly Kafkaesque


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: