opnsense can use the delegated prefix for DHCPv6, it then automatically becomes the “LAN net” firewall alias and you can refer to it in a firewall rule I believe. I assume it’s the same for pfsense and I suspect they are not the only ones.

How could this be a legal requirement and at the same time you can purchase static IPs as a paid option from ISPs, like I did?

There are ISPs out there that distribute IPv6 to the WAN intf of the home router without a /64? What’s the point for them?

Isn’t eIDAS about voluntarily authenticating rather than being controlled/monitored? Or am I mixing up?

Maybe it will be time to have a critical device around, that does not rely on Apple/google and has stuff like eID and other critical digital documents. But this is going to be annoying, carrying two devices. Maybe easier to keep the paper version as backup for such a case.

It might not even have to be a smartphone, but much lighter yubikey style (pk/sk signature) devices.

I hate to say it but the form factor of those crypto hardware wallets might be a good compromise between smartphone and very low level tech. Non-tech folks should be able to use them too, a struggle that the crypto space is constantly working with

You are assuming it will not be possible to add support to other OS. Why?

What would be “knowing it can work on grapheneOS” for example, in your view?

It will be possible but simply won't be done.

And as of now it won't work on GrapheneOS, it doesn't pass anything except MEETS_BASIC_INTEGRITY

That’s not what the parent wrote though.

And why is it so bad that they start with a smaller subset of feature and target the 99% of the population using either google or apple?

This is a misleading way to put it.

Re: Android.

Goggle can supports AOSP attestation like any other vendor who wants to support it. They invented it.

So instead of immediately locking down everyone using android to ONLY Google-dependent method, I'd developers could go the vendor agnostic way, but consciously decided not to.

It's untrue to claim that supporting AOSP attestation only serves GrapheneOS and leaves out everyone using Google-surveiled handset.

Nb, mixing it up with Apple is a conscious way to further the false claim, and I believe it's not accidental since these ecosystems are naturally completely separate.

You are misleading in fact, you use terms such as:

“it won’t work on GrapheneOS” “locking down everyone using android to ONLY Google-dependent method”

which make it sound like it’s a permanent and definitive limitation.

It is not, they can add support later, as they stated already.

> It's untrue to claim that supporting AOSP attestation only serves GrapheneOS and leaves out everyone using Google-surveiled handset.

hmmm, what do you have in mind? Publish it to F-Droid but not to the google app store?

Privacy and security are not binary. Statements like “because it isn’t 100% secure or private, then it is not worth it” means one has essentially no clue. There is not such thing as 100% privacy or security, for starters.

It’s all layers of protection and/or trust and compromises.

Very nice, can’t wait to test it.

FYI, the homwbrew checksum is broken: “Cask reports different checksum”.

Secondly, I would find it amazing if it could be notarized – I do understand however there is a cost associated with getting an apple dev account – and time/effort.

Didn’t know about it, nice, thanks.

btw, this is crazy: “Divvy supports […] Microsoft Windows XP+”