I've never seen more huzzah over a smaller issue...
First off, who the hell searches for apps for their iOS device on a PC, rather than (wait for it...) I don't know, maybe their iOS device??!!
I mean, I'm sure some do... but it's gotta be something like 2%.
Secondly, to even insinuate that Google is generating these errors purposefully (that do FAR more to besmudge their own reputation than some small developers, and have simply zero negative effect on their competitors, no matter how much some of you are grasping) is the very height of delusional paranoia.
You're own bias is as unsupported as the opposite; some please me you're smugness.
Google has had a strong impact on those small devs, that's a fact and they deserve to as much flack as possible for that; why this happened could be incompetency or "evilness", but the impact is real.
I'm glad that Google has been "working hard" to find the solution.
It took me less than 5 minutes to view the page source and see how Google's page scraping algorithm was interpreting an empty value in the App Store page as a minimum value. A trivial range checking error that even the barest minimum of testing should have caught, if Google actually cared.
"Google" (as in the press release people) would likely have no idea that the developer(s) were not "working hard" on a solution. They just report what they've been told by the developer's manager.
Depends on the test cases, of course. Hindsight is always 20-20.
Some developer chose the wrong field to scrape -- and then the wrong way to present an empty value -- and is no doubt now getting heat over it.
Every developer has made a similar mistake, or will do so, at some point.
It's not like choosing the wrong field is something that could remain unnoticed for long.
"Google" (as in the press release people) would likely have no idea that the developer(s) were not "working hard" on a solution. They just report what they've been told by the developer's manager.
Depends on the test cases, of course. Hindsight is always 20-20.
Some developer chose the wrong field to scrape -- and then the wrong way to present an empty value -- and is no doubt now getting heat over it.
Every developer has made a similar mistake, or will do so, at some point.
It's not like choosing the wrong field is something that could remain unnoticed for long.
Wow, you're sure trying hard aren't you. They will be sued for this. This is not excusable.
Or, you know - the Store's way of presenting ratings has changed slightly - and Google simply haven't updated their scraper to reflect it.Some developer chose the wrong field to scrape -- and then the wrong way to present an empty value -- and is no doubt now getting heat over it.
Apple didn't find the GoToFail bug, despite its existence raising serious compiler warnings for years.Do you know anyone who's been through a coding interview at Google? Or works / worked there?
Anyone who works there as a developer would need to perform at a level far above the skill level to get that right. Also, the same apples to code review / QA /etc... - which also "failed" to find this "bug" before it went live.
Or, you know - the Store's way of presenting ratings has changed slightly - and Google simply haven't updated their scraper to reflect it.
Apple didn't find the GoToFail bug, despite its existence raising serious compiler warnings for years.
Stuff slips no matter your profession level - especially if its low-priority stuff.
The code was/is open source and is part of the Darwin Kernel. The library in question is owned, and only used by Apple.Wasn't that bug in an open source library?
Don't confuse it for Heartbleed, a bug found shortly after in OpenSSL - a different library for the same purpose. That library is present mostly in Linux / Server software. However, Heartbleed's issue was an overrun, which isn't detected by compilers.Many people actually had it because of that.
The code was/is open source and is part of the Darwin Kernel. The library in question is owned, and only used by Apple.
Don't confuse it for Heartbleed, a bug found shortly after in OpenSSL - a different library for the same purpose. That library is present mostly in Linux / Server software. However, Heartbleed's issue was an overrun, which isn't detected by compilers.
As for number, keep in mind that as GoToFail affected the OSX / iOS kernel, any app on those platforms that used native networking APIs were vulnerable to the GoToFail bug. That means Mail, Safari, Facebook, Bank Apps, IM apps, etc etc.
Anyone who works there as a developer would need to perform at a level far above the skill level to get that right. Also, the same applies to code review / QA /etc... - which also "failed" to find this "bug" before it went live.
Accepting this as a normal "bug" is like accepting a raw/frozen hamburger patty in 50% of the happy meals you feed to your kids.
google is ****ting on iOS developers because nobody is writing apps for their mobile hemorrhoid platform.
Issue wasn't how long it took to fix; but the sheer number of failures that had to happen for this bug to be possible in the first place. The bug was total amateur hour, and demonstrated the complete absence of basic security auditing, proper use of their toolset, and proper coding practice. And its especially worrying that this occurred in critical code. In many environments, unreachable code warnings are elevated to errors - causing the compile to outright fail.Checked when the bug was found out,; the IOS 7.0.6 release basically came out about same time the bug came to light.
No, its also a problem in that it allows any website to spoof another. You can MITM locally, but you could also do it on the ISP level. This is exactly the type of bug/exploit NSA could've used for eavesdropping (if you're concerned about that).Essentially a problem if on a WIFI net you don't own AND know (like someone setting an access point in a mcdonals and spoofing the look of McD's landing page) and did a secure connection on such net while someone was doing a man in the middle attack on this vulnerability.
Issue wasn't how long it took to fix; but the sheer number of failures that had to happen for this bug to be possible in the first place. The bug was total amateur hour, and demonstrated the complete absence of basic security auditing, proper use of their toolset, and proper coding practice. And its especially worrying that this occurred in critical code. In many environments, unreachable code warnings are elevated to errors - causing the compile to outright fail.
No, its also a problem in that it allows any website to spoof another. You can MITM locally, but you could also do it on the ISP level. This is exactly the type of bug/exploit NSA could've used for eavesdropping (if you're concerned about that).
Don't even get me started on the difference between experienced people, and cheaper younger programmers who look good on paper.
I can't count the number of times I've seen a smart new programmer fail to correctly compensate for a null value. Or my favorite: treating a zip code as a number instead of a string.
Considering that only about a dozen developers complained on the Google forum, it's more like one out of every 100,000 apps or 0.001%.
What's weird is that some of the comments in the same developer threads were about trying to get Apple to help out:
Nov 3 - Senior Apple Advisor responds, "We’ve actually seen a few cases like this as well from other developers. It appears that if your application for its current version does not have enough ratings to display an average, Google’s search results displays the “null” item as a one star rating." and then, "We’ll have to wait to hear back from Google to see if they have any additional input as well."
Nov 18 - developer contacts Apple again, who says, "Right now we do have internal teams working on this issue and we are awaiting a response as soon as they are able to provide a resolution. I will be happy to follow up with you at that time."
Heh. Apple has "Teams working on" it. That's just PR like Google's "working hard on a solution."
Nov 19 - developer urges Apple to contact Google again. Apple rep says he did so, commenting, "Hopefully this information will get to the appropriate team and Apple and Google can get this oddity ironed out."
Another developer comments that that this is "Not exactly reassuring. I feel like Apple should be more concerned about this, considering it could be discouraging people from purchasing our apps and cutting into their revenue as well."
Dec 3 - another developer expresses concern that nothing seems to be happening: "Why is no one talking about this? Google is damaging our brand and Apple is too busy selling jewelry to help us."
Dec 4 - Google Help Forums Manager posts that a fix is on the way and all should be good by mid next week.
Ultimately I think it shows that Google needs to pay more attention to user feedback, and respond quicker. (Pretty much the same complaint that Apple users have on Apple support forums.)
That idea doesn't make sense at all, as the one star rating is based off the relatively rare event of someone's app having less than five reviews, not whether that app is available on both Android and iOS.
As I also pointed out, it's not a subtle bug either. It's something that would be noticed right away by those affected. Hardly the hallmark of a secret conspiracy.
-- REALITY CHECK:
The basic bug is that for whatever reason, Apple does not provide an average rating value until an app has at least five (5) reviews. So, rather than put zero stars, they put a null value. Someone at Google coded things so that null values got at least one star, when what they should've done is print "Not enough reviews available"... assuming that is, that the developer was aware of this review anomaly. If it was only tested on popular apps or ones that had not been very recently updated, the bug would not have shown up.
In the end, it took about a week for people to figure out the bug was real, another two weeks to contact the right people, and two weeks to create, test and deploy a fix. That's about normal time for such a bug. (There's rarely such a thing as a larger corporation testing and putting out a single fix... an update usually means that more than one fix has to be tested at the same time.)
Anyway, these things happen, no matter what the company. It's like when someone at Apple mistakenly (lazily) coded the iOS location cache to keep growing. Remember the anti-Apple conspiracy fest that followed? I said people should take off their tin foil hats then, too.
I've been working as a professional software engineer for over 28 years, with over 10 years in an ISO 9000 certified organization so I know about how software bugs happen.
Given google's position in the industry, this bug is appalling. It never should have happened. Assuming a value for a condition that clearly states no value (null), is clearly a concept from a CS101 level class. This was never Apple's bug.
You've been in the industry for 30 years and you're unfamiliar with the 2014 SSL incidents? Heartbleed and GoToFail should both be known to anyone in the industry since they put serious doubt in the popular assumption that because its open source, someone has reviewed it. GoToFail especially did this because of how trivial the bug was to detect, and how widely used the affected library was. The question raised: If something that easy and popular went undetected for so long, what else are we missing?You probably think I dropped off the boat; been in the industry for 30 years.
Not ideally worded, true - but you should still understand the threat. Any machine could present a certificate claiming to be someone else. The user could be attacked through bad links "BankOfAamerica.com", DNS poisoning, or questionable routing. The first requires some user error, true, but the latter are invisible to the user. And questionable routing incidents occur more often than you think.As for, ISP level... Good grief!