• 0 Posts
  • 27 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle
  • When most sites refer to passkeys, they’re typically talking about the software-backed kind that are stored in password managers or browsers. There are still device-bound passkeys though. Also since they’re just FIDO/WebAuthn credentials under the hood, you can still use hardware-backed systems to store them if you really want.

    While you’re right that device bound and non-exportable would be best from a security standpoint, there needs to be sufficient adoption of the tech by sites for it to be usable at all and sufficient adoption requires users to have options that have less friction/cost associated with them, like browser and password-manager based ones.

    Looking at it through the lens of replacing passwords instead of building the absolutely highest-security system helps explain why they’re not limited to device-bound anymore.


  • Sadly I’ve run into the same type of problem with a newer TLD as well. My solution was to get a domain in the older TLD space (e.g. .com, .net, .org). I doubt this will be the last site you run into that doesn’t support a newer TLD and the low likelihood that you’re going to be able to convince someone to fix the issue at every one of those outdated sites means that you’ll eventually need a backup domain for something.




  • I’d imagine that making it a user choice gets around some of the regulatory hurdles in some way. I can see them making a popup in the future to not use third-party cookies anymore (or partition per site them like Firefox does) but then they can say that it’s not Google making these changes, it’s the user making that choice. If you’re right that there’s few that would answer yes, then it gets them the same effective result for most users without being seen to force a change on their competitors in the ad industry.

    What’s the UK CMA going to do, argue that users shouldn’t be given choices about how they are tracked or how their own browser operates?














  • They haven’t released the text publicly but they’re voting on it in less than a week. That’s also one of the many objections that Mozilla et al has to this whole thing: it’s basically being done in secret in a way that won’t give the public any time to react or object.

    Historically, the browser vendors have only distrusted certificate authorities when they had reason to not trust them, not some arbitrary reason.

    One of the examples of them preventing a CA from being trusted is Kazakhstan’s, which was specifically set up to enable them to intercept users’ traffic: https://blog.mozilla.org/netpolicy/2020/12/18/kazakhstan-root-2020/

    Even if all of the EU states turn out to be completely trustworthy, forcing browser vendors to trust the EU CAs would give more political cover for other states to force browser vendors to trust their CAs. Ones that definitely should not be trusted.

    I think there wouldn’t be nearly the same level of objection if it was limited to each country’s CC TLD, rather than any domain on the internet.


  • How is giving any EU state the ability to be a certificate authority in your browser for issing a certificate for any site, without them needing to follow the rules the browser vendors have for what makes an authority trustworthy, with no option to disable them or add additional checks to their validity, “protecting their citizens from (American) corporate abuse”?

    From the Mozilla post:

    Any EU member state has the ability to designate cryptographic keys for distribution in web browsers and browsers are forbidden from revoking trust in these keys without government permission.

    […]

    There is no independent check or balance on the decisions made by member states with respect to the keys they authorize and the use they put them to.

    […]

    The text goes on to ban browsers from applying security checks to these EU keys and certificates except those pre-approved by the EU’s IT standards body - ETSI.