Windows, dlhodobý kráľ desktopových operačných systémov dlhodobo upadá.


cross-posted from: piefed.blahaj.zone/c/technolog…

Windows Marketshare since 2010

for your enjoyment

source gs.statcounter.com/os-market-s…

Mladí Európania požadujú silnejšiu Európu


cross-posted from: sopuli.xyz/post/38159981

Forget the far right. The kids want a ‘United States of Europe.’

GrapheneOS version 2025121200 released


Tags:

  • 2025121200 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL, Pixel 10 Pro Fold, emulator, generic, other targets)

Changes since the 2025121000 release:

  • disable notification summaries and organizer features due to AOSP and GrapheneOS lacking the AI models used to implement these features
  • add workaround for notification background appearance regression in Android 16 QPR2
  • Vanadium: update to version 143.0.7499.109.0
  • GmsCompatConfig: update to version 167

All of the Android 16 security patches from the current January 2026, February 2026, March 2026, April 2026, May 2026 and June 2026 Android Security Bulletins are included in the 2025121201 security preview release. List of additional fixed CVEs:

  • High: CVE-2025-32348, CVE-2025-48641, CVE-2026-0014, CVE-2026-0015, CVE-2026-0016, CVE-2026-0017, CVE-2026-0018

2025121201 provides at least the full 2026-01-01 Android and Pixel security patch level but will remain marked as providing 2025-12-05.

For detailed information on security preview releases, see our post about it.

Second New IPv4 /24 Subnet Received


We've received a 2nd IPv4 /24 subnet from ARIN for our 2nd anycast DNS network. Both our /24 subnets were obtained quickly under the NRPM 4.10 policy for IPv6 deployment for our dual stack DNS use case. 2nd was obtained without waiting 6 months due to being a discrete network.

We host our own authoritative DNS servers to provide DNS resolution for our services. Authoritative DNS are the servers queried by DNS resolvers run by your ISP, VPN or an explicitly user chosen one such as Cloudflare or Quad9 DNS. We now have our own AS and IP space for this.

Our ns1 has 11 locations on Vultr: New York City, Miami, Los Angeles, Seattle, London, Frankfurt, Singapore, Mumbai, Tokyo, Sao Paulo and Sydney.

Our ns2 has 4 locations on BuyVM: New York City, Miami, Las Vegas and Bern. We'll be adding a 2nd server provider for more locations.

DNS resolvers quickly fall back to the other network if traffic is dropped. Having two discrete networks with separate hosting companies and transit providers provides very high reliability. Individual servers which go down also stop having traffic routed to them due to BGP.

We have tiny website/network servers and also powerful update mirrors around the world. Our DNS servers use a combination of a GeoIP database and their own location to route users to the closest server that's up. Frequent health checks and low expiry time handle server downtime.

GmsCompatConfig version 167 released


Changes in version 167:

  • add stub for BluetoothA2dp.setConnectionPolicy() to fix a crash with a new version of Android Auto

A full list of changes from the previous release (version 166) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Vanadium version 143.0.7499.109.0 released


Changes in version 143.0.7499.109.0:

  • update to Chromium 143.0.7499.109

