pixelschubsi

https://troet.cafe/@pixelschubsi

Public Key

npub1tekutp4hugeck74ujhu9gt3nqps7pj45l0ddensmadlsna7w0d4sv7rm0u

NIP-05 Address

pixelschubsi_at_troet.cafe@momostr.pink

Profile Code

nprofile1qqs9umw9s6m7yvut027ft7z59cesqc0qe260hkkuecd7klcf7l88k6cprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntr6ayy3

Publishing to

relay.momostr.pink

Author Public Key

npub1tekutp4hugeck74ujhu9gt3nqps7pj45l0ddensmadlsna7w0d4sv7rm0u

Show more details

Last Notes

2026-03-26 23:45:44 UTC

- reply

As an app developer that needs to take care of this, I don't want to open the https://grapheneos.org/articles/attestation-compatibility-guide page and copy out the fingerprints for those various devices out and update my local copy of them whenever a new device is supported by GrapheneOS. I just want to have a way to say "I trust whatever GrapheneOS guys consider safe". In understand Unified Attestation could be that way (if GrapheneOS was to provide a backend for it).

2026-03-26 23:31:44 UTC

- reply

Notably, if you worry about old and insecure devices (like those still accepted by Play Integrity) as an app developer your just need to make sure to use a backend that would not sign them off. Which may well be one that's not the hardware manufacturer. I see Unified Attestation more as a decentralized/federated version of Play Integrity that gives app developers control to decide which devices, operating system creators or third-party attestors they trust.

2026-03-26 23:24:52 UTC

- reply

Are you talking about https://uattest.net/? I had a glimpse at it, and they talk about multiple backends and federation of backends. As I understood it, everyone can create a backend and create tokens for devices/OS that they like, it's then subject for the app developers to accept those tokens, either directly or indirectly through federation. Which means it does allow for competitor OS to also be accepted for as long as the app developer or their selected backends support it.

2025-12-23 11:03:54 UTC

- reply

I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.
I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?

2025-11-25 20:55:04 UTC

- reply

And no, for this specific articles in Le Parisien, the journalist already confirmed they reached out to PJ after they were hinted at the existence of the internal notice. It was not PJ reaching out to them or asking them to write favorably about them. And I bet this is how it worked for other news outlets. You have not provided any proof that PJ reached out to specific news outlets asking them to write about this.

2025-11-25 20:54:07 UTC

- reply

I never claimed it was a single article, I claimed it's a single story. The story is about PJ instructing local authorities on how to handle GrapheneOS phones. And everything beyond that is journalists asking about how this instructions came about.

2025-11-25 20:15:54 UTC

- reply

It was then that, when this notice circulated widely, some journalists would find out and ask PJ for a comment and publish articles about it with their replies. I'm not aware of PJ directly reaching out to news outlets asking them to report on this topic. Please provide proof for your claim that this is what happened.

2025-11-25 20:15:16 UTC

- reply

The notice to local police wasn't about fearmongering, it was merely instructions how to handle phones with GrapheneOS, notably to be careful to not enter a PIN, as it could be triggering a wipe. This just makes sense to educate law enforcement personnel.

2025-11-25 19:07:34 UTC

- reply

It's a single story from law enforcement that is then picked up by multiple media. This is literally how media publishing works. One press release leads to multiple newspapers writing about it. That doesn't make it a coordinated effort. Nobody is coordinating anything, law enforcement shares information and news outlets report what they claim. No news outlet claimed that this is their own research, analysis or anything like that.

2025-11-25 14:44:02 UTC

- reply

what does "being threatened" mean? They sent an email and asked friendly? Coordinated media attacks also sounds weird for a single story (that as usual appears in various outlets). Almost as if the GrapheneOS marketing person (as usual) puts things out of proportion for publicity...

2025-10-26 17:36:33 UTC

- reply

