Any large OSS distribution is going to have a fairly continuous stream of security fixes to ship to their users, and that takes a fair amount of time, and I'm always concerned about whether any new project (okay—it's not quite new, but they have a fraction of the number of developers they did twelve months ago!) has the resources to ship them in a timely way.
Blobs incorporate the modem, baseband firmware, bootloaders, and many (most?) of the hardware drivers and imaging drivers.
51% of Android kernel vulnerabilities in vendor drivers are a result of missing or incorrect bounds checks, and over the whole Android kernel, 44% of all vulnerabilities were missing bounds checks, and 12% for null pointer dereference.
Looking across the whole kernel, from Jan 2014 to April 2016, 85% of kernel bugs are born in vendor drivers, with the remainder in the core kernel.
Vendors therefore are shown to write bad code. It's fairly safe to assume this is reflective of the quality of their blobs too - there's certainly a load of vulnerabilities in those if you look at the Android Security bulletins for bugs without a source reference for the fix.
So agreement with your concern, but I'd just like to highlight that custom ROMs are not really a good security solution, as there's just so much to fix (at a kernel level, requiring detailed driver knowledge of the vendor/SoC stuff), and blobs that won't get updated after the vendor abandons the phone.
Ref: https://events.linuxfoundation.org/sites/events/files/slides...
One thing I wish there was more visibility of is "is this device still getting security updates", because there's often almost no visibility about that (and while you obviously can't say the vendor won't fix future vulnerabilities, you can say whether the vendor has fixed all known vulnerabilities), even online, yet alone anything pushed to the device to let its user know it is no longer secure.
e.g., http://web.archive.org/web/20161224231459/https://wiki.cyano... is the old CyanogenMod wiki page for the Galaxy S2: the last "development channel" (i.e., unstable) build is 2016-12-18, the last "release channel" (i.e., stable) build is 2015-11-16. There is nothing on the device page to suggest the stable build is known to be insecure (though given the number of Android bugs found in the last year unquestionably is!), yet alone anything about upstream vendors dropping support for the device and the unstable build being known to be insecure too. How is LineageOS going to do better than that? That's a damn low bar.
I've no idea how to achieve that on volunteer time, maybe a crowdfunded reverse engineering and mainlining org could work?
It's actually astounding, albeit hardly surprising, that companies often have zero interest in pushing security patches to devices not being manufactured anymore.
OTOH, in a sense I have a higher expectation of "aftermarket" OSes insofar as they're actually pushing semi-regular updates which I'd hope would include all needed security updates.
When you buy a windows laptop you'll usually get a bunch of vendor-specific crap, but after doing a clean install you can just pick up the drivers on their website and it'll all work fine. Why isn't this an option with Android?
In reality, we were really spoiled with IBM's massive mistake in standardizing the PC (the BIOS), so while Linux may not pick up your monitor, your monitor is made to work to a basic standard (VGA), so you can at least boot up, read the hard-drive, and have basic "keyboard" IO.
This was really important before Win95 made the PC practically MS owned, as you could (and were expected to) install whatever OS you wanted, so they had to have a standard Boot Sector, etc.
ARM SoC are meant to be built by a manufacturer to their specs (their CPU doesn't have to be compatible with anything because nothing is user-serviceable anyways). In other words, PCs were meant to be an Open Standard, while SoC are like old consoles/"dumb" phones.
Unfortunately, due to MS dominance in the PC world, and the collapse of independent computer manufacturers (I remember the days when buying a cheap computer meant not going to Dell but going to the mom-and-pop shop down the block, but you had to know how to fix things if anything went bust), the PC is moving slowly but surely to the appliance world.
Android can technically do like OpenWRT does, but there is much more stuff involved in the Android world so making a universal build is harder. However, I personally can't think of a hard, technical barrier. New ideas for unifying devices and separating blobs such as device tree or separate vendor partition is getting traction and makers such as Sony are embracing it. Many Sony devices boot the same kernel, and that's why you consistently seeing Sony devices getting support and builds very early on from projects like CM.
BTW, I have been trying to write an answer to you by saying a slightly different version of what dispose54312 said, but then realized it didn't make sense. I came to the conclusion (for myself) this is mostly "how it is done currently for Android." So I hope my unpopular answer is not crazily misguided, and please take my perspective with a grain of salt.
Let me answer that by picking the question apart:
1. To update the system, you need access to write actual system-files. You need system-level access.
2. Android is built entirely up on a "user-space" model where permissions are granted to apps, and almost no apps have system-level access.
3. On rooted phones you can allow system-level access to specific apps, which in theory could install the latest OS version and binaries. In theory that sounds like 1 app which you can use to update the OS, everywhere, right?
4. Except you would need a different installation-strategy for unrooted phones anyway for the installation anyway.
5. To compound the problem the ARM platform has no standardized BIOS/UEFI layer to handle generic booting, so the kernel being booted must be device-specific in order to gain access to the rest of the phone: It can't rely on generic "BIOS"-drivers to load modules on demand from flash storage. And the boot-partition is almost always too small to have a kernel with enough drivers for "everyone" embedded.
6. So you cant make a standard phone-agnostic flashing-app, nor install medium. You do have to build a custom phone-specific initial flash-package for every model you want to support as a bare minimum.
And when you've already put in all that effort, what do you gain by creating an "app" which does this inside a pretty GUI, instead of just rebooting back to recovery to (auto) flash the latest image? Practically nothing.
"Flashing" may sound scary, but in reality it just means installing. There's no technical difference between that and just copying files to a usually write-protected partition.
AFAIK: Apple officially does exactly the same, they just don't call it by that name.
Last update for my phone was early september. Not holding my breath for this.
(yes, it was involved, use Google to search for previous news.
For example at one point CyanogenInc partnered with MSFT so they have a Microsoft sponsored Android flavour with several Microsoft apps preinstalled. https://cyngn.com/press/cyanogen-announces-strategic-partner... http://www.businessinsider.de/why-microsoft-cuddled-up-to-cy... Now it smells like the "embrace, extend and extinguish" strategy that MSFT is using with great success for decades https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
So I hope at one point we will get the full story.)
The problem is two fold:
1. Get maintainers. 2. Make sure that the high ranking individuals can't just "take the ball and go home", and (however unpopular this opinion may be here), GPL is the only way to ensure that they will never be able to sell out ever again.
And especially after the CM/CyanogenOS/Focal/Paranoid Android situation, private ROMs seem to be too much of an "aquihire" risk.
One potential issue with CM is that users were signing contributor license agreements (CLAs) to the "project leads" of the "CyanogenMod Project" [1]. While everything is under Apache 2, which ensures it can be used in future, there were plenty of cases where people submitted code under the copyright of the project (see headers which state "Copyright (C) 2016 The CyanogenMod Project").
You are correct with point 2 - if you want to prevent "acqui-hire" type takeovers, you need to ensure that there isn't a tight-knit group of individuals willing to agree and sign over the rights.
This situation would be very, very different if the original CM project had taken a better approach at the start - perhaps forming a 501(c)3 for the holding of the cyanogenmod.org domain and any trademarks/name rights. Then a commercial license could be granted to the incorporated form of CM.
I wish I could find a good primary source, but best I can see at the moment are fairly blog-type news sites [2]. The issue we see here is that the project's stewards were turning their focus from the project to the "commercial spinout", rather than in keeping the project going. At that point, there's little that the contributors could do really - it seemed the leaders had made the decision to build the inc version, despite high profile disagreement. Not sure GPL would fix that, but it certainly helps ensure a community project can live on, even if it won't guarantee it will.
[1] https://review.cyanogenmod.org/static/cla_individual.html
[2] http://www.androidheadlines.com/2013/09/author-cyanogenmods-...
You can aquihire Linus, you can take his team, but any code you develop "in house" is going to have to go public anyways (because no one owns enough of the code).
You write in past tense; what happened?
This would have be defined carefully to avoid the device dropping out of support quickly.
Personally I think full-time work would be better than bounties.
I also wonder if make sense for donator to be able to select their desired Z percentage.
LineageOS needs a flagship phone, FairPhone needs a community-empowered OS.
To have a large corporate overlord dictating how I use the device I "bought"
I see these same statements in the Linux Desktop world where everyone bitches about how All the Distro's are different, and how the Arch way is different from the Debian Way, and different from Red Hat, Canonical etc.
That is what I LIKE about Linux, that is what is LIKE about Android.
If i wanted a Corporate Overlord I would use an Apple or Microsoft commercial garbage
For one, Cyanogen has always refused to follow Google's guide lines and license terms. This is both what makes Cyanogen appealing to a small minority of users and also why there is absolutely zero chances why Google would ever fund this kind of effort.
The same argument applies to AOSP (cyanogenmod's upstream), but that hasn't stopped Google from supporting it.
Or they are required to release those device's source code to (and pay for) the "communities" for the maintain the security updates.
If they don't do it, they are responsible to damage caused by those devices because of security issue or the customer's loss of data/privacy due to hacking by 3rd parties.
Similar to recent case where "food processor" company is liable if the blade is cracked into pieces into the processed food after a few years.
Just expand the warranty laws – security updates are fixing a manufacturing defect that makes the device unusable.
(Will also look into seeing how I can contribute, although every time I've tried I've hit a "users file crappy bugs" filter that stops me reporting without installing a debug build on my main phone.)
https://www.reddit.com/r/oneplus/comments/5k8ppv/former_cyan...
Not really a brilliant source, but I'd be inclined to believe it in this case. It fits with my understanding of the situation.
I used to use CM on everything but over the last few years I've been plenty happy with pure stock Android (+ root). Didn't end up using most of CM's extra features and found that it was often unstable and/or leaving lots of things just sort of half-working.
I personally stay away from there.
For root level access, I'd prefer relying on a project with actual reputation on the line, and has periodic spot checks.
Privacy guard still beats whatever stock rom has.
The newer phones come with Oxygen OS or w/e they call it now and at least get some sort of periodic update.
http://www.androidpolice.com/2016/12/24/cyanogen-shutting-se...
At some point before 31st December (at the latest), according to their blog post. In reality, their website is down right now. Downloads and other sites are up, but the blog is down.
Why is Cyanogen shutting down?
What I don't get is why they won't just give up the CM name/domain? Are they pulling an OpenOffice?
I thought CyanogenOS was a commercial venture that arose out of CyanogenMod. But that they were essentially separate protects. I'd read about CyanogenOS coming a cropper, but understood this wouldn't affect CyanogenMod. Now, these linked articles seem to be treating -OS and -Mod as the same project/same organisation.
Can anyone explain?
