Graphene OS Questions, comments, concerns, etc

mbananasynergy · April 25, 2024, 5:41pm

This is completely incorrect and betrays a fundamental misunderstanding of how AOSP works, which for someone who makes their own OS, is pretty unfortunate.

You have been trying to spread this narrative about how GmsCompat works for years now, mainly on Reddit, and it seems you’ve moved to try and do it elsewhere since people on Reddit have started realizing that you’re making stuff up.

None of what you’re saying makes sense. Apps that are installed in the regular app sandbox (which is the only way to install Google Play on GrapheneOS) have zero access to anything that privileged apps would have access to. The entire approach has to do with the fact that the apps do not get additional access over other apps. The code you’re pointing to is completely and entirely irrelevant, something which you would know if you’d taken the time to actually look at GmsCompat.

Please stop trying to make people believe something that is so very obviously incorrect across every platform. You don’t have to like GrapheneOS, but stop lying about it.

optimumpro · April 25, 2024, 5:54pm

LOL. Here we go: a typical GOS hysterical response: cry ‘foul’ ‘lies’ and ‘disinformation’.

Don’t believe me, look at the code. Also, while there think about Root applications which can happily execute Root while sitting in Data partition in your ‘sand box’. LOL again.

I won’t respond to childish personal insults.

mbananasynergy · April 25, 2024, 5:58pm

There are no insults in my post. The information you have posted is incorrect. Google Play apps on GrapheneOS sandboxed like all other apps. The code you’re referring to does nothing on GrapheneOS because the apps are not privileged. It is not clear whether you know this and are trying to make other people believe it, or if you genuinely don’t understand it.

I would invite you to do the same. How GmsCompat works is very well documented, and the code is open for you to look at and inspect.

This sentence makes no sense. Regular apps on GrapheneOS aren’t given root access. Ironically, I believe that’s something that your project does.

optimumpro · April 25, 2024, 6:03pm

You are talking Gibberish. An app that is built with System_uid or Root_uid gets automatic permission check (allowed) in AOSP regardless of where it is sitting. The only way to prevent that from happening is to remove those flags together with the corresponding code and rebuild the apps, which in the case of Gapps and Google Services Framework is IMPOSSIBLE due to closed sources.

All that GOS literally does in Gmscompat is telling Gapps not to crash and it works. But it can’t prevent them from executing high level permissions available to Root and System apps.

Edit: GOS doesn’t need to do anything to ‘give Root’, it’s already done in AOSP. Gapps, unlike various Root applications, acquire root silently.

mbananasynergy · April 25, 2024, 6:20pm

        if (uid == Process.ROOT_UID || uid == Process.SYSTEM_UID) {
            // Root and system server always pass permission checks, so don't touch their app
            // ops to keep compatibility.
            return;
        }

All this code is saying that if a process running on the OS has root or system UID (which user installed apps cannot have) then permissions don’t apply to them.

Since the OS is trusted and only trusted OS components can have those UIDs.

This is de facto false. If Android apps actually worked this way, that would be a de facto privilege escalation hole. Your understanding of the Android platform is fundamentally wrong here.

See my prior comment. And there is no need to modify the apps when you control the OS, which is one of the major concepts of Gmscompat, which introduces shims, for example the GMS app can request the IMEI normally on a GMS device, and on GrapheneOS if the user chooses to install sandboxed Google Play, we allow the GMS app to call it but we stub out the response so it gets no IMEI by doing that within the Android framework instead of modifying the app.

I have no idea what you mean by this. The standard security model forbids user installed applications from obtaining root access of any form, this would be a major privilege escalation issue.

This is architecturally not possible, as they are installed as user installed apps, which cannot do this. The applications run in the same sandbox as any other app, they are not special in that regard. You can easily check the SELinux confinement of any of the user installed apps you install and see that they are confined within “untrusted_app” in SELinux using ADB to verify this.

Are you implying now that Google made apps use 0day/n-day privilege escalation bugs in the wild? That would be very major news, I would love to see some proof of that, maybe we can report this issue to Project Zero together?

optimumpro · April 25, 2024, 6:55pm

Nothing that you’ve said advances any viable argument. Again, look at the code I referenced. It is from AOSP. If you can’t read Java, ask someone who can. What those code quotes say is this:

