[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5273 [Firefox Patch Issues]: Update TBB design doc for 2.3.x
#5273: Update TBB design doc for 2.3.x
----------------------------------+-----------------------------------------
Reporter: mikeperry | Owner: mikeperry
Type: defect | Status: needs_review
Priority: major | Milestone: TorBrowserBundle 2.3.x-stable
Component: Firefox Patch Issues | Version:
Keywords: MikePerry201302d | Parent:
Points: | Actualpoints: 16
----------------------------------+-----------------------------------------
Comment(by mikeperry):
Replying to [comment:42 gk]:
> Here comes the second bunch of comments to section 3 - the end to the
document in chronological order:
Ok, I think I've fixed most of these. You can double check when the
website gets updated. The new design doc will claim to be current as of
Torbutton 1.5.1 (rather than 1.5.0).
> 3.1.4) I think you can delete that point as that is better viewed as one
of the myriads of means to reach 3.1.6 and not a separate goal (that is
quite good reflected by "zero in" which you used in both sections (btw. is
it "zero in" or "zero-in"?)
Yep. Deleted. Also added some phrasing to 3.1.6 (now 3.1.5) to capture
this idea too.
> 3.2.4) I am wondering if that adversary described there is still the one
you assume when you are talking about a passive forensic local adversary.
If I as an adversary have intermittent or constant physical access, well,
then I have more options than just passively monitoring something... Maybe
a comment or a hint like you did with 3.3.3 would help here.
Well, 3.2.4 is just about positioning. See the corresponding attack vector
in 3.3.4, which I updated to mention both complete code-exec compromise
and passive forensics.
> 4.5.2) It was a bit confusing to me that the cache domain attribute is
using the FQDN and not the url bar origin (i.e. the second-level DNS name)
especially as the Tor Browser is following that url bar paradigm in almost
all the other cases (and is only mentioning that one MAY use the FQDN as
url bar origin). A sentence or two explaining this "discrepancy" might be
good here.
I added a phrase. I pretty much chose FQDN because it was the simplest
option.
> 4.6.4) While reading that remote fonts are excluded from the defense now
I remembered:
>
> {{{
> When Gecko displays a page that uses web fonts, it initially displays
text using the best CSS fallback font available on the user's computer
while it waits for the web font to finish downloading. As each web font
finishes downloading, Gecko updates the text that uses that font. This
allows the user to read the text on the page more quickly.
> }}}
>
> on https://developer.mozilla.org/en-US/docs/CSS/@font-face. Have you
tested that a remote server cannot fool you here? The question is: Does
the font defense get triggered even if the local fonts are just
placeholders for remote fonts? I am not sure whether there are different
code paths for genuinely loading a local font and having it just as a
placeholder and whether your defense works in both cases. Just a
thought...
I have actually observed this behavior happen visually, but I have not
tested it with code. We do update the actual font rule itself (as the
nsStyleRule member of nsRuleNode) to /only/ list the font-face font before
font rendering, so I'd be surprised if you could still probe specific
fonts this way. My guess is that what happens is that you get /the/ system
generic font, the same one you get with browser.display.use_document_fonts
set to false. But it would be a good test to do, especially if we also
verify that inherited font rules can't somehow alter this fallback
behavior. Both are probably something content window JS can inspect with
getComputedStyle(), if it manages to win the race to inspect the element
before the font is downloaded.
> 4.7) The GeoIP wiki token URL is probably a GeoIP wifi token URL, right?
(at least "geo.wifi.access_token" makes that plausible)
Yeah. Typo.
> 4.8.7) It seems to me that closing the Tor Browser is not early enough
as there are numerous add-ons that start network activity way before the
browser.js code is running. But I am not sure if that justifies an own
Design Goal section here which states that one tries to patch the Tor
Browser in a way that it is guaranteed to only start network activity if
Tor is up, running and used.
I am confused what you mean here. We don't actually kill the Firefox
process, and we consider addon network activity out of scope... I tried to
clarify a couple things in this section, though.
> A) While reading "[...] based on the assumption that link-click
navigation indicates user consent to tracking [...]" I was suddenly
thinking about element.dispatchEvent() and friends. I am wondering whether
there is really the possibility to keep a user clicking on a link
separated from JavaScript "clicking" on a link and whether therefore the
link-click criterion is really useful here. Have you looked into that?
No. I would consider this as part of #3600, as an automated cross-origin
redirect vector. We should probably work on enumerating those, as that
will probably help us decide what to do there. I updated the ticket with a
(probably partial) list of vectors.
> A.1.1) Either "Referer or "referer" should be used but not both (I tend
to the former).
Fixed.
> The idea with making the Referer explicit (and how to do it) is a really
good one! And for the record: it was not mine as your comment 35 indicates
:)
Heh, yeah, but you kept hounding me about it long enough to find some kind
of solution. ;)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5273#comment:43>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs