|
|
Subscribe / Log in / New account

Security quotes of the week

Security quotes of the week

Posted Aug 7, 2015 1:05 UTC (Fri) by dlang (guest, #313)
In reply to: Security quotes of the week by sjj
Parent article: Security quotes of the week

> Neither Google, carriers, or Android OEMs have any incentive to make customer data security a priority, they prefer to sell customer data to advertisers and new handsets every two years

Google has an incentive to increase security because if Android looses market share they will loose advertising (even if you assume that their intent to keep other companies from getting a stranglehold on user devices is a meaningless goal since you don't see them earning any revenue from it)

Carriers and OEMs don't have a strong incentive to provide updates, but as soon as some start providing updates, the others will either have to follow along or users will start seeing problems that their friends don't se.

This is why the Samsung and google Nexus monthly security updates are so important. Even if they don't last as long as we would like, it still sets the stage for ongoing maintenance and gets people used to the idea that they are owed updates.

There's a chance that having to provide security updates to multiple different versions will provide enough incentive to get carriers/OEMs to upgrade older products to new versions to reduce their maintenance burden.

(yes, I'm an optimistic cynic :-)


to post comments

Security quotes of the week

Posted Aug 7, 2015 2:46 UTC (Fri) by sjj (guest, #2020) [Link] (1 responses)

Optimism, nice ;-)

So this new process is going to go Google > OEM > carriers. Sounds like fun when both OEMs and carriers have their own versions of OS mods. At least there is some pressure now to do the right thing. The majority of devices out in the wild will not get updates AFAICT.

I'm just waiting for Samsung to advertise their new phones with "gets security updates", unlike the one bought six months ago. I'm a pessimist cynic, sorry.

Security quotes of the week

Posted Aug 7, 2015 3:09 UTC (Fri) by dlang (guest, #313) [Link]

> So this new process is going to go Google > OEM > carriers.

that's what the old process was as well, just that the OEMs and carriers mostly didn't do any updates (and Google, somewhat understandably, doesn't do many updates to old versions)

Security quotes of the week

Posted Aug 13, 2015 7:56 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> There's a chance that having to provide security updates to multiple different versions will provide enough incentive to get carriers/OEMs to upgrade older products to new versions to reduce their maintenance burden.

Part of the trouble is that most Android phones (all?) are arm-based. And the arm driver tree needs a massive cleanup. Chances are, your phone (with the exact same chipset as mine) uses a completely different set of drivers to mine.

Once the work sorting that mess out is complete, it will be much easier to roll out updates, because it will be a lot easier to sort out what's going on.

Cheers,
Wol

Security quotes of the week

Posted Aug 13, 2015 12:34 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Part of the trouble is that most Android phones (all?) are arm-based. And the arm driver tree needs a massive cleanup.

No, it's not that the "arm driver tree needs a massive cleanup" -- it's that the *manufacturers* of the handsets, platforms, and SoCs need to (first) actually release source code and (ideally) put forth the effort necessary to get that code into the mainline kernel. Only then can the mainline kernel be expected to support things sanely.

Security quotes of the week

Posted Aug 13, 2015 22:52 UTC (Thu) by Wol (subscriber, #4433) [Link]

As I understand it, even the drivers in the mainline kernel suffer from this mess :-(

Too many companies HAVE released their drivers as open source, by tossing them over the wall. And they are heavily garbled versions of other drivers, which are garbled versions of yet other drivers, and it's turtles all the way down ...

I gather a lot of work has been put in to cleaning this mess up, but I got the impression it's not complete.

And that's why DeviceTree is necessary - unlike on x86 where MS pretty much forced standardisation, on arm there is no way to probe and identify hardware because it's far too easy for a probe for device A to crash device B - not a good idea. Once DeviceTree is in place, I think you will just have to give your linux kernel the tree, and it will know what hardware is where in the memory map, which will make driver management much easier.

Cheers,
Wol


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds