Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

"New Identity" button clears history but visited links still get ":visited" CSS style #20

Open
sintime opened this Issue Sep 1, 2012 · 9 comments

Comments

Projects
None yet
3 participants

sintime commented Sep 1, 2012

As the title says.

Browser history / cache / cookies get cleared, but visited links still receive a CSS highlight for ":visited" (purple by default). This could be subject to crafty attacks, but the original script-based attack of this leak does not appear work on iOS Safari — http://ha.ckers.org/weird/CSS-history-hack.html — visited links on this page get proper highlight but do not end up in the "visited" section as the JS attempts to do.

A warning message now shows up in the 1.2.6 version (should be available approx Sep. 12) when pressing the "New Identity" button.

More details in the following comments:


Original report:

Some links on some .onion sites seem to remain purple regardless of pressing "new identity" or indeed the complete deletion and reinstallation of the OnionBrowser.

I'm taking this as meaning there is some history being maintained?

Owner

mtigas commented Sep 6, 2012

Upon examining this some more, it looks like the OS keeps some sort of internal state regarding visited links (which provides the CSS highlight) and there looks to be no way to disable that.

In fact, it looks like "Private Browsing" mode in other third-party apps like iCabMobile have this same issue.

The following things happen when you hit "New Identity":

  • The UIWebView for the app is discarded and a totally new one is used whenever you hit the "New Identity" button, and this does remove all forward/back history information.
  • The app's browser cache is completely reset.
  • All cookies in the app's browser are cleared.
  • Tor attempts to get a "new identity" (new IP address).

Barring any miraculous ways of clearing the history (even this hack using a private internal framework does not properly prevent "visited" links from getting highlighted), I might just have to put a warning up when you press "New Identity", for those who need to avoid this particular attack vector.

Owner

mtigas commented Sep 6, 2012

I've added the warning message to the 1.2.6 build that I've uploaded to the App Store. Hopefully that'll get through review by this time next week.

The URL in that message redirects to this issue page (using my own private URL shortener).

I say that ""iOS is resistant to script-based" attacks because (like most modern browsers) visited/highlighted links on this test page — http://ha.ckers.org/weird/CSS-history-hack.html — do not end up in the "visited" section. (More info on that demo hack implementation: http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html )

Owner

mtigas commented Sep 6, 2012

or indeed the complete deletion and reinstallation of the OnionBrowser.

I'm not seeing this behavior when I force-quit the app. (Quit app, double-tap home, "delete" app from dock that appears.) Can you double-check this and make sure this is actually the case?

sintime commented Sep 6, 2012

Confirmed. Not only force quiting but uninstalling the app and reinstalling. This on the ipad if that effects anything.

sintime commented Sep 6, 2012

Haha ok scratch that. Did a little more investigating. The site I was viewing had a bunch of links which were of the form link :)
So they were links to the current page and were basically purple whenever that page was visited ;-)

So yeah, I don't think this is a bug or a privacy issue. Cheers!

Owner

mtigas commented Sep 8, 2012

Cool. Will leave this ticket open (due to the overall issue of the visited links highlighting), but at least force quitting does seem to clear that state if folks need to be that careful.

VohaBoba commented May 4, 2013

When I want to have new I'd I have the same problem.... Please help

VohaBoba commented May 4, 2013

New ID

Owner

mtigas commented Oct 10, 2013

Hrmph.

I thought dffce70 would’ve fixed it since now I figured out a way to wipe all files in the /Library folder for the app (which is the directory where app caches/cookies/etc are stored). (It did fix #26, which closes up a pretty big tracking hole in the app.)

But… Despite deleting all the files in that directory & starting a new UIWebView (since there is no way to "clear history" without generating a new WebView), this seems to persist.

mtigas added a commit that referenced this issue Oct 10, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment