AnyZone – DNS delegations without configuring a domain
1 points • 0 comments
From 8/2/2013, 4:38:48 PM till now, @lucgommans has achieved 686 Karma Points with the contribution count of 108.
Recent @lucgommans Activity
AnyZone – DNS delegations without configuring a domain
1 points • 0 comments
Library and command line tool to detect SHA-1 collisions (2017)
9 points • 0 comments
(If I would guess at the meaning behind your question given the examples mentioned, the short answer would be: I'm not so fanatical about privacy that I prefer complex glitchy software with missing features over software that has proper encryption but uses a central set of servers.)
Element is a world of UI glitches. At least encrypted chats are functional now (until ~last year, decryption errors made it close to useless without a fallback channel (e.g. Signal) for the person you're trying to chat with). Still, no search in the Android or web client (only on iOS for some reason)....that is, unless you just don't turn on encryption! So it's not a serious option for me. I use it with one person, who has it on iOS and so occasionally gets requests from me "hey what was this thing again we talked about regarding xyz". We also both have Signal to fall back to on occasion. I don't remember if calls work or if those are encrypted nowadays, weren't they partnering with Jitsi here, and Jitsi's e2ee is still in the works last I heard/checked?
Briar is this Tor or mesh thing right? That's very feature-limited since Tor cannot reasonably support calls (the experience would be like trading voicemails). Mesh is very, very cool tech (I love self-supporting things) but there are no nerds close enough (that I know of) that I could actually talk with them practically using the mesh, even if I was willing to break the law on transmission power (and both phones would support that... like, even theoretically I can't generally use this). I think I did try Briar because sometimes you want to chat with someone in wifi range but outside of network coverage. Since I don't have Briar installed, even that must not have worked between me and my girlfriend's phone. I vaguely recall some device discovery issues but I've tried all the available mesh apps on f-droid so I may be mixing things up.
Threema is pretty crappy as well, but by the Telegram standard I've been used to (back when I believed the missing encryption was just growing pains and they'd get around to it any day now), there's nothing remotely close to feature parity anyway. Threema does fail at basic usage for me, though, which is any kind of functional notifications and a functional desktop client.
Yet I think it's important to have more than one option out there (the "one option" around me is facebook's whatsapp) and I'm happy to accommodate anyone that uses some open source chat system. I'm less okay with people that request I install some proprietary messaging solution just to talk with them. (If we wanted to chat and you've got Briar, sure yes I'm totally installing that, even if it has issues that make me not use it as my primary system.) I've got Threema out of curiosity, initially I wanted to see if I could avoid Signal's connection bugs and Wire's glitches, though today I only still use it for one contact whose Signal does not receive my messages at all.
What Threema has going for it, is that it's not using USA infrastructure, which is quite unique for centralized chat software (for better or worse, at least now you have a choice), and nearly as stable as Telegram: things generally just work as designed (major exception being notifications). Features are fairly extensive so that would almost make it a serious option for my primary messaging system, though the two missing essentials are what kill it for me.
The only usable systems, when I last checked ~2 years ago, were Wire and Signal, each with unique but surmountable downsides (Wire is sluggish and more glitchy and much less of a network effect; Signal misses features like message editing and silently suffers regular connection issues). Everything else I know of is not usable for my family (bad UX and/or glitches that'll throw them off), not encrypted (Telegram), missing features (e.g. video calls, search, desktop client), or unusable due to instability (Matrix until recently, though still not a great experience on my friend's home server).
Screenshot: https://snipboard.io/my8dLf.jpg because the page is huge and takes a while to load.
Just noticed this while scrolling through the diff. Apparently info about an f-droid variant was already committed to the repository readme two months ago. There is no blog from Threema yet, though the most recent post[1] about a push service is relevant since that was a prerequisite for making an f-droid version work.
The f-droid version will not depend on Google and uses your system's emojis rather than bundled graphics. Of course it will also not have(/need) the self-updater.
For me, notifications have not been working so I am very excited for this new push service that will be coming in the f-droid release :)
Threema is coming to F-Droid
23 points • 4 comments
Most certainly, too many to count. A few are on github, e.g. https://github.com/lgommans/mountall.sh, various others are on https://lucgommans.nl/p/
If you're just having a look around, I might recommend to start with
- the hangman solver as a funny random example https://lucgommans.nl/p/hangman-solver/ (for a game to try it on: apt install bsdgames && hangman)
I use 'cau' a lot myself for 'inline' footnotes in chats, e.g. https://lgms.nl/p/cau/?Look+at+how+much+data+I+can+fit+in+th.... but I could see how most people would not use my server for that. Feel free to steal the code! https://lgms.nl/p/cau/?source
I'd be curious to know how many people haven't made the equivalent of https://lgms.nl/p/ip/, at least if you're from before when icanhazip became popular
If you've ever ctrl+c'd restic, you'll know the message
> signal interrupt received, cleaning up
Makes perfect sense. Restic kind-of supports this because you can just kill the client after an hour and, tomorrow, it'll see which objects are there already.
I'm not deep enough into the project to know whether this is like an officially supported use-case, but restic was of course made with the idea that interruptions can happen (your computer can crash) and should be handled safely, and for the deduplication it'll cut files up in a deterministic way and thus (as I understand it) store those chunks in a deterministic place.
Depends which back-end you use and which configuration. (Assuming "node" here means a backup client and not a backup-hosting server.)
If you just put stuff on some standard storage (FTP, B2, etc.) without any permissions set up, then no backup client could stop the attacker from using the credentials you've deployed to the backup client to login to your storage and delete your backup files. This is not really specific to restic.
Accessing old files from a backup client is a weakness. Though, personally, I don't store things on a system that this system is not supposed to know, so if someone compromises this system and they see data from the past year... that's nearly the same as just seeing the data that is on this system today. Nevertheless, this could be solved by using public keys, so the backup clients has an encryption but no decryption key (of course it's not as trivial as this sounds, e.g. how could it still do deduplication etc.), but restic does not do this.
There is also https://github.com/restic/others which has some keywords (e.g. is it encrypted, does it do compression) for most FOSS backup solutions. It can be outdated or incomplete for some entries, though.
This point hides a lot of goodness in something that I didn't even understand on the first read:
> - We have added checksums for various backends so data uploaded to a backend can be checked there.
All data is already stored in files with as filename the sha256sum of the contents, so clearly it's all already checksummed and can be verified right?
Looking into the changelog entry[1], this is about verifying the integrity upon uploading:
> The verification works by informing the backend about the expected hash of the uploaded file. The backend then verifies the upload and thereby rules out any data corruption during upload. \n\n [...] besides integrity checking for uploads [this] also means that restic can now be used to store backups in S3 buckets which have Object Lock enabled.
Object lock is mentioned in passing somewhere down the changelog, but it's a big feature. S3 docs:
> Object Lock can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
i.e. ransomware protection. Good luck wiping backups if your file hoster refuses to overwrite or delete the files. And you know Amazon didn't mess with the files because they're authenticated.
Extortion is still a thing, but if people would use this, it more-or-less wipes out the attack vector of ransomware. The only risk is if the attacker is in your systems long enough to outlast your retention period and creates useless backups in the meantime so you're not tipped off. Did anyone say "test your backups"?
For self-hosting, restic has a custom back-end called rest-server[2] which supports a so-called "append-only mode" (no overwriting or deleting). I worked on the docs for this[3] together with rawtaz and MichaelEischer to make this more secure, because eventually, of course, your disks are full or you want to stop paying for outdated snapshots on S3, and an attacker could have added dummy backups to fool your automatic removal script into thinking it needs to leave only the dummy backups. Using the right retention options, this attack cannot happen.
Others are doing some pretty cool stuff in the backup sphere as well, e.g. bupstash[4] has public key encryption so you don't need to have the decryption keys as a backup client.
[1] https://github.com/restic/restic/releases/v0.13.0
[2] https://github.com/restic/rest-server/
[3] https://restic.readthedocs.io/en/latest/060_forget.html#secu...
"of course" thank you, yes this is really very obvious. As if Signal can't see whom I'm talking to if they wanted to. Yes, their marketing material says as much (and they genuinely try to make it hard for themselves), but you're not the kind of person who swallows those blog posts without thinking of the ways you would attack it. In both cases we trust the server not to snoop on our metadata.
Not everything government-funded must be government-backdoored, that is quite the conspiracy theory for an open source application.
You can also download the APK directly from the website (not using Google's store), which will self-update, and will function also if you don't have Google Play Service on your device.
There are caveats, like if you firewalled off Google services because outright removal will mess up other apps and an alternative ROM with µG means no more (proper) camera app: in that case Signal will detect Google Play, wait indefinitely for the push message via Google, and thus not function at all. So I don't like to defend them on this front, but it's simply not true that it's impossible to use without a Google backdoor on your phone.
That's what they claim to store (and I believe it), but that's not all they can be forced to collect.
As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.
> who even cares whether the smiley face is white or black or whatever else?
If it doesn't matter, why not let people choose whatever they like? Personally I'm also wondering if having specifically white and specifically black thumbs-ups does not introduce more racial bias rather than the generic yellow default that I was used to, but I did notice people of color using specific colors so perhaps it does matter, at least for some of them. The rest of us can just be on (the afaik neutral) yellow, presuming that makes everyone happy.
"CNE" is a fancy word for "exploits" that I had to look up, for anyone else not in the know of this specific terminology...
And yeah this is a blanket statement you can use for any application: nation states can get at your data using "CNE" regardless of what app you're talking about, presuming there always exists an "E" for your client (which is indeed a fairly safe assumption with these featureful OSes and apps). Not sure why you're applying this argument to Wire but not Signal.
It does, but that's my point: it ships with its own updater rather than leaving me to just manage updates with a proper repository client (like apt, dnf, f-droid, google store, whatever).
I hadn't even thought of this, that's a good point and (afaik) negates the entire excuse of Signal's not to be on F-Droid.
Your comments sound pretty damning and got me curious if there was some conspiracy I didn't yet know about, but then I click to the source and it turns out that this is not a silent change to upload more data without users knowing anything, it's an announced feature to (afaik optionally) backup this data to Signal's servers, protected with a PIN. It may not be obvious to my mother, sure, but it's also not exactly rocket science that 4 digits will not be secure under any offline-attackable circumstances. (For that they add SGX which seems broken so that is moot.)
On the other hand, it's not exactly hard to find out who's talking to whom if the server owners want to (or are forced to). Traffic analysis without onion routing is trivial at least in theory, so tptacek isn't quite correct either that Signal does not allow any sort of social graph obtaining. Sealed sender helps a little, but is not a solid thing to rely on if you're the kind of target for whom they would even bother submitting a subpoena. Wire also doesn't keep a list of who's in a group with whom (your client handles that) so there, too, you have to do traffic analysis to find these relations -- just an easier form than you would have to do if Wire would have had sealed sender.
Hence I consider it all about equal, with a small asterisk for Signal that they try really hard to make it as good as possible (compared to Wire doing just the now-regular end-to-end encryption).
> The above discusses the marketed features
The above discusses what I notice in practical terms.
As a privacy nut, I want to use an encrypted messenger for my friends and family so I dove into the privacy aspect pretty deep. I work in security so I also understand the technical details. I also use Wire, Signal, Telegram, and Matrix/Element on a daily basis (and Threema ~weekly) so I know which practical pros and cons I run into for each of them.
> what I understand from people with actual IT security expertise
That would be me. Wire is solid. It's based on the same protocol as Signal and my employer (shortly before I started working there) audited the implementations and applications so I know the people that did this audit, and was later involved in a small architecture review as well. The reports are also open and available on the website of my employer as well as Wire's.
Signal goes one step further and does innovative stuff like sealed sender and private contact discovery, but this does not impact the security of your messages or calls. It has more to do with privacy, aka how much Signal is able to do with your metadata. All of the measures they implemented can be broken if they wanted to (SGX vulns, traffic analysis, ...), so I am hesitant to consider it a solid advantage, but it's now harder to get your metadata so it's still worth something.
On the other hand, there are the advantages (and disadvantages) I mentioned above. It's a trade-off and there's something to be said for each.
(Of course I speak for myself and my employer may have a different opinion yada yada)
> [Signal is] really the only option if you want real security
That's not really true as a strong blanket statement.
For message/call integrity and confidentiality: Wire and Signal are basically the same, because they use the same base protocol.
If you (also) mean privacy, then... it depends:
- Threema operates (app and infra) in a country with better privacy laws, and Cure53 audited them recently so their protocol should also be good. I'd go with them if I wanted the best privacy on a centralized service, though you don't get some of the fancier protocol features like plausible deniability (not that that's worth much, but it's nicer to have than not to have)
- Signal does innovative stuff but requires a phone number (in my country that's linked to a government-issued identity)
- Wire has infrastructure in the USA (big downside imo, I don't understand this choice) but their legal entity is iirc in Germany (which I would consider a similar jurisdiction as Threema's (Switzerland)) so that's still better than Signal in terms of coercion to hand over anything
- Keybase has none of these advantages but still many people choose it for their integrations
- Matrix-the-service I don't remember, but with federation it's fairly trivial to use your own home server so you're fully in control. This is obviously the best option, even if you'd not use e2ee and just encrypt-to-your-server because it's your server which can be in your house.
Pick your poison on that front, or go decentralized.
The aspect I cannot really speak to is exploitability, like how hard it would be to find an exploit that works on one of these apps. Best would be to have one that just shows plain text messages and doesn't do image parsing, video displaying, link resolving, peer to peer calling, etc. That is exactly none of the above and I assume that all of the above rely on system libraries for media/emoji/etc. parsing, so it should be about equal, but I don't know that for a fact.
site design / logo © 2022 Box Piper