I'm checking out @Waterfox on Linux and Android and so far it's working well.
Uncategorized
5
Posts
2
Posters
0
Views
-
I'm checking out @Waterfox on Linux and Android and so far it's working well.
I don't know whether it's related but I noticed something unusual. Just after signing into my Mozilla ID in Waterfox on Linux, a container disappeared from the Firefox Multi-Account Containers add-on *in Firefox*. Can both browsers run independently on the same system?
-
I'm checking out @Waterfox on Linux and Android and so far it's working well.
I don't know whether it's related but I noticed something unusual. Just after signing into my Mozilla ID in Waterfox on Linux, a container disappeared from the Firefox Multi-Account Containers add-on *in Firefox*. Can both browsers run independently on the same system?
-
@UkiahSmith Yes, they both sync to Mozilla and I'm using the same ID.
-
@UkiahSmith Yes, they both sync to Mozilla and I'm using the same ID.
-
@UkiahSmith This is how Mozilla sync works in Waterfox:
https://www.waterfox.com/support/access-mozilla-services-waterfox-account
Gli ultimi otto messaggi ricevuti dalla Federazione
-
If you need to ask a question on the FreeBSD-questions mailing list then
https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/\
freebsd-questions/index.htmlcontains lots of useful advice to help you get the best results.
-
No Hack & Craft today! @mlemweb and I are on the road! Cya next time!
-
@soatok @benpate @bonfire Soatok's work provides another mechanism. It is an out-of-band server that e2ee clients submit their keys to. Actor B's client can compare the keys that it gets from Actor A's server with the keys it gets from the Key Transparency server to make sure they are all listed. If it finds keys that aren't listed, it can warn the user, or just drop the key.
-
@soatok @benpate @bonfire one way to mitigate this kind of attack is key verification. This is simply having Actor A and Actor B set up communications out of band, like on a phone call, and list out the key packages they see for each other. It's crude, and nobody ever wants to do it, but theoretically the possibility that this could happen keeps attackers from using this technique.
-
@MajDen
Marco te la può fare come vuoi.
A me l'ha fatta "su misura"
Scrivigli
-
There are other entities in the ecosystem that could also add keys. For example, if Actor B uses their server's proxyUri to fetch Actor A's key package collection, B's server could also add in a separate key package.
-
This structure has the downside that intervening entities can insert their own key packages into the collection -- so that remote clients encrypt to all the actor's keys, as well as to the interloper's keys.
For example, if Actor A's server adds its own key to the collection, any messages sent to Actor A will also be encrypted to the server. Exactly what we are trying to avoid!
-
The spec that we have makes the client key packages available as a property of the ActivityPub actor. This is very convenient in the AP ecosystem, since they can be managed (created, added, removed, deleted) with the ActivityPub API. MLS grinds through key packages pretty frequently, so it's good to have this easy to do.
