The insane behavior in the post is not that you get fancy completions, but that the completion does not match the preview. If the computer starts doing A when you asked it B, it is equivalent to a trash can.
How will this hit OSS projects which rely heavily on github actions? I’m thinking of projects like nixpkgs, which is the backbone of nixos and always has dozens of actions queued or running. (I am using nix as an example for scale, but I am not involved in the project and my description might be inaccurate. I’m also not familiar with nix’s financials at all.)
> Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.
Unfortunately, those are 2 different problems. It’s easy to have servers store encryption keys to make https work. You only need to encrypt trafic between you and a server for 5 seconds at a time.
It’s hard for personal communications. The server shouldn’t know the keys, and they need to survive for decades.
Someone needs to design a super dumb and robust system where I can safely store all my keys on all devices I use an account. The fact that whatsapp, signal and other platforms tend to have a primary device for keys is bonkers to me. A primary device that can randomly die, get stolen or fall in a lake.
I have lost chat histories more times than I can remember, and I have to be extra diligent about this these days.
I don’t even want to think about pgp when I have to manually take care of this problem. Not because of my own skills, but because I could never make it reliable for my family and friends on their side.
Signal's threat model is that everything around you is hostile to you, except the parties you interact with. You are an undercover rebel in a totalitarian sect which would sacrifice you to Cthulhu if they see your chat history. Losing it is much better than disclosing it.
Your threat model is likely random black hat hackers who would try to get into your communication channels and dig some dirt to blackmail you, or to impersonate you to scam your grandmother out of several thousand dollars. Signal protects quite well against it. But the chance of this happening even in an unencrypted channel is low enough. You don't mind making the security posture somehow weaker, but preserve the possibility to restore your chat history if your secure device is lost or destroyed.
I suppose the problem could be solved by an encrypted backup with a long key which you keep on a piece of paper in your wallet, and / or in a bank in a safe deposit box. Ideally it would be in the format that the `age` utility supports.
But there is no way around that paper with the long code. If this code is stored on your device, and can be copied, it will be copied by some exploit. No matter how inconspicuous a backdoor you are making, somebody will find it and sneak into it. Should it happen in a publicized case, the public opinion will be "XYZ is insecure, run away from it!".
> If this code is stored on your device, and can be copied, it will be copied by some exploit.
Yeah... We really need some key-management hardware where the secrets can be copied by some channel that is not the primary one. This used to be more common, before the IT companies started pushing everything into the cloud.
I have recently started to see computer boards with write protection for the UEFI data, what is a related thing that also did go away because mostly of Microsoft. So, maybe things are changing back.
> I have lost chat histories more times than I can remember, and I have to be extra diligent about this these days.
As per Signal’s diehard proponents, losing chat history is a feature, not a bug (I’m not being facetious when saying this, and you can see comments of this kind in Signal related threads here).
Edited to add: I don’t agree with that premise and have long disliked losing chat history.
I know you are not being facetious. My problem is random Joe on the street sees it as a bug. He really does care more about actually being able to talk with his wife than Signal’s mathematically correct principles. He needs it to be reliable first, secure second.
Perhaps it’s a marketing problem, then. Signal is marketed as a secure and full-featured alternative to things like WhatsApp and iMessage. Most people start reading that sentence after the word “secure”, and then are surprised and disappointed when a device replacement loses all their history.
I think it would be better if Signal more loudly communicated the drawbacks of its encryption approach up-front, warning away casual users before they get a nasty surprise after storing a lot of important data in Signal.
I’ve heard Signal lovers say the opposite—that getting burned with data loss is somehow educational for or deserved by casual users—and I think that’s asinine and misguided. It’s the equivalent of someone saying “ha! See? You were trading away privacy for convenience and relying on service-provider-readable message history as a record all along, don’t you feel dumb?”, to which most users’ will respond “no, now that you’ve explained the tradeoffs…that is exactly how I want it to work; you can use Signal, but I want iMessage”.
It shouldn’t take data loss to make that understood.
You've been downvoted, but I think that's a fair take. There will always be tension between security and usability; it's difficult (impossible?) to do the absolute best in both metrics.
Signal's development team can decide that they prioritize security over usability to whatever degree they like, and that's their prerogative. That may result in fewer users, and a less than stellar reputation in the usability space, but that's up to them. And if we (the unpaying user base) don't like it, we are free to use something else that better meets our needs.
Maybe an answer is to have a control for each message that you can set to plain text or encrypted based on a cloud backed up key of encrypted based on a key only on this device. The you could message "hi mum, running late" without complications while being able to hard encrypt when you want?
Signal is already complication free (at least until your phone falls in a lake) making the control useless.
(And you probably don't need to worry about losing the 'running late' message in the lake... The need for good encryption and reliable backup on any given message is likely somewhat correlated.)
(i am a security person who prioritizes security over usability but) you missed the point a bit. If a privacy program is used only by people that have something to hide it turns into a smoking gun. If you care about being targeted by government you should really hope regular people use signal a lot, because government absolutely has (or can procure) a list of people that use signal.
My company recently really cut back on slack retention. At first I was frustrated, but we all quickly got over it and work carried on getting done at the same pace as before and nothing really got impacted like many of us imagined it might.
That bears little resemblance to the Signal concerns. The reason people are worried about losing their personal messages is not lost productivity.
It's also not even really the same situation. A more apt analogy would be, if switching work laptops sometimes meant you could no longer read any Slack history.
Once communication with my customers moved to teams. I've had a very hard time to find historical agreements and decisions.
I try very hard to create a robust system for ADR logging now. And not just for system architecture. But for all decisions and agreements in my projects and across changes.
Well I don't think most people choose who they work with. Even if you like your team a lot, you might have a discussion with someone from another team or division, and that's where it's useful to have a good chat history haha.
I'd hate this, slack is an extension of my memory and it being long lived and searchable can be a super power - you don't have to remember all the details of everything, just enough of the who, what, when to find the rest.
So, the requirement is a system to store all your keys and that it can be duplicated as many times you wish. It looks like a local password manager, let's say keepass. I use it and have copies of the encrypted db on every device of mine, plus the client to access the passwords. I don't know if it qualifies for dumbness but it feels pretty robust. It survived the fall into the lake test (a river in my case.)
But I see every customer of mine using web based password managers, because they want to share and update passwords with all their team. Of course those password managers can use E2E encryption and many do, but my instinct is that if you are using somebody's else service for your data, you can be locked out from your data.
Anyway, it's the concept of having many passwords and having to manage them that's not dumb enough. The most that people do is letting the browser store and complete passwords. The password can be the same 1234pass on every single site.
Web-based password manager user here! It's worth noting that Bitwarden and 1Password (probably all the others too) let you export all of your data into an encrypted archive, so anyone who does this periodically won't be "locked out".
(Naturally, this requires extra effort on the users' part, so who knows how many are actually using this ability.)
I set up automatic backups of WhatsApp to my self-hosted Nextcloud once. Since you need 'tested backups', I tried to decrypt these WhatsApp backups independent of my phone, but this was not possible. You need the original device. There are some hacks online, but they are always out of date.
I am tending now to running Mautrix Whatsapp bridge and backing up my data through this.
But then Apple or Google can control your access to any account that uses those passkeys. We need a protocol where I can store the same passkey on multiple cloud providers
my proposal devices is like yubikey but instead of yubikey hardware in place like USB devices form
its in the form of ring or bracelet, its small enough and can be carried everywhere with you all the time
its use NFC like technology, it works without battery, fast and "secure enough" for 99% of people
what if the device is stolen???? we can add authorization like biometric (fingerprint etc) while touching devices so it can be sure the real owner is "giving" auth
The problem is not a personal hardware security module, as you noted we have them. The problem is that people want redundancy that undermines the point. If you can easily have a copy of your ring just in case, how do you know who has done that process and watches you all the time? Biometrics sounds like a solution yet they are implemented as a cosmetic security layer and this situation is pointless to fix since we leave them everywhere we go.
I admit, it is a good acquisition announcement. I can’t remember the last acquisition announcement that was kept for more than 1-2 years. Leadership changes, priorities shift…
As I understand it, this attack works because the worm looks for improperly stored secrets/keys/credentials. Once it find them it publishes malicious versions of those packages. It hits NPM because it’s an easy target… but I could easily imagine it hitting pip or the repo of some other popular language.
In principle, what’s stopping the technique from targeting macos CI runners which improperly store keys used for Notorization signing? Or… is it impossible to automate a publishing step for macos? Does that always require a human to do a manual thing from their account to get a project published?
I’d like to see a real shell script written in ion very early in the readme or manual. Something that wgets a tarbal, extracts some part if the filename, checks cpu usage, draws a simple progress bar to the terminal, checks a folder for old files, some script that implements prompt completions for some cli tool…
I really don’t care that a new shell is written in rust. I care to see examples of how it actually would be better than bash.
The fact that it’s written as a personal journey and not as advice suggests the author was on a journey to become more genuine/accepting of who they are. It does read as someone who tried to be manipulative at the start but graduated away from that towards the end of their journey.
You can gain a lot from the article and see it as both manipulative, or as insights for working through your own social anxieties. You could bring both attitudes to the article. And one of those is obviously healthier than the other.
Unfortunately, I require PDF outputs for some of my documentation. Right now this is possible via some plugins (I cannot remember which fork of a pdf export plugin worked, but at least one does) in Material for MkDocs. It’s not perfect, but it is good enough.
Should I expect a “good enough” pdf export experience in zensical at some point or now?
Yes, we're basically agnostic to the input and output formats. Right now it's Markdown -> HTML, but with the upcoming module system, it'll be possible to convert anything to anything. Our focus will stay Markdown/HTML first, and once we reach feature parity, we'll explore to support formats like PDF etc. natively.
