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.

Sign up for GitHub

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

Jump to bottom

Enabling users to remove window.ipfs attribute #451

Closed
lidel opened this issue Apr 12, 2018 · 2 comments
Closed

Enabling users to remove window.ipfs attribute #451

lidel opened this issue Apr 12, 2018 · 2 comments
Assignees
@lidel
Labels
area/window-ipfs Issues related to IPFS API exposed on every page help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/in-progress In progress topic/security Work related to security
Milestone
v2.4.0

Comments

@lidel
Copy link
Member

lidel commented Apr 12, 2018 •
edited
Loading

Is it possible to completely/selectively prevent websites from knowing I have IPFS running in my browser?

Or does this extensions have the same issues as Metamask[0], which means there's no way to hide the fact that one has the extension installed?

This is a pretty important privacy feature, because I'm pretty sure the presence of such an extension massively increases the accuracy of targeting.

– asymmetric, https://news.ycombinator.com/item?id=16824809

That is a valid point.

  • Right now window.ipfs is always present (even if access is disabled via Preferences), and can be used for fingerprinting.
  • Content script should be smarter and window.ipfs should not be created if window.ipfs is disabled via Preferences.
    • Ideally, it should not be all-or-nothing. User should be able to choose to whitelist specific domains for use with window.ipfs, but hide it for everything else (disabling fingerprinting by malicious sites)
@lidel lidel added kind/enhancement A net-new feature or improvement to an existing feature topic/security Work related to security area/window-ipfs Issues related to IPFS API exposed on every page labels Apr 12, 2018
@lidel lidel mentioned this issue Apr 13, 2018
Closed
12 tasks
@lidel lidel added the help wanted Seeking public contribution on this issue label Apr 13, 2018
@JonKrone JonKrone mentioned this issue Apr 13, 2018
Closed
@alanshaw
Copy link
Member

Now that we have different manifests for different builds we could fix this in Firefox by moving the content_script entry into the non-firefox manifest and using browser.contentScripts API if Firefox is detected.

@lidel lidel self-assigned this Jun 8, 2018
@lidel lidel added the status/in-progress In progress label Jun 8, 2018
@lidel lidel added this to the v2.4.0 milestone Jun 8, 2018
lidel added a commit that referenced this issue Jun 8, 2018
@lidel
feat: use browser.contentScripts API in Firefox
7f22455 
This change enables Firefox users to disable creation of window.ipfs,
solving fingerprinting issue raised in:
#451

The key difference between tabs.executeScript and contentScripts API
is that the latter provides guarantee to execute before anything else.

Chrome does not provide contentScripts API and we need to statically
load content_script via  manifest.

More info on the underlying issue:
#368
#362 (comment)
@lidel lidel mentioned this issue Jun 8, 2018
Merged
lidel added a commit that referenced this issue Jun 13, 2018
@lidel
feat: use browser.contentScripts API in Firefox
30a7fef 
This change enables Firefox users to disable creation of window.ipfs,
solving fingerprinting issue raised in:
#451

The key difference between tabs.executeScript and contentScripts API
is that the latter provides guarantee to execute before anything else.

Chrome does not provide contentScripts API and we need to statically
load content_script via  manifest.

More info on the underlying issue:
#368
#362 (comment)
lidel added a commit that referenced this issue Jun 14, 2018
@lidel
feat: use browser.contentScripts API in Firefox
52b0190 
This change enables Firefox users to disable creation of window.ipfs,
solving fingerprinting issue raised in:
#451

The key difference between tabs.executeScript and contentScripts API
is that the latter provides guarantee to execute before anything else.

Chrome does not provide contentScripts API and we need to statically
load content_script via  manifest.

More info on the underlying issue:
#368
#362 (comment)
lidel added a commit that referenced this issue Jun 15, 2018
@lidel
Merge pull request #495 from ipfs-shipyard/feat/hide-window.ipfs
032ebdd 
This PR enables Firefox users to disable creation of `window.ipfs` attribute via _Preferences_ screen, solving fingerprinting issue raised in #451.

It requires webpack, so should be merged after #498 

### Background

Existing `tabs.executeScript` API with `runAt: 'document_start'` flag was executing too late and page scripts were  unable to detect `window.ipfs` correctly.  More info on the underlying issue: #368 #362 (comment)

As a workaround that worked in both Chrome and Firefox, we were forced to always load content script via manifest definition. This meant no control over when it is loaded and no easy off switch. If `window.ipfs` was disabled via _Preferences_, it was throwing an Error on access, but remained in the scope.

Mozilla added [`contentScripts`](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contentScripts/register) API in Firefox 59. The key difference between `tabs.executeScript` and `contentScripts` API is that the latter provides guarantee to execute before anything else on the page, passing [our synchronous smoke test](https://ipfs-shipyard.github.io/ipfs-companion/docs/examples/window.ipfs-fallback.html). 

### Known Issues

Chrome does not provide `contentScripts` API so it will continue to statically load `content_script` via  manifest.  Hopefully with time, other browser vendors will adopt the new API.
@lidel
Copy link
Member Author

lidel commented Jun 20, 2018

Enabling users to remove window.ipfs attribute

Since v2.3.1.9890 Firefox users can disable creation of window.ipfs attribute via Preferences screen (or via a global "active/suspend" toggle) providing a fix for fingerprinting issue. More details in PR #495.

Chrome does not provide contentScripts API so it will continue to statically load content_script via manifest and Preferences will simply block access to API without removing window attribute. Hopefully with time, Chrome and other vendors will adopt the new content script API.

I am closing this issue, as this is all we can do fingerprint-wise for window.ipfs given currently available APIs.

Future Work

Some thoughts on exposing IPFS API on-demand in fingerprint-resistant way can be found in #454 (comment)

@lidel lidel closed this as completed Jun 20, 2018
@lidel lidel changed the title Prevent websites from knowing I have IPFS running in my browser Enabling users to remove window.ipfs attribute Jun 20, 2018
@lidel lidel mentioned this issue Jun 28, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lidel lidel

Labels
area/window-ipfs Issues related to IPFS API exposed on every page help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/in-progress In progress topic/security Work related to security
Projects
None yet
Milestone
v2.4.0
Development

No branches or pull requests
2 participants
@alanshaw @lidel