JCjcr·Jun 27, 2014
It's a good article. Those who prefer to have their phones disconnected
from Google for whatever reason at least have some options to limit
exposure, but unfortunately, preventing the mobile web browser in the
phone from leaking information like location, history, and habits to
Google (and plenty of others) is going to be really tough.
Also, the article glossed over an important issue; the need to use
closed-source proprietary binary blob drivers to make the hardware
usable. With drivers running in kernel space, the potential damage of an
intentionally or unintentionally bad driver is pretty much unlimited.
The most problematic drivers are usually the graphics drivers due to
complexity and their impact on both system and battery performance.
Since the companies making the graphics chips (well, they're often just
graphics cores within the
Read the rest
main processor IC rather than separate chips)
like nVidia, Qualcomm, Arm Inc (mali), and Broadcom (to a lesser degree
lately) refuse to release the documentation necessary for open source
hackers to write drivers, tons of unnecessary effort is wasted in
attempts to reverse engineer the binary blob drivers so open source
drivers can be written.
There are quite a few efforts under way to produce open source drivers
for various graphics "chips" on various types of ARM systems. Here are a
few links I've collected:
http://freedreno.github.io/
http://bloggingthemonkey.blogspot.com/
http://limadriver.org/
https://gitorious.org/lima
https://github.com/grate-driver/grate/wiki
https://github.com/laanwj/etna_viv/wiki
http://www.raspberrypi.org/a-birthday-present-from-broadcom/
https://news.ycombinator.com/item?id=7320828
I haven't seen anyone succeed in making a fully open source blob-free
phone yet, but people are working towards that goal.
Unfortunately, even if open source devs eventually solve all of the blob
driver (and chip documentation!) problems, there will still be an
unknown, untested, and unaudited chunk of code running on phones that
cannot be legally altered; it's the baseband processor.
http://en.wikipedia.org/wiki/Baseband_processor
Since the baseband processor controls the radio(s), it's actually
against the law (FCC in the US) to modify the broadcast/receive
power levels or frequencies. As such, each baseband processor has
to be tested and certified by the FCC, and any change means it has
to be tested and recertified again.