If an app or process has System_UID or Root_UID flags, they automatically pass permission and app verification checks. They don’t need to ask for or escalate anything. That’s precisely what the AOSP dev’s comments say: Grant permissions and don’t touch them. Also, those flags are shared meaning, more than one app or process can have them.

As far as Gapps: there is no escalation or zero day tricks. Gapps and GSF are DESIGNED and BUILT with System and UID flags. They are by definition TRUSTED. No OS can function without certain processes and/or apps having those flags. Normal apps cannot be built with those flags or any System level permission: the build will stop with an error: ‘this is a System level permission’ which is not allowed in third party apps. Gapps are NOT third party apps.

Again, your argument is not with me, but with the code.

P.S. By the way, you think calling someone a ‘liar’ who spreads ‘misinformation’ is not a personal insult?! LOL.

Edit:

All this code is saying that if a process running on the OS has root or system UID (which user installed apps cannot have) then permissions don’t apply to them.

It is simply WRONG. If an app or process has System or Root UID flag, it is granted permissions regardless of the location. You don’t get high level permissions by putting a third party app into System, because that app is not BUILT with System_UID flag. Similarly, a System app does not magically lose its high level permissions, if you put it into Data.

mbananasynergy · April 25, 2024, 7:22pm

The code allows processes running as system or root UID to bypass permissions. Only trusted OS code is able to run with system UID or root UID.

Processes will only be able to obtain system UID or root UID if they were built into the OS. You can see more information on how sharedUserId declarations work here: <manifest> | Android Developers Now last I checked, we don’t sign GrapheneOS with the signing keys used for Google Play Services (we are not Google and even Google uses different signing keys for the stock Pixel OS), and we don’t modify/resign any Google apps as part of how sandboxed Google Play works. So due to the signature mismatching, the apps literally by architectural design of Android cannot obtain the ability to run under the system UID or root UID.

See my prior answer, because they are installed as user installed apps and their signing certificates do not match that of the OS, the sharedUserId value in their AndroidManifest is simply ignored. This is just a complete misunderstanding of how Android works. You appear to be under the impression that anyone can just set their app to use system UID or root UID, which would be by definition a privilege escalation vulnerability.

I eagerly await your proof of concept app for achieving root on GrapheneOS by declaring android:sharedUserId="android.uid.system" in its manifest.

I think it should be clear to everybody reading this thread that what you’re claiming is straight up incorrect. I also understand that no matter how much I explain this to you, and how much many sources I point to to explain why you’re incorrect, you are never going to admit to being wrong, because that would be embarrassing. The only reason I’m engaging and debunking your claims here is because you’re wording things in ways that make what you’re saying plausible to people without a technical understanding of how Android or GmsCompat works.

optimumpro · April 25, 2024, 7:39pm

You haven’t explained anything except for this:

We don’t sign GrapheneOS with the signing keys used for Google Play Services (we are not Google and even Google uses different signing keys for the stock Pixel OS),

And even that statement doesn’t make any sense, except identifying you as a part of GOS. LOL.

What you don’t understand is that when an app has System_UID or Root_UID it is already trusted regardless of the signature, because such an app can only be built in a rom environment. In other words, you can’t build it by using Android SDK outside of the rom environment. So, on a device with locked bootloader that uses a different flavor of Android (custom rom), such an app can’t be installed into System, because it would break the verified boot. But, thanks to Gmscompat, you can install that app into Data, which GOS users do. As a result, they have a perfect Trojan horse, i.e., an app that has System and Root UID in Data partition, an app that passes all Android permission checks and verifications. That plus the sense of false security.

What else could go wrong?

Edit: I just got a friendly notification that we could take this discussion private. So, I am ending it here. Please abstain from usual GOS tricks, like posting numerous links to the project.

Best regards

mbananasynergy · April 25, 2024, 9:59pm

Why are you saying this like it’s some hidden fact? I quite literally made an account here with the same name and avatar as I use everywhere else. matchboxbananasynergy - GrapheneOS Discussion Forum is my GrapheneOS forum account.

I felt compelled to make an account here and debunk what you’re saying because people were being misled. We’ve had similar conversations before on other platforms, but unlike those other platforms where you block people so that your statements cannot be debunked, this can’t be done here.

This is literally contradicting the documentation I have linked. Being able to only build something in a particular environment means nothing. You again seem to think that you can do privilege escalation to root, which would be a vulnerability, and is not possible.

