Bug #10695

unscrubbed URL in .xsession-errors (and therefore, in whisperback report)

Added by goupille 2015-11-30 04:25:48 . Updated 2019-09-04 20:45:07 .

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-11-30
Due date:
% Done:

10%

Feature Branch:
whisperback:bugfix/10695-clean-urls
Type of work:
Code
Blueprint:

Starter:
Affected tool:
WhisperBack
Deliverable for:

Description

In at least one whipserback report there was part of the user’s browsing history. the URL appears in .xsession-errors, and are always followed by that warning :


WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts).
pbu_isWindowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14
nsBrowserAccess.prototype.openURI@chrome://browser/content/browser.js:15189:21
noscriptOverlay<.browserAccess.openURI@chrome://noscript/content/noscriptOverlay.js:2822:13

there are a few tickets about that warning on mozilla’s repository :

https://bugzilla.mozilla.org/show_bug.cgi?id=1079805
https://bugzilla.mozilla.org/show_bug.cgi?id=1124129
https://bugzilla.mozilla.org/show_bug.cgi?id=1192601

I wasn’t able to reproduce the issue, the user was using the Windows Camouflage at the time and the URL were visited throught the Tor Browser.


Subtasks


Related issues

Related to Tails - Bug #6571: Sanitize IPv6 addresses in WhisperBack In Progress 2014-03-02
Related to Tails - Bug #6769: Some serial numbers are not removed in WhisperBack reports In Progress 2014-03-01

History

#1 Updated by intrigeri 2015-12-02 04:18:16

  • related to Bug #6571: Sanitize IPv6 addresses in WhisperBack added

#2 Updated by intrigeri 2015-12-02 04:18:34

  • related to Bug #6769: Some serial numbers are not removed in WhisperBack reports added

#3 Updated by intrigeri 2015-12-02 04:19:37

> In at least one whipserback report there was part of the user’s browsing history. the URL appears in .xsession-errors, […]

I don’t think we can reasonably count on the fact that we’ll configure all software to not output private info to STDOUT (and thus to .xsession-errors on Wheezy / to the Journal on Jessie), so I think it’s WhisperBack’s responsibility to clean it up, just like Bug #6769, Bug #6571 and their subtasks.

Alan, what do you think?

#4 Updated by intrigeri 2015-12-15 10:53:04

  • Status changed from New to Confirmed
  • Type of work changed from Research to Code

Ping?

#5 Updated by sajolida 2016-02-08 16:24:22

  • Assignee set to alant

Assigning to Alan who was asked and pinged without being assigned :(

#6 Updated by intrigeri 2016-02-08 17:57:14

> Assigning to Alan who was asked and pinged without being assigned :(

I’m pretty sure I had set him as a watcher before asking and pinging.

#7 Updated by alant 2016-05-15 03:58:36

  • Status changed from Confirmed to In Progress
  • Feature Branch set to whisperback:bugfix/10695-clean-urls

I wrote a small patch (in whisperback:bugfix/10695-clean-urls), but to test it seriously I’d need to be able to reproduce the issue. I even have no example of a real log to clean up.

#8 Updated by intrigeri 2016-05-23 12:15:09

  • % Done changed from 0 to 10

> I wrote a small patch (in whisperback:bugfix/10695-clean-urls), but to test it seriously I’d need to be able to reproduce the issue. I even have no example of a real log to clean up.

I can’t reproduce the original problem anymore (looking at the Journal of course, since .xsession-errors doesn’t exist anymore on Jessie).

But still, let’s protect users in case this problem comes back. IMO you can easily test this using logger(1) to send URLs into the Journal.

#9 Updated by alant 2019-09-04 20:45:07

  • Assignee deleted (alant)