Closed
Bug 779197
Opened 12 years ago
Closed 6 years ago
Use a protocol not accessible from content
Categories
(Add-on SDK Graveyard :: General, defect, P3)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: ochameau, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: privacy, Whiteboard: [fingerprinting])
As reported by Jorge, some hackers exposed ways to detect which addons are installed by loading resource:// URIs. And as all jetpack addons use these URIs it make them a bit more unsafe. We should use another protocol which would prevent that by disallowing loading it from content.
Reporter | ||
Comment 1•12 years ago
|
||
We already discussed about new protocol specific to addon content in bug 644595, as part of Addon Page API.
Reporter | ||
Comment 2•12 years ago
|
||
Blackhat hack description: https://media.blackhat.com/bh-us-12/Briefings/Fleischer/BH_US_12_Fleischer_Implementing_Web_Tracking_gfleischer_WP.pdf
Priority: -- → P1
Comment 3•11 years ago
|
||
Do we have any more details on how he detected add-ons in this way? The paper is pretty short on details and I want to test if the fix I have solves it or not.
Updated•11 years ago
|
Assignee: nobody → dtownsend+bugmail
Comment 4•11 years ago
|
||
Nevermind, I found something that works. I recommend we don't land this before implementing bug 820213 for people who actually want to inject content into content
Depends on: 820213
Comment 5•11 years ago
|
||
We could use an approach that I used in Scriptish to block requests to an add-on's resource: uri if the request comes from page that is not a chrome or resource uri. https://github.com/scriptish/scriptish/blob/master/extension/components/scriptish.js#L192-L198 I think we could even block requests to the internal directories via its resource: uri from outside the add-on.
Updated•11 years ago
|
Flags: needinfo?(dtownsend+bugmail)
Comment 6•11 years ago
|
||
I have an example of the issue on https://github.com/scriptish/scriptish/wiki/FAQ:-What-are-the-security-benefits-over-Greasemonkey%3F in the 'Stealth' section.
Comment 7•11 years ago
|
||
(In reply to Erik Vold [:erikvold] [:ztatic] from comment #5) > We could use an approach that I used in Scriptish to block requests to an > add-on's resource: uri if the request comes from page that is not a chrome > or resource uri. > > https://github.com/scriptish/scriptish/blob/master/extension/components/ > scriptish.js#L192-L198 > > I think we could even block requests to the internal directories via its > resource: uri from outside the add-on. It's a solution, but it adds a lot of work (every add-on with its own content policy for every url access from every page!) that can be avoided with a custom protocol. I should have a proof of concept up in the next few days.
Flags: needinfo?(dtownsend+bugmail)
Updated•11 years ago
|
Keywords: privacy
Summary: Use protocol not accessible from content → Use a protocol not accessible from content
Whiteboard: [fingerprinting]
Updated•10 years ago
|
Assignee: dtownsend+bugmail → nobody
Updated•8 years ago
|
Priority: P1 → --
Updated•7 years ago
|
Blocks: uplift_tor_fingerprinting
Comment 8•6 years ago
|
||
I feel like this is a dupe of another bug, but I think Dan would know for sure.
Flags: needinfo?(dveditz)
Comment 9•6 years ago
|
||
I suppose we can call this done? Comment 0 is about add-ons. Legacy addons are gone and Web Extensions use moz-extension; comment 0 seems to be satisfied. resource:// still exists for internal Firefox resources (including system addons which might be hybrid/legacy ones) but bug 863246 made that better by requiring resources to be exposed intentionally.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•