Talk:GrapheneOS/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

why is the second paragraph in the history section considered promotional?

in my perspective the second paragraph doesnt contain anything from Wikipedia:PROMOTION, please offer a precise explanation to why its promotional so i can resolve it, thanks Omilc (talk) 04:08, 20 August 2022 (UTC)

i've removed what i feel might be like an advert, if there are no objections, ill remove the advert issue banner Omilc (talk) 02:42, 22 August 2022 (UTC)

I object. Some editors continue selectively using often poor sources to "support" what they want the article to say, which is mirroring what GrapheneOS website says. The article should neutrally summarize and balance what independent, reliable sources say, and selectively use primary sources when they meet criteria. It is not neutral to selectively include only self-serving, primary-source "virtues" while ignoring other relevant primary-source info, such as "don't use our source" statments. See 4 and 5 at your link, and tell me how this article is not exactly those. Same for WP:NOTMIRROR section at the same page. -- Yae4 (talk) 21:29, 22 August 2022 (UTC)

im not sure what you are talking about, what do you mean by "see 4 and 5 at your link"? Omilc (talk) 02:12, 26 August 2022 (UTC)

History, transition from CopperheadOS with "Android Hardening", to GrapheneOS

Stale

 – Multiple reliable sources support the history of Android Hardening, and citations for sources about this have been improved over time. Packtpub is no longer referenced. YugaTech is still referenced in the article, although not anymore for statements about Android Hardening. Due to Special:Diff/1105130982, it looks like the mentions of Android Hardening or AndroidHardening are to stay in the article. 84.250.14.116 (talk) 10:39, 19 August 2022 (UTC)

On the history, the article currently seems misleading, and not consistent with the better source (golem.de). If I understand correctly, Micay was working on "Android Hardening" as part of CopperheadOS. The renaming from "Android Hardening" to "GrapheneOS" was about a year after "the incident", if that refers to the firing of Micay in June 2018, yes, but "Android Hardening" was also part of CopperheadOS, which Micay also worked on.

• In June 2018 the Android Hardening repo "platform_packages_apps_Updater" description said "Automatic background updater for CopperheadOS." (archive link above) This indicates Android Hardening was originally being developed as part of CopperheadOS. By November 2018 it may have been splitting off, but this is not entirely clear.
• As of March 2019 it was still called "Android Hardening". [1]
• In May 2019 it "Android Hardening" was being renamed to GrapheneOS.[2]

• Secondary source golem.de says (translated), "The main developer Daniel Micay wants to continue the development of Copperhead OS as well as the Android Hardening project with GrapheneOS." and "Micay is no stranger to the company; he was co-founder of Copperhead, the company behind the hardened Android system of the same name, as well as its lead developer. In mid-2018, the two founders defected. Then, in April 2019, Micay announced GrapheneOS as the true successor to Copperhead OS, which would functionally inherit it." I interpret "defected" as more like "separated", and these statements are saying Micay is moving from CopperheadOS with "Android Hardening" included, to GrapheneOS with "Android Hardening" included.
• "to better reflect what the project has become" is strange language which seems to have a advertising flavor, not neutral wiki-language.

Therefore, I support removing coverage of "Android Hardening" and including statement on transition from CopperheadOS to GrapheneOS more consistent with the golem.de source. I would also support simply removing the Packtpub source, if it wasn't needed to support notability of the article. -- Yae4 (talk) 11:21, 26 December 2021 (UTC)

Removing the coverage misrepresented what the sources say, so I reverted this. 84.250.14.116 (talk) 15:25, 23 June 2022 (UTC)

Your statement is false, but thanks for the response (after 6 months). WP:DUE says we must "fairly represent all significant viewpoints that have been published by reliable sources, in proportion to the prominence of each viewpoint in the published, reliable sources." Your edits are cherry picking a LOT from one reliable source (golem), and one unreliable blog post (Packt) to present - in wiki voice - Micay's version of the history. I simplified the "transition" statement because including more detail gives undue weight to ONE source. Also, too fine details are irrelevant to most readers (i.e. non-encyclopedic), IMO. -- Yae4 (talk) 18:48, 23 June 2022 (UTC)

I also noticed the Android Hardening rebranding to GrapheneOS was already also supported by a Pro-Linux reference in the article, so I added that reference before the Packt reference as a secondary supporting citation. 84.250.14.116 (talk) 18:28, 23 June 2022 (UTC)

And it's in the Yugatech citation too: The former lead developer of the CopperheadOS that had a fall-out last year, Daniel Micay, developed his own open-source project called Android Hardening Project which was later renamed to the GrapheneOS. 84.250.14.116 (talk) 18:36, 23 June 2022 (UTC)

Also in Svět mobilně and Origo sources, so quite well established in third-party sources. 84.250.14.116 (talk) 18:44, 23 June 2022 (UTC)

Yugatech is another poor source that just regurgitates Micay tweets, and should be deleted. Yes, mea culpa for ever including it. I'll have to re-look at the others. See above for more on WP:DUE. -- Yae4 (talk) 18:45, 23 June 2022 (UTC)

I proposed the YugaTech article for deletion. 84.250.14.116 (talk) 19:08, 23 June 2022 (UTC)

Probably a time to remove this YugaTech source, hard to verify anything from it but the existence of a single Tweet. No editorial policy I could find. 84.250.14.116 (talk) 20:16, 21 July 2022 (UTC)

Glad you finally see reason and agree. Now please look more closely at Talk:GrapheneOS/Archive 2#Origo.hu_source_deletion. -- Yae4 (talk) 21:18, 21 July 2022 (UTC)

The latest Android Police citation from a week ago goes even further to claim: Founded in 2014 as CopperheadOS, the privacy-focused operating system was briefly known as the Android Hardening project in 2018, before officially becoming GrapheneOS. 84.250.14.116 (talk) 21:54, 23 June 2022 (UTC)

The Android Police article here at enwiki has had its article deleted and drafts abandoned multiple times for an apparent lack of notability. 84.250.14.116 (talk) 22:01, 23 June 2022 (UTC)

