package.json

{
  "name": "evercookie-dist-only",
  "description": "evercookie is a javascript API that produces extremely persistent, respawning cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (LSOs), HTML5 storage, SilverLight storage, and others. http://samy.pl/evercookie",
  "version": "0.0.3",
  "author": "",
  "homepage": "https://github.com/samyk/evercookie",
  "repository": {
    "type": "git",
    "url": "git://github.com/samyk/evercookie.js.git"
  },
  "bugs": {
    "url": "https://github.com/samyk/evercookie/issues"
  },
  "license": {
    "name": "MIT",
    "url": "http://www.opensource.org/licenses/mit-license.php"
  },
  "keywords": [
    "cookie",
    "cookies",
    "evercookie",
    "persistance"
  ],
  "readme": "Evercookie\n==========\n\nEvercookie is a Javascript API that produces extremely persistent cookies in a\nbrowser. Its goal is to identify a client even after they've removed standard\ncookies, Flash cookies (Local Shared Objects or LSOs), and others.\n\nThis is accomplished by storing the cookie data as many browser storage\nmechanisms as possible. If cookie data is removed from any of the storage\nmechanisms, evercookie aggressively re-creates it in each mechanism as long as\none is still intact.\n\nIf the Flash LSO, Silverlight or Java mechanism is available, Evercookie can even propagate cookies\nbetween different browsers on the same client machine!\n\nBy [Samy Kamkar](http://samy.pl), with awesome [contributions from others](https://github.com/samyk/evercookie/graphs/contributors)\n\nBrowser Storage Mechanisms\n--------------------------\n\nClient browsers must support as many of the following storage mechanisms as\npossible in order for Evercookie to be effective.\n\n- Standard [HTTP Cookies](http://en.wikipedia.org/wiki/HTTP_cookie)\n- Flash [Local Shared Objects](http://en.wikipedia.org/wiki/Local_Shared_Object)\n- Silverlight [Isolated Storage](http://www.silverlight.net/learn/quickstarts/isolatedstorage/)\n- CSS [History Knocking](http://samy.pl/csshack/)\n- Storing cookies in [HTTP ETags](http://en.wikipedia.org/wiki/HTTP_ETag) ([Backend server](#backend-server) required)\n- Storing cookies in [Web cache](http://en.wikipedia.org/wiki/Web_cache) ([Backend server](#backend-server) required)\n- [window.name caching](http://en.wikipedia.org/wiki/HTTP_cookie#window.name)\n- Internet Explorer [userData storage](http://msdn.microsoft.com/en-us/library/ms531424.aspx)\n- HTML5 [Session Storage](http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute)\n- HTML5 [Local Storage](http://dev.w3.org/html5/webstorage/#dom-localstorage)\n- HTML5 [Global Storage](https://developer.mozilla.org/en/dom/storage#globalStorage)\n- HTML5 [Database Storage via SQLite](http://dev.w3.org/html5/webdatabase/)\n- HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images ([Backend server](#backend-server) required)\n- HTML5 [IndexedDB](http://www.w3.org/TR/IndexedDB/)\n- Java [JNLP PersistenceService](http://docs.oracle.com/javase/1.5.0/docs/guide/javaws/jnlp/index.html)\n- Java exploit [CVE-2013-0422](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0422) - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive.\n\nTo be implemented someday (perhaps by you?):\n\n- [HTTP Strict Transport Security](https://sites.google.com/a/chromium.org/dev/Home/chromium-security/client-identification-mechanisms#TOC-Lower-level-protocol-identifiers) Pinning\n- Google Gears\n- Using Java to produce a unique key based off of NIC info\n- Caching in [HTTP Authentication](http://en.wikipedia.org/wiki/Basic_access_authentication)\n- Other methods? Please comment!\n\nThe Java persistence mechanisms are developed and maintained by [Gabriel Bauman](http://gabrielbauman.com)\n[over here](https://github.com/gabrielbauman/evercookie-applet).\n\nBackend Server\n--------------\nSome of the storage mechanisms require a backend server. This package comes with PHP implementation of the etag, cache and png backend servers.\n- For Node.js version, please visit [node-evercookie](https://github.com/truongsinh/node-evercookie).\n- For Django version, please visit [Django Evercookie](https://github.com/gdmka/django_evercookie)\n\nCaveats\n-------\n\nBe warned! Evercookie can potentially cause problems for you or your users.\n\n- Some storage mechanisms involve loading Silverlight or Flash in the client\n  browser. On some machines this can be a very slow process with lots of disk\n  thrashing. On older mobile devices this can render your site unusable.\n\n- CSS History Knocking can cause a large number of HTTP requests when a cookie\n  is first being set.\n\n- In some circles, it is considered rude to use Evercookie. Consider your\n  reputation and your audience when using Evercookie in production.\n\n- Browser vendors are doing their best to plug many of the holes exploited by\n  Evercookie. This is a good thing for the Internet, but it means what works\n  today may not work so well tomorrow.\n\nYou are responsible for your own decision to use Evercookie. Choose wisely.\n\nGot an idea?\n------------\n\nOpen a pull request!\n",
  "readmeFilename": "README.md",
  "_id": "evercookie-dist-only@0.0.3",
  "_shasum": "7d0ed40163f91af4cea0ab63efa7281b4731984a",
  "_from": "evercookie-dist-only@0.0.3",
  "_resolved": "https://registry.npmjs.org/evercookie-dist-only/-/evercookie-dist-only-0.0.3.tgz"
}