Talk:GrapheneOS

Archives (Index)

1 2 3 4

This page is archived by ClueBot III.

The following is an archived discussion of the DYK nomination of the article below. Please do not modify this page. Subsequent comments should be made on the appropriate discussion page (such as this nomination's talk page, the article's talk page or Wikipedia talk:Did you know), unless there is consensus to re-open the discussion at this page. No further edits should be made to this page.

The result was: promoted by Yoninah (talk) 11:58, 12 January 2020 (UTC)

(

• Comment or view
• Article history

)

GrapheneOS logo

• ... that GrapheneOS (logo pictured) is a free and open-source operating system for selected Google Pixel smartphones, which was recommended by Edward Snowden? Source: "GrapheneOS is an AOSP (Android Open Source Project)", "GrapheneOS can only be installed on certain smartphones from the Google Pixel range." "There is recognition on Twitter by Edward Snowden : "If I configured a smartphone today, I would use GrapheneOS from Daniel Micay as the basic operating system."" [1]

• Comment: Quotes for the hook are translations from German

Created by Yae4 (talk). Self-nominated at 15:35, 16 December 2019 (UTC).

• Moved to mainspace on 16 December and nominated straight away. Article is long enough, stable, well written and referenced. Earwig's tool doesn't show any problems (many of the key sources are in German, so close paraphrasing is difficult to detect automatically, but a spotcheck shows no problems; AGF on Hungarian/Czech/Turkish sources). Hook is long enough, referenced, and certainly catchy. Image is used in the article, appropriate, and correctly licensed. Article author has no prior DYK noms, so no QPQ is required. In conclusion, good to go. Constantine ✍ 20:14, 24 December 2019 (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". [2]
• In May 2019 it "Android Hardening" was being renamed to GrapheneOS.[3]

• 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)

Keeping fresh updates

Moot

 – 84.250.14.116 (talk) 09:25, 19 August 2022 (UTC)

Hi,

I don't understand why my modification has been canceled. The latest version of GrapheneOS was released the 11/05/2022, not 2 months ago.

I'm doing the modification again, please keep the section updated.

Thanks. — Preceding unsigned comment added by Didyme33 (talk • contribs) 20:29, 22 May 2022 (UTC)

Because the edit also deleted a phrase and tag, without mentioning or justifying in edit summary. -- Yae4 (talk) 16:01, 31 May 2022 (UTC)

Adding, re "please keep the section updated": A problem with articles like this is keeping such minutia details up to date, unless setup to be done automatically. -- Yae4 (talk) 16:17, 31 May 2022 (UTC)

revision 1090257312 reverted

Stale

 – No reliable, independent sources or new information to add. 84.250.14.116 (talk) 11:30, 19 August 2022 (UTC)

I see no reason why this has been reverted.

> delete statement based only on twitter - unreliable source This makes absolutely no sense. The text said the GrapheneOS team announced something and I gave a link to the actual announcement by GrapheneOS, which was on Twitter. How is this not a reliable source for this matter?

Gaussgroessereuler (talk) 16:20, 30 May 2022 (UTC)

See WP:RSPTWITTER and links from there. The referenced tweet is not only for "an uncontroversial self-description", and "Tweets that are not covered by reliable sources are likely to constitute undue weight." -- Yae4 (talk) 16:02, 31 May 2022 (UTC)

It is an uncontroversial self-description, though... The text that the source was used for said that GrapheneOS announced something and the tweet contains the announcement by the official GrapheneOS twitter account. I don't see how that would constitute undue weight. Gaussgroessereuler (talk) 20:21, 2 June 2022 (UTC)

Controversial - Was it accurate? Did it happen as predicted in a "few months" from February 2022 (i.e. May)? Self-description - No, it involves un-named third parties. Undue weight - See WP:UNDUE, and WP:RSUW. -- Yae4 (talk) 10:07, 3 June 2022 (UTC)

​​Following up: Because an apparently reliable source, Android Police covered the same info', it seems marginally OK for inclusion, although the undue weight issue is still a concern. I still feel we should not link Twitter, although some others editing the article would like to, for selected tweets. I will be seeking independent advice. -- Yae4 (talk) 21:44, 22 June 2022 (UTC)

I stand corrected, thanks to 84.x correlating Android Police with Valnet properties at Reliable Sources Noticeboard. Apologies for ever adding statements based only on Android Police sources. Now removed. -- Yae4 (talk) 22:48, 30 June 2022 (UTC)