It seems to be connected to MakeUseOf.com (the same publisher, Valnet Inc.). User:Newslinger said MUO to be "marginally reliable". (Wikipedia:Reliable sources/Noticeboard/Archive 326#Should MakeUseOf.com be considered a reliable source?) — Preceding unsigned comment added by 84.250.14.116 (talk) 22:35, 23 June 2022 (UTC)

See also Wikipedia:Articles for deletion/MakeUseOf. 84.250.14.116 (talk) 22:37, 23 June 2022 (UTC)

My understanding: Notability of an article about a source is independent of that source's reliability as a source. In other words an obscure publication on ROMs could be little known, but have a reputation of reliability as a source. Repeating: Android Police seems OK but marginal to me; MakeUseOf.com seemed less reliable. Also, any source that basically repeats tweets without any critical analysis or independent thought should be binned. -- Yae4 (talk) 11:02, 24 June 2022 (UTC)

After looking at previous Reliable Source Noticeboard discussions of Valnet properties, which includes Android Police, I now feel Android Police is not even marginally OK, and I was mistaken to add the material from that source. Thus, I will be deleting them. -- Yae4 (talk) 22:38, 30 June 2022 (UTC)

Moved from #aka Primary source statements by GrapheneOS/Micay on Github (and Twitter) re: "Don't use my source" (paraphrase)

Neutrality tag for "Reception" section

Resolved

 – The older revision was restored (Special:Diff/1112436086) per WP:TC after a week. 84.250.14.116 (talk) 20:34, 10 November 2022 (UTC)

To the editors who added or restored the neutrality tag to the "Reception" section, could you please provide the reliable sources that describe GrapheneOS negatively that you believe are omitted from the article? If there are no such sources, the tag should be removed, because according to WP:TC, "Cleanup tags are meant to be temporary notices that lead to an effort to fix the problem, not a permanent badge of shame to show that you disagree with an article, or a method of warning readers about an article." — Newslinger talk 22:03, 19 September 2022 (UTC)

Source doesn't support exclusive Pixel support happened in October 2022

Resolved

 – A cut-down edit Special:Diff/1121888510 replaced mentions of October 2022 back to the cited March 2022 statements. 84.250.14.116 (talk) 05:38, 17 November 2022 (UTC)

"As of October 2022 GrapheneOS only supports the current Google Pixel product line.[8]" https://www.howtogeek.com/790266/what-is-grapheneos-and-how-does-it-make-android-more-private/

The article doesn't mention anything about October and I believe it is an incorrect statement anyway. Saw reddit threads from 2 years ago asking why Graphene only supports Pixels. Dougbeney (talk) 13:21, 8 November 2022 (UTC)

Special:Diff/1116101220 is incorrect (and also removed {{As of}}). I wanted to revert it a few days ago, but noticed the page was semi-protected and did not bother making an edit request. 84.250.14.116 (talk) 20:28, 10 November 2022 (UTC)

Rewrite of the Features section

I have rewritten the Features section to provide a more comprehensive and detailed list of security features rather than focus just on the sandboxed Google Play Services: and as it's a substantial enough change, I figured it would be best to let the talk page know.

I don't forsee there being any problems, however, a variety of sources like listing and going over individual security changes (which makes finding good citations much easier).

There are one or two features (sensors permission and scoped storage access) that I could not find any news outlets mentioning. I have just linked to the official GrapheneOS website for those. 75.172.38.252 (talk) 21:05, 24 July 2022 (UTC)

"Good" citations is a whole "thing." Thanks for the rewrite. I've changed it some. See above for discussion of why Android Police was previously removed as being unreliable. -- Yae4 (talk) 07:48, 25 July 2022 (UTC)

Now {{Prose|section}}. 84.250.14.116 (talk) 09:46, 25 July 2022 (UTC)

Possibly also {{Excessive examples|section}}, but I've not tagged this. 84.250.14.116 (talk) 10:17, 25 July 2022 (UTC)

84.250.14.116: For a "Features" section: is prose all that desireable? Not all that much necessarily needs to be said about each change: which I think fits a bullet point list well.

I don't think it was Excessive Examples (it certainly isn't now in the current state, after review + cleanup): my impression is that example cruft applies to examples of a concept (for explaining). The Features section isn't trying to say "GrapheneOS has features, this is why", it's trying to give an overview of all the features in GrapheneOS. 71.212.97.112 (talk) 09:24, 27 July 2022 (UTC)

It's to nudge contextualization and explain the significance of listed features, for Wikipedia:Notability. I would make comparisons to Debian#Features (GA-class article) and revision 1099482303 of this article. I agree the list itself should no longer as excessive as it was before after the cleanup and peer review, but prose is preferable for an encyclopedia (when expanding on what a feature is, and how it's different). 84.250.14.116 (talk) 21:59, 29 July 2022 (UTC)

See Wikipedia:Reliable sources/Noticeboard/Archive 379#Jonathan Lamont's review at MobileSyrup and the previous discussion #Jonathan Lamont's review at MobileSyrup on this talk page. These recent edits expanded referencing the biased MobileSyrup citations beyond the reception section, now in the features section (but perfection is not required and even biased sources may be reliable in context). Should those citations be referenced in the "Features" section? 84.250.14.116 (talk) 10:01, 25 July 2022 (UTC)

In my opinion, may be marginally reliable in this context with in-text attribution (according to Jonathan Lamont of MobileSyrup in July 2022), matches what the GrapheneOS official website says about itself. 84.250.14.116 (talk) 10:26, 25 July 2022 (UTC)

"Peer" review among IP editor(s)

