6 ms·

That's not to say Google has no responsibility in this. Google's OS has a terrible security-update policy. Being able to buy a new computing device from a sto

by Pxtl 10y ago

That's not to say Google has no responsibility in this. Google's OS has a terrible security-update policy. Being able to buy a new computing device from a store that will receive no security updates is terrible, and is fairly common in Android devices. Now, there are valid technical reasons that Google can't be as good as Microsoft at pushing out updates to every device running their OS, but still, it's hard to say that Google has made fixing this problem a priority. Even their own 1st-party devices have a pathetic 2-year upgrade window from launch, which, I'll remind you, still means somebody can buy last year's device on a store shelf and stop getting security updates before the device is even out of warranty.

Kurtz79 10y ago
Google in most cases is not the device's manufacturer, and in a mobile device OS and application SW are tightly coupled, so you cannot really have OS updates separate from firmware updates, bypassing the actual manufacturer's own updates. Google (and Apple and Microsoft) can totally do it for devices that manufactures and maintains on its own, and actually it is one of the selling points of their new phone. In addition, at least in the US, devices connecting to a cellular network have to go through a certification process, enforced by the carriers, and every firmware update requires additional regression testing (time and money) for the device to be admitted on the network again. (That's my guess of why Lenovo dropped the policy of fast updates for Moto phones when they bought Motorola)
- jdietrich 10y ago
  Google have an approval system before they allow a manufacturer to bundle Google services. Update mechanisms could easily be built into that approval process. I suspect that they haven't turned the screws too hard on manufacturers for fear of Samsung or LG making an Amazon-style fork. Google have already drawn their own roadmap with the Android One project - a number of low-end manufacturers have devices that get updates directly from Google. They could easily create a Nexus-type brand that manufacturers can opt into, guaranteeing timely updates and long-term support. This could be a big draw for mid-tier manufacturers. https://en.wikipedia.org/wiki/Android_One https://en.wikipedia.org/wiki/Android_One
  - deleted 10y ago
    [deleted]
  - djsumdog 10y ago
    Exactly. Apple only has one set of hardware to support. Microsoft support the PC platform and you can usually do a fresh install on any machine and it will boot (driver support is a little different). Android is garbage in this regard. Google binds everyones' feet with the OHA so they are required to use the Google Play Store and services (and they can also never manufacture Amazon devices) yet they don't standardize the system to ensure that AOSP can install anywhere. Part of this is the difficulty of ARM not really being an architecture, but even Microsoft was able to deal with this by requiring UEFI and some standardization on Windows devices (although they're more like Apple where there's limited hardware to support). Google makes a ton of money from their licensing. It's in their advantage that people buy new phones all the time. If the hardware wasn't all over the place, we'd see more uptake for thinks like Plasma. What are the alternatives right now for software devs that are willing to do their own roll-your-own work? Ubuntu Touch doesn't seem to have been updated for most of their ports in forever. Plasma supports two devices, neither of which have sdcard slots.
    - amyjess 10y ago
      > Part of this is the difficulty of ARM not really being an architecture, but even Microsoft was able to deal with this by requiring UEFI and some standardization on Windows devices (although they're more like Apple where there's limited hardware to support). Well, the reason why PCs are a standardized platform is because the industry was built around cloning the AT. If anything wanted to be successful, it had to do everything the AT did the way the AT did it. Once the AT started getting long in the tooth, the industry got together to agree on further standards like the ISA bus (an extended version of the AT's bus), various ATA storage standards (again, derivative of the AT's storage protocol), the ATX form factor, the PC System Design Guide (PC 97/98/99/2001), etc. The PC industry has a culture of working together and collaborating for the sake of compatibility. For part of this, Intel was involved with the standardization process (something ARM refuses to do), but even they didn't have the full authority to force anyone to adopt their standards. In fact, there were plenty of manufacturers of x86 machines who decided to skip out on PC compatibility entirely in order to do their own thing. Just go ahead and try to install Windows 3.1 on a WonderSwan, for example. It's x86, but not a PC or any kind of AT clone. The industry simply declined to see it as a PC and moved on. It's a shame that nobody in the phone industry every attempted a hardware standardization effort. Google and Qualcomm could've worked together to come up with some real standards, but they dropped the ball. I have to wonder if Google would've been able to force something through if they made Android run entirely on native code instead of shoving everything into a Java-based VM. If the industry couldn't take the shortcut of "let's just port Dalvik to our hardware and call it a day" and instead had to ensure compatibility for a wide array of native software, they might actually have developed some form of collaborative discipline. What Google needs to do now is collaborate with Qualcomm and come up with their own standardized hardware platform. Create a phone equivalent to PCI, ATX, PC 98, etc. And then refuse to license Android to any device that isn't built on this platform. They should complete the process of moving AOSP into GApps, replace the Linux kernel with a closed-source BSD derivative, and then announce the closure of AOSP. They should do with Android exactly what Microsoft does with desktop Windows.
- archivator 10y ago
  > and in a mobile device OS and application SW are tightly coupled I call bullshit. There's no reason Google can't update everything AOSP-y in /system - libc, libart, libwebkit etc. > Google (and Apple and Microsoft) can totally do it for devices that manufactures and maintains on its own That's a low bar. When you buy a Dell laptop, you continue to receive updates from Microsoft. This is the bar we should hold Google to. As for the certification process, surely having one update that ships to N models is easier to test than N updates shipping to N models?
  - kyrra 10y ago
    Except it's not that simple in the Android world. Someone explained it really well a couple days ago: https://news.ycombinator.com/item?id=13057605 https://news.ycombinator.com/item?id=13057605 The basics are that every phone out there uses a forked Linux kernel patched to hell to get it working. Since none of the drives are upstreamed it's unmaintainable. The linux kernel does not have a stable driver interface so shipping updates to phones is a LOT of work.
    - deleted 10y ago
      [deleted]
    - mortehu 10y ago
      This doesn't explain why they can't upgrade user-space applications and libraries. It's very rare for a user-space application upgrade to require a kernel update on any major operating system.
  - Kurtz79 10y ago
    > and in a mobile device OS and application SW are tightly coupled I call bullshit. There's no reason Google can't update everything AOSP-y in /system - libc, libart, libwebkit etc. That's not the point. Even if it were so, it's still responsibility of the manufacturer to integrate it in its own firmware and push the update with the carrier's approval. You are comparing a laptop to a smartphone, which makes no sense, the smartphone has to connect to cellular network to be useful, and it's the carrier that establishes the rules for the update process. I agree that it should work as you say for devices with no cellular connectivity, such as WiFi only tablets, where no other parties other than the OS and device manufacturers are involved.
- nradov 10y ago
  That is specifically a design flaw in the AOSP. Right now manufacturers have to integrate their custom device drivers into every new OS build, leading to long delays and fragmentation. The device drivers should be separate, and the OS should expose a stable API and integration points. That way OS upgrades could be pushed out without breaking everything, just like with desktop OSs.
  - zigzigzag 10y ago
    That's not Google's policy, it's Linux. What you suggest would mean abandoning Linux as a kernel. I'd be all for it - the industry needs some more open source kernel competition.
    - dep_b 10y ago
      Linux is a bad choice for a half-open environment. Either it's totally open (like most Linux distros) or everything is done by the manufacturer (like routers). But not this garbage with closed source drivers that will prevent you from recompiling eventually somewhere in the future.
    - nradov 10y ago
      No one is stopping Google from forking Linux, or using a different OS kernel.
sqeaky 10y ago
> Being able to buy a new computing device from a store that will receive no security updates is terrible, and is fairly common in Android devices. This seems like the kind of problem the free market could solve. Just get one phone vendor to guarantee secruity updates for a few years and then some customers will start buying those phones. After a while other vendors will start promising it or losing sales.
- jugbee 10y ago
  Blackberry android phones does this. They patch phones the same day google nexus is patched or even earlier for beta program users. Still no one is buying them
- myowncrapulence 10y ago
  the kind of problem the free market could solve Yet the free market doesn't solve this problem.
  - danudey 10y ago
    The market obviously isn't free enough. Maybe we should stop taxing rich people.
    - UniversalBlue 10y ago
      Yeah, poor rich people, being taxed to death. How can they afford their gold iPhones now?
- rpedroso 10y ago
  The underlying assumption is that a multitude of users would switch to devices produced by such a manufacturer. This, I think, overestimates how much most users currently care about security. As it turns out, there are more secure devices in the marketplace than the affected phones, but they cost more. All other things equal, a contractual obligation for security policies would increase the cost (and thus price) of devices, and users would likely stick with cheaper options.
s_q_b 10y ago
Right now, Google has no credible open competitor to Android, and not for lack of trying. If Android wants to be the Windows to iPhone's Mac, it will have to get serious about security, or be swept away by the competitors which will inevitably emerge. I also want to say that voting machines run unsupported Android builds. If Google is derelict in that duty... well, that's a much bigger deal than some compromised Google accounts.
- matt_wulfeck 10y ago
  I never heard that about voting machines. Do you have a source for that? I'm not sure why that's more surprising than hearing that they run Windows XP...
  - s_q_b 10y ago
    These are the certified electronic voting machines (DREs) for Pennsylvania: http://www.dos.pa.gov/VotingElections/OtherServicesEvents/Pages/Voting-Systems.aspx http://www.dos.pa.gov/VotingElections/OtherServicesEvents/Pa... The Android device in use is the EA Tablet. The certification tests are listed in "EA TABLET FOR ANDROID WITH JELLYBEAN 4.2.1 ELECTRONIC Test Report," dating from 2013. To be fair, it's probably the best of the horrible lot in security, but that ain't saying much. For example, the iVotronic systems contain a readily accessible compact flash card right on the top, which stores the election returns. Demonstration machines are set up in each county, so I went to see one in person. Unsurprisingly, the demo machine's card wasn't even covered with a tamper-evident seal. The devices, including the compact flash cards and the PEBs, are reused from year to year because the legally required certification for the device is very narrow. As the demo machine compact flash cards and PEBs are re-used in each election, at any time prior to the election, infecting the demo machine can be used as a vector to attack the entire county voting total. Since the demo machine is not sealed, its compact flash can be accessed. If the compact flash card is compromised, the system can be quickly owned. From there, the malware can spread rather trivially to the PEB unit used as a secure token by the election workers, and from there to the county's Unity system at Election Central, allowing the entire county's vote to be altered. So instead of the 4,500 machine compromises PA is claiming would be necessary to influence a state election, it would probably only take 6-7 people any time in the past ten years planting their malware in a few key counties. All one would need to do to untraceably change the vote totals would be walk in to the county election commission, swap the compact flash out for your malware, and leave. If you do this at any point prior to the election, the malware can spread from the demo machine, to a live voting machine, and finally, when the compact flash cards are entered into the Unity system for final tally, the malware can compromise the whole lot. Then the malware would self-delete, leaving no reliable paper audit record. Interestingly, from a legal perspective, the Secretary of the Commonwealth's certification for these machines is contingent upon the locking mechanism preventing access to the compact flash card. The machine that I saw, the most common model in use in the state, physically could not be secured that way. The plastic cover mechanism to which the lock is affixed simply doesn't cover the flash card slot well enough. Under the PA election code, if a specific requirement of the Secretary's certification is not met, the law would invalidate the votes cast through all the iVotronics as a matter of law. As the machines were not configured as approved, they aren't approved for casting ballots, which would throw the PA recount into chaos. It's probably the only judicial avenue left to sue for a state-wide recount that might actually have a chance of being considered. Nobody tell Jill Stein. In all liklihood, the PA legislature would just send the current electors anyway, as is their prerogative.

by Pxtl 10y ago

Kurtz79 10y ago

Google in most cases is not the device's manufacturer, and in a mobile device OS and application SW are tightly coupled, so you cannot really have OS updates separate from firmware updates, bypassing the actual manufacturer's own updates. Google (and Apple and Microsoft) can totally do it for devices that manufactures and maintains on its own, and actually it is one of the selling points of their new phone. In addition, at least in the US, devices connecting to a cellular network have to go through a certification process, enforced by the carriers, and every firmware update requires additional regression testing (time and money) for the device to be admitted on the network again. (That's my guess of why Lenovo dropped the policy of fast updates for Moto phones when they bought Motorola)

jdietrich 10y ago
Google have an approval system before they allow a manufacturer to bundle Google services. Update mechanisms could easily be built into that approval process. I suspect that they haven't turned the screws too hard on manufacturers for fear of Samsung or LG making an Amazon-style fork. Google have already drawn their own roadmap with the Android One project - a number of low-end manufacturers have devices that get updates directly from Google. They could easily create a Nexus-type brand that manufacturers can opt into, guaranteeing timely updates and long-term support. This could be a big draw for mid-tier manufacturers. https://en.wikipedia.org/wiki/Android_One https://en.wikipedia.org/wiki/Android_One
- deleted 10y ago
  [deleted]
- djsumdog 10y ago
  Exactly. Apple only has one set of hardware to support. Microsoft support the PC platform and you can usually do a fresh install on any machine and it will boot (driver support is a little different). Android is garbage in this regard. Google binds everyones' feet with the OHA so they are required to use the Google Play Store and services (and they can also never manufacture Amazon devices) yet they don't standardize the system to ensure that AOSP can install anywhere. Part of this is the difficulty of ARM not really being an architecture, but even Microsoft was able to deal with this by requiring UEFI and some standardization on Windows devices (although they're more like Apple where there's limited hardware to support). Google makes a ton of money from their licensing. It's in their advantage that people buy new phones all the time. If the hardware wasn't all over the place, we'd see more uptake for thinks like Plasma. What are the alternatives right now for software devs that are willing to do their own roll-your-own work? Ubuntu Touch doesn't seem to have been updated for most of their ports in forever. Plasma supports two devices, neither of which have sdcard slots.
  - amyjess 10y ago
    > Part of this is the difficulty of ARM not really being an architecture, but even Microsoft was able to deal with this by requiring UEFI and some standardization on Windows devices (although they're more like Apple where there's limited hardware to support). Well, the reason why PCs are a standardized platform is because the industry was built around cloning the AT. If anything wanted to be successful, it had to do everything the AT did the way the AT did it. Once the AT started getting long in the tooth, the industry got together to agree on further standards like the ISA bus (an extended version of the AT's bus), various ATA storage standards (again, derivative of the AT's storage protocol), the ATX form factor, the PC System Design Guide (PC 97/98/99/2001), etc. The PC industry has a culture of working together and collaborating for the sake of compatibility. For part of this, Intel was involved with the standardization process (something ARM refuses to do), but even they didn't have the full authority to force anyone to adopt their standards. In fact, there were plenty of manufacturers of x86 machines who decided to skip out on PC compatibility entirely in order to do their own thing. Just go ahead and try to install Windows 3.1 on a WonderSwan, for example. It's x86, but not a PC or any kind of AT clone. The industry simply declined to see it as a PC and moved on. It's a shame that nobody in the phone industry every attempted a hardware standardization effort. Google and Qualcomm could've worked together to come up with some real standards, but they dropped the ball. I have to wonder if Google would've been able to force something through if they made Android run entirely on native code instead of shoving everything into a Java-based VM. If the industry couldn't take the shortcut of "let's just port Dalvik to our hardware and call it a day" and instead had to ensure compatibility for a wide array of native software, they might actually have developed some form of collaborative discipline. What Google needs to do now is collaborate with Qualcomm and come up with their own standardized hardware platform. Create a phone equivalent to PCI, ATX, PC 98, etc. And then refuse to license Android to any device that isn't built on this platform. They should complete the process of moving AOSP into GApps, replace the Linux kernel with a closed-source BSD derivative, and then announce the closure of AOSP. They should do with Android exactly what Microsoft does with desktop Windows.
archivator 10y ago
> and in a mobile device OS and application SW are tightly coupled I call bullshit. There's no reason Google can't update everything AOSP-y in /system - libc, libart, libwebkit etc. > Google (and Apple and Microsoft) can totally do it for devices that manufactures and maintains on its own That's a low bar. When you buy a Dell laptop, you continue to receive updates from Microsoft. This is the bar we should hold Google to. As for the certification process, surely having one update that ships to N models is easier to test than N updates shipping to N models?
- kyrra 10y ago
  Except it's not that simple in the Android world. Someone explained it really well a couple days ago: https://news.ycombinator.com/item?id=13057605 https://news.ycombinator.com/item?id=13057605 The basics are that every phone out there uses a forked Linux kernel patched to hell to get it working. Since none of the drives are upstreamed it's unmaintainable. The linux kernel does not have a stable driver interface so shipping updates to phones is a LOT of work.
  - deleted 10y ago
    [deleted]
  - mortehu 10y ago
    This doesn't explain why they can't upgrade user-space applications and libraries. It's very rare for a user-space application upgrade to require a kernel update on any major operating system.
- Kurtz79 10y ago
  > and in a mobile device OS and application SW are tightly coupled I call bullshit. There's no reason Google can't update everything AOSP-y in /system - libc, libart, libwebkit etc. That's not the point. Even if it were so, it's still responsibility of the manufacturer to integrate it in its own firmware and push the update with the carrier's approval. You are comparing a laptop to a smartphone, which makes no sense, the smartphone has to connect to cellular network to be useful, and it's the carrier that establishes the rules for the update process. I agree that it should work as you say for devices with no cellular connectivity, such as WiFi only tablets, where no other parties other than the OS and device manufacturers are involved.
nradov 10y ago
That is specifically a design flaw in the AOSP. Right now manufacturers have to integrate their custom device drivers into every new OS build, leading to long delays and fragmentation. The device drivers should be separate, and the OS should expose a stable API and integration points. That way OS upgrades could be pushed out without breaking everything, just like with desktop OSs.
- zigzigzag 10y ago
  That's not Google's policy, it's Linux. What you suggest would mean abandoning Linux as a kernel. I'd be all for it - the industry needs some more open source kernel competition.
  - dep_b 10y ago
    Linux is a bad choice for a half-open environment. Either it's totally open (like most Linux distros) or everything is done by the manufacturer (like routers). But not this garbage with closed source drivers that will prevent you from recompiling eventually somewhere in the future.
  - nradov 10y ago
    No one is stopping Google from forking Linux, or using a different OS kernel.

sqeaky 10y ago

> Being able to buy a new computing device from a store that will receive no security updates is terrible, and is fairly common in Android devices. This seems like the kind of problem the free market could solve. Just get one phone vendor to guarantee secruity updates for a few years and then some customers will start buying those phones. After a while other vendors will start promising it or losing sales.

jugbee 10y ago
Blackberry android phones does this. They patch phones the same day google nexus is patched or even earlier for beta program users. Still no one is buying them
myowncrapulence 10y ago
the kind of problem the free market could solve Yet the free market doesn't solve this problem.
- danudey 10y ago
  The market obviously isn't free enough. Maybe we should stop taxing rich people.
  - UniversalBlue 10y ago
    Yeah, poor rich people, being taxed to death. How can they afford their gold iPhones now?
rpedroso 10y ago
The underlying assumption is that a multitude of users would switch to devices produced by such a manufacturer. This, I think, overestimates how much most users currently care about security. As it turns out, there are more secure devices in the marketplace than the affected phones, but they cost more. All other things equal, a contractual obligation for security policies would increase the cost (and thus price) of devices, and users would likely stick with cheaper options.

s_q_b 10y ago

Right now, Google has no credible open competitor to Android, and not for lack of trying. If Android wants to be the Windows to iPhone's Mac, it will have to get serious about security, or be swept away by the competitors which will inevitably emerge. I also want to say that voting machines run unsupported Android builds. If Google is derelict in that duty... well, that's a much bigger deal than some compromised Google accounts.

matt_wulfeck 10y ago
I never heard that about voting machines. Do you have a source for that? I'm not sure why that's more surprising than hearing that they run Windows XP...
- s_q_b 10y ago
  These are the certified electronic voting machines (DREs) for Pennsylvania: http://www.dos.pa.gov/VotingElections/OtherServicesEvents/Pages/Voting-Systems.aspx http://www.dos.pa.gov/VotingElections/OtherServicesEvents/Pa... The Android device in use is the EA Tablet. The certification tests are listed in "EA TABLET FOR ANDROID WITH JELLYBEAN 4.2.1 ELECTRONIC Test Report," dating from 2013. To be fair, it's probably the best of the horrible lot in security, but that ain't saying much. For example, the iVotronic systems contain a readily accessible compact flash card right on the top, which stores the election returns. Demonstration machines are set up in each county, so I went to see one in person. Unsurprisingly, the demo machine's card wasn't even covered with a tamper-evident seal. The devices, including the compact flash cards and the PEBs, are reused from year to year because the legally required certification for the device is very narrow. As the demo machine compact flash cards and PEBs are re-used in each election, at any time prior to the election, infecting the demo machine can be used as a vector to attack the entire county voting total. Since the demo machine is not sealed, its compact flash can be accessed. If the compact flash card is compromised, the system can be quickly owned. From there, the malware can spread rather trivially to the PEB unit used as a secure token by the election workers, and from there to the county's Unity system at Election Central, allowing the entire county's vote to be altered. So instead of the 4,500 machine compromises PA is claiming would be necessary to influence a state election, it would probably only take 6-7 people any time in the past ten years planting their malware in a few key counties. All one would need to do to untraceably change the vote totals would be walk in to the county election commission, swap the compact flash out for your malware, and leave. If you do this at any point prior to the election, the malware can spread from the demo machine, to a live voting machine, and finally, when the compact flash cards are entered into the Unity system for final tally, the malware can compromise the whole lot. Then the malware would self-delete, leaving no reliable paper audit record. Interestingly, from a legal perspective, the Secretary of the Commonwealth's certification for these machines is contingent upon the locking mechanism preventing access to the compact flash card. The machine that I saw, the most common model in use in the state, physically could not be secured that way. The plastic cover mechanism to which the lock is affixed simply doesn't cover the flash card slot well enough. Under the PA election code, if a specific requirement of the Secretary's certification is not met, the law would invalidate the votes cast through all the iVotronics as a matter of law. As the machines were not configured as approved, they aren't approved for casting ballots, which would throw the PA recount into chaos. It's probably the only judicial avenue left to sue for a state-wide recount that might actually have a chance of being considered. Nobody tell Jill Stein. In all liklihood, the PA legislature would just send the current electors anyway, as is their prerogative.