dvzk

Is the monarch just a figurehead, or a failsafe? I know nothing about UK politics, but sometimes I wonder if sovereign influence would re-emerge if democracy or society were to fail.

No, I do think Kiwifarms should have been prosecuted and unhosted, for failing to curtail frequent mass harassment threads against ordinary and mentally ill individuals, which led to real-world harm. I'm just not going to defend deplatforming by quoting downvoted and deleted jests from a few users who could also be anti-KF astroturfers.

Just say that you want Kiwifarms deleted from the internet. There is nothing tenuous or uncertain about that stance, if you own it openly. Hiding behind concern over a false and un-serious threat is a coward's strategy.

It is kind of irritating for a commuter to dismiss competitive and fitness sports as hobbies, but that aside, the aforementioned trail parallels a major highway and it’s used by thousands of cyclists and commuters each day for the majority of their routes. Some toss their bikes onto the lightrail and bus racks at the end to avoid roads.

It's a different cycling experience to live in an area with 30+ continuous miles of a paved and forested riverside bike trail and 50+ miles of interlaced dirt trails. Cars can barely be a threat consideration most of the time.

I disabled iCloud Photos sync some time ago, and even though there are some pain points, it's surprisingly easy to work without it. Just do a manual direct sync every so often. Run borg or bupstash to encrypt and backup the copied photos to any location.

I ended up hand sewing several patches onto my synthetic $100 MTB shorts just last week. No guides, and the process was excruciatingly long, but it turned out fine. Give it a shot! I gained a newfound respect for sewing.

I’ll let you know the outcome when someone jacks my custom $7000 bike from its truck bed rack for the second time.

Actually, it's more that many of us frequently risk the likely theft of our precious items, the permanent loss of which would be extremely damaging or upending. And the contrived examples of abuse cases are much less compelling, especially when the only alternative, cellular GPS trackers, are even more invasive. And I dare someone to formulate an ethically consistent argument for banning GPS tracking devices.

This is the line which remotely stores your contacts encrypted E.164-formatted phone numbers:

https://github.com/signalapp/Signal-Android/blob/main/app/sr...

protobuf files just contain data structure definitions. StorageService.proto contains only one reference to StorageRecord, but Signal actually syncs hundreds of StorageRecords.

Instead of linking to source code examples, which is easily misunderstood, here is Matthew Green's summary:

https://blog.cryptographyengineering.com/2020/07/10/a-few-th...

Alternatively, you can just open the app settings, which tells you that it will attempt to restore your contacts if you create a PIN:

> PINs keep information stored with Signal encrypted so only you can access it. Your profile, settings, and contacts will restore when you reinstall. You won’t need your PIN to open the app

From my 5-minute reading of the Signal source code it seems that disabling the PIN results in the generation of a random 256-bit master key for cloud storage encryption:

https://github.com/signalapp/Signal-iOS/blob/main/SignalServ...

The primary developer has stated previously that cloud storage is still used even with the PIN disabled:

https://community.signalusers.org/t/beta-feedback-for-the-up...

I do think considering the average use case is paramount. That's why I think remote encrypted contacts storage should have never been implemented: most people won't choose strong passwords. Giving them the false notion that their sensitive stored data is cryptographically indecipherable is wrong.

As it stands now, people who create a Signal PIN aren't even warned about the security implications of using weak numeric PINs, which is among the worst of all possible worlds.

If this feature is critical, it should have been gated behind prominent passphrase entropy warnings, along with the data being put at risk [1], or it should have enforced actual strength requirements.

Signal is still better than most other messengers. I am mostly comparing it to its former self. And its former self worked flawlessly without needing to upload persisted contacts information.

1. https://github.com/signalapp/Signal-Android/blob/main/libsig...

Basically there are many options, none of them perfect:

1. Support phone number contact discovery, with persistence provided by the contacts provider. This is seamless and causes the least amount of complaints.

2. Support username discovery, with persistence provided by passphrase-encrypted online storage. This is painful and risks backlash from people losing access to data. Also, now the threat model must account for or ignore weak derived keys (which is probably most of them).