Peer review LTE-only mode I removed the "LTE-only mode" because of finding various web search results for Android + force LTE (or similar), those mentioning the same Settings ➔ Network & Internet ➔ SIMs ➔ Preferred network type as mentioned in GrapheneOS official website. I may be miseducated, because the GrapheneOS website also says: This section doesn't list features like the [...] and so on but rather only our improvements to modern Android. I could also not find the GrapheneOS LTE-only feature covered by third-party sources (except from Android Police). 84.250.14.116 (talk) 12:06, 25 July 2022 (UTC) Kernel security fixes. This may be a feature fluff advert, because it lacks a comparison point. GrapheneOS website (currently cited as a reference) describes it as: GrapheneOS includes fixes for many vulnerabilities not yet fixed in Android. On modern devices with Generic Kernel Image (GKI) support, we update the kernel to the latest stable GKI release many months before the stock OS gets the update. This means we're shipping hundreds of fixes not included in the stock OS including many security fixes. We also backport more fixes on top of this for the kernel and for other components too. According to Ron Amadeo of Ars Technica (WP:RSP#Ars Technica), Google has described Generic Kernel Images to work across all Android devices, [...] to enable faster security deployments. Amadeo also reported LTS kernel updates occasionally arrive via OTA updates, but devices typically don't jump to major new kernel versions. Google intended to ship GKI to consumers starting with Android 12, with Pixel 6 being the first anticipated phone to receive it. I don't think GKI needs to be mentioned in the article's features section at any point (in comparison to AOSP, there is little or no distinction). Next, I found and read Amadeo's news article on how Samsung and third-party devs fixed the Dirty Pipe bug faster than Google. So where is the patch? It hit the Android codebase on February 23 and then didn't ship in the March security update. That would have been a fast turnaround time, but the April security update is now out, and Dirty Pipe, CVE-2022-0847, still isn't anywhere to be found on Google's security bulletin. Once the fix hit the codebase in late February, many third-party ROMs like GrapheneOS were able to integrate the patch in early March. The Pixel 6 being the last phone to get an update would certainly be on-brand for Google, as the company has continually struggled to get updates for its new flagship out on time. The phone's December and January patches arrived weeks late, even though speedy updates are supposed to be a major selling point of the Pixel line. According to Amadeo again, Google shipped the Dirty Pipe patch in Android's May 2022 security update. There may be one inaccuracy in the GrapheneOS website in this example, because it seems to me reportedly the slow man (for Google Pixel device) security fixes here was Google (not Android, or AOSP developers). Based on this available information, I would still remove the "Kernel security fixes." as a feature, but add a new mention to the history section referencing GrapheneOS and Samsung releasing the patches faster than Google (or in other words, Google delaying releasing the patches after the source code patches become available in Android). We've already done something similar with the 9to5Google reference about GrapheneOS releasing Android 12L earlier than Google. MAC address randomization I've added a comparison to Android Open Source Project as a footnote. Besides verifiable claimed existence in GrapheneOS, I don't think see this being covered by reliable third-party sources. I've been wrong about the lack of adequate sourcing, it appears in the Golem.de source on page 2. 84.250.14.116 (talk) 22:39, 5 August 2022 (UTC) Vanadium (web browser) The German-language quote in footnote from golem.de source was lost in the editorial process. I'm not sure why, though the other German-language quotes were kept. Later, the same reference was re-used in the same statement needlessly (once to support a statement about Vanadium web browser, a second time to support a statement about its basis on Chromium web browser). I may have preferred the former prose text with in-text attribution, because the golem.de source may be biased as an opinion piece. How-To Geek reference in reception section This reference is not an opinion piece or a critical review, and should be moved back to the features section with prose (in my opinion). Apps app It's currently tagged as "citation needed", after an editor removed the Android Police citation. "Apps app" can be found mentioned in the March 20, 2022 review from Lamont at MobileSyrup, but needs additional consideration if it warrants any mention in an encyclopedia, due to WP:NOTGUIDE context and the trivial mention. Several applications not present in the default AOSP distribution have been developed for GrapheneOS may be okay for it (makes a comparison to AOSP). Auditor service / app Possibly redundant mentions in article. Oddly enough, one of them with "citation needed", one cited to GrapheneOS website (despite how both can be found from the same reference in the same section), after the Android Police citation was removed. The attestation service references Micay's attestation.app service, which doesn't seem notable (beyond a few user-generated sources and the previously discussed Packt Hub citation); advert? GrapheneOS website says (potentially unreliable reference): The hardware attestation feature is part of the Android Open Source Project and is fully supported by GrapheneOS., further going on to advocate the use of a hardware attestation API instead of Google's SafetyNet API. I remember attestation being mentioned in the Android Police and Pro-Linux sources, however those aren't quite appropriate to reference in this context. I also had trouble verifying or comprehending the statements made there within about origins from the Android Open Source Project, which could harm WP:Verifiability in my view (and it's not entirely a statement about self). With the information available to me, I have not established its relevance in the features section and I could not (due to an editorial limitation of knowledge) make a neutral, understandable comparison to AOSP. I'll keep this updated as I find more concerns. 84.250.14.116 (talk) 16:57, 25 July 2022 (UTC); updated 18:10, 25 July 2022 (UTC); updated 19:48, 25 July 2022 (UTC) Thanks for the review. I split the section back into being somewhat divided between OS-level features and apps because I think the distinction is important: Apps can be installed on other Android distributions and are not exclusive to GrapheneOS (yet still being a "feature" developed by the GrapheneOS project), while OS-level features are specific to the operating system itself. I also made a few minor changes to clean up the grammar and flow and remove some ambiguity. One specific change is to the MAC address sentence, it was editorialized to add "enabled by default" which unfortunately had the effect of implying standard AOSP has the same feature (it doesn't, GrapheneOS's randomizes per-connection instead of per-network). Re: LTE only mode, I think it may be a feature removed in later Android versions and frontported to GrapheneOS, but it needs more research. Re. Kernel security fixes, I wasn't particularly happy with that either as I wasn't able to find a great source (although one certainly should exist? kernel security fixes are a main focus of the project). Moving notable ones to the history section seems like a good idea. Re. Auditor service app / attestation.app, as I understand it that's a core feature / motivation for GrapheneOS. I do know that the "hardware attestation feature" mentioned on the GrapheneOS website just refers to the cryptographically signed boot process. Every (decent) default Android phone has this, and usual practice for custom ROMs is to completely break it to get non-stock code running on the device. GrapheneOS tries to do this "correctly" which is why the installation process is so different from other custom ROMs (at least ones I've installed, so Lineage). The hardware attestation API should be different and that should be what is done through the Auditor app. When I mentioned "service" in that section, I was referring to the standard way it's used (two devices each with the app audit each other). That attestation.app service seems to just be an extension of that, maybe by acting as the second device. I don't think it's noteworthy enough for the article. With the Android Police source deemed as unreliable, I'll find some replacements for sections missing citations shortly. 71.212.97.112 (talk) 09:06, 27 July 2022 (UTC) Whoops, I'm definitely wrong about the MAC addresses. Thank you for the detailed descriptor, 84.250.14.116. 71.212.97.112 (talk) 09:35, 27 July 2022 (UTC) Vanadium's WebView A hardened WebView implementation provided by the Vanadium browser cannot be entirely verified from the golem.de source alone. "WebView" appears in primary sources (the official website), and WebView is a Wikipedia disambiguation page, so a reader is unlikely to understand what a "WebView" is from Wikipedia. Does WebView warrant any mention? GrapheneOS includes a number of security and privacy focused changes compared to other Android distributions. Which distributions (and how do they make the operating system more secure or privacy focused)? At the moment, only a few comparisons are drawn to Android Open Source Project. Theoretically it would also be possible to draw conclusions to other mobile operating systems (such as iOS), but I'm not doing that here (possibly due to systematic bias and my lack of knowledge/research on the topic). Relevance (in general) A lot of features mentioned, but not much coverage in third-party sources to establish relevance. See WP:LSC and WP:NOTDIR. The section lede may need a better descriptor to reduce the scope of examples (i.e. "[some] notable features", according to Wikipedia's policies). We're supposed to cover what reliable sources cover about the subject, not what Wikipedia editors (or the article subject) thinks to be important. Sensors permission toggle For a better source, look out for "peripherals toggle" or similar wording in sources to cite. I can't remember which source said this, unfortunately. 84.250.14.116 (talk) 10:09, 27 July 2022 (UTC) > Vanadium's WebView It seems I missed replying to this: "WebView" is just the technical term for the OS-provided browser library, that then can be used by other apps for opening webpages within themselves. I could add a descriptive note to clarify this since it doesn't have its own Wikipedia page if you'd think that would be helpful: but I also found another source verifying it. I found the source on the sensors permission toggle, by the way: it was buried in a general Android Hackaday article. I've also backed it up with a good Polish source I found. 98.97.36.93 (talk) 06:55, 5 August 2022 (UTC) Finding bits of sources to support adding what you want the article to say is not how wikipedia is supposed to go. Your "good Polish source" looks like a republisher of Android Police (and GrapheneOS website), and thus unreliable. -- Yae4 (talk) 16:24, 5 August 2022 (UTC) Consider writing the article first, instead of making footnotes or links about WebView. Looks like you found the same source I was previously talking about (Hackaday). 84.250.14.116 (talk) 21:08, 5 August 2022 (UTC) Per-application scoped storage access. Another fluff feature listing? AOSP documentation suggests this feature may not be exclusive to GrapheneOS: Scoped storage limits app access to external storage. In Android 11 or higher, apps targeting API 30 or higher must use scoped storage. Previously in Android 10, apps could opt out of scoped storage. I can make a comparison to AOSP, if it can warrant a mention. The given reference to GrapheneOS website is described as follows: GrapheneOS provides Storage Scopes as a fully compatible alternative to the standard Android storage permissions. Instead of granting storage permissions, users can enable Storage Scopes to grant the requested permissions in a highly restricted mode where the app can create files/directories in the user's home directory but can only access the files it has created itself. Users can then optionally add files and directories as storage scopes to permit the app to access files created by other apps. Which sounds a lot like how AOSP describes it: No read or write access to other apps' external app data directories and Write access to other apps' media files is allowed only with direct user consent (exceptions granted to System Gallery and apps that are eligible for All Files access). I'll be removing this for now, unless and until coverage in third-party sources mentions it as something relevant to GrapheneOS. 84.250.14.116 (talk) 12:28, 27 July 2022 (UTC); edited 12:34, 27 July 2022 (UTC) Here's two references from (who else but) Ron Amadeo at Ars Technica, saying Scoped Storage is a feature of Android 10 / Android 11. 84.250.14.116 (talk) 12:57, 27 July 2022 (UTC) Re. "Storage Scopes": scoped storage is a feature of base AOSP, "storage scopes" is a feature of GrapheneOS only. "Storage scopes" come into play when an application requests access to the entire filesystem (whether it does that by being legacy, poorly designed, or malicious). GrapheneOS then doesn't allow read access to previously created files: instead only giving it the ability to write new files and read the files which it has written. This is optional and pops up when total storage access is requested (as I learned today, upon encountering an app that wanted that permission). The documentation for this is here, after scrolling down slightly to the "Storage Scopes" sub-section: https://grapheneos.org/usage#storage-access This is a confusingly named setting and could use an explanation block like the one you've previously written for the MAC addresses point. 98.97.32.199 (talk) 02:05, 1 August 2022 (UTC) I still do not grasp the full difference (if there is any), and could not establish its significance from independent sources to warrant a mention in the article without undue attention to the verifiable existence of that feature. I've found a blog post (which I didn't read) from a pseudonymous author which seems to explain some differences, but as it stands, I wouldn't cite it in an encyclopedia (self-published and anonymous) or consider it adequate sourcing or significant coverage (nor reliable, as the author also hints on its "README" page). I also do not think the MAC address randomization warrants undue attention without adequate sourcing, right now. The features section is not meant to be a catalog, but focus on improving an encyclopedia (WP:5P). Lastly, I wish to clarify myself: I do not intend to require a comparison to be made. 84.250.14.116 (talk) 16:31, 1 August 2022 (UTC) I see - I suggest that comparisons would work well for the features list, because GrapheneOS is primarily a project made up of patches / individual tweaks made and kept up to date with AOSP. See below, but this is also why I don't think the features list is example cruft. I agree that source isn't fitting for Wikipedia (very much a blog) which is unfortunate because that's an excellent explanation of how storage scopes work. I think keeping it out of the features list for now, until/if a better source reports on it, is the way to go. To try and explain how it works again, for clarity: old apps can target a permission that allows for complete control over the filesystem, and if they don't get this, they break. AOSP does not provide for making this any safer for older apps: but for newer apps, introduced settings that can confine an app to a folder or just media. GrapheneOS introduced a setting that can trick older apps into thinking they have complete file access but actually confines them only to the files they create, which gets rid of a large potential for abuse. I think the MAC address randomization section has adequate sourcing. 98.97.32.199 (talk) 19:02, 1 August 2022 (UTC) The issue I saw with the MAC randomization statement: It was referenced to a non-independent, self-published source (the official website), with no discussion in independent sources; it could only promote the subject's own views (features), a conflict of interest. I agree the footnote I wrote put it in better position for an encyclopedia (explaining a difference), and strictly speaking would not oppose if another editor undid me on that MAC randomization statement (WP:BOLD), however I am siding with caution. As for your explanation about storage scopes or scoped storage, I can only take it as a grain of salt. You may be right, you may be wrong, but I don't have the competence in this storage / permissions subject. Thank you for the feedback. 84.250.14.116 (talk) 19:21, 1 August 2022 (UTC) See below, it was originally sourced by Android Police [independent] and the GrapheneOS website [primary], and the Android Police source was never replaced after it was removed for being unreliable. 98.97.32.199 (talk) 19:34, 1 August 2022 (UTC) I have to disagree about revision 1100243710's Android Police reference by Alessandro Mascellino to be independent, as claimed here. See also #Revisiting Android Police's reliability discussion here. 84.250.14.116 (talk) 22:14, 5 August 2022 (UTC) I've now removed a lot of example cruft which was given undue attention, lacking coverage in independent sources: Special:Diff/1101751029. 84.250.14.116 (talk) 17:05, 1 August 2022 (UTC) An alternative way to address the viewpoint, if desired: Keep the primary sourced information, but cite reliable sources (Ars Technica) about the existence of said features in Android (AOSP), such as "scoped storage". You can undo me. 84.250.14.116 (talk) 18:00, 1 August 2022 (UTC) 84.x: did you also intend to remove the section on external applications developed by the GrapheneOS team? Those are notable and have been covered by independent sources. The attestation service (especially this) and MAC address randomization points are also definitely notable. Although I think someone replaced the independent source citations that I used on those with GrapheneOS's primary website? Maybe they were never replaced when the Android Police source was deleted? Strange, but I've definitely seen coverage from other, more reliable outlets. Though it initially appears not interesting: I also think the sensors permission toggle is notable due to Android malware historically using sensors to evade detection: as well as collect and steal data (source is about detecting these after-the-fact, but based on defeating malicious apps found in the wild). Agree that scoped storage should be cut due to lack of sources explaining GrapheneOS's changes (see above). With regard to example cruft: it's my understanding upon reading through Wikipedia:Example cruft that example cruft first and foremost applies to using too many examples to explain something, which I don't really think bullet point statements providing an overview of the (rather few) notable changes are (and also I personally don't think there are too many bullet points, but that's certainly very subjective). I suggest rather than removing examples for example cruft just leaving the "may read better as prose" tag. I might look into rewriting it if I have some time. If you don't mind, I'll fix the sources and undo you in a little bit. 98.97.32.199 (talk) 19:31, 1 August 2022 (UTC) Sources fixed: I also added a point on the hardened memory allocator, since several of the new sources I found went in detail about it and it's a fairly massive feature despite having no user-observable impact (possibly why many sources don't mention it at all). 98.97.36.93 (talk) 07:32, 5 August 2022 (UTC) The removal of external applications developed was intentional as a middle-ground, specifically to address User:Yae4's concerns about repetition in the history section. 84.250.14.116 (talk) 22:19, 5 August 2022 (UTC) The latest restore/revision with new sources: "LTE-only" mode appears mentioned in the newly cited Oficina da Net source, however I refrain to comment at this time whether it warrants a mention in the article at this time or not. 84.250.14.116 (talk) 21:58, 5 August 2022 (UTC) References

---

For the picture added to features, is it possible to stop it from shifting the other sections? I'm assuming it's caused by the features section being too short to encompass the entire image. 76.135.154.252 (talk) 14:26, 22 November 2022 (UTC)

Difficulties and proposals for finding consensus at Talk:GrapheneOS

Collapsed Meta discussion, contrary to WP:TALK#NOMETA

Example Sockpuppet and off-wiki canvassing investigation and threats of reports: For possible future reference: Sockpuppet and off-wiki canvassing investigation[3] involving a recent editor [4] of this article, Xaeonx7. Also noting response to warning, and threat to "report you".[5] A similar threat of "being reported to Wikipedia Administrators" was recently made by 2603:7080:a903:f154:495:4a48:c4a:a888 on my Talk page.[6] -- Yae4 (talk) 19:31, 16 November 2022 (UTC) Off-topic  – This is a body-content matter to raise (and keep) at WP:SPI, WP:AN/I and user talk pages, not here on this article talk page which is only about the discussion of the article (and improving it). 84.250.14.116 (talk) 05:49, 17 November 2022 (UTC) Your statement is noted. Awaiting others. -- Yae4 (talk) 12:02, 17 November 2022 (UTC) This article and talk have been "plagued" with SPAs, and variable IP editors, including one who was determined by an Admin to be trolling[7] (and IMO continues similar behavior). As the true number of editors here is unknown, extended discussions or attempts to "vote" on changes or consensus seems pointless wastes of time. Recent examples of the types of difficulties, wasting editor and Admin time, are above (and in archives). My conclusion is the only effective solution is asking for extended Protection for the article, and then probably regular wasting of time in Sock Puppet Investigations. The question is: Can anyone else propose other reasonable solutions for this article? -- Yae4 (talk) 12:02, 17 November 2022 (UTC) WP:IPDIS I disagree, the existence of IP editors alone is no reason for extended protection nor ignoring consensus. 76.135.154.252 (talk) 14:09, 22 November 2022 (UTC) The problem is not only "the existence of IP editors alone". It is a combination of IPs (some with same geo-location), Single Purpose Accounts, and Sock and Meat Puppetry. An older example of admin investigation that confirmed sock puppets and revealed some "traffic is on proxies, and the kind of proxies used to intentionally obfuscate your identity" was here:[8] -- Yae4 (talk) 18:59, 22 November 2022 (UTC) This was one user approximately 5 months ago, and you are trying to use that to stop current discussions. SPA: WP:GF. 76.135.154.252 (talk) 23:34, 22 November 2022 (UTC) Your statement is false and misleading. It was one proven sock puppet, plus another proven to be using "the kind of proxies used to intentionally obfuscate your identity". I am not trying to stop discussions. I am trying to not waste time with identified trolls, and wiki-astroturfers. -- Yae4 (talk) 01:58, 24 November 2022 (UTC) My statement is neither false nor misleading. One user was a proven sock puppet, that is a fact. Using proxies on a registered account does not prove they are a sock puppet; to the same extent SPA IP's are not proof. Even if that user was a sock puppet that changes absolutely nothing, my point is that you are trying to tie in a event from 5 months ago as reason to take action on current discussion. You claim that you're not trying to stop discussions, yet this section was only sparked by recent debate. Otherwise why bring this event up now? 76.135.154.252 (talk) 05:43, 24 November 2022 (UTC) Please read what I wrote at the top of this section. We can also ask for disinterested, uninvolved advice through dispute resolution or a variety of options. -- Yae4 (talk) 22:39, 5 December 2022 (UTC) That seems like the only option for resolution. This article is lacking in editors, the few that remain seem quite invested in this niche of technology. My concern is that there's legitimate issue taken with the ANOM section and I interpret this section as an attempt to silence that. Hopefully we get more RFC contributions to reach consensus. 76.135.154.252 (talk) 05:18, 7 December 2022 (UTC)

A couple Micay primary sources for history

A lot of the history centers on Micay. I saw a couple primary sources that may be of interest for the article.

In 2017, Micay said maintaining hardened Android kernels was part of "my job" and he spent "far more than 40 hours a week on CopperheadOS". This was in context of stopping support of Arch packages PaX and grsecurity.[9]

In 2012 Micay posted an application for Arch Linux Trusted User, and gave other background.[10] -- Yae4 (talk) 01:35, 7 December 2022 (UTC)

I don't see a problem with adding more history relating to Micay,

But when adding this history editors should avoid turning the History section into a background on Micay, It also may be worth creating a Wikipedia page on Daniel Micay. 2603:7080:A903:F154:7D1A:5A11:EB2A:AA6 (talk) 06:31, 7 December 2022 (UTC)

The history sections of both this article and CopperheadOS are mostly about Micay, but I have not found enough reliable, independent, secondary sources to support an article on Micay. -- Yae4 (talk) 14:29, 7 December 2022 (UTC)

Security incidents

Resolved

 – Special:Diff/1126311161

I don't believe the Dirty Pipe section, or any section on individual 0days, are due. First, this wasn't a 0day in GrapheneOS itself, but in the Linux kernel. But even then, it wouldn't even belong at Linux kernel or Android (operating system), since security bugs are routine coverage. Every platform has dozens of serious ones per year. DFlhb (talk) 23:59, 7 December 2022 (UTC)

I agree with your point to remove the Dirty Pipe section, if it was a GrapheneOS specific 0-day i would probably disagree, but if this page had a section for every Linux/Android 0-day it would be a way too much information thats not necessarily relevent to GrapheneOS.

Considering the lack of Security incidents with GrapheneOS specifically should the section be removed entirely or just commented out? 2603:7080:A903:F154:5172:EDF1:382E:794B (talk) 05:02, 8 December 2022 (UTC)

I'd remove it; my criteria is that if a bug gets fixed promptly and competently, it's routine coverage and therefore undue; if a bug gets ignored, or there's "more" to a story (backdoor allegations, or a released "fix" that doesn't actually fix the bug, or general incompetence) then it would be due. The Graphene team seems pretty competent so I'd say that's unlikely.