You can install Google Play Services or Google Services Framework which doesn’t even have a declaration of android:sharedUserId="android.uid.system or android:sharedUserId="android.uid.root and instead has a declaration of android:sharedUserId="com.google.uid.shared" (so they can talk to each other, which is a standard part of Android, this is working as intended) (anyone can crosscheck this by decompiling with apktool) or any other app which has android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root declared in its manifest just fine on any Android OS as a user installed app (obviously you can’t install Google Play Services as a user installed app on a GMS Android OS).

GmsCompat does not change the ability for users to install apps which have sharedUserId declarations. To state otherwise is objectively wrong.

Verified boot doesn’t factor in here because user installed apps are architecturally not installed to read only partitions.

I encourage users reading this who have doubts to try install Google Play Services or Google Services Framework on an AOSP variant of the Android emulator (not Google Play Services variant, since those already have the apps preinstalled of course) in Android Studio by installing Google Play Services apk into it and seeing for themselves that it is possible, and then you can use a decompilation tool such as Apktool to clearly see that there is no android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root declaration in AndroidManifest.xml, which even if there was, would do nothing since the signatures would not match that of the OS they are running on. You can also demonstrate the ability of being able to install applications with android:sharedUserId="android.uid.system" or android:sharedUserId="android.uid.root" by just building an app with that declaration in its AndroidManifest.xml in an AOSP build environment and trying to install it.

Additionally, on a GrapheneOS device with sandboxed Google Play, you can clearly see the application UID is not root or system by using adb shell dumpsys package com.google.android.gms | grep uid. You can see what the SYSTEM_UID and ROOT_UID values are here for additional clarity: https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/Process.java;l=63-68

Here is a GIF showing the installation of Google Play Services as a user app on the AOSP emulator.

This is completely false. Please see my prior responses along with cited sources. You are objectively wrong here and I’m hoping that people will take the time to read through these replies and try this stuff out for themselves to see that this is the case.

There are absolutely no “tricks” here. I’m merely providing evidence that what you’re claiming isn’t the case. If you’re going to be making claims like this, they should stand up to scrutiny, and people who are being convinced because they may not know any better should have the chance to see the other side of the coin (with sources) and try things out themselves.

I am happy to leave things here and don’t want to violate any rules, but I similarly don’t want to let people be misled, so I had to provide an explanation.

Best regards

optimumpro · April 25, 2024, 10:50pm

Here you go. You could’nt help yourself and started posting links.

By the way, you just replied to my month-old post on Reddit and then immediately blocked me so that I couldn’t respond. LOL.

I am not playing these silly games. As I’ve said. I am done here. Forum users can read and form their own opinions.

End of transmission.

Edit: @triptamine, another ‘profie’ created 10 minutes before posting:

I understand what you are saying, but uid ## on Android don’t mean the same thing as on Linux. Example: check System Update in your rom. It will have a number similar to that of any third party app like ‘10256’, not ‘1000’. Yet, System Update can write to ALL phone’s partitions, which means total control.

mbananasynergy · April 25, 2024, 10:53pm

Links that are 100% relevant to what is being discussed, yes.

Very much agreed! Hopefully the next time you try to make this claim, you’ll point people to this conversation, so that they can actually hear from the other side and make up their own minds. Thank you for the opportunity.

Tryptamine · April 26, 2024, 1:44am

I just checked, I sideloaded a temporary root, and set App Manager with root permissions via KernelSU so I could see the signatures of all Sandboxed Google Play apps and the UID’s of the apps. This is what they are really installed as:

Google Play Services: UID: 10252 (shared /w Google Services Framework) 3 Signatures signed by Google Inc. NOT by my system certificates, which are signed by me, Tryptamine, or GrapheneOS (my own build. On regular releases by GrapheneOS ALL system apps are signed only by GrapheneOS. Same signatures and UID for Google Services Framework {Shared UID}).

Google Play Store: UID 10251 3 Signatures signed by Google Inc. Same as above.

System apps on GrapheneOS (that have full system permissions) have UID of 1000. Root apps have UID 0. I have NEVER seen a single app in an official GrapheneOS build, or my own build with UID 0, full root privileges! It would be unnecessary and giving too much privilege to any one app. Even the base “GrapheneOS” app is only “1000!”