Whether to include or mention celebrity tweets?

2nd opinion requested

 – More opinions could be desirable for a clearer consensus. 84.250.14.116 (talk) 10:43, 19 August 2022 (UTC)

Finally, as suggested by El_C, I would support removing the statements about Dorsey tweet (and additionally Snowden tweet), as they add little. -- Yae4 (talk) 02:31, 23 June 2022 (UTC)

Maybe it would be more appropriate to address all the low effort endorsements to a single sentence list of celebrity endorsements. "GrapheneOS has been endorsed by Ed Snowden and Jack Dorsey." Perhaps endorsed isn't the right word, but that sort of list of celebrity nods seems common on musician/artist articles. Anonymous526 (talk) 05:48, 23 June 2022 (UTC)

Admin El C said "I'm not sure why that entire paragraph about Jack Dorsey's tweet is even worth mentioning at all, Derek Lee'ing or not. But then again, this is the first time I've heard of this OS."[4] With this advice and WP:RSPTWITTER, it seems appropriate to delete statements about tweets. This is obviously not a "musician/artist" article. I originally added the bit about a Snowden tweet because we were struggling to convince reviewers this article was even notable, in late 2019,[5] and it and a wiki-link[6] might give the article a smidge of a notability push. If you've looked for recent "reliable" source coverage recently, as I have, you know there still isn't much now. Nevertheless, the tweet garbage should be deleted. -- Yae4 (talk) 12:07, 23 June 2022 (UTC)

That was just something that confused me. I'm not actually interested looking into this further, in any capacity, really. El_C 12:48, 23 June 2022 (UTC)

I agree, the Dorsey tweet is pretty pathetic. I've now removed it. Perhaps the Snowden tweet is still needed for its original purpose. Has the OS/article now accrued sufficient notability independent of it? Anonymous526 (talk) 18:53, 23 June 2022 (UTC)

Delete it. It's a poor source. -- Yae4 (talk) 19:21, 23 June 2022 (UTC)

I was inclining to keep the Snowden tweet because of the "Did you know?" this article had, but I'll stay neutral to this opinion so I don't have to express better arguments based on policy. 84.250.14.116 (talk) 20:28, 23 June 2022 (UTC)

I count two IDs saying let's delete tweet-only sources, and one abstaining. Sounds like time to delete the Snowden tweet mention too. -- Yae4 (talk) 19:51, 27 June 2022 (UTC)

WP:RSPTWITTER isn't an issue for the Snowden tweets. The article is not citing the tweet itself directly, but multiple news sources mentioning it. Seems okay for the reception section, unless it's weighting for WP:UNDUE. 84.250.14.116 (talk) 08:39, 28 June 2022 (UTC)

I thought we were near agreement that sources mainly regurgitating tweets would be considered not-usable? Here you favor regurgitating tweets because why? Defend notability, or make GrapheneOS look good/endorsed? Also, what about the 2-1 consensus? Maybe we should request more 3rd party opinions here too. -- Yae4 (talk) 15:13, 28 June 2022 (UTC)

Snowden isn't a primary source, nor are the third-parties quoting Snowden. 84.250.14.116 (talk) 17:30, 28 June 2022 (UTC)

Snowden is a self-published (unreliable, except maybe about himself) source. The third-party sources need to be judged on their merits, considering WP:DUE as well as meaning and intent of WP:RSPTWITTER. Sure, it made a catchy "hook" for DYK, but that time has passed. -- Yae4 (talk) 11:28, 29 June 2022 (UTC)

And the third-party sources aren't self-publications from Snowden. Simple fallacies. 84.250.14.116 (talk) 13:14, 29 June 2022 (UTC)

We can judge how much the cited sources relied only on paraphrasing tweets from Snowden. -- Yae4 (talk) 22:50, 30 June 2022 (UTC)

Snowden tweets

I reviewed the sources (or 2 of 3) more carefully; here are my notes:

• Der Standard: says, "The ex-secret service employee would not leave standard Android on the device, but replace it with Graphene OS."[7] Source Weaknesses: passing mention in article about Snowden. Article is based only on paraphrasing Snowden tweets, so very weak source as a whole.

• la republica, about Snowden says: "The former contractor recommends using GrapheneOS software as the phone's base operating system," (and would do a bunch of other things).[8] Source weaknesses: Same weaknesses as above.