If anyone's motivated, the biggest missing piece of this article is a section on GrapheneOS's security measures; it's the defining theme of the project, and they've done very interesting work (their extensive custom security mitigations, or their interesting approach to web browsers, their finding of Gecko being too insecure, etc.) DFlhb (talk) 05:23, 8 December 2022 (UTC)

I removed the section, i doubt that anybody will try to dispute its removal after reading your good points about the matter.

Some of GrapheneOS' security measures are already listed in the Features section, but alot more could be added and it could be formatted/written better, also non-primary sources for things like security measures may be hard to find. but i agree that it should be expanded. 2603:7080:A903:F154:41D3:962E:4162:2579 (talk) 17:46, 8 December 2022 (UTC)

I agree with removal of the Dirty Pipe mention. When mention of Dirty Pipe was first added in Special:diff/1100388586] by

84.250.14.116 (edit | talk | history | protect | delete | links | watch | logs | views)

it said, "In March 2022, GrapheneOS released Android 12L and patches for a security exploit named "Dirty Pipe" for Pixels before Google did." This was a biased, advertising-like statement, making it look like GrapheneOS did something unusually quickly. However, if you read the citation or explanatory note, you see GrapheneOS was "one of many 3rd party ROMs" that did so, which sounds more neutral.

My criteria are Wikipedia guidance on sourcing, Wikipedia:Reliable_sources. If something has not received coverage from reliable secondary sources, then it is probably not encyclopedic. Someone who wants to read GrapheneOS website can do so; we don't need to copy that WP:WPNOTRS primary source material into Wikipedia. I plan to delete more poorly sourced statements. -- Yae4 (talk) 18:46, 8 December 2022 (UTC)

