Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Flaw in Chrome for iOS 7 Reveals Incognito Searches
- Thread starter MacRumors
- Start date
- Sort by reaction score
You can get semantic on the word "bug" if you like. It shows your inexperience as a developer (if you even are one). When something works incorrectly vs. intent, it is a bug. Documenting the shortcoming doesn't change that. At the very least, it is a feature design bug, even if you refuse to acknowledge it as an engineering bug.
And your reasons are non-sensical. The bug is how incognito searches are accidentally/unintentionally shown in normal mode. That is easily fixed with no downside whatsoever.
The fact that local storage data can't be truly sandboxed is not the concern. But you're right, there is also no fix for that except to avoid using local storage at all when incognito (you could use session-based local storage, but that wouldn't guarantee the data to disappear by when you'd expect it to). Furthermore, that local storage can't be sandboxed is common across all browsers on all platforms; it is not specific to iOS.
The issue here is how Google specifically is utilizing local storage. They are saving data to local storage while incognito and then reading those same values while not incognito. Pretty straightforward flaw. Pretty trivial fix.
Where "they" here is referring to a website.
You have to remember that this could just as easily apply to any search engine or any site for that matter.
Actually, "they" here is referring to the browser reading/writing data from/to the local storage store. Depending what code the webpage includes, it may or may not communicate this data with the website, but it does not have to for the client-side storage to be useful.
Of course, the 'incognito-' prefix fix isn't *quite* the right way to go about it, since knowledge of that would enable a site to request a piece of data utilizing the publicly known prefix. Instead, you use a prefix generated as a hash of some hardware identifier unique to each phone. (That's a pretty common method used to protect browsers' various *other* config/data stores, so that an attacker can't simply point to one of those files in order to do something malicious.)
I don't find Bing to be all that great. I try to use DuckDuckGo as much as I can. Google is better though
At least they offer their browser alternative on other platforms. Where is safari elsewhere? O, yes..
Clearly it's a conspiracy by Google. It couldn't possibly actually be a "flaw" of iOS.
If you can't get your private browsing to work right, you should not advertise it as a feature. Blaming the OS maker because you can't figure out a way to implement your feature is not a reasonable excuse.
Try this modified version of the above steps:
- Open an Incognito window
- Navigate to bing.com
- Enter a search term and hit enter
- Open a non-Incognito window
- Navigate to bing.com
- Tap the search box on the page and NOT see Incognito searches
(If needed, go ahead perform additional steps to convince yourself that bing.com will indeed cache and display the search term between two non-Incognito windows.)
See the difference? We're still using Chrome. It's Google and Google alone, as easily demonstrated.
LOL. Ok. Apple, Samsung, Google, etc - they never release software that they themselves never acknowledge has flaws.
Yes - they should have had better QA. But not knowing personally how they developed or tested the App before it's release or if this "flaw" is more complicated than it appears to be - I'm not going to scream how Google is trying to screw everyone over and did it either on purpose or is making Apple the fall guy.
p.s. You know blame is a funny word here. One person can see a company blaming the other. Another person can see a company responding to a query as to why something glitched and providing an accurate answer.
Seems a little unfair to say that this isn't a problem in Safari because Safari doesn't support simultaneous regular and private tabs like Chrome does. I suppose this might be one reason why. Safari probably blows away all HTML 5 storage when switching, or swaps in a separate storage cache temporarily. Even if Chrome could do that it wouldn't help since it would need to have two separate but simultaneous pools. (Barring a way to share the pool with hidden keys somehow.)
You don't understand the problem.
HTML 5 Local Storage allows websites to store information in your browser.
Google Search (i.e. the page you go to on Google.com) stores your previous searches using the Local Storage feature.
Bing clearly does not, but that doesn't mean that other sites are not affected. Any other website that uses Local Storage (including MacRumors) will have the same problem - it just might not be as visible to the user. I have no idea what MacRumors is using Local Storage for, but it's there.
I don't understand why people are saying this.
Google posted a support article outlining the problem in June 2012 when Chrome for iOS launched. If it was a QA problem, they wouldn't have needed to do that.
Last edited:
Sorry, but need to call you out on this poor wording. Google.com is a website, Chrome is a browserthere is no Google.com browser.
I understand the technical side of the situation quite well, thank you.
The actual problem at hand is that the end-user has an expectation that Private ("Incognito") means Private. No cookies, no history, no trace whatsoever. An average user who explicitly uses an Incognito tab, then explicitly closes that tab when done, has reasonable expectation that the next person who touches that device cannot still see activity from the previous session.
Sure, a support note that "retracts" elements of the implied privacy covers them legally. But it was from day one a conscious design decision to push to local storage, even if from an Incognito tab - hence Google and Google alone. It is neither necessary to provide search functionality, nor by any stretch a requirement of the running platform.
Clearly it's a conspiracy by Google. It couldn't possibly actually be a "flaw" of iOS.
I blame everyone involved.
Why?
Cuz it's a lot more fun, that's why.
Damn you, everyone connected with this. All out to make my life fractionally more difficult. I hate you all.
I was able to reproduce these steps in Chrome for iOS. (Original steps did not work for me for some reason.)
Then I decided to try the same steps using iCab Mobile's private browsing mode and turning it off. iCab did not have the problem, the senrch results were not retained. So how is another third party browser able to do it correctly if Chrome can't?
I guess my point is that if it's working in another third party browser then google can't blame the problem on Apple's sandbox policy. There is obviously a way to handle it correctly.
But you haven't fixed it either. So it's your fault.
I don't use Chrome on iOS, because I put it on a home page I don't like to go to. So, I'm safe.
Clearly it's a conspiracy by Google. It couldn't possibly actually be a "flaw" of iOS.
And of course we should believe Google because they say so
I couldn't care less if Chrome dried up and blew away. See what I did there.