• Futurezone.de: Not Found error page (verification fail), but I am confident it has at least the same source weaknesses as above.[9]

Note: Glancing at Edward Snowden these sources - which are about Edward Snowden - were not found, nor was even mention of GrapheneOS. If weak sources about Snowden are not used there, what does it say about using them here, in an article about GrapheneOS.

Summary: Passing mentions of GrapheneOS in weak sources based on tweets, does not justify giving the tweet any weight. WP:RSPTWITTER says tweets do not carry much weight, WP:DUE, unless covered by reliable sources: these sources are weak paraphrasers of tweets. Also, "Twitter should never be used for third-party claims related to living persons." It also makes the article look like an advertisement. So, the Snowden tweet statement is stretching the intent of a lot of guidance, and it should be removed. -- Yae4 (talk)

Mentions of Snowden also appear in the Golem.de and heise online citations. 84.250.14.116 (talk) 22:20, 30 June 2022 (UTC)

When several factors point to not using it, why are you so determined to use it anyway? The Heise citation is a transcript of "independent" YouTube productions, i.e. non-reliable source. See Reliable Sources Noticeboard discussion, ongoing. If we cite Golem.de much more, we will be including the whole article. It already is cited several times. Can find any non-bio, or better any related "tech" wiki-articles with similar endorsement tweet statements as this article? I tried and failed. -- Yae4 (talk) 22:56, 30 June 2022 (UTC)

• Plan to delete Unless someone provides support for why the Snowden tweet sentence should remain, or improves or better defends the citations, for reasons above, I plan to delete the sentence soon. -- Yae4 (talk) 11:56, 6 July 2022 (UTC)

  There was a WP:3O request on this, but no volunteer responded. 84.250.14.116 (talk) 22:26, 21 July 2022 (UTC)

Delete redundant repetitions of security and privacy in lead

Resolved

 – Special:Diff/1094619241, Special:Diff/1095466917. 84.250.14.116 (talk) 14:53, 28 June 2022 (UTC)

In the second sentence, "It is focused on privacy and security," is repetition of "security-hardened, privacy focused," in the first sentence. I suggest deleting the second, and attaching "and is compatible..." to the first sentence. -- Yae4 (talk) 16:49, 23 June 2022 (UTC)

 Done 84.250.14.116 (talk) 16:53, 23 June 2022 (UTC)

Thanks. "for selected smartphones, and is compatible with several Google Pixel smartphones." is odd, and should be changed to just ",and is compatible with several Google Pixel smartphones". Sorry I didn't catch that sooner. -- Yae4 (talk) 17:17, 23 June 2022 (UTC)

I agree it's awkward right now, but there may be a small distinction between what it's aimed for and what it's compatible (or officially supported) with. So not done for now. I couldn't think of a better way to say it. 84.250.14.116 (talk) 17:48, 23 June 2022 (UTC)

It should be changed. I still favor what I suggested. Also, I believe somewhere guidance says the lead does not need sources, and the lead material should have been included already in the body. -- Yae4 (talk) 10:53, 24 June 2022 (UTC)

Adding: See MOS:CITELEAD -- Yae4 (talk) 11:52, 24 June 2022 (UTC)

Yes, but because of this, the second request was not so easy to change, it takes more time to analyze the citations that are there and what they say about the jargon of definitions and support of Google Pixel devices. So not done for now. That's what I was trying to say when I couldn't think of a better way to say it. If you'd like to change this before your partial block is over, please propose the exact text to be replaced, what it's going to be replaced with, and what to do with the citations in more detail. Wikipedia:Edit requests style. It may take multiple steps. 84.250.14.116 (talk) 12:05, 24 June 2022 (UTC)

Thanks for the offer, but I'm in no hurry, so let's go the easier route and wait a few days. -- Yae4 (talk) 20:06, 27 June 2022 (UTC)

Citation by Huff at Android Police repeats and references a citation by Hazarika at XDA

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.

---

Special:Diff/1094410995 added the following (see the diff for attribution, parts of reference improvements were by me):

In March 2022, [...] GrapheneOS applications Secure Camera and Secure PDF Viewer were released to the Google Play Store.

The latter citation by Huff says: As first noted by XDA, linking to the citation from Hazarika, hardly adding any new critical analysis of its own. I don't think this recycling of news is needed, I'd remove the Huff citation. — Preceding unsigned comment added by 84.250.14.116 (talk) 12:32, 24 June 2022 (UTC)