- 2a. Enforce strong passphrase requirements. Many users will abandon the product.

- 2b. Sync usernames between linked devices (using a generated key). Requires multiple devices, risks people losing data, more complaints.

- 2c. Sync usernames using custom contacts provider fields (e.g. email). Nobody is accustomed to doing this, but it might work. Automatic discovery rates would be low. Possibly requires an odd workflow for people adding Signal contacts by their email/username.

Most people will choose weak passwords given the option. And so I think it's the responsibility of the developer to enforce strong requirements (edit: when dealing with data encryption susceptible to brute-force attacks): entropy estimations, 128(+)-bit static keys, etc. If any user has chosen a weak passphrase, and still believes it to be secure, the developer has likely failed.

I think developers have a moral responsibility to make their products as secure as possible, within reason and while still being usable. It doesn't matter if the users care about the benefits. To your second question: no, not yet.

It was because of over-represented complaints about phone number requirements that Signal implemented the mistake that is SGX and server-side contact lists. Now the social graph of millions of Signal users is instead centrally protected by Intel's attestation obfuscation and a weak 4-digit PIN. All to eventually support usernames, which normies won't use.

It won't prevent theft of ephemeral SSH session keys, but consider using a HSM or at least a TPM (with Termius, or Secretive) for long-term private key storage. 2FA will situationally help with the other concerns. (You can and probably should use 2FA with SSH as well.)

I’m torn between thinking it’s voting manipulation or the network effect of creating a desirable product so simple nearly anyone can use it. A huge amount of Tailscale comments are from people who find configuring trivial Wireguard tunnels challenging.

Sadly almost none of that is complex or surprising if you’re used to dealing with DNS deployments on Linux or BSD. What’s new is bundling a custom system name resolver for machines that can’t forward matching domain requests to specific name servers. Users are often left to their own solutions if they don’t use systemd-resolved or NSS.

Custom peer to peer networks over Wireguard are theoretically more secure. A list of additional potential adversaries who can remotely access your Tailscale network without client manipulation:

- Tailscale’s coordination server

- Tailscale’s cloud provider

- anyone who compromises the coordination server

- SSO provider you have chosen

- SSO’s cloud provider

- anyone who compromises the SSO provider

It doesn’t matter if they are real. If the topic is about practical suggestions for reducing the attack surface of current systems, it’s the wrong place to bring up global surveillance and vague allegations about vendor trust and world governments.

Distinguishing between security and privacy is important, because otherwise you get a bunch of uninformed conspiracists who insist that hardening a machine involves installing Tor; or that using Google is bad, in a topic about using cryptographic signatures.

If you use uBlock's advanced mode to default-deny scripts or third-party resources then no other extension comes close. (Except for uMatrix, which is by the same developer.)

Requiring an administrator or other device to pre-authorize or manually approve a new device, by signing the new device key with a client signature key.

Why would you expect anything else? That’s like saying Wireguard or SSH servers should just accept any client. The purpose of mesh VPN controllers is to automate redundant key management, not to subvert the original security model.

I've never used or examined Tailscale either, but I assumed that:

- Tailnet traffic needs to be associated with an approved device key

- Tailnet device addition needs to be signed by the offline key of another approved device

If a compromised control plane and/or SSO provider can add and approve devices on their own then the security architecture of Tailscale would be fundamentally broken. I wouldn't even call it end-to-end encrypted.

And? This just proves you lack a fundamental principle for or against discrimination. That’s fine, you do not need one. But you can’t refute a categorical opposition to discrimination by listing more subcategories of discrimination.

It’s rare to find any ethics professors who argue in favor of moral relativism in this manner. A vast majority are realists or constructivists who would easily claim that Romans were bad for practicing slavery and forced combat for fun.

The inconsistency gotchas in this thread are hilarious. “What if you replace religion with race or gender?” “What if you replace AI with god?” If your answers change then you have no principles.

Have you described your reasons for not migrating to Wireguard in v2.0? Is it partially because Wireguard only really has a portable (and heavyweight) Go implementation that's also tightly bound to OS networking primitives? I'm mainly wondering if there are also cryptography or protocol limitations that make it unsuitable.