Here's just a wild suggestion: Instead of changing GrapheneOS, why don't you report that "security issue" to Google. Either they will fix their client library (improving security for everyone) and give you a bounty for it or they will tell you that it's not a security issue. It's less work for you in both cases plus potentially some extra money in form of a bounty.

2025-10-25 11:44:43 UTC

- reply

What if @npub1am6…4z5c was to support the same semi-offline design for database access that Apple has? I don't think storing gigabytes of databases with wifi ap and cell towers on end user devices, when they don't need most of them is the best approach either (that's why I like GrapheneOS' Apple-based approach).

2025-10-25 11:34:02 UTC

- reply

I'm not talking about how it technically works under the hood, but rather how it works for endusers.
Although I believe there could be advantages of having a central services for some things. Like, single sign-on with a Google account. I certainly don't want to enter my Google account password in arbitrary apps, but I might be fine with them signing in and getting a token from my account.

2025-10-25 11:28:02 UTC

- reply

> stub out more APIs to further expand app compatibility without sandboxed Google Play installed.
So you're essentially creating a new microG, just directly baked into GrapheneOS. That would be HUGE.

2025-10-25 11:26:33 UTC

- reply

FCM might work because it does not use GmsService APIs, but rather uses the very old C2DM API. Which makes sense because the functionality of push notifications predates the existence of Play Services.
However, as push notifications are not meant to include sensitive data, being the delivery agent for push notifications is nothing that needs privilege. In fact, GrapheneOS could provide a C2DM compatible push notification service completely independent of microG and Play Services.

2025-10-25 11:20:10 UTC

- reply

I tried microG on GOS and many apps that require GMS complained about Play Services not being installed and refused to work, when they worked perfectly fine on LineageOS when installing microG. In both cases microG was installed as a regular sandboxed app, so the culprit must be either the lack of signature spoofing or something else in GOS broke those apps. I was under the impression that this is known and intended behavior, but if you say it "works", should I file issues for those?

2025-10-25 11:12:11 UTC

- reply

If it's just in edgecases, why do most apps work well with microG if signature spoofing is active and don't work on systems like GrapheneOS that don't support it? It seems rather the opposite: most features in Play Services require signature spoofing and only some rare don't.

2025-10-25 11:04:57 UTC

- reply

microG doesn't work properly on GrapheneOS. Only a handful of features work, far less than on systems that provide signature spoofing. So practically, it's not really possible to use microG on GrapheneOS. All you can do is install it and see most apps not working anyway.
If it wasn't to bypass signature checks, why would you make an effort to put original GmsCore signature at https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/blob/219b4c2895d30ebb4d0cdea2a57f25d0df269362/lib/src/app/grapheneos/gmscompat/lib/sysservice/client/GclPackageManager.java#L41 ? Couldn't you just keep it empty or insert a dummy signature?

2025-10-25 11:00:38 UTC

- reply

I'm actually surprised that you don't share this opinion, given that you rightfully pointed out security and privacy issues with microG.
All I'm saying is that with this change, you open GrapheneOS to some of these security and privacy issues. And I feel you don't make a serious attempt in trying to understand what I say.
But hey, if you say that this is the right way to do it in GrapheneOS, do it this way. Wondering when people will come up with a hardened GrapehenOS then...

2025-10-25 10:57:58 UTC

- reply

I doesn't matter to me what you call compatibility layer, I was talking about the code in GmsCompat that I linked above, that creates a fake package info entry with Google signature if no `com.google.android.gms` package is installed. This is clearly intended to bypass third-party apps' signature checks in the same way that signature spoofing for microG bypasses signature checks.
I'm saying that by adding this, you're risking security/privacy problems that wouldn't exist without.

2025-10-25 10:53:56 UTC

- reply

When uninstalling the official Play Services, apps can receive a `android.intent.action.PACKAGE_REMOVED` broadcast so they know they need to no longer assume GMS is installed. With your GmsCompat solution, no such broadcast is sent between the spoof package being "uninstalled" (= the spoofing being stopped) and a malicious package with the same package name installed.

2025-10-25 10:47:50 UTC

