This looks great, nice work! (For me personally, the biggest issue is that it's a pop-up, not the text in the warning itself)
As for the strings, "determining that you're logged in to" isn't really accurate. If I go to Wikipedia and load the main page, then I will still get the warning if I open it in a new tab, even though I am not logged in.
So for the humane string, maybe "determining whether [or not] you're logged in to" would make more sense?
Maybe a third option could also be possible, like "prevented ... from reading [user] data that belongs to www.youtube.com", but I don't know if this is more clear. (I'm not an UX expert at all)
Probably most people have a vague understanding of what cookies are, so it might be OK to say "prevented ... from reading cookies (that belong|belonging) to" or "prevented ... from reading cookies from/for ", but I don't know if this would be inaccurate.
I mean, you're saying that even if you fix this, it can also be fingerprinted by other means. If so, why not try to remove all of the fingerprinting vectors? Why should the OS be special?
Why so? Why can't Tor attempt to plug the "other holes" as well?
You also want to handle navigator.oscpu
and the like as per #31667 (closed).
Right. I'm sorry about this delay. No, I unfortunately don't really have the time right now, but I hope to be able to get to it eventually.
It's not a whole lot of work (well, that's easy for me to say!), but I'd need to test it as well. And I seem to have broken my entire rbm install somehow, so it is not a quick get-in-get-out job for me anymore, alas.
If anyone else wants to take a look at it, they might also want to change the method for the build timestamps to use SOURCE_DATE_EPOCH
(see here) and remove my patch. (Note that the other patch should still be kept, extracted into a separate file, and done as a unified diff.)
That being said, all of these are "cosmetic" issues, so you should be able to use it fine if it's just for a minor thing - the actual build is reproducible, as far as I can determine. (Provided as is, without any liability, etc)
This PR adds support for the MATCH_TARGET
option to ATTACHSTREAM
, REDIRECTSTREAM
, and CLOSESTREAM
, as proposed in #40376.
This PR also contains a change for the max number of arguments for CLOSESTREAM
, from UINT_MAX
(i.e. infinite) to 2. This is not a deviation from the spec. The spec says that there are two mandatory arguments and a potentially unlimited number of flags. The argument parser does not count flags or keyword arguments towards "arguments," i.e. mandatory arguments.
This PR also refactors handle_control_redirectstream
and handle_control_closestream
to remove complexity that was unneeded after the removal of smartlist_free
with https://github.com/torproject/tor/pull/980.
Unit tests are included; make check
runs without issue.
yanmaani (9903bcb8) at 03 Dec 17:22
Add unit tests for MATCH_TARGET option in {ATTACH|REDIRECT|CLOSE}ST...
... and 1 more commit
yanmaani (b184e5e5) at 03 Dec 16:36
Add unit tests for MATCH_TARGET option in {ATTACH|REDIRECT|CLOSE}ST...
yanmaani (b4c55f3a) at 03 Dec 16:15
yanmaani (2a63de81) at 03 Dec 16:04
Add unit tests for MATCH_TARGET option in {ATTACH|REDIRECT|CLOSE}ST...
yanmaani (a7e9e3c4) at 03 Dec 15:28
Add unit tests for MATCH_TARGET option in {ATTACH|REDIRECT|CLOSE}ST...
... and 4 more commits
https://www.ctrl.blog/entry/tor-onion-location-header.html from June 2020:
I crawled the top 1 million domain names (from the Tranco List) on 2020-06-21 and found 30 websites that issued the Onion-Location response header. (You can get the full list of discovered Onion sites below.)
Onion-Location response header crawl of Tranco List (ID PX8J).
2020-06-21
Also, for research purposes, the Internet Archive records all headers in their crawls. That would get you historical info.
Should also keep in mind that some sites (i.e. https://www.getmonero.org) serve it as a HTML meta tag and not a HTTP header.