Thread by @GrapheneOS

We no longer have any active servers in France and are continuing the process of leaving OVH. We'll be rotating our TLS keys and Let's Encrypt account keys pinned via accounturi. DNSSEC keys may also be rotated. Our backups are encrypted and can remain on OVH for now.

Our App Store verifies the app store metadata with a cryptographic signature and downgrade protection along with verification of the packages. Android's package manager also has another layer of signature verification and downgrade protection.

Our System Updater verifies updates with a cryptographic signature and downgrade protection along with another layer of both in update_engine and a third layer of both via verified boot. Signing channel release channel names is planned too.

Our update mirrors are currently hosted on sponsored servers from ReliableSite (Los Angeles, Miami) and Tempest (London). London is a temporary location due to an emergency move from a provider which left the dedicated server business and will move. More sponsored update mirrors are coming.

Our ns1 anycast network is on Vultr and our ns2 anycast network is on BuyVM since both support BGP for announcing our own IP space. We're moving our main website/network servers used for default OS connections to a mix of Vultr+BuyVM locations.

We have 5 servers in Canada with OVH with more than static content and basic network services: email, Matrix, discussion forum, Mastodon and attestation. Our plan is to move these to Netcup root servers or a similar provider short term and then colocated servers in Toronto long term.

France isn't a safe country for open source privacy projects. They expect backdoors in encryption and for device access too. Secure devices and services are not going to be allowed. We don't feel safe using OVH for even a static website with servers in Canada/US via their Canada/US subsidiaries.

We were likely going to be able to release experimental Pixel 10 support very soon and it's getting disrupted. The attacks on our team with ongoing libel and harassment have escalated, raids on our chat rooms have escalated and more. It's rough right now and support is appreciated.

It's not possible for GrapheneOS to produce an update for French law enforcement to bypass brute force protection since it's implemented via the secure element (SE). SE also only accepts correctly signed firmware with a greater version AFTER the Owner user unlocks successfully.

We would have zero legal obligation to do it but it's not even possible. We have a list our official hardware requirements including secure element throttling for disk encryption key derivation (Weaver) combined with insider attack resistance. Why aren't they blaming Google?

In Canada and the US, refusing to provide a PIN/password is protected as part of the right to avoid incriminating yourself. In France, they've criminalized this part of the right to remain silent. Since they're criminalized not providing a PIN, why do they need anything from us?

@__tommyFR__ The initial articles consisted almost entirely of directly quoting law enforcement leadership in France including an interview with them. There was also paraphrasing of them which you could claim is inaccurate but there are plenty of direct quotes including a very direct threat.

@__tommyFR__ That was only the beginning. They've sent out a memo to police across France telling them to treat Pixel phones as highly suspicious and with more misinformation about GrapheneOS. They've made false and also unsubstantiated (almost certainly false) claims about GrapheneOS.

@OF24com @infogulch We plan to colocate the more sensitive stuff including our mail server in particular but we can move it to an non-OVH provider as a temporary bridge to that, potentially Netcup. Whole thing is a huge pain to do urgently. We were planning to move stuff long term but not quickly.

@dietzi96 One of their legacy data centers we didn't use for any production services burning down doesn't mean much. Amazon had serious fires at their DCs too and that's the premium option. In practice, AWS has also had plenty of downtime. OVH has been extremely reliable for us overall.

@PlugNTweet @artiomxxxiom @__tommyFR__ France has seized servers from companies selling secure devices. In a lot of the news coverage, they're quoted as very inaccurately comparing us to 2 of those companies (Encrochat and SkyECC). Why would we just let them hijack our website and other stuff which was still on OVH?

@PlugNTweet @artiomxxxiom @__tommyFR__ If people use either Private DNS or a VPN then they're benefiting from DNSSEC by trusting their provider to enforce it. That's not as good as enforcing is locally but it is getting enforced by a party they chose to trust to see their traffic. It's important beyond this though.

@PlugNTweet @artiomxxxiom @__tommyFR__ DNSSEC is enforced by most certificate authorities. We set Let's Encrypt as the only CA allowed to issue certificates via CAA and pin our per-server / per-server-cluster Let's Encrypt account keys via accounturi in CAA. This uses DNSSEC to properly secure certificate issuance.

@PlugNTweet @artiomxxxiom @__tommyFR__ We use TLS key pinning with the present and future Let's Encrypt roots along with backup leaf keys for our apps. It's not super useful for App Store and System Updater due to signing but it's still helpful. It's also used by our Auditor, Info and Network Location apps too.

@PlugNTweet @artiomxxxiom @__tommyFR__ TLS is what secures most of the connections. We pin the Let's Encrypt roots + our backup leaf keys for most of what's relevant. Securing the validation done by Let's Encrypt via CAA accounturi matters for securing TLS for all our users whether or not they have DNSSEC.

@PlugNTweet @artiomxxxiom @__tommyFR__ What you're suggesting does not provide them the ability to intercept connections which all use authenticated encryption via TLS. We use HSTS for everything too so users can't bypass the error in a browser. What would sending those IPs accomplish if it can't pass authentication?

@PlugNTweet @artiomxxxiom @__tommyFR__ What's the benefit to them of providing IPs which aren't going to be able to provide a valid certificate instead of simply blocking it with a server error? It's pretty much the same end result with a different error message. Blocking with a DNS resolution error is stealthier.

@PlugNTweet @artiomxxxiom @__tommyFR__ For our apps and several other things, we have the Let's Encrypt roots pinned so using another certificate authority is not going to work those. Certificate authorities are required to enforce CAA and supposed to enforce DNSSEC. Certificate Transparency is enforced by browsers.

@PlugNTweet @artiomxxxiom @__tommyFR__ We monitor certificate transparency logs for our domains for non-LE certificates. We can also audit to make sure all LE certificates were issued by audit but since we have accounturi pinning that implies compromising Let's Encrypt quite deeply, which is not really very likely.

@svr123456789 @dlandre The same goes for the US. They aren't trying to make what we do illegal and aren't trying to harm us or force us to include a backdoor. A list of countries which used to have the closest intelligence sharing with the US has little to do with us. France is a much bigger issue.

@narkshula See here:

grapheneos.org/install/web
grapheneos.org/faq#recommende…

@ciaomiabelladia The vast majority of people who use the GrapheneOS code are good people and aren't using it to harm anyone. People use it protect themselves from rampant privacy invasion by corporations and states. GrapheneOS isn't a weapon but rather a defensive tool like ballistic glass.

@ciaomiabelladia Someone could use a car with ballistic glass to commit crimes. Do you think that's the responsibility of the car company and ballistic glass company? How are they supposed to control how people use their own car and why is it their responsibility to do so because of a protection?