A full list of changes from the previous release (version 143.0.7499.52.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

GrapheneOS Foundation Responds To Jolla


Jolla has spent years disparaging projects based on the Android Open Source Project (AOSP) for marketing. SailfishOS has a largely closed source user interface and application layer with no equivalent to the open source AOSP. It's far less private and secure than AOSP or iOS too.

Jolla recently launched a new product so their supporters are understandably trying to promote it. As part of that, they've been posting about it in replies to posts about GrapheneOS. We've replied to some of it with our perspective within threads originally about GrapheneOS.

Since we dared to post accurate information in threads about GrapheneOS where they mentioned us in replies to promote it, their forum is being used as a place to attack GrapheneOS including libelous attacks towards our team referencing harassment content:

forum.sailfishos.org/t/sailfis…

Several of their supporters are taking the usual approach of calling us crazy and delusional while referencing harassment content at the same time as calling the factual info we posted aggressive. They're brigading discussions about GrapheneOS with attacks so we made this thread.

Brigading threads about an open source project and attacking the team with libelous claims is toxic. Defending ourselves from it with factual statements is not toxic. Repeating dishonest attacks on our team based on similar attacks over and over doesn't make it any less untrue.

in reply to KindnessInfinity

At this point, it feels like Graphene is making this out of whole cloth in order to gin up donations.

I see no evidence of specific attacks presented here, and I'm not going out to "X" and every other shit platform looking for contrarians besides. There's always noise being made on the internet in contrast to anything. I challenge anyone to point to the specific consternation any other open source product is making intentionally at a high level to try to take down graphene.

This project seems to be ran by an individual with a martyr complex and simply needs better management. I do run GOS myself, but can't wait to move to a full *nix device, particularly after this repeated whinging. Why would anyone trust someone so capricious?

Edit: wanted to add that the thread linked is largely the Sailfish community complaining about the graphene community, specifically Micay. I see no evidence of brigading or the like, plenty of unbacked assertions, however.

This entry was edited (1 day ago)

GrapheneOS version 2025121000 released


This is our first non-experimental release based on Android 16 QPR2 after our initial experimental 2025120800 release.

The change to the style of notification backgrounds is an upstream regression rather than an intentional change to a more minimal style. It will be fixed in a subsequent release since we decided it isn't important enough to delay this.

Tags:

  • 2025121000 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL, Pixel 10 Pro Fold, emulator, generic, other targets)

Changes since the 2025120400 release:

  • full 2025-12-05 security patch level
  • rebased onto BP4A.251205.006 Android Open Source Project release (Android 16 QPR2)
  • disable promotion of identity check feature not currently present in GrapheneOS due to depending on privileged Google Mobile Services integration
  • GmsCompatConfig: update to version 166

All of the Android 16 security patches from the current January 2026, February 2026, March 2026, April 2026, May 2026 and June 2026 Android Security Bulletins are included in the 2025121001 security preview release. List of additional fixed CVEs:

  • High: CVE-2025-32348, CVE-2025-48641, CVE-2026-0014, CVE-2026-0015, CVE-2026-0016, CVE-2026-0017, CVE-2026-0018

2025121001 provides at least the full 2026-01-01 Android and Pixel security patch level but will remain marked as providing 2025-12-05.

For detailed information on security preview releases, see our post about it.

1 zo 4 lekárov v USA považuje kryonické uchovanie za trochu alebo veľmi pravdepodobné pre budúce oživenie


Nová štúdia ukazuje, že podstatná časť lekárov v USA verí kryonike, cíti sa komfortne ak si ju ich pacient vyberie a dokonca podporuje legálnosť procedúr, ktoré ju vylepšia.

Celá štúdia, ešte pred revíziou od kolegov a pred tlačou, je dostupná zadarmo 👇
medrxiv.org/content/10.64898/2…

Aký je váš názor na kryoniku? Ak by peniaze neboli problém, dali by ste sa vitrifikovať ("zmraziť") pre oživenie v budúcnosti?

This entry was edited (2 days ago)

Ďalšie Lemmy komunity v slovenčine?


Zdar. Poznáte na Lemmy aj ďalšie komunity v slovenčine? Ja som zatiaľ našiel len všeobecné /c/Slovakia, pričom len táto jediná má nejaký nový zmysluplný obsah. Viem, že je nás tu málo, ale možno máme aj nejakú tematickú komunitu v slovenčine (alebo aspoň budeme mať ;).
in reply to kubofhromoslav

Čau, nuž zo začiatku boli viac menej 2 relatívne aktívne:
* !slovakia@sopuli.xyz
* !slovakia@lemmy.world

Okrem toho sú aj tieto viac menej mŕtve komunity:
* !Slovakia@kbin.social
* !slovakia@lemmy.ml

Tématická komunita je fajn nápad, je to trocha odvážne keďže máme problém ako tak udržať nad vodou tieto naše generické komunity (je nás tu fakt málo) ale veď prečo nie, kým neskúsime nezistíme :)