- reply

> Apps handling that incorrectly is not related to our compatibility layer.
It's not like apps have a choice which play services client library to use. Does the official Google play services client library do this correctly and ensures there is not race condition here?

2025-10-25 10:46:29 UTC

- reply

I'm not talking about sandboxed Google Play, I'm talking about
a) The new GmsCompat fonts provider spoofing the existence of a Google-signed com.google.android.gms without sandboxed play services being installed
b) Apps checking this fall for this spoofing, assuming that original GMS is installed when it is in fact not installed
c) Malicious apps with com.google.android.gms package name being possibly installed after apps performed the check described in (b).

2025-10-25 10:39:15 UTC

- reply

Because, if the above is true and the GmsCompat functionality makes the 1 check pass even without com.google.android.gms installed, couldn't I technically install a malicious app under com.google.android.gms package name between steps 1 and 2, resulting in potential security/privacy issues?

2025-10-25 10:38:02 UTC

- reply

Just for clarification, you're saying that if a third-party app uses the play services client library it doesn't do the following:
1. Check if com.google.android.gms is installed and that it is signed by Google
2. Connect to services/providers/etc provided by com.google.android.gms

2025-10-25 10:34:39 UTC

- reply

- microG installs its compatibility layer as `com.google.android.gms` and makes the system claim it's signed by Google
- GmsCompat installs its compatibility layer as `app.grapheneos.gmscompat.lib` and makes the system claim there is a `com.google.android.gms` with Google's signature and makes the system redirect certain requests originally intended for `com.google.android.gms` to GmsCompat.
They're not the same, but also not far off from how they work in principle.

2025-10-25 10:33:49 UTC

- reply

Well, but for this compatibility layer, you claim to third party apps that `com.google.android.gms` is installed and that said package has google's signature, no? I'm not saying you use microG, just that you're using a similar concept. And sure, having a clean new implementation of these services certainly doesn't hurt.

2025-10-25 09:47:56 UTC

- reply