Most system apps in GrapheneOS also may be signed by my build keys (release key, not the higher trust platform key), but they don’t have UID 1000. They don’t need full system permissions, so they don’t get them! Only very few system apps need full system permissions. This is a sign that GrapheneOS is working on the principal of least privilege. Which is a great thing!!

Yes, also I can see the SELinux policy is also not the same for the Sandboxed Google Apps as it is for the system apps:
System:

platform:privapp:targetSdkVersion=34:partition=system:complete

Gapps:

default:targetSdkVersion=34:complete

Time to go back to my nice & safe unrooted GrapheneOS!

vdbhb59 · April 26, 2024, 1:47am

Closed the topic to take the heat off. Kindly take it to PM like Optimum already received request. @optimumpro @mbananasynergy
This forum can very well do without personal hitting and heated arguments. Kindly refrain from doing so, to maintain harmony.

Also marked my answer as SOLUTION. lols

vdbhb59 · April 27, 2024, 2:18am

Have reopened and I wish everyone follows sensibility and let us have this data driven and not personal, unless positive in nature.
Also, let us just have no finger pointing.

Pharott · April 27, 2024, 9:39pm

@Tryptamine thank you so much for verifying! I was already pretty convinced it was fine cause I think about this kind of stuff a lot going back and fourth inside my head about it but it’s nice to have someone to actually be able to verify it rather than having to go off of what was said and speculation.

I whole heartedly agree. It was more or less why I joined the f-droid forum to be honest. I wanted a place to hear discussion on open source software, privacy and overall technical stuff. I tend to avoid a lot of forums however due to often times having slandered other projects or spreading misinformation which usually more often than not results in unnecessary and unproductive conflict.

optimumpro · April 28, 2024, 3:22am

@Pharott

Tryptamine, the same way as another user who both created their f-droid accounts 5 minutes before posting, have verified NOTHING.

I’ve dealt with the first one. Now, let’s take care of the claim about UID numbers. Android marks UIDs differently than Linux. In Linux, applications with UIDs up to 1000 indeed have higher permissions. So, he is trying to show that Gapps have numbers above 10000, which in his mind, means no high level permissions. Android, however, numbers UIDs differently.

Here are 2 screenshots. The first one shows Android’s System Update with UID no. 10241. The second one shows Antimine game available on F-Droid with UID no. 10348. System Update is a System app that has high permissions. It actually takes your entire device over. It installes OTA or Local Updates. In other words, System_Update can write to any partition including Firmware, Antimine is a third party app that has no high level permissions. Yet, by UID numbers, both are in the same category.

So, in Android, it’s not the arbitrarily assigned number that’s important or the location for that matter, but rather permissions that an app or process has.

lucasmz-dev · April 28, 2024, 9:57pm

The only thing I can say about the G thing is that I don’t see why an OS can’t sandbox proprietary code by emulating an environment and only passing necessary things and stuff. It’s sad it came to this;
I use Calyx (as they offer support for a device I can buy where I’m located, well already had) and help with translations, also to microG, Divest… And I’m not fond of GrapheneOS in a social standpoint, but I do find some of their work like Sandboxed Google Play interesting, I’ve used it before on a fork of Lineage but couldn’t get it to work, but it did seem quite interesting. I don’t think it makes sense for any of these communities interact with one another, like at all, if it brings fights everywhere.

To answer the actual post, I would recommend using F-Droid Basic instead of the regular build, beta has some interesting stuff when it comes to security, which I feel like would bundle with GOS well (and to any other OS, really).
Particularly some features about separating apps and repos, so for instance, one repo doesn’t try updating some app when you actually want it to come from F-Droid, so even as a beta I like it. It is also built for more recent versions of Android, a lot of this work is going back to the main F-Droid AFAIK.
I like to use the F-Droid builds whenever possible, but I might still have other dedicated repos either for specific apps that I don’t necessarily want to use.

Here’s some examples:

Default F-Droid repo, doesn’t show anything

User-added repo, warns the user it’s from an alternative repo

Moving repos (affects their default priority): (srry for the imgur link… i don’t know any other service to upload video here)

Changing the repo used for a specific app:

Since these are security features, I’m currently using the beta because of them. It makes using other repos like IzzyonDroid less worrying, as while I trust the repo, I don’t necessarily trust their builds that they take from devs as much as I do with F-Droid which builds them which puts it in a central tracker.