(1) Current version as modified by you "GrapheneOS applications Secure Camera and Secure PDF Viewer were released to the Google Play Store." is misleading and inaccurate summary of the source, because play store is not the only place they were released, as the XDA source you prefer[10] says: "For any app developers that read this, they are open source, so you can..." and includes link to github. This is why my version (you linked to diff above) says "GrapheneOS applications Secure Camera and Secure PDF were released, including at Google Play Store." This is a more correct summary of the source (and the true facts).

(2) By deleting the Huff source[11] you make it appear less attention was given by "independent" sources to the announcements of the apps, which risks criticism under WP:DUE. Personally, I doubt whether the 2 apps merit any mention in this article. Let's be honest, both XDA and androidPolice are heavily advert-infested sites; they publish whatever announcements they think their readers may look at; they are basically parroting what Micay tweeted or self-published about the apps - See the "Source" links to two tweets at the bottom of the XDA source. Neither source shows any signs of "critical review" or real independent thought, not that it's a criteria for wikipedia. -- Yae4 (talk) 19:46, 27 June 2022 (UTC)

For the record, the wording was changed by another user there: Special:Diff/1094647324. Because the latter source is no longer referenced, I'm inclined to keep the current revision as is, or agree with you to remove the paragraph. 84.250.14.116 (talk) 08:48, 28 June 2022 (UTC)

The XDA links leans on WP:SYNTHESIS for released on GitHub, however if a compromise must be made then I would use the Android Police reference for avoidance of doubt, keep your original wording (revert Special:Diff/1094647324), and remove the XDA reference. 84.250.14.116 (talk) 08:59, 28 June 2022 (UTC)

Independent, secondary, reliable sources are allowed to synthesize information. It is wikipedia editors who are not supposed to. -- Yae4 (talk) 15:13, 28 June 2022 (UTC)

Exactly, and the XDA reference does not explicitly say they are released on GitHub. XDA says it's "open source" while linking to repositories (which we also do from the infobox in general). Huff says it's open source and the code is available on GitHub. Say "made available" instead of "released", to be so pedantic. 84.250.14.116 (talk) 17:34, 28 June 2022 (UTC)

The meaning of the source is plain as day to me (plus consistent with the facts as I know them, not that that carries any weight at wikipedia). This twisting of meanings does make AGF difficult. -- Yae4 (talk) 11:41, 29 June 2022 (UTC)

References

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.

Proprietary firmware, statement in Infobox?

Stale

 – The consensus seems to be between no consensus and "open source". The article moved on from "Open source with proprietary firmware" to "Open source" for source model, which is supported by multiple sources in the article. No reliable, independent and unambiguous sources have been brought up in this discussion to support the former "proprietary firmware" statement. 84.250.14.116 (talk) 11:36, 19 August 2022 (UTC)

Has anyone found sources to support the proprietary components (firmware) statement in the infobox? It's been there for a long time without a supporting reference (since at least December 2021). If I had to take an educated guess, it may be something to do with baseband radio firmware and Android bootloader (Aboot), but so far the sources cited have only supported the statement of "open source" source model. 84.250.14.116 (talk) 11:54, 21 July 2022 (UTC)

I understand it to refer to proprietary firmware blobs that must be included for some hardware components to function. It appears inconsistently in ROM articles, but Replicant_(operating_system) correctly says only "open source" as their goal is to entirely remove all proprietary blobs. Other articles the same phrase "Open source with proprietary components" is used include Resurrection_Remix_OS, LineageOS, and OmniROM. "Source model" could also be interpreted to include whether the ROM supports adding proprietary apps or not, as some, like GrapheneOS do, and others like Replicant do not. Template:Infobox_OS says, "Source model of the operating system." Thus, "Open source with proprietary components" is correct for GrapheneOS. -- Yae4 (talk) 17:24, 21 July 2022 (UTC)

Though I seem to agree what you said about the ROM articles and Replicant in general, no original research. The statements must be verifiable. I'm also fine with leaving the citation tag there for longer if needed. 84.250.14.116 (talk) 19:32, 21 July 2022 (UTC)

Template:Infobox OS/doc actually says development methodology. Leaning on synthesis here, but I've understood from the sources available in the article and GrapheneOS FAQ the project development model of GrapheneOS is described as "open-source", but firmware (security updates) is reliant on OEMs like Google. Google doesn't develop GrapheneOS (they develop Android), so I'm a bit more inclined to call it just "open-source" and stick to sources. 84.250.14.116 (talk) 21:06, 21 July 2022 (UTC)

