-
Notifications
You must be signed in to change notification settings - Fork 325
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
Fixes window.ipfs is added after page load #368
Fixes window.ipfs is added after page load #368
Conversation
"swarm.peers", | ||
"swarm.addrs", | ||
"swarm.localAddrs" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Too permissive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a whitelist right? Any other calls will by default be blocked? Think they are all fine, but I do worry about for example MFS being totally open for everyone with access to window.ipfs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we remove all *.ls
from whitelist for now. Adding / reading specific hash can be done without explicit permission, but listing internal node states should require explicit confirmation.
"swarm.peers", | ||
"swarm.addrs", | ||
"swarm.localAddrs" | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we remove all *.ls
from whitelist for now. Adding / reading specific hash can be done without explicit permission, but listing internal node states should require explicit confirmation.
package.json
Outdated
@@ -44,6 +46,7 @@ | |||
"babel-preset-es2015": "6.24.1", | |||
"babel-preset-es2017": "6.24.1", | |||
"babelify": "8.0.0", | |||
"brfs": "^1.4.4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^
:))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry!
8c1fded
to
4604290
Compare
Tried it out, worked beautifully! Nice to see a IPFS app whose size is only 2.2K 👯 |
@@ -5003,7 +5343,7 @@ level-js@^2.2.4: | |||
typedarray-to-buffer "~1.0.0" | |||
xtend "~2.1.2" | |||
|
|||
level-js@timkuijsten/level.js#idbunwrapper: | |||
"level-js@github:timkuijsten/level.js#idbunwrapper": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird, somehow this changed from being a npm link (I think?) to being a github link, requiring git and therefore breaking the docker image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it in 1a968ee. More context:
Same thing happened to me after a
yarn cache clean
(trying to get a git branch dependency to update).Removing the
node_modules
folder and runningyarn
again seemed to work around the issue.
– yarnpkg/yarn#2083 (comment)
Closed since this seems to be resolved in recent versions.
– yarnpkg/yarn#2083 (comment)
@lidel good to merge now? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alanshaw after solving problem with git (1a968ee) now we are blocked by a problem with addon linter (npm run lint
):
ERRORS:
Code Message Description File Line Column
FILE_TOO_LARGE File is too large to parse. This file is not binary and is too large to parse. Files larger than 4MB will not be parsed. If your dist/contentScripts/ipfs-proxy/content.js
JavaScript file has a large list, consider removing the list and loading it as a separate JSON file
instead.
and indeed, our content scripts take more space than entire addon 🙃
--- ipfs-companion/add-on/dist ---
8.0 MiB [##########] /contentScripts
3.9 MiB [#### ] ipfs-companion-common.js
1.2 MiB [# ] /background
404.0 KiB [ ] /popup
184.0 KiB [ ] /pages
64.0 KiB [ ] /options
--- ipfs-companion/add-on/dist/contentScripts/ipfs-proxy ---
4.1 MiB [##########] content.js
3.9 MiB [######### ] page.js
4.0 KiB [ ] inject-script.js
eek, wtf?! I'm guessing that's because we're adding |
I am afraid removing |
I can bring |
Yes, we can minimize the output as long we have reproducible builds (#306). |
@lidel what did you do to fix the yarn issue? |
@alanshaw removing the |
🙄 that's what I did... |
Did you run via |
I did yes. I'm not sure how we can avoid this when our dependencies have github dependencies e.g. |
Temporary fix until ipfs#372 is merged
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)
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)
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)
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.
fixes #362
also fixes whitelist by default from review feedback
see #362 (comment) for discussion