Ako ja dlho snívam o nejakej čisto slovenskej inštancii - napr. lemmy.sk (čo už niekto kúpil) alebo piefed.sk ktorá by sa sústredila čisto na Slovensko. To by bolo krásne, no len čo som čítal tak že je to relatívne drahé a náročné prevádzkovať takú inštanciu. No a trebalo by ľudí samozrejme. Ale snívať môžem :)

in reply to kubofhromoslav

Uff presné číslo neviem ale za posledné roky už pár inštancií skončilo s tým že proste sa im to neoplatí, tak z toho usudzujem. Hlavne si spomínam na 2 prípady
* ~~lemmy.zip~~ lemm.ee - to bola všeobecná inštancia a relatívne veľká. Oni skončili myslím že pre to že tá správa toho vyžadovala dosť času a už sa tomu nechceli venovať
* diagonlemmy.social - to bola Harry Potter inštancia a pokiaľ viem tak oni skončili pre peniaze, že je to proste príliš špecifická inštancia a nestojí to za to spravovať pre tých pár komunít celú inštanciu. Ale toto ma mrzelo lebo ich som videl ako príklad toho ako by to malo fungovať.

Ale pre porovnanie - veľké inštancie ako lemmy.world uvádzajú že majú výdavky asi 9000 € ročne (keď pozerám na ich výdavky z 2023 a 2024)

opencollective.com/mastodonwor…

Ale zas treba zohľadniť to že to je najväčšia lemmy inštancia na svete a spravujú mimo nej aj Mastodon inštanciu, Piefed inštanciu a bohvie čo ešte. No a že sú v cloude, tam aj malá inštancia vyjde tipujem aspoň na 100 € mesačne. Keď to človek rozbehá na nejakom PC doma pod stolom tak to nebude stáť takmer nič (ehm no mimo elektriny, domény, PC súčastí, ...)

This entry was edited (3 days ago)

Experimental GrapheneOS Release Based On AOSP 16 QPR2 Now Available For Testing


An experimental release of GrapheneOS (2025120800) based on Android 16 QPR2 is available for testing via sideloading. It won't be pushed out via Alpha. You can join our testing chat room if you want to help with testing (grapheneos.org/contact#communi…). No security preview variant yet.

GrapheneOS Based On AOSP 16 QPR2 Releasing Soon


Android 16 QPR2 experimental releases will be available soon. We're dealing with a lot of attacks on the project branching off from the smear campaign in France. We'd appreciate if our community would debunk this nonsense across platforms for us so we can focus on QPR2. Thanks.

If you see the fake story about someone claiming to be charged with premeditated murder because GrapheneOS supposedly didn't protect their data, see nitter.net/GrapheneOS/status/1… for a thorough debunking. Their story keeps changing and clearly isn't real. They may be a career criminal but this is fake.

GmsCompatConfig version 166 released


Changes in version 166:

  • add initial stubs for Android 16 QPR2

A full list of changes from the previous release (version 165) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

in reply to EfreetSK

Nech odpočíva v pokoji, a sústrasť jej rodine a priateľom!

V článku nespomínajú príčinu úmrtia, ale očakávam, že je to následkom starnutia. Je to tým smutnejšie, že vedci už vyvíjajú lieky na ozajstné zvrátenie starnutia. Ak by vydržala ešte cca 15-20 rokov (pri jej veku a súčasnom stave medicíny by to bolo ťažké), mohla by žiť ozaj veľmi dlho. Koľko vecí by ešte mohla napísať 😥

GrapheneOS version 2025120400 released


Tags:

  • 2025120400 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL, Pixel 10 Pro Fold, emulator, generic, other targets)

Changes since the 2025111800 release:

  • full 2025-12-01 security patch level (has already been fully provided by our security preview releases for at least a month and most of the patches since September)
  • add experimental support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold (there were 2 standalone experimental releases prior to this via 2025112500 and 2025113000 along with corresponding security preview releases for each)
  • Cell Broadcast Receiver: switch back to our modified text for the presidential alerts toggle
  • kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.158
  • kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.116
  • kernel (6.12): update to latest GKI LTS branch revision including update to 6.12.60
  • Auditor: update to version 90
  • Vanadium: update to version 143.0.7499.34.0
  • Vanadium: update to version 143.0.7499.34.1
  • Vanadium: update to version 143.0.7499.34.2
  • GmsCompatConfig: update to version 164
  • GmsCompatConfig: update to version 165

