05-17-2013 7:38 AM
05-17-2013 7:52 AM
05-17-2013 7:58 AM
I love my Galaxy SIII! It has never given me any freezes, GPS has always worked wonderfully, never had trouble with downloads and is a nice looking unit.
05-17-2013 8:07 AM
05-17-2013 8:18 AM
05-17-2013 8:31 AM
05-17-2013 8:35 AM
05-17-2013 9:16 AM - last edited on 05-17-2013 9:28 AM by Phil-101
Thanks for your response Evandela, but we all already understand the process flow.
I think @ECERRL's concern is more along the lines of the end result of your process taking so long (much longer than the rest of your industry, by the way) to deliver one very time-sensitive aspect of this- security fixes. Every major release of Android (and iOS, and Windows Phone, etc.) contain security fixes and patches for known and potential threats, and the longer the corrective measures (contained in the updates) are delayed, the greater and more risk is introduced- which is a dangerous situation for all involved.
So let's talk about risks, and risk management. The risk begins initially with the device and user infected, placing the user's privacy and personal data/files at risk; which is a situation that is able to be handled effectively when it is one customer, or a handful of customers- but remember, the entire population of non-updated devices are actually at risk of infection. Now consider that at some point, a malware author will realize this, and as he/she always works to infect as many devices as possible, he/she might begin to look for commonalities between the devices; there's the base software the devices are all running, but there is also one common network (with the same protocols and underlying language) connecting all of these devices. So the formula for maximum delivery would become very simple at that point- infect a device, then penetrate the network to spread the infection. The scale could be immense, and while it has not happened yet, the risk is present, and every delay is playing with fire. Now I am sure you have backend support in place to prevent such a wildfire from occuring, but I would caution that your firewalls and anti-viral packet analyses are very likely focused on if the network itself is the end target, but what if it were simply the means of delivery, and the infection could pose as an upload to an url or something along those lines - would the backend support be effective (most likely not, or Dropbox would not work over your network)?
I do not point all of this out to scare anyone, but I work in risk management and am merely concerned that AT&T's view on this issue has been particularly one-sided, if we take the cookie-cutter narrative that the update process stalls because of error and problem and network deterioration factor testing at face value. Ironically by focusing only on the update package as released by the manufacturer (before infection risk can even really be known), the process is actually exponentially increasing infection risk in the name of protection! You see AT&T's protection is centered around the network itself, and NOT its end-users- the subscribers (customers who are paying for protected access to the service the network provides) with the devices who actually face the risk of infection and of privacy compromise.
<Legal discussions are not permitted per the Guidelines>
I could never let my company face such a potentiality as this (or I would be and should be fired), and am frankly surprised that this situation exists at all.
So what is my answer? Revamp your process (a mirror of Google's and Twitter's own):
First receive the update file from the OEM, do the initial network compliance tests, and push on to subscribers while also initiating internal vulnerability testing (focusing on the devices itself), then release low-level security patch updates as risks are discovered and solved. Rinse and repeat...
"pushing" the update really has to involve nothing more than hosting the file at the specified url, and having the software know where to look for it.
Divide the testing engineers into teams focused on aspects such as application compatibility, network compatibility, and infection/penetration risk, and working concurrently in the issue identification phase (only the actual solutions are part of the entire ecosystem).
set regular deadlines for solution releases
I think you would find a quicker (and more importantly) and more protective and effective solution, and would find that you had the support and loyalty of a much happier customer base (who are not constantly weighing the cost of an ETF vs. living in the fear of how unsafe your device actually is)
05-17-2013 9:19 AM
Lastly, I could buy the whole "...[software update] that is done right" argument if they were released without major bugs, but I actually have yet to experience that. It really does not seem that the users are the real focus of this whole process.
05-17-2013 9:35 AM
05-17-2013 10:22 AM
@Evandela - Sorry, I actually did think you worked for AT&T, so sorry about that! you are correct in that Google is trying to correct this, but I think bigger guns than Google will soon be getting involved over this issue. The FCC is currently re-writing their Online Safety Initiative under Consumer Safety, and the rumor is there is a good deal more about smartphones and malware now that smartphones have penetrated a significant part of the internet usage market.
thanks again for the clarification
05-17-2013 10:31 AM