[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 gk):
Here comes the second bunch of comments to section 3 - the end to the
document in chronological order:
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"?)
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.
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.
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...
4.7) The GeoIP wiki token URL is probably a GeoIP wifi token URL, right?
(at least "geo.wifi.access_token" makes that plausible)
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.
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?
A.1.1) Either "Referer or "referer" should be used but not both (I tend to
the former).
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
:)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5273#comment:42>
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