I've not found indication GrapheneOS builds their own hardware / firmware (yet). 84.250.14.116 (talk) 21:08, 21 July 2022 (UTC)

It's not really WP:OR. It's almost common knowledge, or should be. Wikipedia is unreliable, but see Android_(operating_system)#Licensing, search for "proprietary components", "blob" or "firmware" and look for sources if you wish. This is a basic Android thing, with only one exception AFAIK. Why are you asking, really? This has all appearances of continually trying to make GrapheneOS appear less "proprietary" and more "open source" in this article than they really are or behave. -- Yae4 (talk) 21:18, 21 July 2022 (UTC)

I'm not opposed to making a distinction where the development model differs between "open source" and "proprietary". It's a matter of question which entities follow which development model, and if the proprietary firmware development is related to GrapheneOS (this article subject) at all. Right now the infobox could be understood as GrapheneOS developing their own proprietary firmware, but I can't verify. The purpose is to clarify; perhaps {{Clarify}} would've also been appropriate or more appropriate, to improve verifiability. 84.250.14.116 (talk) 21:32, 21 July 2022 (UTC)

For GrapheneOS specifically: I'm not sure if there are actually relevant proprietary firmware blobs. The Pixel line of phones has fully open source kernel drivers and is a reason for why it's so widely supported among custom Android distributions. Other projects like LineageOS deal with a far wider range of phones, many of which do have proprietary drivers.