mbananasynergy · April 28, 2024, 10:24pm

It’s interesting that nothing in my last post was addressed or responded to, and that you mentioned you “were done”, but continued making these claims which have already been debunked after that. We can continue going back and forth on this forever, and I know I’m not actually going to to convince you because it’s unclear whether you actually believe what you’re saying in the first place, but I will say what I said in my last post.

For anyone who has doubts about how sandboxed Google Play works, feel free to take a lot at the posts in this thread and try the things mentioned for yourself. Feel free to verify what I’m saying, instead of taking it at face value. I hope that this time around, you can actually “be done”.

It’s not clear what you mean here. On GrapheneOS, Google Play can only be installed as a regular sandboxed app. Functionally, it has the same privileges/access that any other app does. If that’s what you mean, then sandboxed Google Play achieves that already.

I guess it’s “emulating an environment” that I’m not really clear on. Are you referring to virtualization here, or? If you are, then in the feature GrapheneOS plans to take advantage of pKVM to allow virtualization of either entire OSes (think Windows or desktop Linux) or maybe even running a barebones light version of GrapheneOS with the purpose of using that to run specific apps within for further isolation.

There are a lot of things that can be done given the resources, especially since the hardware (Pixels, in this case) are trending towards allowing more and more on that kind of thing.

Re: F-Droid Basic, I agree. If someone chooses to use F-Droid, F-Droid Basic is the client I would recommend using, too.

Tryptamine · April 29, 2024, 4:42am

Sure, ill play! No worries, i build my own builds of GrapheneOS, and I am not as experienced or as knowledgeable in the deeper workings of it as @mbananasynergy, however I know a thing or two. I’ve been researching how it works on a deeper level than a standard user for about 6 months, and I can say that I have in that time, never seen Google Play Services, Store or Framework do anything at all, ever outside of their permission models!

Yes, I do believe that system apps need to be build into the system to be system level apps. They should be in /system/priv-app/
/system/ is a read only partition with 0 bytes available as well after it is built! Well, really after it is packaged… I can see all the system partitions being created as part of the app signing/factory build/OTA update creating process, which comes right after the build in the GrapheneOS build process It has been modified substantially from the standard Android build process, just like the Vanadium (GrapheneOS’s default Chromium based browser) has been, referencing standard AOSP code may not be 100% relevant to GrapheneOS!

I can say this with confidence because I’ve been building my own builds, and working my way through reading the GrapheneOS source code for about 7 months now! Modifying tiny bits of it, but so very cautiously, because it is very clean and well thought out code. The last thing I want to do is integrate a security flaw… More on this below, but first, I NEED to bring this up…

If you want to reference any code, or post screenshots, please reverence GrapheneOS code which is freely available.

Referencing regular AOSP code isn’t that relevant here… The GrapheneOS code is publicly available, so i dong know why your using other, not applicable code to attack the project… Probably because it sounds right to non technically-inclined users who don’t know any better, so in effect you are taking advantage of their lack of knowledge. Very shameful of you, *especially since you should know better!

You can also reverence it’s kernel code, but that’s mostly a GKI kernel with added hardening that can be integrated integrated into any Linux kernel (integrity mode/confidentiality mode, I believe GrapheneneOS uses Confidentiality mode, not 100% sure though… May only be enabled when Lockdown Mode is activated.)

Please STOP using the straw man of pretending to know what is happening inside of GrapheneOS by reading code that is not GrapheneOS code! When you put it simply like that, it does sound silly, doesn’t it? Also your using a formal logical fallacy, in and real debate (formal) it wouldn’t stand, but here it makes you sound like an expert, without needing to actually know anything about GrapheneOS! Lets base this on facts about the actual product you and I are talking about, OK?

Because i build my own flavor of GrapheneOS, I’m currently running a build where everything including the bootloader keys are signed by me, with my own signing keys. That enables me to sideload a temporary root without needing to unlock the bootloader.(locked bootloader root with fully working verified boot) so i can load apps temporarily like App Manager with full root, UID 0 permissions and inspect on a running production build of GrapheneOS, the claims you are making. The last post I made,
I got the information this way too.

