Closed Bug 1036975 Opened 10 years ago Closed 8 years ago

Content Security Policy breaks Webmaker's X-Ray Goggles

Categories

(Webmaker Graveyard :: X-Ray Goggles, defect)

Product:
Webmaker Graveyard
Component:
X-Ray Goggles
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: avarma, Assigned: avarma)

References

(Depends on 1 open bug)

Details

Unfortunately, as CSP is adopted by the world's most popular sites, they become un-remixable via the Web X-Ray Goggles due to Bug 866522 (Chrome and other browsers have similar behavior). In particular, Facebook uses CSP, and it's no longer remixable via the Goggles due to this. Which is highly unfortunate, because the first place lots of people go to try them out is Facebook.
Depends on: 866522
Summary: Content Security Policy breaks the Goggles → Content Security Policy breaks Webmaker's X-Ray Goggles
Should Goggles be an addon?
When I first created the Goggles, I specifically wanted them to work cross-browser, without a "proprietary" browser add-on needing to be created for every browser. There's a number of technical reasons for this, including the fact that some very locked-down environments (like libraries) might not allow users to install add-ons, while bookmarklets are OK. There are ideological reasons for it, too, though; the goggles are about showing people that *the Web itself* is hackable, not that the Web is hackable on a particular vendor's browser. If the goggles do need to be turned into an addon, I strongly believe that it should still be available for as many browsers as possible, rather than solely supporting Firefox only.
(In reply to Atul Varma [:atul] from comment #2) > If the goggles do need to be > turned into an addon, I strongly believe that it should still be available > for as many browsers as possible, rather than solely supporting Firefox only. Yes. I was referring to the generic term of "addons", not something Firefox-specific indeed.
Atul, do you think we can at least reliably detect sites where CSP will make the goggles impossible to use, and explain what is happening to users? Also, this bug makes me sad :(
Flags: needinfo?(avarma)
(In reply to Brett Gaylor [:brett] from comment #4) > Atul, do you think we can at least reliably detect sites where CSP will make > the goggles impossible to use, and explain what is happening to users? One possibility is to attach an onerror event handler to the script element inserted in the page. I haven't verified if CSP does actually trigger an error event on <script>. If someone finds out they don't, ping me, I'll report back to standards to figure out what is the appropriate behavior and file browser bugs as appropriate. CSP 1.1 has the concept of "violation event" which would be exactly what is needed to know for sure that CSP is blocking the script (and inform the user appropriately). It hasn't been implemented anywhere to the best of my knowledge. Bug on Firefox side is bug 1037335.
+1 to what David Bruant just said... If that doesn't work, another thing we can do is add a setTimeout in the code that waits a several seconds for the goggles' script to load, and if it hasn't loaded within that time frame, simply *assume* an error has happened (which could actually be CSP *or* a more general internet connectivity problem) and let the user know. However, it should be noted that any such functionality would need to be added to the bookmarklet's javascript: URL--the one that "bootstraps" the goggles by injecting a script tag into the current page--which means that people who have already dragged the bookmarklet to their bookmarks bar won't experience this new functionality.
Flags: needinfo?(avarma)
:atul - I don't think the bookmarklet fix would work either, since execution of the bookmarklet would likely be blocked too.
Assignee: nobody → avarma
Status: NEW → ASSIGNED
Flags: needinfo?(avarma)
Yeah, that's likely true Jon. I think the only case it'd work in would be for browsers that allow the inline script in bookmarklets to be executed but not for <script> tags to non-whitelisted domains to be loaded, and I don't even know if any browsers have that kind of behavior (it was suggested in some of the W3C threads I read as one possible interpretation of the "bookmarklets should still work" aspect of the CSP specification). Anyhow, what information do you need from me Jon? Should I be actively pursuing a solution for this, e.g. an add-on or contributing patches to browsers to ensure that bookmarklets still work on CSP sites?
Flags: needinfo?(avarma)
This is very hard to do in practice because most bookmarklet download the actual script from outside (they do so by adding a <script> element to the <head> of the document). How do you differentiate then when such a script is doing some action that should be prevented by CSP (like posting some content) ? I've another solution that does not involve installing add-ons or anything, in the former thread (search for my name). Basically, a bookmarklet could provide a "CSP-overide: form-action *.instapaper.com" directive in the initial javascript (since this is a string it's no-op in javascript, just like "use strict"). When installing such bookmarklet, Firefox could parse this and pop up a security dialog asking the user the permission ("do you allow this bookmarklet to post to *.instapaper.com ?"). If the user refuse, the bookmarklet is not installed. If she accepts, the bookmarklet is installed. Whenever the user clicks on the bookmarklet, the CSP override directive is merged, and the bookmarklet is run. Everything will then work. It's the only solution that really, really safe (safety is as high as it could be), the user is aware of it (unlike while-listing script that no one will know how to do), and this requires very small work from what we have now (even the security dialog is already existing for add-ons). It's declarative: the bookmarklet author told his intends and can not change them (even if the bookmarklet download another script, this other script would not merge the CSP-Override) without having the user reinstall the bookmarklet (and thus, being presented a new security dialog).
Marking this as resolved as we move to deprecate the Webmaker Product on BZ. X-Ray Goggles issues can be filed/refiled at https://github.com/mozilla/goggles.mozilla.org/issues/new
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.