I am neutral about this, but seeing the level of consensus (and with the edits already being made) I'll mark this as resolved. 76.135.154.252 (talk) 05:52, 9 December 2022 (UTC)

Vice Motherboard source on ANOM involvement

Resolved

 – Please see Talk:GrapheneOS#Should_the_ANOM_section_be_removed.

Special:Diff/1102150367 by EndariV removed a citation. Special:Diff/1102151664 restored it. ANOM#Distribution_and_usage cites the same source with different summary. Feel free to discuss how to include and word the summary. Ignoring it is not a reasonable option. -- Yae4 (talk) 16:48, 3 August 2022 (UTC)

Rewritten. Special:Diff/1102210134 Special:Diff/1102206950/1102213400 84.250.14.116 (talk) 23:01, 3 August 2022 (UTC); 23:26, 3 August 2022 (UTC)

I will lastly ask: Should the following be part of the section, or is it {{Editorializing}} because there is no source to support the statement unambiguously? Phones with GrapheneOS or a fork of GrapheneOS may have been involved in the ANOM FBI honeypot sting operation. 84.250.14.116 (talk) 23:45, 3 August 2022 (UTC)

Another rewrite was required in response to Special:Diff/1102224906 by User:Yae4: Special:Diff/1102224906/1102231750. 84.250.14.116 (talk) 01:40, 4 August 2022 (UTC)

And let me say, I don't prefer the second rewrite I authored because it uses closer paraphrasing, which risks running into Wikipedia:Copyright violations issues. 84.250.14.116 (talk) 01:45, 4 August 2022 (UTC)

Rewritten to resolve your concerns about your re-write. -- Yae4 (talk) 06:35, 4 August 2022 (UTC)

I merged it into the main history section and rewrote it partially to add a little more context about what the ANOM sting was. 98.97.36.93 (talk) 07:47, 5 August 2022 (UTC)

I disagree and reverted. -- Yae4 (talk) 16:34, 5 August 2022 (UTC)

There's not much to disagree with, the ANOM sting factually was done through cell phones distributed with an FBI-controlled messaging app. Can you elaborate? 98.97.36.93 (talk) 19:47, 5 August 2022 (UTC)

84.x and I had converged to a mutually acceptable format and presentation, and you changed it entirely, without explanation or consensus. -- Yae4 (talk) 20:21, 5 August 2022 (UTC)

I'm also okay-ish with the current revision 1102582741 text, though both Yae4 and 98.'s revision risks of editorializing sources. 84.250.14.116 (talk) 20:30, 5 August 2022 (UTC)

I would prefer to make a short expansion for a due weight opinion: GrapheneOS developer Daniel Micay denied the claims., or similar. (Copyedit required.) 84.250.14.116 (talk) 22:24, 5 August 2022 (UTC)

Not addressed at all in this big, burdensome copyedit/undo by User:Yae4: Special:Diff/1102771432. This also introduced the same incorrect information to the article for the fourth time about devices in question (Pixel 3a and Pixel 4a said in sources, not 3 or 4), which had been previously corrected three times. By definition, wikt:controversy also means A debate or discussion of opposing opinions, since this moved it from the "History" section to "Controversies" without giving any weight for the opposing opinion. 84.250.14.116 (talk) 23:16, 6 August 2022 (UTC)

You overlook facts such as in Special:Diff/1102771432 it said: "According to Joseph Cox of Vice Motherboard in July 2021, Pixel 3 or Pixel 4 series phones". IMO "series" is more than accurate enough for encyclopedic entries such as this. Actually "Pixel phones" should be sufficient. -- Yae4 (talk) 01:23, 7 August 2022 (UTC)

Sorry to say, the context of what ANOM sting was has been lost in editorial process. 84.250.14.116 (talk) 12:34, 19 August 2022 (UTC)

---

I agree with 76.135.154.252, this paragraph is not a security incident for GrapheneOS, I've read the article and don't see how it should be here. I've reverted. Omilc (talk) 17:48, 3 November 2022 (UTC)