I also use App Ops extensively on rooted and unrooted production builds of GrapheneOS. The 3 main Google apps in discussion here (Services, Store, Framework) start with NO permissions except network, and in App Ops (the backend to all permissions on modern Android systems) they are all “undefined.” On a system of root app they start with all requested permissions as “granted.”

I can see, and EVERYONE can see the permissions Google Play Services wants access to by going to it’s app settings screen, then Permissions, then the three dots in the upper right corner and selecting “All Permissions.” These are not all currently granted permissions, unless it is a system or root level app on the stock Google OS!

I can see a massive amount of permissions there for Google Play Services, and even more in App Manager as it exposes the highly privileged, system level permissions! It also says that almost all of them are “revoked”! If it were a system app, then they would be GRANTED!

Here are sone of the MANY permissions for Sandboxed Google Play Services, that it requests from the system, there are really enough for over 30 screenshots, so here is a few off the top:

Notice they are all “revoked”? Wouldn’t be possible if it was a system level app!

Didn’t you start all this off by claiming that these apps must have UID’s of 1000 or 0? And that cannot be changed, therefore because of some code that is not GrapheneOS code, but standard AOSP code, they must have full system level privileges?

Now your shifting tactics after I pointed our that on GrapheneOS they do not have UID’s of 1000 or 0! Shows that your arguments aren’t on solid ground if you need to change them, and you seem insecure if you cannot even concede the point when faced with proof that you were wrong…

Anyways, on to more proof!

Also if it were a system app, a user **Would not be able to revoke permissions from it without becoming a higher privilege level themselves, something forbidden in the Google stock OS, and on standard builds of GrapheneOS! Again, I only can do this because i have built multiple kernels with root integrated into one of them, and i switch modes by sideloading different OTA updates.

I’ll post again my observations of the **different SElinux rules for system apps with privileged permissions, vs the Sandboxed Google Play Apps, and then a regular, user installed app:

Google Play Services SElinux Policy (and installed/data directories):

default:targetSdkVersion=34:complete

Google app for running Gemini on GrapheneOS SElinux policy:

default:targetSdkVersion=34:complete

Another random user app (NASA) SElinux policy:

default:targetSdkVersion=33:complete

Main system app bundle SElinux policy (and installed/data directories):

platform:privapp:targetSdkVersion=34:partition=system:complete

Android Keychain non-user facing system app SElinux policy/installed/data directories:

platform:privapp:targetSdkVersion=34:partition=system:complete

Non-privileged system-level app (default AOSP keyboard) SElinux policy:

default:targetSdkVersion=30:partition=product:complete

Default AOSP Phone dialer SElinux policy:

default:privapp:targetSdkVersion=30:partition=product:complete

Dynamic System Updates system app SElinux policy/install/data directories:

platform:privapp:targetSdkVersion=34:partition=system:complete

The apps that are marked as “privapp” cannot be disabled. The system apps that are simply partitioned on read only filesystem’s outside of user control you can disable.

So… I think you can easily see that the system apps have different permissions based on SElinux on GrapheneOS. SElinux is used heavily on GraphebeOS because it is such a powerful tool, used of many desktop operating systems to lock down application’s permissions very effectively! It is much stronger than the simple permission model that most users are aware of.

You can also see, both system level apps that are not privileged, as well as user apps are installed with UID’s of 10xxx. This just goes to show (in multiple ways) that Google Play Services and the other two Google apps that make up Sandboxed Google Play are not system apps and do not hold system level permissions!

I have now shown you that they:

Do not reside where system APKs reside, because they are not built into the operating system but optionally added later.
They do not have a UID label of a privileged app, nor are they located where privileged apps are on the correct partition for them.
The SElinux policy for these Sandboxed Google apps is that of unprivileged user apps. They don’t even have an SElinux policy of unprivileged system apps, giving them system-level partitioning different from user apps, **the policy for them is identical to that of regular user apps!
Finally, I have shown you that Google Play Services may request all of the powerful, system permissions that it is used to getting, but receives almost none! If it were a system or root level app with special access, it would get these.

Convinced yet? Really I care little about convincing you, my ego doesn’t depend at all on what some random person on the internet thinks. This post and the effort that went into it is for all future viewers so they get a taste of the truth of things, and they aren’t taken in by the outright falsehoods backed by made-up data you are presenting.

The truth has a way of rising to the top, and when placed next to falsehood, people are usually quick yo recognise which is which…