All of the Android 16 security patches from the current January 2026, February 2026 and March 2026 Android Security Bulletins are included in the 2025120401 security preview release. List of additional fixed CVEs:

  • Critical: CVE-2025-48631, CVE-2026-0006
  • High: CVE-2022-25836, CVE-2022-25837, CVE-2023-40130, CVE-2025-22420, CVE-2025-22432, CVE-2025-26447, CVE-2025-32319, CVE-2025-32348, CVE-2025-48525, CVE-2025-48536, CVE-2025-48555, CVE-2025-48564, CVE-2025-48565, CVE-2025-48566, CVE-2025-48567, CVE-2025-48572, CVE-2025-48573, CVE-2025-48574, CVE-2025-48575, CVE-2025-48576, CVE-2025-48577, CVE-2025-48578, CVE-2025-48579, CVE-2025-48580, CVE-2025-48582, CVE-2025-48583, CVE-2025-48584, CVE-2025-48585, CVE-2025-48586, CVE-2025-48587, CVE-2025-48589, CVE-2025-48590, CVE-2025-48592, CVE-2025-48594, CVE-2025-48596, CVE-2025-48597, CVE-2025-48598, CVE-2025-48600, CVE-2025-48601, CVE-2025-48602, CVE-2025-48603, CVE-2025-48604, CVE-2025-48605, CVE-2025-48609, CVE-2025-48612, CVE-2025-48614, CVE-2025-48615, CVE-2025-48616, CVE-2025-48617, CVE-2025-48618, CVE-2025-48619, CVE-2025-48620, CVE-2025-48621, CVE-2025-48622, CVE-2025-48626, CVE-2025-48628, CVE-2025-48629, CVE-2025-48630, CVE-2025-48632, CVE-2025-48633, CVE-2025-48634, CVE-2026-0005, CVE-2026-0007, CVE-2026-0008

For detailed information on security preview releases, see our post about it.

Vanadium version 143.0.7499.52.0 released


Changes in version 143.0.7499.52.0:

  • update to Chromium 143.0.7499.52

A full list of changes from the previous release (version 143.0.7499.34.2) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Vanadium version 143.0.7499.34.2 released


Changes in version 143.0.7499.34.2:

  • avoid always open external links in Incognito mode causing bookmarks to always open in it
  • enable autofill configuration screens regardless of autofill settings
  • remove unused Google autofill status
  • enable Drumbrake WebAssembly interpreter for x86_64 builds used in the emulator too