The LTE/baseband/SoC code is a closed-source blob. But this is closed-source in the same way that CPU microcode on typical computers is closed: it's a low level component that fully open source operating systems have to interact with, that doesn't affect their being open. (You wouldn't consider Arch partially closed-source, for example).

I think the question is, if binary blobs are

- not distributed with the project

- not a part of the GrapheneOS codebase

- but still necessary for the project to work

Is the project fully open source? I would say yes.

I'll also call back over to the Android article: their "Source Model" tag in the sidebar says "Open source (most devices includes proprietary versions of the OS with proprietary components, such as Google Play)". GrapheneOS's OS is open source (being an open fork of AOSP) and it doesn't contain proprietary components (Google Play must be downloaded manually if desired). 75.172.38.252 (talk) 21:25, 24 July 2022 (UTC)

Almost ignoring the github (and twitter) posts by Micay asking or demanding other projects to not use their sources, those low level components necessary to make the devices work do make those things less than FOSS, and less than "open" source. Re the aside on Arch_Linux, FSF does not list Arch, although they list Hyperbola and Parabola, based on Arch[12]. Even unreliable wikipedia says "the default Arch Linux kernel contains nonfree proprietary blobs, hence the distribution is not endorsed by the GNU project." As I understand it, these issues are what distinguishes Replicant and makes it fully open, unlike most others. Finally, GrapheneOS adding features to help install proprietary apps, and use play services, makes the project far less than fully "open source" in my opinion. -- Yae4 (talk) 07:47, 25 July 2022 (UTC)

Arch's nonfree blobs statement is referenced and verifiable in that article. 84.250.14.116 (talk) 09:32, 25 July 2022 (UTC)

I haven't seen any sources backing up your claims of demands by the GrapheneOS project for other projects to not use their sources. However, asking other projects to not use their sources would be fine and not affect open source status as they can use them anyway. I could see valid reasons for this attitude from the developers if the GrapheneOS source code contains many device-specific or project-specific tweaks, but I'll note again that that does not affect nor put an asterisk on the project being open source.

Re. Arch Linux again, I brought it up because Wikipedia lists it as "Open Source" without any qualifications. The Free Software Foundation considers Hyperbola and Parabola (and not Arch) "free software" which is a distinct and much more loaded term than "open source". If we agree that Arch Linux falls into the same category of openness as GrapheneOS, then we should remove the "proprietary components (firmware)" label (and as I previously mentioned, it is unsourced and misleading: components implies things distributed with the project, like kernel drivers, which are all open source).

> GrapheneOS adding features to help install proprietary apps, and use play services, makes the project far less than fully "open source" in my opinion.

This is definitely wrong. Open-source's requirement lies within the code, not what the code does. Would you consider a web browser to be "less than open source" because it provides access to websites running obfuscated and nonfree JavaScript?

Yae4, please give a read through the section of the below article for the difference between free software and open source software, I believe you're conflating the two.

https://en.wikipedia.org/wiki/Free_and_open-source_software#Overview 71.212.97.112 (talk) 07:48, 27 July 2022 (UTC)

Yae4, I do not think you understand how open source software works. Under your wrapped definition of what an "open source operating system" is, you would have to add the "proprietary components (firmware)" label to almost every relevant operating systems out there, including Red Hat Enterprise Linux, all variants of Fedora Linux, all variants of Ubuntu and the vast majority of its derivatives, all variants of openSUSE and the vast majority of its derivatives, Arch Linux and the vast majority of its alternatives, and so on. In fact, you would need to add it to every single Linux distribution that's not using the Linux-libre kernel, since the Linux kernel itself contains blobs. Even then, operating systems like ReplicantOS or /e/OS require proprietary firmware to function. Just because they do not ship firmware updates doesn't mean the proprietary firmware isn't there. It gets to the point where the label no longer means anything, because it doesn't make any sense.

Next, let's have a look at your "help install proprietary apps" claim. As IP user 84.250.14.116 said, it does not matter what the code does, what matters is what the code actually is. GrapheneOS's codebase is entirely open source. Just because it gives the user the freedom to install whatever they want (including proprietary packages) does not make it not so. Are you going to make the claim that every Linux distribution which allows users to install proprietary packages from its repository not fully open source? Are you going to claim that Flatpak (especially with its defacto FlatHub repository) and AppImages are not fully open source, just because of they give the user the freedom to install proprietary software? This is total non-sense.

Finally, you mentioned Micay's tweets. It doesn't matter what his wishes are. What matters here is the licenses that he uses, which are Apache, MIT, GPLv2, and various open source licenses. Your code doesn't magically become proprietary if you express your wish that certain people don't use it when it is licensed under GPLv2.

Please, let Wikipedia be the place for objective information, and not your personal blog expressing your opinion. LennartMcKenzie (talk) 07:47, 29 July 2022 (UTC)

I see your links, and suggest you WP:5P1, WP:5P2, and WP:NPOV, particularly the "nutshell: Articles must not take sides, but should explain the sides, fairly and without editorial bias. This applies to both what you say and how you say it." Sides and context here include both the letter of the Copyrights and Licenses, and the other-than-open statements of the project leader. It is difficult to summarize "GrapheneOS" in terms of a one category "source model", but all sides of the characterization should be included, somewhere, with due weight. Zero weight (as is now) to the post-2019 controversies over licensing is too low, even if, so far, the only sources are primary. Much other information has been added to the article based only on primary sources. Due weight is due weight in all relevant topics. I am OK with explanatory notes, or a whole section on Controversies, but zero mention is insufficient. -- Yae4 (talk) 16:17, 30 July 2022 (UTC)

This is the problem with what you are doing. You are taking a side and attempting to impose your bias to a factual page.

Just because you do not like the lead developer doesn't mean that you can magically change what the License their code actually use and who owns the Copyright to what.

Let's apply the Neutral point of view here: If you think that every operating system that require proprietary firmware to function (practically all major relevant operating systems) should have the label "with proprietary firmware", then you should add it to almost every single operating systems artcile out there. Not doing so but only doing it to GrapheneOS is being biased and taking sides.

The same thing goes with licensing: If the developer express their opinion that certain people do not use their open source code warrants you calling it "less than open source", then you should also give that label to every single piece of software licensed under restrictive licenses like GPLv3. That license is a VERY restrictive license, prohibiting the use of that piece of software in any project (open source or not) that do not use the same license. People who write software under the Apache, MIT, or BSD licenses cannot use GPLv3 code at all. https://www.gnu.org/licenses/rms-why-gplv3.en.html Does that make GPLv3 sftware not open source? Likewise, Bromie being GPLv3 cannot use Vanadium code because it is GPLv2, does that make Vanadium/GrapheneOS any less than open source?

Your logic does not make sense and y ou should really look past your bias and be neutral here. LennartMcKenzie (talk) 00:05, 31 July 2022 (UTC)

Red_herring and Straw_man illogic doesn't help. Repeated lies about me or my feelings are just personal attacks per WP:NOPA. As for fixing all the other articles, don't worry, 84.250.14.116 has seen some light and is on the job.[13] -- Yae4 (talk) 02:09, 31 July 2022 (UTC)

So are accusing others of your own sins at this point. You are quite literally violating the rules about neutrality while accusing others of it. LennartMcKenzie (talk) 02:15, 31 July 2022 (UTC)

You are&* LennartMcKenzie (talk) 02:16, 31 July 2022 (UTC)

That said, the documented/primary-sourced requests by GrapheneOS for other projects to NOT USE THEIR SOURCES, should be at least noted in this article. -- Yae4 (talk) 17:26, 21 July 2022 (UTC)

Relevance (or irrelevance) aside, the statement had no apparent effect on the source model or firmware. 84.250.14.116 (talk) 21:49, 21 July 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

"As of" in past tense

Resolved

 – The statement was restored to "As of March 2022", and the citations have been replaced. 84.250.14.116 (talk) 09:37, 19 August 2022 (UTC)

I believe Special:Diff/1100306954 changed the "As of" year to 2019 and then to past tense; formerly it was 2019 in current tense, with reliably sourced information (while 2022 information was unreliably referenced). Template:As of/doc#Usage guidelines suggests it is used only in cases where an article is intended to provide the most current information available and should not be used for historical information that will not change. 84.250.14.116 (talk) 09:41, 25 July 2022 (UTC)

Statements sourced to 2019 articles should be attributed to the author and dates. It is not "history that won't change". One reason is if you dig into the releases, you will find mentions of "other devices". Thus, the real history is one thing, and the advertised history is another. Therefore, attribute and "as of" the old 2019-based statements. -- Yae4 (talk) 16:13, 30 July 2022 (UTC)

Importance

Disregard

 – There are no more "importance" inline tags in the Features section, and the features list was rewritten as prose. Editors are encouraged to further demonstrate encyclopedic significance for statements in the features section. 84.250.14.116 (talk) 09:41, 19 August 2022 (UTC)

There are lots of "importance" superscripts in this article. The answer to every single one of those is that the item in question demonstrates the security and privacy of GrapheneOS over Android, just as the text before that list indicates. These can be expanded if that is deemed necessary. (I don't disagree with the stated "low importance" of this article as a whole. GrapheneOS aspires to be as relevant an Android ~fork as say OpenBSD is a relevant NetBSD fork.) Adam KatzΔ☎ 19:17, 28 July 2022 (UTC)

I would like to read more about their significance from independent, reliable sources, so that the features list is not an indiscriminate collection of information (or accidentally a feature list of the Android Open Source Project). 84.250.14.116 (talk) 22:11, 29 July 2022 (UTC)

One example about MAC randomization: Does it really demonstrate any security or privacy improvements (for a non-technical reader)? In my opinion, no. A threat model is not described or contextualized. Discussion at #Android MAC randomization can improve it. The few others tagged with "importance" I've already removed. 84.250.14.116 (talk) 21:02, 1 August 2022 (UTC)

Vice Motherboard source on ANOM involvement

Being worked on: Renewed discussion with more opinions. 84.250.14.116 (talk) 06:03, 17 November 2022 (UTC)

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)

References

"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)

Revisiting Android Police's reliability

I'd like to revisit the discussion of Android Police's reliability after finding it used as a citation across a number of articles: Android (operating system), Android 10, Android 11, Android 12, Google Pixel, Smartphone, Google.

It seems - I wasn't here for this discussion, and I may be missing some context - that Android Police was decided to be binned after finding that Valnet, which owns some sources considered to be unreliable, also owns Android Police. I do not see why the owning publisher should be used primarily as a basis for reliability.

Furthermore, searching through the Reliable Sources noticeboard for other Valnet properties: I see that ScreenRant is broadly considered to be reliable, MakeUseOf is considered marginally reliable (with minimal discussion, however), and Comic Book Resources is considered unreliable. The reliability of these sources seems to me independent of the publisher: and so as that seems to have been the basis of Android Police's removal, and noticing the presence of Android Police citations in other, high-quality articles: I would like to discuss its reliability once again (and maybe get some more opinions than from just the three of us).

And Yae4: I would appreciate it if you leaned towards peer review and removing problematic citations rather than bulk-removing any large changes. I find that behavior unwelcome. 98.97.36.93 (talk) 19:26, 5 August 2022 (UTC)

My opinions: Articles by Alessandro Mascellino at Android Police are not independent, in my opinion. Those should be treated the same as Valnet Inc's other publication MakeUseOf (advertising / promotional / sponsored), as they add no critical evaluation or history on its own but rehearse a primary source (the official website), from what I've seen.

My RFC-like rating at Wikipedia:Reliable sources/Noticeboard would be option 2: unclear or additional considerations apply (marginally reliable) for the independent news articles from Android Police for uncontroversial statements. It is a borderline group blog (as hinted by Mascellino's posts). The site has fact checking, corrections and ethics policies and the authors are not anonymous. Android Police aclaims Valnet has no influence on the opinions of editors.

Android Police gets occassionally cited in other reliable publications, such as WP:RSP#CNET and WP:RSP#Ars Technica for two examples (there may be more).

You may be interested to start a new discussion at WP:RSN. 84.250.14.116 (talk) 20:06, 5 August 2022 (UTC)

If I had to clarify my opinion, then option 1 or 2 for independent news sources at Android Police, option 2/3 for the rest. 84.250.14.116 (talk) 20:20, 5 August 2022 (UTC)

Mascellino at Android Police parrots PR from GrapheneOS like a fan. It's a terrible source to start with, and the cites here are among the worse examples. So it seems we agree - it certainly does not deserve a full paragraph of non-critical advertising, particularly when the cite does say something about pixel 4 and higher versus lower having lesser support. -- Yae4 (talk) 17:39, 18 August 2022 (UTC)

See WP:CYCLE. As stated on your Talk page(s?) your edits appear primarily promotional to me, and will likely continue being undone as long as it continues. -- Yae4 (talk) 20:25, 5 August 2022 (UTC)

References

Hackaday sources self-published Doug Leith report

Resolved

 – This citation and its inappropriate use has been removed. 84.250.14.116 (talk) 09:15, 19 August 2022 (UTC)

This Hackaday source refers heavily to a self-published Leith, academic, study report, which caused The Register to publish a "correction". See more here: Talk:/e/_(operating_system)#Oct._2021_Study_paper_is_self-published? Thus, this Hackaday source quality is in doubt. I haven't looked deeply, but would not be surprised if it republishes without credit other articles like The Guardian's. I won't say I haven't also cited Hackaday, but looking at this now, it has appearances of a group blog (unreliable), and I did not quickly find any evidence of editorial policy etc. Regardless, it is cited for "A sensors permission toggle for apps" which is nowhere mentioned, and therefore a bogus citation.

-- Yae4 (talk) 11:57, 6 August 2022 (UTC) Yae4 (talk) 11:57, 6 August 2022 (UTC)

The sensors thing was my indirect suggestion in the #Peer review section, which another editor then implemented, however it is inappropriately cited in revision 1102467857 (for the wrong thing); the source speaks of disabling of peripherals via toggles. 84.250.14.116 (talk) 23:25, 6 August 2022 (UTC)

References

Features list selection criteria wording

Disregard

 – The section was rewritten to prose. Special:Diff/1104837594 84.250.14.116 (talk) 09:04, 19 August 2022 (UTC)

Please propose how to include or word the selection criteria for the features list. "includes the following features" is not okay, because the section should not invite editors to turn it into an indiscriminate collection of information. WP:LSC. 84.250.14.116 (talk) 22:29, 6 August 2022 (UTC)

includes a number of security and privacy focused changes compared to standard Android distributions is also not okay, unless it is demonstrated in the article with encyclopedic information (preferably in prose). 84.250.14.116 (talk) 22:33, 6 August 2022 (UTC)

Notes need to be in English

Resolved

 – 84.250.14.116 (talk) 00:20, 9 August 2022 (UTC)

While it's fine for references to be in another language, it's the nature of things, the notes that are manually added need to be in English as they're explanatory for readers of this article. Notes in German need to be deleted or translated. Canterbury Tail talk 16:01, 8 August 2022 (UTC)

WP:LONGQUOTE says Long quotations may be hidden in the reference as a WP:FOOTNOTE to facilitate verification by other editors without sacrificing readability., however I've now removed those footnotes (they were clearly marked as German-language text and quotes). The alternative would be to input the same CS1 reference multiple times with different |quote= values. 84.250.14.116 (talk) 00:20, 9 August 2022 (UTC)

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)

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)

Noting Sockpuppet and off-wiki canvassing investigation and threats of reports

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)

For possible future reference: Sockpuppet and off-wiki canvassing investigation[14] involving a recent editor [15] of this article, Xaeonx7. Also noting response to warning, and threat to "report you".[16] 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.[17] -- Yae4 (talk) 19:31, 16 November 2022 (UTC)