Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please disable DOM localStorage and DOM sessionStorage (supercookies) if you can #63

Closed
hdatma opened this issue Jul 18, 2015 · 2 comments

Comments

@hdatma
Copy link

hdatma commented Jul 18, 2015

No description provided.

@jcs
Copy link
Contributor

jcs commented Aug 14, 2015

These should already be disabled by trying hidden WebKit flags (not sure if these do anything anymore):

https://github.com/OnionBrowser/iOS-OnionBrowser/blob/master/OnionBrowser/OnionBrowser/AppDelegate.m#L75

and then injecting Javascript into the beginning of HTML/Javascript downloaded that redefines the global functions that other Javascript would need to use storage:

https://github.com/OnionBrowser/iOS-OnionBrowser/blob/master/OnionBrowser/OnionBrowser/AppDelegate.m#L693

@mtigas
Copy link
Member

mtigas commented Oct 22, 2015

Per @jcs comment, I've done everything I can to disable these features. Unfortunately, it does look like the browser ignores that preference (I think it used to work in earlier versions of iOS — and it seems to work in the current version of the simulator).

Interestingly, this evercookie test fails http://samy.pl/evercookie/ but other tests just for localstorage/sessionstorage http://dev-test.nemikor.com/web-storage/support-test/ does show that the value is being written.

If you press "New Identity" or when you force-quit Onion Browser (or if it crashes) and you start it up again, the app will clear all local data. It's known that HTML5 storage and local databases are stored in the Caches directory of an app.

Testing this by setting "Allow All Active Content" (which takes away the JavaScript injection to overwrite global functions) and using the samy.pl test, you will get the "evercookie" set; then pressing "New Identity" properly wipes the value from all mechanisms on that test.

So unfortunately, because we actually don’t have direct access to WebKit (only the APIs given to us in UIWebView & associated controllers), any blocking code the app provides is disadvantaged and can always be pre-empted by the OS and the framework. But the app does purge the data when it can (starting a new session of the app) and when the user prompts, which is maybe the best we can do without a chance of side effects (i.e. clearing the Caches during browser use).

@mtigas mtigas closed this as completed Oct 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants