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.
Composable moderation/custom labeling and custom algorithmic feeds are two things that Mastodon doesn’t have that Bluesky does.
I’m a little surprised we haven’t heard about one of these smart TV brands using something like Amazon Sidewalk yet to communicate the analyzed data:
https://www.amazon.com/Amazon-Sidewalk/
A popular brand could totally set up their own network like this and with apartments there would probably be sufficient density to ensure that there’s always at least one connected device nearby to act as a bridge.
I agree that the no algorithm hill gets annoying once you’re following enough people.
What I don’t understand is why they don’t setup something like Bluesky has where you can choose which algorithm you want, including those not made directly by the Bluesky team: https://www.theverge.com/2023/5/26/23739174/bluesky-custom-feeds-algorithms-twitter-alternative
One of those algorithms could just be a chronological feed that some people seem dead set on sticking with. Everyone can be happy.
A lot of sites are willing to have something that’s good enough, rather than perfect, so if they find that using a list like this solves the majority of their abuse/deliverability issues, it’s unfortunately pretty logical they’d use it for that.
I feel like having different attributes for each domain might be helpful so that those services using the list can filter for just the things they care about such as burner emails, anonymous registration, whether it requires any email/phone verification, etc. Right now domains kind of have the problem of just being on the list or not, with no indication on why they might be a problem.
And that’s a bad thing?
The desktop is finally catching up with the more restrictive permissions model where an app doesn’t just have the ability to do anything the user can do but instead only has access to what it needs.
Going with a familiar interface style like the ones people already use on mobile just makes sense.
What would you want it to look like instead?
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.
Vizio makes twice as much profit from those ads and tracking services than the actual TVs:
https://www.theverge.com/2021/11/10/22773073/vizio-acr-advertising-inscape-data-privacy-q3-2021
I can see warning fatigue being a problem and trying to avoid the use of the interstitial pages because of that. That don’t want to display the big warning when they’re not confident as then people might ignore those in other contexts (cert errors, phishing/dangerous sites, etc).
How it works: Chrome only displays the lookalike phishing protection screens for sites with similar domains to the ones you visit, which can be detected by a server when the site doesn’t load (the warning first appears instead).
Summary from the conclusion:
Lookalike Warnings are arguably a great safety feature that protects users from common threats on the web. It’s hard to balance effectiveness and good user experience, making Site Engagement a vital source of information. However, since disabling Site Engagement or Lookalike Warnings is impossible, we believe it’s important to discuss these features’ privacy implications. For some people, the risk of exposing their browsing history to a targeted attack might be far worse than being tricked by lookalike phishing websites. Especially given that site engagement is also copied into incognito sessions.
Looks like it just concatenates them:
The shared secret is calculated as the concatenation of the X25519 shared secret (32 bytes) and the Kyber768Draft00 shared secret (32 bytes). The resulting shared secret value is 64 bytes in length.
https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html>
Yeah, I feel like it’s going to take both browser vendors shaming sites once a standard is developed/finalized and something like a quantum version of whynohttps.com to drive adoption.
The problem really is the store and decrypt nature of it. It could be used against old data so the time when it needs to be implemented is before it becomes possible to decrypt. I feel like people aren’t good about planning like that and tend to be more reacting to what is currently possible.
Considering this proposal is used for the key exchange, they definitely need to update both the client side and server side part to be able to make use of it. That’s the kind of thing that may take years but luckily it can fall back to older methods.
It also needs to be thoroughly vetted so that’s why it’s a hybrid approach. If the quantum resistant algorithm turns out to have problems (like some others have), they’re still protected by the traditional part like they would have been, with no leaking of all the data.
Currently being investigated by browser makers but not something they can just do on their own like Signal.
Here’s Chromium’s current proposal that they’re testing:
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
Here’s Microsoft’s information page on it:
https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby
Even votes aren’t private and an instance could be setup to collect that data and make it viewable.
The ability to easily link to a specific post or comment in a way that works across instances/clients, like you can with communities.
I think the Firefox settings now call it the address bar when selecting if you want it to do both functions or have separate boxes. It may still be that internally.
Also I just looked it up and apparently I was wrong anyways and the Chrome internal docs call it the omnibox actually…
And the chromium developers blog calls it the address bar…
And so does The Keyword (blog.google)…
I think they’ve both given up on getting the public to use their special names now that it’s just an expected feature of a browser.
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.