In the source provided it's clear that the developer is speculating the reasoning behind rumors he heard. It is baffling to me to use that as any sort of evidence or source to tie these two systems together, let alone suggest it as an security incident. It seems its been re-re-re-re-reverted by Yae4, and protected as others have reached the same conclusion... 76.135.154.252 (talk) 00:31, 12 November 2022 (UTC)

@Yae4 is reverting disputes from multiple editors and leaving nothing except "Restore more impartial, consensus-based version" dispute multiple people disagreeing. Omilc (talk) 13:17, 14 November 2022 (UTC)

I believe the "consensus" he is referring to is between him and 84.250.14.116, I would be interested to hear 84.x's opinion on this as they have previously mentioned the ambiguity of the source. I could agree with 174.233.17.107's edit (Special:Diff/1120050486) of moving it to history as it's not a security incident. But given how weak the source is on this topic if you actually read it and the amount of people who seem to agree, I still think removal is the better option. 76.135.154.252 (talk) 11:59, 16 November 2022 (UTC)

Wikipedia articles report what independent sources say. If those independent sources had a published consensus that the earth is flat, then Wikipedia would also say so. The press can lie and omit details to drive an agenda and get away with it, Wikipedians don't editorialize their beliefs on the subject into articles to make it right or sound favorable. Trying to change consensus on Wikipedia is often a fool's errand; Wikipedia is not controlled by its editors, it's controlled by the media, and the media controls the narratives to the general public in their cone/sphere of influence (culture and language). You may explore Wikipedia's sister language sites in different languages and find encyclopedic articles with wildly different encyclopedic narratives on the same subject. Likewise, the media doesn't often report on multiple critical vulnerabilities found in Android; the Dirty Pipe exploit is just one example of several critical vulnerabilities disclosed, but because it was reported in independent sources, Wikipedia does too (without weight on other critical vulnerabilities the press didn't pick up on). Hopefully this drives a point forward on what Wikipedia includes (and what it doesn't). Because these opinions were published in an independent source, they may merit some encyclopedic significance, and should be included in the article. Thus, in reply to 76.135.154.252: I disagree with the removal of this text from the article.

On that note about the body text of revision 1120387542 § ANOM sting operation seems like an accurate representation or summarization of the Vice source, without omitting details or reading between lines to come to a different conclusion. I feel like the Vice source is first and foremost about Anom phones with ArcaneOS; secondarily it's about encrypted phones like Encrochat, Phantom Secure, rumors of operating on GrapheneOS and opinions of Micay on what Anom phones are operating on or advertised to have, and this feels like to me to be unambiguous. I feel like the only part where the Vice source could be ambiguous is that Micay's quoted opinions do not explicitly refer the names of these (former three) companies or advertisers specifically. However, I have no no doubt to the authenticity of this Vice source, and the source should stay.

The next question is how the section should be titled. The Vice source cited does not explicitly call the subject matter as an "incident" or "controversy", but I imagine – by Wiktionary definitions – the Vice source to cover a news story about the ANOM incident in general, and a debate or discussion of opinion about their relation to GrapheneOS with Micay, where Micay has been given a voice for an opposing opinion. I support retitling the section as one of the following:

• ANOM incident or ANOM sting operation;
• Controversies; or
• Relations to ANOM, Encrochat and Phantom Secure.

In my opinion these are the most neutral representations for the article. I feel like calling it a "security incident" is a bit far of imagination. 84.250.14.116 (talk) 05:18, 17 November 2022 (UTC)

I can also propose the following paragraph as a replacement, which the editors concerned may find more acceptable or consensus-like:

According to Joseph Cox writing for Vice Motherboard in July 2021, an analysis of an Anom phone (advertised in the ANOM FBI honeypot, sting operation) and an investigation of forum posts online by Motherboard found Anom phones display a boot logo for an operating system named ArcaneOS. Daniel Micay reportedly received photos of a Pixel 3a phone with Anom software, which he shared with Motherboard. Micay reportedly heard claims Anom used GrapheneOS and speculated "it sounds like" Anom may have been advertised to use GrapheneOS, but claimed "it has no basis." Motherboard also reported encrypted phone firms such as EncroChat and Phantom Secure used by organized criminals in the past offered devices similar to an Anom device; in another quote Micay also said, "[it] sounds like people have heard of GrapheneOS so these companies either use it" [GrapheneOS or a fork] "in some way or just claim they did when they didn't."

This removes editorializing and non-evidential statements, while trying to remain impartial to statements represented in the source. This proposal still ties the Anom phones to the FBI operation, and Anom's relation to GrapheneOS. 84.250.14.116 (talk) 06:35, 17 November 2022 (UTC)

Alleged relations to ANOM, Encrochat and Phantom Secure or something along those lines is also fine. 84.250.14.116 (talk) 06:54, 17 November 2022 (UTC)

"Independent, reliable" sources are allowed to editorialize, and that can be summarized in the article, as it has been. Re: Security incident, count how many times "secur" is found in the source. Then the source includes, Micay said. "Quite amusing security theater." I object to any more changes to the section unless truly uninvolved editors say otherwise. -- Yae4 (talk) 12:10, 17 November 2022 (UTC)

If I'm understanding this correctly, you're saying that because "secur" exists in the source that's why this paragraph specifically should be labeled as a security incident for GraphineOS? If that's what we are going by then the "incident" involving Copperhead Limited should be moved from History to Security incidents as the sources use the German word "sicher" a lot. The word secure is inherently tied to GraphineOS as it's security-focused, you would be hard pressed to find an article about it that doesn't include that word. I'm confused how this constitutes a security incident such as the dirty pipe exploit when its obviously closer to an allegation or controversy. 76.135.154.252 (talk) 12:12, 18 November 2022 (UTC)

I've read the Vice article (again), and the source's statement about security theater seem seem to be quotes from Micay aimed at Anom / ArcaneOS' calculator application. I see Vice discusses two things: Security incidents of Anom; and a controversy of (unsubstantial) alleged relations of Anom (and ArcaneOS) to GrapheneOS. These two subjects are distinct. I agree with the opinions of User:Omilc, 76.135.154.252, 174.233.17.107 and 2603:7080:a903:f154::/64 that this is not a GrapheneOS security incident (for this article). 98.97.36.93 kept it in the history section. Also important: Wikipedia is not a collection of unverifiable speculation, rumors, or presumptions. 84.250.14.116 (talk) 23:17, 18 November 2022 (UTC)

Obviously I'm new to editing on Wikipedia, so I appreciate that explanation. If that is how Wikipedia operates, removing that section shouldn't be the right course of action, yet I think it still needs to be improved.

My original gripe with the section was its placement under Security incidents. By retitling, are you suggesting moving it under one of the names proposed? If so, then I very much agree. It could probably be shortened to "Alleged relations to ANOM" as Micay is directly referring to Anom here "Micay said others claimed that Anom used GrapheneOS itself". But as he uses the phrase "these companies" later, is that enough to assume the other two are a part of the claims he heard?

As for rewriting it, your version is easier to read with its greater use of parentheses and brackets. The slight change to some of the sentences makes it more objectively convey what is actually in the source. I didn't take issue with how the original paragraph was written per-se, but looking at it now, this version is an improvement and should be used. 76.135.154.252 (talk) 09:49, 18 November 2022 (UTC)

A note, FYI, the Vice source states The phone offers "PIN scrambling," (like that is special). CopperHeadOS and GrapheneOS since early 2020 include this, [11] (as does LineageOS at some point). Re: "Security" incident, there is no question "Security incident" is a fitting section title, but I don't care if it is changed to just "Incident", and will do so. The proposed modified paragraph changes the introductory summary sentence to just another statement, and lengthens a couple other statements. The first is poor writing - a paragraph should have an intro summary sentence; the second is just fluffy. -- Yae4 (talk) 10:02, 21 November 2022 (UTC)

There's no question that "Security incident" is a fitting title... if you ignore other users opinions. Which, unfortunately, is an ongoing theme here. Changing the main title to "Incidents" doesn't cover all my concerns; as I've said, it's more appropriately labeled as an allegation or controversy as what's provided by the source. The source is effectively saying "I heard people say this, but it has no basis", an allegation or controversy is clearly more fitting. You've jumped the gun and changed it, but we should hear from 84.250.14.116 or Omilc before reaching a decision.

I should also note an outside opinion on the administrator noticeboard suggested it be removed entirely, but that's a separate question.

Really, you should NOT note it here while ongoing, because it could be considered improper Wikipedia:Canvassing. -- Yae4 (talk) 19:04, 22 November 2022 (UTC)

I am directly linking this users edit. If you're suggesting I'm canvassing for the incident itself, that is not my intention. 76.135.154.252 (talk) 23:37, 22 November 2022 (UTC)

Also, I accidentally submitted an edit before finishing the edit summary so I'll explain it to you directly. As the new source you cited is a summary of vice including "according to engadget" is undue as for both sources its according to the vice article. However, that source should be included so I put their citations together. If you disagree with this middle ground please discuss it here so we're not edit warring. 76.135.154.252 (talk) 01:39, 23 November 2022 (UTC)

As said in the edit summary, see Wikipedia:Attribution. We should attribute and cite statements accurately. Restoring, again. -- Yae4 (talk) 01:45, 24 November 2022 (UTC)

Jon Fingas's article is reporting the existence of the Vice article alongside a summary, in text citation for Jon Fingas when Vice's article is the source material is WP:Undue. If numerous articles reported on vice's story, are you to preamble the text with every single outlet and author who mentioned Vice? No, you cite the source of the material being used. Jon Fingas's article is only being used here to show that another publication was interested, and for that a ref note is perfectly acceptable Attribution. 76.135.154.252 (talk) 05:33, 24 November 2022 (UTC)

Do you have a objection to my clarification or should I redo my edit? I'm trying to give you the benefit of the doubt by waiting, but this seems like pretty evident WP:Stonewalling. 76.135.154.252 (talk) 09:59, 3 December 2022 (UTC)

Regarding GrapheneOS involvement, Fingas[12] says Some user said Anom was based on the existing GrapheneOS, but Anom may have lied to buyers about the software to instill a false sense of trust. and does not include the more extensive discussion regarding GrapheneOS involvement as given in Vice Motherboard.[13] Thus Fingas is cited for what it supports - only the paragraph introduction sentence. If Fingas is cited at the end of the paragraph, it implies support for all of the statements, which Fingas does not give. In summary, I repeat: I object to any more changes to the section unless truly uninvolved editors say otherwise. -- Yae4 (talk) 22:39, 5 December 2022 (UTC)

As for the rewrite I don't really care either way, IMO the current paragraph isn't flawed enough to argue over.

CyanogenMod introduced pin scrambling in 2014, and I'm assuming LineageOS would inherit that as it's a fork of CyanogenMod. However, I don't know why this is relevant. 76.135.154.252 (talk) 13:45, 22 November 2022 (UTC)

References

Should the ANOM section be removed

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Resolved

 – Enough input from outside editors has led me to consider this matter resolved, the ANOM section has been removed from the GrapheneOS Wikipedia page.

The section of this page about ANOM has caused alot of controversy, and has had a long discussion which can be hard to follow, So this section is a attempt to resolve this matter.

If you have a opinion on this matter reply to this section of the talk page with it, When replying please state at the beginning or end of your reply if you Support the removal of the ANOM section, Do not support of removal of the ANOM section, or are Netural or otherwise do not wish to vote on this matter, If you have already "voted" on this matter in another reply please state that instead of "re-voting".

I Support the removal of the ANOM section: because i feel it is not relevent enough to GrapheneOS to be on this page. — Preceding unsigned comment added by 2603:7080:A903:F154:6004:A9E1:32DE:8BFD (talk) 19:29, 5 December 2022 (UTC)

• Disagree with deletion: I object to any more changes to the section unless consensus of other uninvolved editors say otherwise. It is inappropriate to discuss deletion when there are now two secondary sources cited. I suggest using WP:RFC to get uninvolved editors' opinions. -- Yae4 (talk) 22:39, 5 December 2022 (UTC)

• (Already voted on this discussion): I have added a Request for comment (WP:RFC), but i feel that should not stop other editors from participating in this discussion. -- 2603:7080:A903:F154:F84D:833:5DBE:C705 (talk) 03:43, 6 December 2022 (UTC)

I Support removal: I fail to see how this is an incident of GrapheneOS. Daniel Micay states that he heard rumors that ANOM used GrapheneOS but that it doesn't seem to be true. There is nothing substantial here; It's a side note even in Vice's own article.

The relevance of Engadget's article is also of ongoing debate, specifically if its current in-text citation is WP:DUE. It's a extremely brief summary of Vice's article, so much so that the primary source is falsely attributed to "some user [of anom]" instead of GrapheneOS's developer Daniel Micay; Perhaps because it's been summarized down to a single sentence. It's sole purpose in this article should be to show that another outlet was interested in Vice's story. As such, I disagree with keeping this section solely on the basis of containing two sources. 76.135.154.252 (talk) 11:40, 6 December 2022 (UTC)

• Remove - The cited connection to ANOM is speculative and this is already a tangential topic for this article. This material can be moved to ANOM if editors there find it relevant. ~Kvng (talk) 22:13, 6 December 2022 (UTC)

• (The user below this comment Already voted on this discussion but is not following the format of the section) — Preceding unsigned comment added by 2603:7080:A903:F154:B992:783B:E850:2A41 (talk) 19:22, 7 December 2022 (UTC)

• The Vice Motherboard source quotes Micay, who is central to this topic, several times. Much of the speculation is his. It is a directly connected topic for this article, and the real or potential connection causes serious concern for GrapheneOS users, which is why GrapheneOS supporters and promoters are pushing so persistently to remove it. -- Yae4 (talk) 01:42, 7 December 2022 (UTC)

• (Already voted on this discussion): Yae4 maybe you should read the Vice article again, Micay commented on ArcaneOS, and also commented on the claims that GrapheneOS was used in some way by ArcaneOS, but Micay himself said "it has no basis",

If you can find proof that in some way at ArcaneOS used GrapheneOS i could see the relevence to this Wikipedia page, but even Micay didnt have proof to support these claims.

I dont see how this is a "serious concern for GrapheneOS users", even if it was this page is not a news website and is not a GrapheneOS communication channel.

(At least to me) This is not some kind of conspiracy against GrapheneOS users/supporters/promoters and is not some kind of coverup about the alledged use of GrapheneOS in ArcaneOS. -- 2603:7080:A903:F154:2427:1B44:F9DC:60A8 (talk) 08:20, 7 December 2022 (UTC)

• (Already voted on this discussion): Micay's interview is only partially mentioned in ANOM at the moment. I agree that moving/expanding it there is another possibility, but the same issues on its speculativeness/relevency may still arise.

76.135.154.252 (talk) 06:47, 7 December 2022 (UTC)

• Remove This has poor relevance to this article, and IMO is non-encyclopedic content; I don't think it belongs here, and don't think it belongs at ANOM either unless better sources exist than just rumors. And contrary to what's said above, an RFC isn't required at all to remove sourced statements. There are many other considerations than WP:V, includng WP:POV and WP:DUE, which editors can an should take into account. DFlhb (talk) 21:04, 7 December 2022 (UTC)

  Thank you for your input, An RFC was requested because otherwise User:Yae4 would likely have reverted removal of the ANOM section, with the claim that it wasnt a "consenus based" decision. At this point i think there is enough input to consider this matter closed. 2603:7080:A903:F154:B992:783B:E850:2A41 (talk) 21:43, 7 December 2022 (UTC)

  I counted outside input from one editor with under 3 months Wiki-experience, and one more experienced editor. This is helpful, but not overwhelming. I feel the article is out of balance with some citations used several times, and now, two citations on one incident completely ignored. This is not closed, but it may need to be taken to other venues for oversight. -- Yae4 (talk) 18:43, 8 December 2022 (UTC)

  under 3 months Wiki-experience hey, don't sell me short! It's exactly 3 months to the day! (And coincidentally, my account itself is 6 years old, also to the day!) DFlhb (talk) 18:54, 8 December 2022 (UTC)

• User:Yae4 If you want to get a Admin involved please be my guest, but Every Single Person except you agrees with removing the ANOM section, also i counted 3 outside editors, User:Kvng, User:DFlhb and User:Rhododendrites.

(Rhododendrites commented in the RFC section, in case you missed that comment). Also your history of discriminating against users because they are a IP-only editor or their account history/age isnt old enough is making me consider reporting you.

(Wikipedia:Assume_good_faith, Wikipedia:Please_do_not_bite_the_newcomers, Wikipedia:IP_editors_are_human_too) and your behavior is borderline (if not already) Wikipedia:Passive_aggression. 2603:7080:A903:F154:DD70:6479:C1AB:85F0 (talk) 20:31, 8 December 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Pixel 3 or Pixel 4 series"

Resolved

 – An older version was restored (Special:Permalink/1105130982), which no longer misleads about the devices in question. 84.250.14.116 (talk) 10:10, 19 August 2022 (UTC)

I disapprove the article's statement "Pixel 3 or Pixel 4 series", while the reference speaks of Pixel 3a and Pixel 4a devices. Although self-referencing Wikipedia is unreliable, they are all the same series (Google Pixel; compare to the previous lineup, Google Nexus). For models, Pixel 4 and Pixel 4 XL were marketed and released at the same time, but Pixel 4a was marketed / first released distinctively a year later. I agree with "Pixel phones" or "Pixel 3a or Pixel 4a phones". To be even more precise, there is no context in source which devices may have been advertised with GrapheneOS with Anom messaging, but it could be fair to assume and say "devices" or "phones" without a specifier. Special:Permalink/1102242945, with its caveats, made no assumptions about the device type or context for statements about GrapheneOS. 84.250.14.116 (talk) 09:32, 7 August 2022 (UTC); edited 12:12, 19 August 2022 (UTC)

Disapprove all you wish. Looks like we agree on "Pixel phones". I disapprove of removing the section entirely, which was recently done. Will be restoring an older version shortly. -- Yae4 (talk) 17:38, 18 August 2022 (UTC)

Based on this Vice Motherboard source, I can only agree "Pixel phones" "Pixel 3a or Pixel 4a phones" were loaded with Anom software. This is aside from reading Micay's opinion Anom may have advertised to use GrapheneOS. I cannot determine from such (possibly non-factual) opinion, without more context, which specific Anom devices (if any) were involved and I should not synthesize those to have been Pixel devices. 84.250.14.116 (talk) 11:52, 19 August 2022 (UTC); edited 12:10, 19 August 2022 (UTC)

Ugh, after many edits, intent-based writing is still difficult. I should disagree with "Pixel phones" and agree "Pixel 3a or Pixel 4a phones" were loaded with Anom software based on this source. My intent is to message the difference between the Google Pixel series and Pixel (1st generation). Anyway, in current revision Special:Permalink/1105130982, this is a non-issue. 84.250.14.116 (talk) 12:07, 19 August 2022 (UTC)

Request for comment - Archived December 2022

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.

A summary of the debate may be found at the bottom of the discussion.

---

Resolved

 – This matter has been resolved, please see Talk:GrapheneOS#Should_the_ANOM_section_be_removed.

The deletion of GrapheneOS#ANOM_sting_operation has been discussed here: Talk:GrapheneOS#Vice_Motherboard_source_on_ANOM_involvement and here: Talk:GrapheneOS#Should_the_ANOM_section_be_removed, But the discussion has gotten complex to follow and has not reached a clear consensus,

Outside editors: it may be a good idea to read the refrences in GrapheneOS#ANOM_sting_operation before the Talk page, in order to have full context of the discussion. 2603:7080:A903:F154:F84D:833:5DBE:C705 (talk) 03:39, 6 December 2022 (UTC)

Shouldn't this be posted on Talk:GrapheneOS#Should_the_ANOM_section_be_removed, as that's where the new discussion is taking place? 76.135.154.252 (talk) 11:42, 6 December 2022 (UTC)

According to WP:RFC#Creating an RfC the Request for comment is supposed to be in a new section of the Talk page. 2603:7080:A903:F154:FC90:F665:F8A5:1215 (talk) 16:20, 6 December 2022 (UTC)

Okay, then should the conversation be moved into this section? I feel like it's slightly confusing to have the conversation in a different section then whats linked on the RFC, as that's not the case for other articles. 76.135.154.252 (talk) 10:18, 7 December 2022 (UTC)

I disagree with moving the conversation, this section is only supposed to be for the RFC,

User:Yae4 for whatever reason is adding comment(s) that belong in Talk:GrapheneOS#Should_the_ANOM_section be_removed, but due to Wikipedia policy i cannot delete, move or edit them. 2603:7080:A903:F154:B992:783B:E850:2A41 (talk) 18:27, 7 December 2022 (UTC)

 Off-topic: A section for the discussion already exists, please avoid futher fragmenting the discussion, And the RFC requester (me) would like to keep this section netural. --

• Oppose deletion. Two independent, secondary citations support inclusion. Additional background: When originally added by me in Special:Diff/1102122284, it was a single sentence, According to Joseph Cox writing for Vice Motherboard in July 2021, Pixel 3 phones with GrapheneOS or a fork of GrapheneOS may have been involved in the ANOM FBI honeypot,sting operation. Another editor wished to expand it significantly, not me. I could support a similar more brief statement like this, instead of the current long paragraph. It would need a minor correction of deleting the "3" after "Pixel". -- Yae4 (talk) 21:57, 6 December 2022 (UTC)

• This is not an area I have expertise in, but I looked at this when it came up at WP:ANI. I support removal of the subsection. There are two sources, neither of which say anything of substance, and nothing conclusive, about this subject. Gizmodo is a single line that literally credits "some user" who made a claim about this subject. The other source, Vice, effectively just quotes Micay to say "they might've pitched it as having GrapheneOS, but that was just because people have heard of it, not because it actually used it". None of the sources actually say GrapheneOS was involved or attribute such a claim to any reliable source, but we have an entire heading for "ANOM sting operation". That is WP:POV/WP:UNDUE. — Rhododendrites ^talk \\ 21:16, 7 December 2022 (UTC)
• Comment: This WP:RFC was closed prematurely, among other problems. "Enough input from outside editors has led me to consider this matter resolved" is invalid. The general problematic behavior issues will have to be taken up in other venues. -- Yae4 (talk) 18:50, 8 December 2022 (UTC)

  I disagree, there was more than enough feedback against keeping the ANOM section, also who put you in charge of deciding whether or not a comment i made was vaild? And as i stated in my comment in the Talk:GrapheneOS#Should_the_ANOM_section_be_removed section of this talk page feel free to get a Admin involved, but i don't think it will work out in your favor. 2603:7080:A903:F154:DD70:6479:C1AB:85F0 (talk) 20:36, 8 December 2022 (UTC)

  I was surprised to see the RFC concluded so quickly, but there was a clear consensus from those outside editors so I don't really take issue with it. Had there been less editors or non-unanimous agreement between them, I would've agreed. 76.135.154.252 (talk) 05:44, 9 December 2022 (UTC)

  While maybe i should have left the RFC open for a little while longer it seemed like the consensus was quite clearly against keeping the ANOM section. 2603:7080:A903:F154:54AA:B9AC:7D66:5B3C (talk) 06:36, 9 December 2022 (UTC)

  FFR, it is not good form to close an RfC that you initiated (or participated in) - see WP:RFCCLOSE. There's no reason for anyone to get WP:POINTY about it now though. ~Kvng (talk) 15:28, 12 December 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.