A full list of changes from the previous release (version 143.0.7499.34.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

GrapheneOS Foundation Suggests Improvements For Early Security Patch Previews


Our security preview releases have provided the December 2025 security patches for the Android Open Source Project since September 2025. December 2025 security patches are now public and being integrated into our regular releases while our security previews have up to March 2026.

A bunch of the patches previously scheduled for December 2025 were made optional and deferred to future months so they're not listed in the public bulletin. That's why even our September 2025 security preview releases list CVEs which are still not public in December 2025.

The reason patches get deferred is because OEMs aren't capable of quickly integrating, testing and shipping patches. When issues are identified including an OEM having trouble with it, they'll often defer it to a future month. Our security previews can continue shipping these.

GrapheneOS is the only Android-based OS providing the full security preview patches. Samsung ships a small subset of their flagship devices. Pixel stock OS gets a portion of it early but we aren't sure exactly how much since they don't follow their guidelines for listing patches.

Providing our security preview patches is a lot of work for us. It requires a full time developer spending a significant fraction of their time on it. It's hard to understand why large companies can't keep up with these patches but what matters is that we can provide them early.

Android security preview patches are currently backports to Android 13, 14, 15 and 16. Since GrapheneOS is based on Android 16 QPR1, we need to forward port the patches from 16 to 16 QPR1. Our understanding is they're going to start backporting to some quarterly releases too.

Android 16 QPR2 appears to be the first quarterly release of Android which is going to be shipped by non-Pixel devices. If that's the case, they'll need to start providing security preview patches backported to it too. It's not clear if it will happen for every quarterly release.

Spending a significant amount of time on this is part of the reason GrapheneOS feature development has slowed down. Expanding our servers and now migrating away from OVH is another. We'll be hiring more people and improving our organization structure to get things moving better.

We would greatly prefer it if patches were disclosed to OEMs 1 week ahead instead of 2-4 months ahead so our security preview releases would only need to exist for a week and regular releases would get the patches much faster. OEMs should just hire far more people and do better.

Vanadium version 143.0.7499.34.1 released


Changes in version 143.0.7499.34.1:

  • fix regression for setting opening external links in Incognito mode
  • disable search engine compose plate feature to avoid a UI feature exclusive to Google search promoting AI mode

A full list of changes from the previous release (version 143.0.7499.34.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

GrapheneOS Experimental Releases For Pixel 10 Devices Now Available


We now have experimental support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold.

Our initial 2025112500 release for these is available through our web installer or releases page on our staging site:

staging.grapheneos.org/install…staging.grapheneos.org/release…

GrapheneOS Foundation Explains Why GrapheneOS Has Left France


A false narrative is being pushed about GrapheneOS claiming we're ending operations in France due to the actions of 2 newspapers. That's completely wrong. If both newspapers and the overall French media had taken our side instead of extreme bias against us, we'd still be leaving.

We're ending operations in France and ending our use of French companies (mainly OVH) to provide services because of direct quotes by law enforcement in dozens of French news publications. Their inaccurate claims about GrapheneOS and thinly veiled threats were our sign to leave.

French law enforcement hijacked the servers of companies selling secure phones multiple times and is comparing us with those companies. They've made it clear they expect access to phones and will go after us if we do not cooperate. Cooperating with that means adding a backdoor.

We were already moving away from OVH over time. We didn't have authoritative DNS or update mirrors on it anymore prior to this. We were only going to be using it for our website/network service instances which are tiny servers with only static content and reverse proxies.

We couldn't see any of the specific claims from French law enforcement until the news stories were published. French law enforcement are wrongly conflating GrapheneOS with products using portions of our code. Claims about our features, distribution and marketing are inaccurate.

French law enforcement brought up SkyECC and Encrochat, two companies they went after with arrests and server seizures. They made it very clear they'll go after us similarly if they're able to conjure a good enough justification and we don't cooperate by providing device access.

Thinly veiled threats from law enforcement are quoted in several of the news article including archive.is/UrlvK. We don't store user data and cannot bypass brute force protection for encryption. Cooperating to provide device access means one thing: encryption backdoors.

in reply to KindnessInfinity

They’ve made it clear [they expect access to phones and ...]


How did they make it clear? Can you provide the full quote or reference to the message?

Thinly veiled threats from law enforcement are quoted in several of the news article


Which ones exactly? Unfortunately I don't speak French, but here's what I get with a translator on the reference link:

With this new tool, for some users there is a genuine legitimacy in wanting to protect their communications. The approach is therefore different. But this will not stop us from prosecuting the developers if links are found between them and a criminal organization and they do not cooperate with justice.


Is it a thinly veiled threat, or it could be something else as well, such as simply news coverage and a warning? They clearly acknowledge that "some users ~have a genuine legitimacy in wanting to protect their communications".

I mean I get it if you want to leave France due to *fears*. If and only if you say you're afraid, not that you know for a fact about "thinly veiled threats", "they make it clear", "no open-source privacy project can exist in France" etc. Or if you do know some of it as a fact, then provide proofs, not "we have information that......".

This entry was edited (1 week ago)

Social and Organizational Talks at FOSDEM 2026


Hey, all. One thing that's different this year about the Social Web Devroom at FOSDEM 2026 is that we're going to include talks about the organizational and social aspects of rolling out Open Source Fediverse software for individuals and communities. Last

Hey, all. One thing that’s different this year about the Social Web Devroom at FOSDEM 2026 is that we’re going to include talks about the organizational and social aspects of rolling out Open Source Fediverse software for individuals and communities. Last year, we focused pretty heavily on technical talks from the principle developers of FLOSS packages. This year, we want to make sure the other aspects of Fediverse growth and improvement are covered, too.

Consequently, the guidance for last year’s event, which was focused on how to make a great technical presentation, might seem a little outdated. But on reviewing it, I’ve found that it still has good advice for social and organizational talks. Just like software developers, community builders see problems and construct solutions for them. The solutions aren’t just about writing code, though; more often they involve bringing people together, assembling off-the-shelf tools, and making processes and rules for interaction.

Talks about Open Source software to implement ActivityPub and build the social web are still welcome, of course. We’re just expanding a bit to cover the human aspects of the Fediverse as well.

I’m looking forward to having the interesting discussions about bringing people together to make the Social Web. If you haven’t already, please consider submitting a talk to pretalx.fosdem.org/fosdem-2026…. Select “Social Web” from the “Track” dropdown, and include the length of your talk (8/25/50) in the submission notes. The deadline is December 1, 2025, so get them in as soon as possible!

This entry was edited (2 weeks ago)

GrapheneOS team thank you for nominating us for Proton fundraiser


Thankyou from me, @akc3n and the whole team here at GrapheneOS we appreciate you all who contributed a nomination for our project for this year's Proton fundraiser. After writing to them to give us a festive treat. I hope you all get a peaceful, fulfilling, trouble free run up to the holidays. 🤝🫶

GrapheneOS team thank you for nominating us for Proton fundraiser


This entry was edited (2 weeks ago)

French Servers Discontinued, Further Infrastructure Changes To Come and More - GrapheneOS Foundation


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?

This entry was edited (2 weeks ago)
in reply to KindnessInfinity

Personally, I’d feel safer if the longer-term place were in Europe.

For example, in the Netherlands, which quickly and clearly was against ChatControl. (I'm partially repeating myself from the previous post here. I don't intend to copy-paste my opinion, it's just relevant to both news, while the topic is still fresh and actively being discussed.)


GrapheneOS Server Infrastructure Changes Involving New ASN, DNS and New Servers Away From France


We host our own authoritative DNS servers to provide DNS resolution for our services. Authoritative DNS are the servers queried by DNS resolvers run by your ISP, VPN or an explicitly user chosen one such as Cloudflare or Quad9 DNS. We now have our own AS and IP space for this.

You can see information about our AS and IP space here:

bgp.tools/as/40806

We received a free ASN, IPv6 /40 and IPv4 /24 from ARIN. We use one IPv6 /48 for our ns1 anycast DNS network and one for our anycast ns2 network. We're using the IPv4 /24 for ns2 and need another.

Our ns1 network currently has 10 locations: New York City, Miami, Los Angeles, Seattle, London, Frankfurt, Singapore, Mumbai, Tokyo and Sydney. We're considering moving London to Amsterdam. We plan to add a South American location and perhaps Warsaw. ns2 isn't as scaled out yet.

Our ns2 network currently has New York City, Miami, Las Vegas and Bern.

Here's latency to ns1:

ping6.ping.pe/ns1.grapheneos.o…
ping.pe/ns1.grapheneos.org

Here's latency to ns2:

ping6.ping.pe/ns2.grapheneos.o…
ping.pe/ns2.grapheneos.org

We plan to add more locations to ns2 via another provider.

When we begin a reboot of a server, the change propagates across all internet backbone routers within a few seconds. This provides high availability for server downtime too. We have 2 networks so routing/transit issues or a malfunctioning server don't break using our services.

For ns1, there's a mix of different upstream transit providers. We've done traffic engineering with BGP communities configuration to get traffic routed to the right places. We prioritize Arelion and NTT since nearly all locations have both and we can configure their routing well.

We make the routes announced by our servers deprioritized when propagated into other continents for Arelion, Cogent and NTT. We deprioritize transit ruining global routing (GTT, Lumen) and block some peering (RETN, Bharti). We deprioritize Cogent since only 3 locations have it.

Our authoritative DNS server setup is largely in a public Git repository:

github.com/GrapheneOS/ns1.grap…

Here's our BGP communities setup ns1 New York City as an example:

github.com/GrapheneOS/ns1.grap…

Here's ns1 Miami with different handling for South America:

github.com/GrapheneOS/ns1.grap…

We have two main groups of servers around the world:

1) website and OS network services

github.com/GrapheneOS/ns1.grap…
github.com/GrapheneOS/ns1.grap…

2) update mirrors, which are currently 3x sponsored dedicated servers with 10Gbps

github.com/GrapheneOS/ns1.grap…

We'll have more of both soon.

We're in the process of our website and OS network services away from OVH due to the threats from French law enforcement. We're going to add nodes in South America, India, Japan and Australia as part of this. We also have 5 non-static-content servers in Canada to move off OVH.

The servers with more than static content are our discussion forum and attestation service for our users along with our email, Matrix and Mastodon servers for our project. These will move to colocated servers in Toronto long term but short term we'll just switch providers for it.


in reply to eldavi

From my understanding, there is the "enforcement" branch of the justice system, and there is the "judiciary" / "legal" branch. Police belongs to "enforcement", and they tend to want more control, less privacy, tighter regulation... for obvious reasons. So they will of course want Chat Control to make their job easy, American Tech or not. Policing everything is also easier to "explain" to people than diversity, so right-wing populism naturally uses that as well (also as means to tighten control and move the country towards authoritarianism). So all of these things aren't exclusively American. They are just societal.

BTW, I also believe it's off-topic, as I'm merely saying that I'd prefer Europe-based servers for security, such as in the Netherlands. This country is not perfect, but it's pretty good with respecting privacy. And it's less prone to US influence.

This entry was edited (2 weeks ago)

Germany are no longer against chat control - (German article)


[TRANSLATED ARTICLE]

EU chat control comes – through the back door of voluntariness

The EU states have agreed on a common position on chat control. Data protection advocates warn against massive surveillance. What is in store for us?

After lengthy negotiations, the EU states have agreed on a common position on so-called chat control. Like from one Minutes of negotiations of the Council working group As can be seen, Internet services will in future be allowed to voluntarily search their users' communications for information about crimes, but will not be obliged to do so.

The Danish Council Presidency wants to get the draft law through the Council "as quickly as possible", "so that the trilogue negotiations can begin promptly", the minutes say. Feedback from states should be limited to "absolute red lines".

Consensus achieved

The majority of States supported the compromise proposal. At least 15 spoke in favor, including Germany and France. Germany "welcomed both the deletion of the mandatory measures and the permanent anchoring of voluntary measures", said the protocol.

However, other countries were disappointed. Spain in particular "continued to see mandatory measures as necessary, unfortunately a comprehensive agreement on this was not possible". Hungary also "seen voluntariness as the sole concept as too little".

Spain, Hungary and Bulgaria proposed "an obligation for providers to detect, at least in open areas". The Danish Presidency "described the proposal as ambitious, but did not take it up to avoid further discussion.

The organization Netzpolitik.org, which has been reporting critically on chat control for years, sees the plans as a fundamental threat to democracy. "From the beginning, a lobby network intertwined with the security apparatus pushed chat control", writes the organization. “It was never really about the children, otherwise it would get to the root of abuse and violence instead of monitoring people without any initial suspicion.”

Netzpolitik.org argues that "encrypted communication is a thorn in the side of the security apparatus". Authorities have been trying to combat private and encrypted communication in various ways for years.

A number of scholars criticize the compromise proposal, calling voluntary chat control inappropriate. "Their benefits have not been proven, while the potential for harm and abuse is enormous", one said open letter.

According to critics, the planned technology, so-called client-side scanning, would create a backdoor on all users' devices. Netzpolitik.org warns that this represents a "frontal attack on end-to-end encryption, which is vital in the digital world".

The problem with such backdoors is that "not only the supposedly 'good guys' can use them, but also resourceful criminals or unwell-disposed other states", argues the organization.

Signal considers withdrawing from the EU

Journalists' associations are also alarmed by the plans. The DJV rejects chat control as a form of mass surveillance without cause and sees source protection threatened, for which encrypted communication is essential. The infrastructure created in this way can be used for political control "in just a few simple steps", said the DJV in a statement Opinion.

The Messenger service Signal Already announced that it would withdraw from the EU if necessary. Signal President Meredith Whittaker told the dpa: “Unfortunately, if we were given the choice of either undermining the integrity of our encryption or leaving Europe, we would make the decision to leave the market.”

Next steps in the legislative process

The Permanent Representatives of the EU states are due to meet next week on the subject, followed in December by the Ministers of Justice and Home Affairs, these two bodies are due to approve the bill as the Council's official position.

The trilogue then begins, in which the Commission, Parliament and Council must reach a compromise from their three draft laws. Parliament had described the original plans as mass surveillance and called for only unencrypted suspect content to be scanned.

The EU Commission had originally proposed requiring Internet services to search their users' content for information about crimes without cause and to send it to authorities if suspected.

This entry was edited (3 weeks ago)
in reply to einkorn

It's been very interesting since I've moved to Germany.

I'm white, and not once during train checks have I ever been spoken too or asked for my info.

However, ever single person that's slightly tanned is asked for their identification. Also the German officers often speak English to these people they suspect of being here illegally. I can't tell you how many times I've seen the person they're questioning respond in Germany and pull out a German passport or one from an EU nation. But if I had to guess I'd say 9/10 times that's the case. In the remaining 1/10 times the questioned almost always pull out a visa or a valid passport.

It's a huge waste of time and I've only seen 1 person ever taken off the train.

Frankly border checks like this are pointless. They select very few people to ask for their documents. Frankly if I was in a position to be entering the country illegally from one of the bordering nations I'd just walk across and take a bus to the next town over before taking a train. It's not like there are border guards at most crossings, they only ever check the trains, and don't check outside of border crossing. All of this to say it's security theater that isn't accomplishing much, is a waste of resources, and is usually racist in application.

Auditor app version 90 released


Notable changes in version 90:

  • add support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold with either the stock OS or near future GrapheneOS releases
  • add back check for Auditee support for remote verification
  • update Android target API level to 36 (Android 16)
  • switch transition for QR scanning activity to handle target API level 36 predictive back more smoothly
  • properly distinguish unknown vs. invalid values for extended GrapheneOS security information covering auto-reboot, etc.
  • fix displaying lowest possible auto-reboot timer supported at a low-level in the OS
  • remove unused support for new pairings without StrongBox (secure element keystore as opposed to a less secure Trusted Execution Environment keystore)
  • add support for new key attestation root certificate launching in February 2026
  • add new protocol version 7 with a new DEFLATE dictionary adding the new attestation root and dropping the non-StrongBox sample
  • raise minimum app version for Auditee to 87 which was released over a year ago
  • add new far future Let's Encrypt roots to TLS key pinning configuration
  • drop obsolete workaround for old Android versions on 6th gen Pixels not declaring attest key support
  • drop unsupported legacy devices without Android 13 or later from supported device list
  • enable hardware memory tagging for use outside of GrapheneOS in the narrow cases where it's available for apps opting into it (Android 16 Advanced Protection Mode on hardware with support for MTE)
  • update ZXing barcode scanning library to 3.5.4
  • update CameraX (AndroidX Camera) library to 1.5.1
  • update Bouncy Castle library to 1.82
  • update Guava library to 33.5.0
  • update Material Components library to 1.13.0
  • update AndroidX Core library to 1.17.0
  • update AndroidX AppCompat library to 1.7.1
  • update Gradle to 9.2.1
  • update NDK to 29.0.14206865
  • update Android Gradle plugin to 8.13.1
  • update Kotlin to 2.2.21
  • update Android build tools to 36.1.0

A full list of changes from the previous release (version 89) is available through the Git commit log between the releases.

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.