I'm now wondering if we can make use of this to run microG...
EDIT: No, not really. The signature spoofing will only happen if no com.google.android.gms is installed. This introduces a race condition (requiring microG to be installed between signature check and an app's usage of it). So we have the same security impact of microG compatible signature spoofing without the benefit of being able to use microG in practice.

2025-10-25 09:41:05 UTC

- reply

Isn't this essentially adding some sort of signature spoofing, a feature GrapheneOS was always very much opposed to adding? What's the rationale to now consider it acceptable to fake to third-party apps that a package com.google.android.gms signed by Google is installed on the system when it actually isn't?
Reference: https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/blob/219b4c2895d30ebb4d0cdea2a57f25d0df269362/lib/src/app/grapheneos/gmscompat/lib/sysservice/client/GclPackageManager.java#L37-L43

2025-06-10 21:18:13 UTC

- reply

I was wondering what you think about Signal's registration_id. It seems to be a longterm device id that is attached to some(?) messages?

2025-01-27 15:00:10 UTC

- reply

If those resources and cookies blocked had not been of purpose to the tracking/ads/... industry, they would not have been requested. Thus, while certainly not perfect, it reduces how much tracking happens and/or how much data is shared and/or how many receive it.
It might not be perfect, but it did some good. And that's better than doing nothing just because you can't be perfect.

2025-01-27 14:57:22 UTC

- reply

All you write is correct and still it is totally missing the point.
Try the following: Install a popular ad blocker into your web browser and configure ad and privacy filters. Now open the developer tools to monitor all requests done. Navigate to a few popular websites and check how many invasive cookies are set and how many tracking endpoints data is sent to. Now reset and repeat the same with the ad blocker disabled.
You'll see the blocker blocked a lot.

2025-01-27 14:46:30 UTC

- reply

And lastly, Google doesn't even provide proper APIs to pass data into Google Analytics without using their tracking library. So using a tracking blocked which blocks their tracking library in fact does effectively block the app from sending tracking data to Google. Yes, a win against Google is just a small win, but it's a win that can be reached.

2025-01-27 14:45:07 UTC

- reply

Also, there's privacy laws (at least here in the EU). Forwarding the user's IP address from your server to Google for Analytics would be illegal without good reason, but connecting to Google servers for Analytics and there for effectively sharing the user's IP address as well is considered legal because it's technically required.

2025-01-27 14:40:37 UTC

- reply

We know that in reality, most websites don't try to bypass adblockers. Some try to detect them and block using their websites if you don't disable them. The same holds true for tracking, where the ROI to build a bypass for the blocker is even lower (because the tracking data really isn't worth as much). This is of course what we know from the web, but there's no reason why this should be any different on android apps.

2025-01-27 14:37:49 UTC

- reply

You're right in theory, but not how things work in practice. The large majority of apps send tracking data to Google exclusively directly through their tracking library. They don't send tracking data to their own servers so they couldn't silently forward it. A future version could send tracking data to their server, just as a future version could serve ads through their server. Thus, with every new version you'd need to verify again what they send where.

2025-01-27 14:27:28 UTC

- reply

And in case that wasn't obvious, this isn't meant as an attack towards GrapheneOS. You do amazing work and your results are astonishing. But that shouldn't keep you from realizing that the work of others, even if only opportunistic, also improves people's life in the wild.
Greetings from a user of a custom-built GrapheneOS modified to support microG in regular user sandbox.

2025-01-27 14:23:17 UTC

- reply

If ad blockers work reasonably well in practice, it is likely that privacy blockers do so as well. They're not perfect, they will let some data slip through, so any absolute approach is to be preferred when available and applicable. But they likely are a good addition to provide opportunistic improvements for what absolute approaches can't do (yet).
Opportunistic improvements are still better than no improvements.

2025-01-27 14:19:17 UTC

- reply

Please realize how I was talking about ad blocking and ad blocking only here, not that some ad blocker lists also include tracking blocking.
I use the ad blocker example because it's a perfect analogy that is much easier to grasp. The effect of privacy blocking is almost impossible to quantify, because you don't know how much less data about you is collected due to using them. With ad blockers you can easily see yourself how effective they are.

2025-01-27 14:04:27 UTC

- reply

I know all this. But again: In practice ad blockers work reasonably well. Yes, some ads manage to pass through, but most get blocked. It effectively improves the user's experience.
The absolute stance would be to say that either you have to accept the websites render ton of ads, because there is no guaranteed way of blocking them, or you stop using the web. But some people prefer the non-absolutist way, that is to use an ad blocker.

2025-01-27 13:51:37 UTC

- reply

I'm not saying that FOSS has better privacy just because it's FOSS, but also we know that in practice, this is the case. The average FOSS app is more privacy friendly. If you install 10 random apps from F-Droid, you're likely to end up with 10 somewhat privacy-friendly apps (especially if you have the filter for anti-features enabled). If you install 10 random apps from Play Store, about half of them probably perform tracking that is illegal in the EU.

2025-01-27 13:44:30 UTC

- reply

> Privacy/security features need to hold up to an adversary aware of it and which can actively adapt to it in order to be a serious approach.
See, this is what I mean. I totally agree with you on the one hand, but on the other hand, I understand people consider, for example, an ad blocker a useful tool, because it works reasonably well in practice even if technically, it can be bypassed easily.

2025-01-27 13:37:09 UTC

- reply

Auf der anderen Seite ist es deutlich differenzierter: Bei FOSS Apps guckt man einfach was sie machen und die Berechtigungen sind quasi nebensächlich, bei proprietären Apps gilt zwar die Annahme, dass sie womöglich die Daten "falsch" verwenden, aber ein Nachweis dazu macht es eben doch noch schlimmer. Dazu kommt, dass man einem kleinen, lokalen Unternehmen anders Daten zugesteht als etwa Apple oder Google (wo Missbrauch stärker vermutet wird).

2025-01-27 13:35:02 UTC

- reply

Ich denke der Hintergrund ist ein grundsätzlich unterschiedliches Verständnis von Datenschutz in verschiedenen Bubbles der Privacy-Community.
Auf der einen Seite ist es mehr absolut: Was eine App kann, das müssen wir auch annehmen, dass sie das auch tut. Ob es faktisch Tracking gibt oder nicht, ist dabei fast egal, genauso wer die Daten bekommt (weil er ja weitergeben könnte). Der einzige wirksame Schutz ist, die zugreifbaren Daten zu reduzieren.

2025-01-19 09:13:20 UTC

- reply

I mean, I totally understand why @npub1m9z…whzq did this, as they somehow have to manage with limited amount of money and this probably saves them a bunch.
But to me they still broke their social contract: (at least some of the) people that have signed up for an account on matrix.org expected to use a free software server. Now they and their data have been forcefully migrated to proprietary software.

2025-01-19 09:09:18 UTC

- reply

What strikes me most about this recent #Matrix announcement is not that they created a commercial version and that this version is more efficient, but rather that users of the matrix.org home server are now using a proprietary server software.
If I now go on the main website of @npub1m9z…whzq, where they repeatedly mention how they're open-source, and follow the guide to create an account, I will end up with an account on a proprietary server running in a proprietary cloud environment.

2025-01-06 14:45:45 UTC

- reply

Das Niveau auf dem wir uns hier bewegen ist nicht weit entfernt von:
"Kritische Sicherheitslücke in F-Droid: Wer einen Browser aus F-Droid installiert und dann damit auf eine Webseite geht, führt potentiell Schadcode (JavaScript) aus"

2025-01-06 14:37:45 UTC

- reply

Das gleiche gilt für alle anderen binaries die im Quellcode so rumfliegen, ich kann dir auch Schadcode in eine .png packen. Der Code der code aus Binärdateien oder Drittquellen ausliest und dynamisch zur Ausführung bringt ist IMO bereits Schadcode und sollte nie in F-Droid landen. Die Signaturblöcke sind zwar hier ein zusätzlicher Weg, aber eben bei weitem nicht der einzige um Schadcode auszuliefern, wenn Code dynamisch geladen wird.

2025-01-06 14:31:53 UTC

- reply

Ja, aber kaputte Signatur-Blöcke haben halt keine Auswirkungen auf den ausgeführten Programmcode der Apps, wenn diese nicht im Quellcode schon Schadcode haben, der dynamisch Schadcode nachlädt. Die Signaturblöcke werden ja nicht einfach ausgeführt. Deswegen ist der maximale Impact hier eben, dass die App mit kaputten Signaturblöcken im Repository landet und deswegen Updates nicht mehr funktionieren.

2025-01-06 14:11:15 UTC

- reply

Nein, das wird da genauso dargestellt. Das ursprüngliche Problem wurde durch Änderungen, die die F-Droid-Entwickler selbst gemacht haben behoben, die patches des Entdeckers der Lücke wurden nicht genutzt. Bei den Änderungen von F-Droid selbst gab es bekannte Probleme, die aber keine Sicherheitslücken darstellten. Eine Sicherheitslücke darin wurde erst mit Datum 2024-12-30 gefunden und direkt veröffentlicht. Der Finder selbst sieht den impact aber "lower".

2025-01-06 13:44:35 UTC

- reply

Interessant auch, dass keiner in der Community bemängelt, dass hier kein responsible disclosure zum Einsatz kam. Klar, muss man nicht, aber dann ist die Beschwerde, dass eine Lücke mit effektiv geringem Impact nicht in 7 Tagen über Neujahr gefixt wurde doch schon etwas abgehoben.

2025-01-06 13:37:02 UTC

- reply

Das stimmt, ich hab ja auch "Updates" gesagt :) Wichtig ist und bleibt aber, dass nur der Original-Quellcode im F-Droid repository landet.

2025-01-06 13:29:38 UTC

- reply

du meinst seit ein Paar Tagen mit "lange"? Die ursprüngliche Lücke die letzten April gefunden wurde, wurde bereits letzten Mai geschlossen, es wurde nur vor ein Paar Tagen eine neue Lücke an ähnlicher Stelle im gleichen repository als "Update" veröffentlicht.

2025-01-06 13:15:03 UTC

- reply

Wie gesagt, für diesen Angriff müsste der Schadcode, der den Schadcode aus der Signatur nachlädt, bereits im Open-Source code der App sein. Wenn wir bereits Schadcode im Open-Source code der App annehmen, kann durch diese Lücke auch kein zusätzlicher Schaden entstehen.
Ich will nicht sagen, dass man diese Lücke nicht schließen sollte. Es ist aber ein Klassiker in der Community, bei einem sehr komplexen Thema wie diesem einfach ohne Verstand drauf zu hauen...

2025-01-06 12:48:33 UTC

- reply

Theoretisch könnte man sich auch noch ein Szenario ausdenken, wo der Publisher einer App in der kaputten Signatur Schadcode einbettet und in dem reproduzierbar gebauten open source code seiner app Logik hat, die den Schadcode aus der Signatur sucht und ausführt. Da gibt es aber verschiedene Gründe die diesen "Angriff" nahezu unmöglich machen (Länge der Signatur, Einschränkungen in Android welcher Code ausführbar ist, usw.)

2025-01-06 12:44:17 UTC

- reply

Das führt im schlimmsten Fall dazu, dass der Publisher einer App (der erst eine entsprechend präparierte .apk mit kaputter Signatur veröffentlichen muss) damit erreichen kann, dass Updates seiner eigenen App im F-Droid kaputte Signaturen haben und diese durch den Nutzer nicht mehr installierbar sind.
Und ich bin mir nicht mal sicher, ob dieser Angriff überhaupt möglich ist, gegeben wie der Buildserver die Signatur kopiert.

2025-01-06 12:41:23 UTC

- reply

Der schlimmstmögliche Angriff auf dem offiziellen F-Droid-Repository ist also nicht, wie von @npub1g6j…4s5g behauptet, dass eine "manipulierte oder unsichere" .apk im offiziellen F-Droid repository landet, sondern nur, dass eine kaputte oder falsche Signatur an die reproduzierbar gebaute .apk angehängt wird.

2025-01-06 12:38:48 UTC

- reply

Das offizielle F-Droid repository benutzt diese Funktion auch in ihren Metadaten um bei reproduzierbar gebauten .apk die Signatur des ursprünglichen Entwicklers zu erzwingen. Allerdings werden wie bereits erwähnt, alle .apk die im F-Droid repository sind, auf dem Server von F-Droid gebaut und dann entweder eine eigene Signatur, oder im Falle reproduzierbaren .apk die Signatur der Original-App angehängt.

2025-01-06 12:34:09 UTC

- reply

In den Metadaten zu einem F-Droid-Repository kann ein öffentlicher Schlüssel hinterlegt werden, sodass auf dem Server nur noch .apk für eine bestimmte App akzeptiert werden, die mit diesem Schlüssel signiert sind.
Diese Signaturprüfung hat aktuell Fehler, die unter Umständen dazu führen könnte, dass in einem F-Droid repository .apk mit Signaturen sind, die dort laut Metadaten nicht sein dürfen.

2024-12-10 14:17:05 UTC

- reply

That's not how this works. @npub1le8…4nlt is registered as a Swiss company and thus is not a data subject in the sense of the GDPR (only natural persons can be data subjects).

2024-08-01 07:25:59 UTC

- reply

When you use Signal on iOS or Google Android, it will register for the OS push notification system and link your burner phone number with all the other apps/accounts you have on the same phone that use push notifications, including the Apple and Google accounts that you likely have on the same phone. So you'd also need to use a burner phone, that you use exclusively for Signal (or an OS that doesn't have a push notification system like @npub1kwa…e0nj and take extra caution)