🆕 Software Suggestion | GrapheneOS #832
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#832
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Basic Information
Name: GrapheneOS
Category: Mobile Operating Systems
URL: https://grapheneos.org/
Source code: https://github.com/GrapheneOS
Description
GrapheneOS comes from Daniel Micay, the former lead developer of another security-based Android fork called CopperheadOS. Daniel Micay says that “[The] project develop[s] privacy and security improvements for Android and other operating systems.”
GrapheneOS is a full-fledged operating system with a security-hardened memory allocator, patches for the Chromium web browser, and an Auditor app that “uses hardware-based security features to validate the identify of a device along with he authenticity and integrity of the operating system.”
An interesting project, in particular the remote-attestation thing is potentially EXTREMELY valuable against most forms of software-based-attacks: even if the badguys rootkit Bob's device, Alice figures it out before she sends the clubhouse passphrase to poor pwn'd Bob which means Eve does not benefit.
Eve can still make an attack, but it has to be a physical-world attack, not an over-the-internet attack: maybe Eve installs a spycam or a hardware keylogger to observe Bob's activities in the analog realm where GrapheneOS has no powers, or maybe Eve just confiscates Bob and his device and then xkcd 538's the unlock PIN, either of which will fool remote-attestation (and unless Alice is extremely resistant to social engineering will also very likely fool Alice at least some of the time).
Caveats: codebase is not fully libre (edit: correction, per comments below, the GrapheneOS codebase was fully funded in September 2018, however, some of the tightly-related apps such as the Auditor are still under source-available non-libre licenses -- pending retroactive funding which is expected to arrive in the future), and monetization model aka bizplan remains unclear (edit: clarification, the sponsors involved remain unclear -- aka the people actually providing money to move the project forwards), but there is going to be one (so there is risk it will be The Wrong Plan which is what happened last time). Edit: the project itself is intended to be retroactively-sponsored codebase that has no internal monetization and no internal biz-plan, the money is going to come from to-be-determined sponsoring-organizations which have their own goals / models / missions, might be hardware vendors and might be charitable entities and might be various other types of businesses, details still pending.
In particular there has been handwaving about 'someday we will manufacture our own hardened handsets' which is extremely worrisome to my jaded ears: rate of failure in the secure handset manufacturing niche is >99% of all past attempts. Just handwaving so far, (edit: correction, Micay says the project has been contacted by a major handset manufacturer that is potentially interested) and hey, maybe they will prove me wrong and hardened $99 grapheneHandsets will be on sale at consumer-electronics retailers worldwide in a few years. Edit: clarification, there has been no pricing for any future potential handset-manufacture announced, and no price-targets either. My point stands though: either the handset will be an expensive niche project, and average endusers won't be able to buy GrapheneOS handsets in their local retailers, or it will beat incredible odds to become a wild success, and a few years from now I will happily be proven wrong. Which would absolutely thrill me, just, I think it is about as probable to happen, as Zuckerberg giving a big speech about how "facebook takes your privacy seriously" but then not issuing the 'minor' typo-correction the next day ("our apologies the comma between the words seriously and privacy was omitted")
Crypto and infosec vetting is extremely low -- mostly rests on Micay's reputation rather than on independent analysis and field-usage. Hardware support is extremely weak, with not much plan to expand: buy a Pixel v
21+ or go away, basically. See the plan above to custom manufacture even bettererer handsets, this is very much a niche OS aimed at ultra-high-security endusers willing to buy expensive hard-to-configure devices (edit: apparently GrapheneOS is really easy to install?) for themselves and everybody they contact so as to benefit from the remote-attestation magic and other codebases tightly related to GrapheneOS: SeamlessUpdate / HardenedMalloc / et cetera / etc. To be crystal clear, since apparently this seemingly-straighforward point is 100% impossible to understand otherwise: GrapheneOS is a good pick for securing an individual device compared to the average stock smartphone in the wild -- if you like the reputation of the folks contributing, which is strong, though as far as I'm aware only Micay is named. But to install at all, you need special hardware or willingness to hand-compile and self-harden, and to get maximum benefit from all the intertwined projects in the same repo as GrapheneOS, so do all your contacts.Like the SilentCircle project, methinks GrapheneOS might be WorthMentioning, but should not be in the 'recommended for most endusers' top3 rankings methinks. Similar project to grapheneOS, but concentrating more on privacy than on security, is the https://e.foundation by Gael Duval of Mandrake/Mandriva fame (but forks Lineage rather than AOSP and is aimed more at everyday endusers "in the long run"). All of these are "🧙🧙🧙" tools that require level-three wizardry to mess with, versus something like LineageOS which requires 🧙🧙 because of a larger user-community and a large amount of supported devices and so on. Debian is something like 🧙 or maybe one-and-a-half wizards, most people can use it though they might need a bit of help installing it.
I agree with most of what @five-c-d said. I don’t think their supporting only Pixel 2 and up devices is a big deal because they are the most secure Android headsets, and they have good reasoning. Everything else though I think is a potential issue: I personally would like to see it audited, I would like to see their business plans, and I would like to see people actually using it before adding it to the site.
I’m not sure if an /e/ issue has been opened on this repo yet, and I just haven’t seen it at the time of writing this comment (I’m on mobile), but if it hasn’t I’d love to see that discussed in another thread, I’ve heard a lot about that recently.
/e/ does not meet the requirements of PTIO and uses proprietary software (Telegram), which cannot be removed (currently). Gael Duval does not answer the question why Telegram is implemented in the firmware and who finances the project.
Is there a list of these? My understanding was that it was unwritten/collaborative
Many of the services offered in the VPN listings presumably use proprietary software server-side, and I know for certain that several of the webmail-offerings are at least partially proprietary codebases. See question above, about where the requirements are written down, because if that is on the list then I've got some removal-requests to write :-) But I suspect you just mean YOU do not like proprietary software personally, rather than that proprietary server-side software is a dealbreaker for privacyToolsIO listings?
Wrenching the discussion back on-topic, I will also note again that some of the GrapheneOS codebase is/was non-libre-licensed until September 2018 and some of the tightly-inter-related apps such as the Auditor remain source-available as of April 2019. Micay has sufficient reputation that he is confident releasing the
binary-onlysource-available portions, and promising to MIT-license the corresponding codebase once 'donations sufficient to cover the cost of developing that code' are received, if I understand the situation correctly. (Edit: see comments below, apparently I did not understand that the codebase is made source-available, a meaningful improvement on the way the process works.) Which is a bit of a strange way to run things, not sure I've ever heard of libre-licensed-once-the-bills-are-paid kind ofbusinessfunding model :-)Pretty sure it is not a violation of the spirit of the open source ecosystem, though I would consider it a pretty clear violation (edit: see below, source is available) of the free-as-in-freedom model unless the promises were contractually inescapable and with a fixed absolute YYYY-MM-DD deadline for libre-licensing -- codebase held in trust by a proxy competent to judge it was the source, the whole source, and nothing but the source -- rather that just say-so-on-the-interwebz. (Edit: the source-availability somewhat mitigates this difficulty from a practical perspective... in a situation where the promise was not kept, e.g. because of the hit-by-a-bus factor or some similar unforeseen problem, endusers would have the code... the copyright would not give them freedom to redistribute still, legally speaking, but they would HAVE the promised code. Recommend adding a specific clause into the last will and testament, plus also a "license canary" to the primary website, such that if the developer(s) with copyright control are unable due to incapacitation or ill health to fulfill the promise, that the failure of the digitally-signed "license canary" to be updated after N years automagically releases the corresponding codebase(s) under the MIT License at the end of year N, unless released prior to then by the developer, or unless the developer updates the value of N manually prior to year N with a valid digital signature. This would permit long-term efforts to work on a codebase whilst seeking retroactive sponsorship to fund the work, but would give the four freedoms out legally, should untimely demise or incapacitation occur, since the license-canary would no longer be receiving updates. The developer would need to memorize a passphrase used to protect the private key associated with their digital signature, but that is a sufficiently small promise -- especially if the "license canary" makes clear that the named developer must personally perform any alterations of the value of N, not their heirs or assigns, and that the digisig is just for integrity-purposes and not legally binding.)
There are plenty of libre-licensed consulting biz-models that work in a vaguely similar fashion, but with "corporate client pays for the work up-front and at the end of the 3-month contract the source-code is contractually guaranteed to be libre-licensed" sort of thing, with NDA's used in the interim. Micay's approach is somewhat like that, except the client is retroactively located and the work is done up-front "on spec" in a sense.
There is at least one person I'm pretty sure is actually using GrapheneOS, who I happen to be acquainted with. The name GrapheneOS is very new, but the codebase is older: it was previously called AndroidHardening and previously-previously
calledhosted at the related SeamlessUpdateDotApp. Before the political troubles that led to the split, Micay was developer at CopperheadOS, and that effort in turn was based on his libre-licensed efforts prior to CopperheadOS. Dunno how many people have installed some-variant-of-Graphene, at this point, but it is non-zero.The official subreddit has ~300 people as subscribers, https://www.reddit.com/r/GrapheneOS , whatever that is worth. Probably most of those folks just follow the discussion, but surely some of them have flashed the ROMs :-) The main LineageOS subreddit has 135x as many subscribers, so extrapolating from that heuristic there could be even in the low thousands of GrapheneOS users? I expect it is more likely in the low hundreds however.
@zaidoon1
Please note that you're taking information from an article with various errors and misquotes.
This is a misquote completely reversing the meaning of the quoted statement.
Here is what I actually stated in context:
https://www.reddit.com/r/Android/comments/b8fhiv/grapheneos_the_true_of_successor_of_copperheados/ejxoooy/
This is the sentence being misquoted:
The URL of the GrapheneOS project is https://grapheneos.org/. You're giving the URL of the update service, going along with the Updater app. I tried to make it clear that the releases being listed at https://seamlessupdate.app/ was entirely temporary but it was misinterpreted as being the GrapheneOS site or something tied to the name of the project.
@five-c-d
That's not true. GrapheneOS is fully licensed as an open source project
The Auditor app is not yet permissively licensed but that's a completely standalone project hosted here, and primarily focused on verifying the stock OS across various devices:
https://attestation.app/about
It supports GrapheneOS and will also support CalyxOS in the near future. As I've made clear, it will be permissively licensed once the work is funded. If you want that, you're free to fund the work that has gone into it. My work on GrapheneOS is already funded, and other developers being funded as well. It isn't a hobby project with occasional work going into it as free time allows.
That's not true and this has been clearly explained on many occasions. You're making another false claim.
That's not true, and in fact it has been clearly stated on many occasions that there will be no business model as it's not a business but rather a non-profit open source project. It will be supported by businesses and other organizations allocating resources and developers to it based on their own goals and business models / charitable missions. The project is entirely independent from any current and future sponsors though, and will continue one way or another regardless of their support.
There has been no handwaving about this and certainly none of the nonsense claims you are making about a $99 price point or availability directly through mainstream retailers internationally. You're being incredibly disingenuous and hostile for no apparent reason. It's something that is being actively pursued and there are both current and potential partners interested in making this happen. There has been interest from major mobile device manufacturers who reached out and contacted the project.
There are other people reviewing the code and other developers collaborating with the project. Their suggestions have been extremely valuable. Some of the components are used by other open source projects, and the OS as a whole is the foundation for other products at multiple companies and organizations supporting the project as a shared base. You're inventing false claims without actually knowing what you're talking about, simply based on your uninformed assumptions.
This is not true either. It currently supports the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL with official production releases and provides device-specific hardening for them. It has source level support for other devices, but not device-specific hardening or official builds. That doesn't mean it isn't compatible with them and can't be built for them. It's also completely untrue that there is not much plan to expand. It has been clearly stated on many occasions that the intention is to expand hardware support to other devices meeting the standards. Hardware, firmware and device-specific software has a huge impact on privacy and security. It cannot support devices unable to install an alternative OS and it makes no sense for the project to support devices where full security updates are not possible due to lack of support. That already narrows it down a lot, and it also needs to stick to devices supporting the standard hardware-based security features for other operating systems, which narrows it down far more. That still leaves a broader set of devices as potential targets than Pixels and it has been clearly stated that the intention is to choose compelling devices among those to properly support. It takes a lot of work to do proper device support with full functionality, production releases that are properly tested and with substantial device-specific hardening.
Broad hardware support is not a strength for this kind of project. It would be harmful to offer releases for devices not meeting basic security standards or without full functionality and proper testing for each release. The core developers need to own each of the supported devices and test each release across every single one of them, along with developing the device-specific hardening work across them. A substantial portion of the project will be that device-specific hardening work tied to firmware, drivers, etc. It's a mix of research and engineering work, including collaboration with upstream projects and manufacturers / vendors.
There's no reason it can't support cheaper devices, and there is nothing hard to configure about them. It's also completely nonsense to claim that the only reason for the existence of the project is remote attestation, or that it determines the hardware support. The Auditor app is a standalone project that's distinct from GrapheneOS: https://attestation.app/about. There is far more to hardware, firmware and device-specific software (including drivers and a lot more) security than the attestation implementation. That's a complete misrepresentation of the reasoning behind choosing hardware targets to officially support which involves a lot of work and resources invested into hardening and testing for the devices.
It's not at all a similar project. GrapheneOS is a privacy and security hardening project developing privacy and security improvements / technologies, and they are not doing that. It has very little overlap. It's definitely not more privacy focused either. GrapheneOS is focused on both privacy and security. Privacy builds on top of the security and requires that the security model is kept intact and that devices receive full security updates. Security updates include privacy fixes and are also required to prevent trivially bypassing privacy protections.
I'm also not sure how you get the idea that it's aimed at more everyday end users. GrapheneOS doesn't intend to target a niche and isn't aimed at technical users. In fact, it's far less interested in catering to power users and far more interested in preserving the standard privacy and security model that power users often consider an annoyance.
I'm also not sure why you think basing it on LineageOS is a good idea when it has substantial security issues and major long-term issues of being dishonest with their users when it comes to privacy and security including lying about the security patch level (https://source.android.com/security/bulletin) to deceive users into thinking they're receiving full security updates.
It's easier to install than LineageOS and I'm not sure what size of the community or number of supported devices has to do with ease of use, especially when LineageOS is quite broken and incredibly insecure across the majority of those devices. It makes it harder to use it robustly and securely when you only get snapshots of the development branch without proper testing and tons of functionality is broken across devices. It's not production quality software. It also doesn't meet basic standards of security for builds, signing and updates along with breaking a lot of the standard security model and presenting a false security patch level. Many of those security fixes are direct fixes for privacy issues, and most of the rest are required to have privacy by keeping the device from being compromised locally or remotely.
This makes even less sense and I'm unsure how it's even related. It's far easier to install than that.
@five-c-d
This is completely false. GrapheneOS is already licensed as an open source project. You're confusing GrapheneOS with the Auditor app (https://attestation.app/about) and developers certainly often require that funding is provided in order to release the project under an open source license. I'm also not talking about donations but rather the work being funded, which is not a donation, but rather is payment provided for development work in exchange for the code under the desired license. Most developers working on core infrastructure projects like the Linux kernel are paid to do so and only a small portion are volunteers. There are extremely few people doing full-time open source work without funding. Very few people are in a position where they can do that.
I don't know how you think it's a violation of the spirit of the open source ecosystem for open source developers to be paid for their work. That's a disgustingly unethical and entitled opinion. I also have no clue why you think contracts, something being held by a proxy or deadlines are relevant. The Auditor app will be open sourced immediately as soon as the funding for it is provided. It makes no sense to demand that the code is held by a proxy. It's on GitHub already: https://github.com/GrapheneOS/Auditor. You're falsely claiming that the code is not published and you're also misconstruing it as part of the GrapheneOS code.
It's not my preferred approach to do work without funding and then seek funding for providing source code licensing. It wasn't my plan to spend 8 years of my life barely earning income due to choosing to work on open source projects and rejecting / ignoring many lucrative job offers.
I'm asking for funding to release the Auditor app under a permissive license like GrapheneOS. Funding to do that for the next generation hardened malloc implementation and the rest of GrapheneOS was provided in September 2018:
https://twitter.com/danielmicay/status/1047539079653408768
The model was successful for starting up the GrapheneOS project without needing to seek funding before doing lots of the work and proving it to be valuable through the merit of the work. I'm sure it will also be successful for the Auditor app, but there has been a lot more interest in the OS hardening work. I think the remote attestation work on Auditor and AttestationServer is very compelling and incredibly important / useful, but most people don't get it, which makes it far harder to get the work funded. There is no way that I could have gotten it funded without writing it first. I expect that I still need to put a lot more effort into improving it before people start to understand the usefulness and actually become interested in funding it.
It's also not at all something strange or abnormal to seek funding for releasing a project under a permissive license. The only thing you might find abnormal is the fact that I've been posting the Auditor app code for review / auditing all along before putting it under an open source license permitting derivatives and redistribution. I took the same approach for GrapheneOS and as you can see it was successfully funded in September 2018 and released under permissive licenses in October 2018. You are falsely claiming otherwise as if it didn't happen. It happened many months before it became GrapheneOS when it was known as the AndroidHardening project.
The previous subreddit is https://www.reddit.com/r/CopperheadOS, and it still belongs to the original project rather than to Copperhead. My previous account is still the moderator of it and it's about GrapheneOS since it's the continuation of the original project. The new subreddit was only recently created and most of the people following it on Reddit haven't moved over to it. I can't currently do a more forceful migration because my old Reddit account is still suspended for a bogus reason, which is also why I took so long to make a new subreddit because I didn't want to fragment the community.
my apologizes for the misquote. It has now been corrected.
I have corrected the link. Thanks again.
@five-c-d Please stop spreading misinformation about GrapheneOS and misrepresenting the statements / positions of the project. You're misinforming people and you should correct or retract the false claims that you're made here and perhaps elsewhere. If you don't, it will become more clear that you are just acting dishonestly and unethically.
I find it particularly interesting that you are slandering the project and myself in an attempt to promote /e/ here (which is not comparable and is not a project that's doing the same kind of privacy / security research and engineering work to improve privacy), especially since you have an issue open about including it:
https://github.com/privacytoolsIO/privacytools.io/issues/864
I don't particularly care what is listed here, and it's not me requesting that GrapheneOS be listed. I would certainly never spread dishonest attacks on other projects and misrepresent the statements of their developers to try to fight against their inclusion here. That would be incredibly unethical and shameful behavior.
It's pretty clear that you are just trying to promote something else by attacking others that are doing actual work to improve privacy and security rather than just jumping on the bandwagon to promote products doing nothing of the sort. That's a very scummy approach to take especially when you're still using and benefiting from from substantial amounts of my work that I've landed upstream. I guess that goes hand in hand with believing in exploiting people for free labour and not making it possible for them to earn a livable wage from their work.
It doesn't reflect well on whatever it is that you're trying to promote with this behavior.
I shouldn't be put in a situation where people point me towards something that they have read like this, and then need to spend my time correcting the false claims that have misled and confused them. I don't think it's unreasonable to expect better than this.
@zaidoon1 Thanks, I know you were just basing it on that article but it had some accuracy issues and their misquote is super annoying since it totally changed the meaning of my words.
@thestinger I'm actually in favor of your project, and think it is worth listing here, but I've never used Copperhead (when you were there or subsequently), and I don't own a Pixel so there is basically zero chance I'm able to work on GrapheneOS myself.
Am perfectly happy to correct anything that needs correcting, but the person being hostile here is you. The internet is full of misinformation, and people commenting on things they don't fully understand. If you feel this is unreasonable, and wish that nobody would comment on a project they did not personally investigate for dozens of hours, then I sympathize.
But that is not reality. Please live in the now, and once you've invented the perfect internet where only 100% well-informed things are said, let me know. I'd heard some good things about GrapheneOS from a person on the internet that I'm friends with. I did an hour of "work" browsing your website. I pointed out, for the benefit of the project-maintainers of the privacyToolsIO listings, the results of my quick peek: GrapheneOS requires specialized hardware, GrapheneOS is not ready for gramma nor for ten-year-olds, the funding-model is unclear, and although the primary developer is somewhat famous there has been a lot of churn over the last year (which is problematic for privacyToolsIO listing-stability).
No, I'm reporting what I think about the project, and saying that it looks promising but there are a lot of questions. Everything I said about you was complimentary: that you are a respected name, that you have done good work in the past, that the remote-attestation work you are doing now is extremely interesting. You seem to have completely misinterpreted everything. Whether this bodes well for the long-term success of GrapheneOS, kinda depends on whether this incident is a one-off.
the point of privacyToolsIO is to compare OSes to each other
I don't promote /e/ and for exactly the same reasons as with GrapheneOS, I don't use it either (also due to hardware support). I heard about both projects because -- like Copperhead -- /e/ formerly-or-maybe-currently uses a version of signalapp baked into the ROM infrastructure, and I have a list of "related projects" that I worked up. One of the project maintainers of privacyToolsIO asked me to open a discussion about /e/ ...and therefore I opened one. That is the purpose of this privacyToolsIO github: to discuss which things (browsers/OSes/webmail/VPNs/etc) should be listed at www.privacytools.io -- and in what position/ordering.
You can disagree that your GrapheneOS project -- which is a custom ROM for android devices which concentrates on security+privacy and is intended to be a not for profit libre-licensed operation -- is in the same universe as the /e/ foundation project. But they are also, a custom ROM for android devices which concentrates on privacy+security and is intended to be a not for profit libre-licensed operation, so as far as privacyToolsIO listings go, that puts you and Duval in exactly the same category: mobile OSes that might be WorthMentioning here, https://www.privacytools.io/operating-systems/#mobile_os SilentCircle by Phil Zimmerman is in the same boat, but is a commercial only-source-available project.
It is literally impossible to install GrapheneOS on anything except Pixel-hardware. Most people don't own pixel-hardware, especially everyday endusers: non-tech-savvy adults, the elderly, teenagers that don't care about technology, et cetera.
This is not a question of whether, on devices that are supported, the UI/UX of the GrapheneOS installer is user-friendly, compared to the UI/UX of LineageOS. This is a question of whether installation is possible such that an everyday enduser -- some normal teenager or some typical grandfather or whatever -- can do it all by themselves without assistance from a tech-savvy person. Almost anybody who owns a smartphone can install FirefoxFocus and signalapp, because they are supported on most every smartphone, and because they are designed with everyday endusers in mind. GrapheneOS is simply not yet at the point where the same can be said.
Debian, like GrapheneOS, is an operating system. Debian, like GrapheneOS, takes special effort to install -- but once installed, can be used by an everyday enduser. The difficulty of installing Debian is related to complexity of getting a nice easy-to-use laptop operational; nowadays a fair percentage of everyday endusers can perform the install all by themselves, though often they at least want some tech-savvy linux wizard available before they have the courage to try. The difficulty of installing GrapheneOS is lack of hardware support: you cannot install unless you purchase specialized hardware, unless you already happen to own it for whatever reason.
audits? endorsements? public statements?
Has the codebase of GrapheneOS ... as well as the codebase of the related projects such as the auditor app and the seamlessUpdate project and so on ... undergone a security audit, by an independent third party?
What are their names, please, those that are willing to disclose? I know your name and reputation, which is a good start, since you have a good reputation for technical prowess. But until and unless other people put their name and reputation on the line, and say "I have looked at GrapheneOS and it is solid" then it is still just one person. This is the same yardstick I use for any crypto, and for any intended-to-be-secure codebase: what people have audited the code, and recommended it explicitly, and are they people that know their stuff?
That you have made the codebase available, is an excellent first step -- and for folks that are capable of doing the audit themselves, means GrapheneOS is "immediately" usable (after they do an internal audit). But for everyday folks are not capable of that, so as a proxy, they depend on the reputations for competence of the folks which did audit / endorse / etc.
the bizplan(s) still do exist, but belong to the *sponsors*
The direction that the project goes in, will thus at least partially depend on which major manufacturer decides to standardize on pre-installed GrapheneOS, and on which organizations decide to provide developers and/or funding. As you say: "based on their own goals / models / missions" which will exert influence on what direction GrapheneOS moves, and how quickly. It is good of you to promise that the project will continue with or without funding, and completely independent of the sponsors, but this is hard to make stick in practice because as the old saying goes, money talks.
As a somewhat separate matter -- but often tightly intertwined with sponsorship-dollars and also with the length/quality of security-patching (see below) -- manufacturing handsets is an incredibly capital-intensive and risky sector, compared to the software industry.
what is the funding-model for security-patches?
For devices in the wild, I consider the most important thing to be the duration of support for security-patches, and my friend who uses GrapheneOS says that one of the strengths is that security-patches are kept up-to-date, unlike e.g. Samsung which ends over-the-air upgrades to their handsets after 3.5 years roughly, last time I looked. But is the plan for security-patches, whether backported from AOSP or independently created, to fund them in the same way as the seamlessUpdate and Auditor app and so on: the patches are created, and the source is made available, but until the specific security-patch is funded by sponsor-money, the code for that specific security-patch is not released under a libre-license?
What about for security-patches which are GPLv2 because they are linux-kernel-related, are those just going to be inherited from upstream? or is GrapheneOS or a related project in the same orbit, potentially going to be working on patches like that? If so, what would provide the funding of such work, since license-incompability would (unless I'm mistaken) prevent release of source-available patches... there is an attempt still in the court system to release GPLv2 patches which have a contractual clause that stops redistribution: https://en.wikipedia.org/wiki/Grsecurity#Speculations_on_GPLv2_violation_and_copyright_infringement but I don't expect GrapheneOS is doing that type of thing. The question is though, what is the plan for kernel-level security-patches? Does it depend on what specific hardware-manufacturer backs GrapheneOS-handsets, or...?
what is the stability-level / production-readiness level?
Is there a public count of how many devices "in the wild" (as opposed to android emulators and other testing-and-development installs) are currently running GrapheneOS, available? Is grapheneOS still in alpha/beta, or is it officially v1.0 and ready for production use as a daily-driver handset?
This is mostly a question of is-the-product-ready-for-normal-endusers that are not comfy hand-compiling anything and expect their GrapheneOS-install on their device to JustWork(TM) ... it is unrelated to broad hardware support of lots of handsets, and indeed, is presumably weighted based on the number of supported hardware handsets that are in the wild. Is there a guesstimate as to, if GrapheneOS is running on N.NN% of the pixel 2 devices in the wild, or M.MM% of the pixel 3 devices in the wild? These would give a better idea of how widely-deployed the code is, more than a raw count.
Yes, I mistakenly assumed you were NOT posting source-available code, since that is definitely not the usual approach. It was just a mistake though, you are over-reacting like I have personally insulted you; that is not the intent. Although you say it is not strange, to do things the way you are doing them, I've never seen any other projects which do it thataway. Perhaps this is just my lack of exposure to such projects -- what other ones work thataway? To me, that newness is a good thing: you invented something innovative, and it seems like a promising approach, very cool. But as with anything new, there are risks that the new process won't be sustainable, or will have unforeseen problems (e.g. see my above worry about license-incompatibility with security-patches... mayhap you have solved that already but again I would like to see this rationale/logic).
That said, there are a lot of projects which operate on a model where they provide GPLv3 code in public, but then require payment ("retroactive sponsorship") should a proprietary software project wish to dual-license the same codebase under a different licensing-model. What you are doing with GrapheneOS and the related-but-standalone-projects, is quite similar in practice but distinct in the details: you publish fully-copyrighted code in public, for security purposes, and then release permissively-licensed proprietary-codebase-compatible version thereof, once retroactive sponsorship arrives. Different, but could work well.
It doesn't fundamentally require Pixels at all. I don't know where you get that idea. As stated by the project, they're the initial devices chosen for official support based on their hardware security and support for alternative operating systems. Many devices supporting unlocking the bootloader don't have support for locking it with another OS and enabling verified boot, along with missing other hardware security features that are available for the stock OS. Simply limiting the choice to devices where full security updates are even possible already rules out most devices.
The choice for the initial set of officially supported devices doesn't mean that it does not already support other devices at a source level or that it cannot support them. That's far from the case. It can already be built and run for other devices and simply doesn't have official support and releases for them or ongoing work on device-specific research, hardening and testing.
Yet what you've done is spreading further misinformation and you haven't actually corrected the false claims. It's very clear that your intent is to spread harmful lies about the project, and that you're willing to spin and misrepresent everything that you can to achieve that.
I don't know what you could have been browsing other than https://github.com/GrapheneOS, https://reddit.com/r/GrapheneOS and https://twitter.com/GrapheneOS. The false claims you've made are not based on anything present there, especially the clear attempt to misrepresent / spin statements from the project into completely different things.
Yet you claim that an OS with only developer snapshots, serious security issues and lack of stability / robustness is ready. Okay... and you also falsely claim that it isn't aimed at regular people or non-technical users when it is less catered towards technical users. You're happy to recommend a project substantially rolling back the security of the OS for the sake of ease of modding by power users, when they could have still done that modding in a security preserving way without these serious regressions. There's a gap between what you're claiming is the reasoning behind your opinions and your actual opinions.
It isn't though.
You're stating many things that are objectively false. I expect you to correct the false claims and stop continuing to make them.
Hardly.
I didn't misinterpret anything. I clearly quoted where you were making false claims. You have a chance to correct it and demonstrate that you aren't being intentionally dishonest. You failed to accurate correct all of the false claims and added even more misleading / false information. It's a joke.
Nice, more of your disparagement of the project / myself and attacks on whether it's viable.
It has production releases. It's certainly far more stable / robust and tested than LineageOS if you really want to compare it to an Android modding project breaking the security model and lacking real releases / testing for them.
It doesn't contain analytics so the only way to measure installs is based on the number of devices checking for updates. The rate is approximately once every 4 hours when devices are connected to the internet but users have control over which kinds of connections it uses to check for updates. If many of them configure it to only check on non-metered networks and often aren't connected to Wi-Fi, the numbers are going to be warped based on that, among other things. There is no uniquely identifying information in those update checks so there is no accurate way to track number of installs.
It's also not possible to count users on alternate builds that aren't using the GrapheneOS update server, including companies with their own builds, which is what many of them are doing, so they can make other changes that they want and aren't bound by the choices in the upstream GrapheneOS.
GrapheneOS is open source. The Auditor app is not GrapheneOS. It's a standalone app primarily focused on verifying the stock OS on a broad range of devices: https://attestation.app/about. Every single device that has had valid attestation samples submitting is supported so every possible device people wanted to be supported is now supported, other than one which had a broken attestation / keystore implementation. GrapheneOS support is something added on alongside the stock OS support and it wasn't present until March. It was only set up for verifying the stock OS before that.
You keep making false and misleading claims, along with trying to spin things as negative and different than the actual reality. I am not overreacting. I expect you to stop doing it, and if not I expect the repository owners to bring an end to it. You've continued doing it.
This is just concern trolling. It's not about GrapheneOS but rather the standalone Auditor app project and whatever this claim is about license incompatibility is totally bogus, even in the past (before October 2018) when this applied to GrapheneOS itself. AOSP is licensed under permissive licenses, not copyleft licenses, other than a few things like the kernel, and obviously the changes made to the kernel were GPL2-compatible from the start rather than being approached like the other changes.
You are being incredibly disingenuous / misleading to trick people into thinking this applies to GrapheneOS and you're trying to invent problems so that you can criticize it. I have no idea what the relevance is to this thread, because the issue is not about listing the Auditor app. It may make sense to list the Auditor app, but I would not expect that to be done before it's MIT licensed as planned if open source licensing is part of the decision making for listing projects. Again, it's not what the issue is about, and it would only be useful to people using the stock OS or an alternative OS that preserves the security model including verified boot and the clear separation / privilege boundaries between the base OS and third party code. CalyxOS is also going to be supported by the Auditor app. It cannot support an OS disabling or breaking verified boot or the security model that it depends on, so it fundamentally cannot support anything based on LineageOS even if they start properly signing their releases.
Again, despite your misrepresentations, this does not apply to GrapheneOS, only the Auditor app. Stop these false claims about GrapheneOS. I already corrected it and yet you are still brazenly lying about it. It's clear concern trolling and FUD. It's incredibly dishonest and unethical as I previously stated. I should not have to come here and correct harmful lies being spread about the project.
There are also many projects requiring funding (including after the initial code is written) for release under open source licenses. The only thing that's different in this case is that the Auditor app has sources available for auditing / review rather than only being released as an apk. Again, this is about the Auditor app, and the issue is not about listing the Auditor app here, but rather GrapheneOS, which currently doesn't even bundle the Auditor app.
If you want to talk about the Auditor app, make another thread about listing it, because this issue is not about that and you're being incredibly misleading with how you're talking about it here and tricking people into thinking it applies to GrapheneOS with your intentionally ambiguous / vague wording about it.
Since you want to make this thread about the Auditor app, here is the list of supported devices for verification:
That includes every single device that has had valid attestation samples submitted with the app by the users. If someone wants another device supported, all they have to do is install the app, use 'Submit sample data' in the menu and wait patiently for the next release. Of course, they have to be using a device with the necessary hardware support and it needs to be running the stock OS with the bootloader locked, or an alternative OS with verified boot support, the relevant security model intact and the bootloader locked. In general, alternative OSes don't preserve enough of the security model and don't support verified boot (LineageOS) so the only one it can currently support is GrapheneOS. However, CalyxOS will also be supported in the near future, and maybe even on the Xiaomi Mi A2 in addition to Pixels, depending on whether it turns out to have fully working verified boot / attestation support for alternative OSes. I don't think they have fully figured that out yet.
I've received hundreds of sample submissions from Pixels alone, which is not really useful, but shows that a lot of people did install the app and try it out. There is no motivation to submit a sample from an already supported device so I doubt that most users are doing that. It isn't currently bundled with GrapheneOS, so anyone using it on GrapheneOS installed it from the GitHub releases page on their own. It's a standalone project and is not a core part of GrapheneOS, or even part of it at all as an OS rather than a project right now. It will be bundled in the future, but bundling apps hasn't been done yet.
It's not like https://github.com/GrapheneOS/hardened_malloc which is both a standalone project available for other operating systems and also a core part of GrapheneOS. The Auditor app is entirely separate from the OS work. It has no integration / changes going along with it in the OS. It's just an app, no more specifically tied to the OS than something like F-Droid (which is not yet bundled either). Not every repository in the GrapheneOS GitHub organization is part of GrapheneOS as an OS. It replaced the AndroidHardening organization as the umbrella organization for assorted mobile privacy and security work.
Anyway, I don't think that belongs in this thread, but since you want to mix them together, that is the officially supported device list, not only Pixels. It supports every single Android 7+ device for the Auditor side of the verification. The supported device list is only for the Auditee side, i.e. the device being verified.
aside: there is a section for android-addons, yes
This is actually somewhat of an open question, i.e. what the decision-making process consists of, exactly. Right now there is no written-in-stone set of requirements. But there are pretty strong unwritten requirements that the code needs to be available, and that the project preferably-but-not-necessarily is ready for immediate use by normal everyday humans that are currently stuck on win10 + chrome + facebook + gmail. Actual decision-making is discretionary though, and done entirely by the six listed project-maintainers, usually after internal teamchat; the github-issues (such as the one we are in right this second) are mostly used as a place for discussion and for recommendations from enthusiasts. See https://github.com/privacytoolsIO/privacytools.io/issues/780#issuecomment-473632400 and the OP thereof.
To me, the auditor app is possibly worth listing alongside OrBot and Blokada and friends == https://www.privacytools.io/classic/#aaddons ... but since the plan is to bundle it with GrapheneOS, someday, it is helpful to have it here in this thread, as well. There are not strong rules about what thread is used for what purpose, here in this github anyways, although there is some individual effort to remain on-topic. You and I have a mostly-synthetic disagreement about whether the licensing-model and repo-location and security-patches of the Auditor app and the core codebase of GrapheneOS, differ... and thus, whether it is "on topic" here in the GrapheneOS thread, or belongs in another thread.
Feel free to open a new issue, I don't think there is any written-or-unwritten prohibition against project-maintainers starting Discussion-topics. Or if you like, I can start the thread, I primarily appreciate the remote-attestation portions of the GrapheneOS-and-surrounding-projects aspects, so I can legitimately say it is worth consideration. Just don't flip out if you dislike my wording-choices related to "retroactive-sponsorship business model" versus "completely non-profit funding model" and also "part of GrapheneOS-fka-AndroidHardening-fka-CopperheadOSprecursor" versus "completely separate and distinct app which just so happens to share the same repo and is intended to be bundled with GrapheneOS releases someday in the future". To me those are semantics, whereas to you they are crucial distinctions worth going to the mat over. "I don't see what you hope to gain by trying to inflict harm on someone that doesn't even disagree with you" seems to be the relevant quote here. Such is life, on the internet, I suppose.
(edit) There is also a section for browsers, are there plans to make the Vanadium rebuild of Chromium-browser available as an APK separate from GrapheneOS, that runs on stock android handsets? https://github.com/GrapheneOS/chromium_patches has some commits about rebranding to that name, it looks like
No, this is your misunderstanding. I don't think LineageOS and /e/ and UbuntuTouch are ready for everyday endusers either. I'm not recommending /e/ because it isn't at v1.0 yet, and thus, the issue I opened up for it was "Discussion" as distinct from "Software Suggestion". But more broadly, to me the mobile OS listings right now (LineageOS + UbuntuTouch + etc), are out of joint with the rest of the privacyToolsIO listings, which tend to have at least one option that doesn't require purchase of specialized hardware and/or ability to utilize TWRP, let alone hand-compiling. Don't confuse my opinions with the opinions of the project-owners, aka people with commit-access.
et cetera: pixel-only, hand-built, install-proxy-count, diff-suggestion
My actual opinion, if you care, is that there should be some listings in the mobile OS category that are well-chosen handsets that are capable of running stock android, albeit with tweaks... giving a modicum of privacy through the removal of apps and the toggling of settings and such... but can also, ideally, be upgraded to run LineageOS+microG or GrapheneOS or Auditor-as-the-auditee or /e/ or UbuntuTouch various other types of projects which are currently listed (or under suggestion-or-discussion-or-about-to-be-under-discussion status). And yes, I'm aware you don't think any of those mobile OSes hold a candle to GrapheneOS on the security-front, and you also think they are weaker on the privacy-front ... but to me those are very distinct considerations, and should not be conflated.
Typically this would include e.g. the Samsung S5 handset, which has a removable battery and reasonably active LineageOS klte support-base including 16.x -- though I suspect, has not been receiving over-the-air firmware-updates since summer 2017 or thereabouts. Those come with Knox v2.6 class of hardware, and I believe SecureFolder still functions thereon. Most of the android-app listings of privacyToolsIO would function on such a handset, and if it was using Yalp+FDroid rather than playStore, arguably would boost privacy significantly over the 'average handset of the average enduser' aka AHOTAE in the wild today, despite the lack of firmware-upgrades.
The same line of thinking would lead to including the S9+ handset specifically the SM-G965F, Knox v3.2.1 base, with active star2lte support-base, and firmware-updates are likely to continue until sometime in 2021 if past trends continue to hold. Even with stock ROMs, those would be valid privacy-upgrades (once tweaked) versus AHOTAE. Unlike the S5, this particular S9+ would also be auditee-compatible out of the box, an added advantage.
Obviously, the project-maintainers don't yet agree with my actual opinion, because they would have already been doing what I say, in the listings, if they did agree :-)
Again: you misunderstand. My point is very simple. Everyday people do not own Pixels, and GrapheneOS only runs on Pixels right now, officially. Eventually that may change: possibly a large number of people will someday own hardware that officially supports (or is officially supported by) GrapheneOS, or possibly more devices will get official GrapheneOS support. That is not the case right now though, and privacyToolsIO listings are intended to be useful/usable right now, today -- ideally by regular people. Hence my disagreement with the project-owners about whether most of the entries in the mobile-OSes category, are aimed at the same readership as the rest of the listings, in other categories.
Wrong, see above: not my recommendation, I don't have commit-access here. Don't confuse my opinions with the opinions of the project-owners with commit-access.
Wrong, see above. My opinions are my own.
Sure, I know that, but that is the situation right now: pixel-only, and until recently, pixel 2+ only. When more devices are officially supported, that will be nice. But as you state, you are only ever planning to support devices like those, where long-term security-patches and low-level hardening are possible. Today, you support six pixel-series devices, officially. Earlier, it was four pixel-series devices, officially. The future will bring what the future brings. If a device that I own happens to be supported, I might try GrapheneOS out.
Sure, but my understanding is that privacyToolsIO listings do not target a readership that hand-compiles. If enough support -- userbase and especially support forums and helpdocs and the like -- ever arises for unofficial GrapheneOS, that won't hurt the chances of being listed. (You expressed dismay earlier that size of the userbase had any relationship to ease-of-use, but it is very simple: large userbase means lots of help potentially available, tiny userbase means the opposite.) There are cases where community-built flavours of a project are linked to, if a major platform is officially-unsupported by the main top-level project: Keka7zip for OSX is mentioned with PeaZip, because OSX support by PeaZip is still in beta.
Same deal: TorBrowser links to downstream ports to a few alternative OSes as well. Plus of course, LineageOS is almost by definition unofficial, but because of XDA and the large active userbase, it is the top-listed mobile OS right now. If the open pull request for GrapheneOS is merged, you will be in good company, though you may not necessarily like that other mobile OSes are also considered to be mobile OSes, and thus listed next to your project. That cannot be helped, unless you convince the project-owners here to delist all other mobile OSes, and solely promote the one you consider to be the most secure. As noted above, my opinion is to keep listing what is there, and also list some recommended device-models that run stock ROMs, with tweak-lists to give a modicum of privacy and an upgrade-path later.
Is there a list of which devices have community-supported pre-built downloads of unofficial GrapheneOS, plus related software from the same github repo, that receive regular updates/maintenance from the downstream community-project-owners? Preferably with approximated daily-userbase-counts like https://stats.lineage.org offers
Yes, that was my question, whether there is a ballpark rough number that is publicized. I understand this undercounts hand-compilation and people that configure their handset to only update when on wifi and/or when on a charger, etc.
But the number of update-checks tends to roughly correlate with the size of the userbase, and would be very roughly comparable to the info published by LineageOS, link above. GrapheneOS would have a higher undercount if the number of hand-compiled endusers is higher, but for the purposes of privacyToolsIO, the "just regular folks" lower-floor userbase size as indicated by the daily count of auto-update-requests, is more relevant
Be specific which things need changing. In the following format to minimize talking past each other, if you would be so kind as to think of yourself as making pull-requests with commit-messages, that will assist the clarity of our back-n-forth.
yYYz"Or don't, and go back to working on the projects, rather than being unhappy about what somebody said on the internet, about their opinion about your various projects: past ones, current ones, and the future thereof.
I re-read all of what you wrote, looking for a place where a factual correction was needed, and didn't find any -- just yet-another-misunderstanding, which I've clarified. You seem to believe that if you ASSERT everything I ever wrote is misinformation, and that if ANYTHING but direct quotes from the (very new when I commented a few weeks ago) official website promoting the official sub-project was ever utilized, that means I'm lying / scummy / unethical / all the rest of your insults. You assume that everywhere on the internet is like reddit and twitter, basically.
And in your mind, this makes me worse than the person that elided your "not" and thereby completely misquoted you, apparently? Sheesh. You may not call it over-reacting, and you may double down on your verbiage, but as I recall explaining to you before, that is not how the internet works. If you see a place where I've misquoted you, point it out, per
strikefix please. If you see a place where a factual correction is needed, point it out, ditto. If you see a place where you disagree with my opinion, feel free to point it out, and feel free to suggest strike-n-fix diffs, but persuasion is the only way to alter opinions, not whatever it is you are doing.Handset-manufacturing is a tough business to succeed in, and I wish you well, but there is no way that I'm going to predict success of your venture into that territory, when the history of such ventures -- especially security-oriented efforts -- is littered with the opposite outcome. Those are not "unfactual" assertions insulting you and your project, those are just realistic off-the-cuff assessment based on past attempts. Correct way to prove a naysayer wrong, is by succeeding in the marketplace where others failed. Arguing on the internet? Before you have proven the point that your handset venture will succeed, by actually shipping a first version of the hardware, and then shipping a sequel-handset a year later, and then demonstrating long-term viability, realworld? Not an efficient use of time and effort.
Apparently, in addition to your ambition to someday soon "merely" compete in the hardware handset market, also in the long run, you want to compete with the Linux kernel? https://www.reddit.com/r/linux/comments/bd2fm7/grapheneos_an_open_source_privacy_and_security/ from 18 days ago:
There is nothing wrong with ambitious plans, and your points about the insecurity of writing a kernel in C with a monolithic architecture are legit, but to me this is in the same risk-category as wanting to manufacturer hardware-handsets. I had a professor that wanted to help microkernels take over the world, in the previous century. They saw mainstream OSes as too insecure, with all the kernelmode compromises to speed and backwards-compatibility and tons of features. They weren't wrong on the merits, either, just like yourself. But for all their efforts, here we are today using monolithic kernels, to talk to each other on internet servers that are themselves running monolithic kernels. So forgive me if I'm pessimistic that the future GrapheneOS microkernel will be the one to finally break the logjam.
I agree it needs breaking, to be clear. I agree about the security-aspects (though I don't see microkernel efforts as privacy-related per se except as a side-effect of stronger endpoints). But like with security-oriented handset efforts, the microkernel has been attempted often and never managed to get mainstream penetration. There is a huge up-front investment of sunk capital costs in handset-manufacture, and almost as huge of an up-front investment of r&d costs to make a microkernel. You are planning to pick a suitable project, rather than start from scratch, so that is a point in favor of your long-term plan succeeding. And I've no doubt you will be able to implement the AOSP compatiblity-layer on top of the chosen microkernel. But there is a lot of blue sky between there, and mainstream acceptance: building something that everyday regular endusers would actually be able to purchase at boring normal retail outlets where they also buy their other consumer electronics.
You seem to believe that if you complain long enough and loud enough and rudely enough, that I will delete everything written prior to this point, and become a huge supporter of your project, or as you prefer to describe things, of all your separate projects -- that are yet, still housed under the same roof. And that you plan to bundle together, someday soon. This is not the way to impress people, whoever it is you are writing to convince. Your OS project does not run on my handset, unless I hand-compile and hand-harden and hand-audit.
Your auditor code would run on at least one of my handsets ... but none of them are in the auditee-list of successfully-tested targets, and it will be a few years before I upgrade to an S9-class device. I'm content to wait and see how it goes. With any luck you will finalize the sponsorship of the auditor, bundle it with GrapheneOS, negotiate a deal with some handset vendor, release the android-compatible microkernel to vast acclaim, and continue pushing out regular security-patches all the while to everyday endusers, with the innovative funding-model you describe above, mayhap with gradual transitioning to other funding mechanisms.
Yes, I was not fully precise, apparently. What you did with GrapheneOS -- funded by sponsors and thus fully libre-licensed as of September-or-October 2018 -- and what you are currently doing with the Auditor app, that will itself someday be bundled into GrapheneOS (but is not yet).
I don't see, however, where you talk about the security-patches to GrapheneOS, that will come out in summer 2019, and the security-patches to GrapheneOS, that will come out in fall 2019, and so on -- as long as official support lasts on the Pixel 3XL for instance? That is, in fact, the only really serious question/concern that I have remaining: the funding-model for how security-updates to GrapheneOS will work, is unclear (to me at least -- you can explain it or hyperlink to it or just continue whatever it is you are doing if you prefer).
Are the security-patches to GrapheneOS, going to be published in source-available form, but not libre-licensed until sponsorship-funds for that security-patch arrives? What is the funding-model, of the security-patches and OS updates and such, during the next N years?
I understand that some of this depends on whether the GrapheneOS install in question was hand-built or community-built or official, I'm specifically only asking about the officially-supported devices (although I'm interested in learning about the other things... those are not relevant to privacyToolsIO discussions, unless there are community-build usage-stats).
No, not currently, because unlike the Auditor app it depends on changes to the underlying OS. Most of the hardening is done via OS hardening work in repositories like https://github.com/GrapheneOS/platform_bionic and https://github.com/GrapheneOS/hardened_malloc (Chromium doesn't use TCMalloc on Android) including a lot of changes inside Bionic and elsewhere that still need to be added back. It's also largely included as the WebView provider and the changes are focused on the WebView and Monochrome (WebView + browser) build targets.
If it wasn't tied to GrapheneOS, it could bundle a hardened libc internally, among other additional changes, but that isn't a path that I'm interested in taking for it. It's not intended to be a standalone project. It would also not make much sense to use Monochrome when it can't be used as the WebView without being built into the OS, so that would require modernizing one of the non-WebView Chrome apk targets (none of them has a modern API level since stock Android never uses them anymore) and making the same kind of downstream changes for it.
GrapheneOS doesn't use an insecure third party recovery image unable to be verified and unable to verify updates itself. It also doesn't have a weird installation process. It's flashed via the same method as the stock OS by running a flash-all.sh or flash-all.bat script with the Android SDK platform tools available in the environment. I extended the script to handle flashing the Android Verified Boot (AVB) public key for verified boot so it's exactly the same process as the stock OS. The only difference is that if someone is replacing it with the stock OS and wants to return the device to an entirely factory state they need to erase the AVB public key. It will work fine if they don't and it's something that I've documented. It's way easier and far less risky than installing a desktop OS. It's very robust due to the dual firmware and OS partitions so it's extremely difficult to unintentionally brick a device.
If it wasn't so heavily based on license ideology, it would list the iPhone. Either way, I don't see how a Pixel is any more specialized hardware than an iPhone or vice versa. An iPhone is the best option for most regular users. It's certainly far better than hobby projects maintained by volunteers that are aimed towards power users and modding which means they destroy lots of the security model and have an approach to testing / review and security that's a complete joke. Simply using TWRP at all rules out having verified boot (a standard security feature deployed on most devices), proper keystore / encryption security, a locked bootloader (and basic tamper resistance in general) and proper update verification.
Hardware plays a huge part in privacy and security. Pretending otherwise doesn't work. If people don't have ongoing support for their device providing full security updates (which cannot be provided via an alternate OS once the device is end-of-life), they aren't going to be able to have much privacy or security. Similarly, the major OS updates bring very important / substantial privacy and security improvements. It's very important to move to those promptly, and full security updates via the past major OS version stop being possible once the stock OS moves to the new version across the board. There is forwards compatibility with future versions for the device support code but not backwards compatibility.
Software being open source doesn't make it any more private or secure. It doesn't have any direct impact on it, and it's not a disadvantage for the iPhone. It's a development model choice and whether or not it contributes to better privacy and security is an open question along with other development and governance model differences. Regardless of which device or OS is chosen, a huge part of the complexity is in proprietary hardware and firmware anyway. Every single ARM device has a massively complex proprietary SoC and firmware at the core, and other hardware tends to be proprietary too. At best, the board design and a couple miscellaneous bits of hardware are open. Having those peripheral components be open is often at the cost of privacy and security by choosing legacy / obscure components without a proper approach to security or ongoing support / updates. The FSF-style approach is to forbid shipping firmware updates... including crucial security updates... and relying solely on the proprietary firmware / hardware that's already there. In fact, they consider disabling firmware updates by blowing a fuse to be a solution to the problem, ruling out security updates, which somehow makes devices be considered more 'free' because the vendor can't make an update for it anymore, meaning they aren't in a position that they can something that the user can't do. It hardly makes any sense from a practical or security perspective.
Software licensing also has little to do with the barrier to security research / auditing in general, and proprietary licensing even without source code availability doesn't make software into a black box especially without any obfuscation. It's the hardware that truly can't be meaningfully inspected, and that doesn't change if it's supposedly built from an open design / specification and with fully open firmware anyway since that can't really be demonstrated / proven. There isn't an equivalent to reproducible builds for hardware.
Anyway, if it was really about privacy and security, not primarily software licensing ideology, it would list the iPhone prominently. Do you disagree?
It's quite possible that Auditor app will be permissively licensed in the very near future and bundled into the OS, maybe even in the upcoming release. It's quite possible that this is planned already and I just can't speak about it yet.
No, it's permissively licensed from this point onwards and is funded through multiple organizations and companies providing money, infrastructure and developers. The companies intending to build on the project need to hire developers to work on it, some of them to work on it upstream under my oversight and also others to work on their downstream projects outside of the scope of GrapheneOS. The devices as supported until they're end-of-life, and there are only minimum guarantees about their end-of-life dates. It's not known how much longer past those minimum guarantees they will receive updates. The Pixel and Pixel XL are receiving Android Q despite that being an extra year past their guarantee for major updates, and I wasn't going to add back support for them until it turned out they were getting it. They may receive another 2 years of security updates after their minimum guaranteed EOL date in October 2019. Maybe even another year or two of major version updates. It's not something that I can predict.
The downstream variants of the OS by the companies supporting the project are the main way that it's being used, and those are officially supported in a sense. The companies / users on those devices don't receive updates or support directly from the GrapheneOS project, but the GrapheneOS project does receive funding and developer time (i.e. their developers contributing upstream, including developers they'll be hiring to work full-time on the upstream project) partly to support these downstream variants.
The primary stated goal of privacyToolsIO is specifically trying to work against mass surveillance, so it is about a specific type of privacy&security ("the masses")
No, I would agree, although "with tweaks" would be essential. iPhone+gmailApp+fbookApp, is not more private than LineageOSfrom2013+tutanota+mastodon, all things considered. But you can run privacy-respecting apps on an iPhone, and for everyday endusers that do not care much about free-as-in-freedom, this might be their best way forward. Apple lock-in problem is quite severe, but security/privacy are above-average. Cost of the handset is above-average, but as you say, hardware cannot be ignored
I think that LineageOS can be used with reasonable privacy-and-security, but it requires a lot of skill on the part of the enduser (and needs to be a recent model since firmware-OTA is still something only the handset-vendor can supply). But I have not brought up such a heretical stance yet in public here on privacyToolsIO, partly because I'm one of those free-as-in-freedom people who dislikes the iPhone on general principles. But that's for me personally, and I have family that use iPhones -- I don't give them too much grief over it
Hah :-) Well, as they say, anything is possible if you put your mind to it ;-) And yes, my "concern-trolling" is not intended to be trolling. I do think there is a good model here, just, something needs to be done about what-happens-if-the-copyright-holder-of-a-source-available-codebase-is-hit-by-a-bus, to guarantee that the codebase in question will become free-as-in-freedom within N years of that tragic happening. There is some theoretical risk of "author decides to withdraw the codebase if sponsorship does not arise" and such, but all is done in public so this seems like a worry-not-worth-worrying-about.
Okay, sounds good to me
Which is fine, and answers my question about "who is funding the security-patches" as well. Thank you. And I hope this approach takes off, security-patching on mobiles at the behest and discretion of the carrier & handset-vendor always makes me think grim thoughts.
Yes, and to me those are "officially supported enough to be considered for privacyToolsIO listings" ...and compared to the UbuntuTouch and LineageOS listings, this might even be more-official-than-the-alleged-competition, even.
p.s. Offer to "merge some patches" into comments you were unsatisfied with, that I made, was intended to be taken at face value. I'm happy to correct whatever needs correcting, or insert rebuttals you would like to see inlined, or whatever. Like I say, I actually do like your project, and am not here to badmouth it. I just don't see any badmouthing; I really do think that handset-hardware is a huge tarpit of despair. (And microkernels as breathtakingly difficult to mainstream.) I hope you win, I just am pessimistic, at this early stage.
None of which detracts from the usefulness of GrapheneOS now which is what privacyToolsIO listings are supposed to be about, that I can tell, and it looks like the security-patch and long-term-support aspects are being suitably handled, per above. Such that, I can tell my cousin next month, "hey buy a pixel and I'll help you install grapheneOS onto it" and thereafter they will be okey-dokey, not needing to call me up every few months with some smartphone-emergency or other. Is that roughly the state of production-readiness that GrapheneOS has achieved, or am I off in the wilderness of inaccuracy again?
I use an iPhone personally (for security reasons) but I'm not sure if recommending one is within the scope of this project because most/all(?) of the projects we recommend are mainly recommended because they're verifiably better alternatives as a result of them being open source. We typically would want people to be able to view the source themselves if they had the technical ability to and see how things work, rather than take things at the word of iOS developers. So it's more of a balancing act between the projects we recommend. In theory I suppose we would recommend a closed-source solution if there were no open-source alternatives, but GrapheneOS (and the other projects to a lesser extent) seem to negate the need for that.
Out of curiosity, will GrapheneOS fully support Pixel devices still getting security updates, or only devices still receiving security updates and major updates?
I just bought a Pixel 2 specifically to test GrapheneOS so... I guess I'll wait for that to arrive this Tuesday.
I don't think so, when the security model is so severely crippled along with the poor security for builds and updates.
The issue is with a lot more than firmware, and they generally don't bundle all of the vendor / firmware updates even when they are available such as for Pixel devices. The expectation from them is that users will flash the vendor and firmware images every month on their own, defeating the purpose of over-the-air updates, and also adding yet another reason that a locked bootloader and verified boot cannot be used with it.
iOS offers better privacy than AOSP at a software level, with the gap substantially smaller with Android Q but still present. An iPhone is also leagues ahead of the hardware security of any Android device other than a current generation Pixel.
The open source licensing cannot be withdrawn retroactively once it's released under that licensing. It's highly unlikely that anyone would be both willing and able to continue my work anyway. It didn't ever happen in the past. The only people interested enough in continuing it / forking it have been companies making proprietary operating systems based on the code. Essentially no one has ever used the code for anything else beyond building it, and the people who have audited it and helped with it would nearly all have done it regardless of licensing. It's entirely theoretical that anyone will actually do anything with the code based on it being open source other than trying to profit off of it through commercial forks. Since I'm receiving funding for the work, rather than needing to build a business model, it doesn't bother me much this time around. The sponsors may end up being unhappy that other companies are using the work for free but it's not my problem directly and all of them fully understand that this can and will happen to some extent. I also don't think a lot of them are going to care, since many are not even for-profit companies.
Yes, but you are going to need to install F-Droid, probably also the Yalp Store, and help them understand the issues with apps on the Play Store having various levels of dependency on Play Services. I'll end up bundling F-Droid and various other apps but I need to be able to make modifications to all included code (such as fixing bugs in F-Droid that are neglected upstream and particularly relevant to GrapheneOS) and I wanted to change the app / package ids to avoid a conflict with the official or F-Droid versions of the apps so I haven't gotten around to doing this yet.
Also, I strongly recommend against getting a 1st generation Pixel, due to lack of too many of the hardware security features and the potential of it approaching end-of-life. I would recommend either buying a Pixel 3 on sale or waiting for the Pixel 3 Lite which is likely going to be $400 not on sale. I will likely support the Xiaomi Mi A3 or a similar device as a low-end option offering less security too. The main improvement of the Pixel 3 over the Pixel 2 is an improved security chip: https://android-developers.googleblog.com/2018/10/building-titan-better-security-through.html. The Pixel 2 used a off-the-shelf NXP security chip for Weaver (hardware-based exponential throttling for decryption including other benefits) and had the insider attack resistance feature, but it didn't have the other features like the StrongBox implementation providing a far better keystore (including a separate attestation implementation) than the TEE-based implementation.
It's as stable as the past incarnation of the OS as a commercial product which was being successfully sold for ~$400 on top of the price of a Pixel. Most of those customers were very happy until my former business partner destroyed everything. I'm no longer interested in approaching it as a business or having it closely tied to any specific company. I've learned not to trust other people to pretty much any extent but rather to plan from the start for everyone trying to screw over the project and myself. For that reason, I'm making sure that the funding and developers will be from diverse companies / organizations.
Only Pixels are comparable to iPhone security though, so it's not like there are a lot of options in the Android world. Most people are probably also not going to be very happy with tons of mainstream apps not being available, although it's true that it is best if they don't use the vast majority of those. They can still use apps like Facebook and WhatsApp on GrapheneOS if they really want to do it anyway, and they fully work. However, a huge number of apps depend on Play Services to some extent.
I will be adding support for a few other carefully chosen devices to GrapheneOS, but primarily as low cost options that are known to be less secure. I'll be explaining the disadvantages of them on a page comparing the security of the devices. The Xiaomi Mi A2 was a potential target but I think the time has passed for considering it and the future Xiaomi Mi A3 is the best hope for an alternative low-end device with acceptable (but not great) security.
An iPhone doesn't make people compromise between app availability and having decent security / privacy. GrapheneOS aims to provide substantially better privacy and security than an iPhone, but it's a long term undertaking. It also aims to fill in the gaps left by not having Play Services, but it's absolutely not going to take the approach of microG where for the most part they are simply implementing new clients for Google services. It also has some serious security issues not applicable to Play Services itself and in many ways I think people are better off just using Play Services than microG, especially since it is relying on using unstable internal APIs, binaries, etc. without permission and can break or be banned from them at any time.
Both, as it did in the past in the past incarnations of the project. It's easy enough to make maintenance branches for legacy devices with only security updates / bug fixes. I think that the days of needing to do this might be over though, due to Treble. Unlike in the past, a major OS upgrade for the AOSP portion can be shipped without the kernel / vendor portion being updated for it. Pixel receiving Android Q in the 3rd year of support months before the minimum guarantee for security updates ends is not something that happened in the past.
The Android security patch level includes the kernel, vendor and firmware updates. It's split into a YYYY-MM-01 patch level for the fixes included in the AOSP tags and YYYY-MM-05 for device-specific fixes. For example, look at https://source.android.com/security/bulletin/2019-04-01. LineageOS merges in the AOSP tags, so they get those fixes, for the most part (other than the fact that they are breaking some of the security model, and some of what they are doing would be considered security vulnerabilities and defeat the purpose of fixes for things like verified boot). They set the security patch level based on this, so they claim to have the latest security patch level across all devices. However, in reality, most devices are missing most of the YYYY-MM-05 portion of the security updates with LineageOS. Even for devices where these updates are available, they are often not shipped with LineageOS but rather need to be obtained and flashed by users. For Pixels, this is fairly straightforward, but means that the over-the-air updates are not providing proper full security updates. For other devices, it's often not clear where to obtain vendor.img and the firmware images or even how to flash them.
It's also worth noting that the YYYY-MM-01 patch level is supposed to include all previous patch levels including the previous month's YYYY-MM-05 patch level. The split is only present to give vendors an extra month to include the device specific updates, while still claiming to be on the latest month's patch level even though they really aren't. It's just Google giving some leeway to vendors. They also split out a lot of the fixes into recommended updates not required for baseline compliance. You can see these in the Pixel security bulletins, even though the vast majority are not Pixel specific. For example, in https://source.android.com/security/bulletin/pixel/2019-01-01, those f2fs fixes are hardly Pixel specific, they are just not important enough to mandate them everywhere. In the past though, they've often included lots of fairly concerning issues as recommended updates at least until future months.
I have access to the internal bulletins given to vendors so I get to see the full descriptions of the issues a month early (which is really too long) along with the split into mandatory and recommended, which is presented as Android vs. Pixel updates publicly, to save face for the other vendors not doing everything like Pixels, similar to the YYYY-MM-05 split.
@five-c-d
https://twitter.com/GrapheneOS/status/1125928692671057920
Is what I was talking about. I couldn't leak it here in advance though.
Right, congratulations on that, and congratulations#2 because :-) grapheneOS is now in the listings of privacyToolsIO, also. I heard about the attestation-server being libre-licensed on Mastodon, indirectly, so it is not news to me, but I appreciate you remembering that was one of my worries. But of course, your not-a-leak was pretty transparently hinting that you were expecting Big News to break, soon, as well :-) :-) :-)
p.s. I'm still working on my reply to your other points. But this bit is relevant...
Correct, exactly. Once any bit of code is libre-licensed, especially one that was already posted to the internet source-available at some earlier time, it will never disappear. It might get proprietarized by a corporation if it is not strong copyleft (sometimes even then), it might be lost in a future dark age where the internet is outlawed worldwide, but those are corner cases, and don't detract from the freedom the libre-licensing gives. So first of all, thank you, glad you earned your well-deserved payday. Add another success-story to the funding-model, and I hope that you decide to continue thataway, rather than switching over to work-for-hire or something. You might even consider setting up a two-tiered payment system: source-available upon initial release, relicensed as AGPLv3 when half the payment for the work has arrived, and then re-relicensed as MIT when the final half has arrived. Or if you want, 60/40 or 70/30 or whatever.
My concern was about, what if before the libre-licensing (final payment), but after the source-available initial release, Something Bad was to happen to the copyright-holder(s) on the work in question? As a practical matter, if developer X releases source-available Y, and then is hit by a bus prior to satisfying promise to libre-license under Z, well... the code is available. It is not strictly legal to redistribute, since that is copyright infringement, and in most countries the deceased would pass along their copyright-ownership to their heirs, and MOST heirs would -- once the final payment arrived -- honor the wishes of the dead, and release the copyright, as promised.
Since I strongly dislike probate court, though, I would prefer if the developer of available-now-libre-upon-payment code, used some other arrangement: "license canary" thing, or a clause in their source-available statement ('copyright 2019 Daniel Micay all rights reserved but in case I am incapacitated or presumed deceased for more than 18 months I hereby assign my copyright to [the OpenBSD foundation or FSF or whatever you prefer]').
Now... for the paranoid amongst us, that would provide a perverse incentive, for unethical entities, to kidnap you and hold you in chains for 19 months, or even send Leon The Cleaner! So please make sure that the asking-price of all software, over which you have copyright control, which is in the interim state where it is not yet libre-licensed, sums to less than the cost of hiring professional kidnapping-rings... I guess ;-)
p.p.s. Impatient for another promised update, from another person:
@JonahAragon ...ahem, looks like it is Tuesday.
Have you ditched the iPhone yet, and... Gone Perfectly Graphene? It's the new GPG :-)
@five-c-d funny story, the one I got was mislabeled and was actually a Verizon edition, no unlockable bootloader for me! 😬
So I'm returning that. It's a blessing I suppose, since all of @thestinger's comments made me want to get a Pixel 3 instead, with its fancy new Titan M chip and all. So I'll either get that "soon" or get a Pixel 3a if GrapheneOS supports it, although I'm not holding my breath on that happening anytime soon (unfortunately).
I'm working on potentially getting funding for android-prepare-vendor which would including paying someone to work on replacing the prebuilts with building from AOSP and the Qualcomm open source releases. Obviously, firmware can't be built from source due to signature verification, which is important for the security model anyway (and a lot is closed source). Most of the other components in there are either open source or available via the Qualcomm SDK, and for the components in the SDK permission could potentially be obtained to rebuild them with compiler hardening instead of using the prebuilts.