[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6279 [EFF-HTTPS Everywhere]: Rules: POF / Plenty Of Fish
#6279: Rules: POF / Plenty Of Fish
----------------------------------+-----------------------------------------
Reporter: grarpamp | Owner: MB
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: EFF-HTTPS Everywhere | Version:
Keywords: | Parent:
Points: | Actualpoints:
----------------------------------+-----------------------------------------
Comment(by grarpamp):
backref...
I don't know the answer on holding memory usage. I meant people are
'?:'ing with no '$n' replacement, so the '()' would seem to become
a simple PCRE matching group. No '$n's, no held atoms and unneeded
'?:'s. Something like that, afaik.
Aside: All the PCRE I tried works, so I'm assuming HTTPS-E/FF uses
formal PCRE engine. I have a query open on that though.
remapping, known hosts...
We can't know how a site expects to work, so blind redirection of
working hosts to a single fqdn just because it also appears to
'works/serves' isn't the best idea and is likely to break as a site
evolves. Likely also are 404's and other processing oddities.
Whether/where one preemptively '\d's or otherwise captures unknown
hosts is uncertain as to best practice. For example, POF wildcards
their dns zones. So someone's saved pages would then act differently
if pic3 drops from dns but is still mapped. Same as for if pic33
goes live under a new usage model.
redir https...
If a site author embeds a https link, it is expected to work. Yet
people are remapping https to https, that's redundant. Their use
of 's?' in from=https? appears misguided.
exclusions...
Much unauthored material in that... pics.*aspx, www.pof.com.*thumbs
CAPS, akamai...
The goal here is working encryption... so you don't want to exclude
broken certs, user can always accept/pin them in the browser to
gain warning free TLS, or to retain TLS period. I'm still laughing
at that CAPS CommonName.
Back to the basics, aspx...
Other than pictures, POF is almost entirely made up of aspx pages.
Since POF 302's or hangs on essentially all of them, we have two
choices...
1) exclude them and gain no TLS
2) include them and gain an unusable site
Therefore the rules as proposed via commits gain us nothing, further
developing them is moot, and the user might as well leave them off.
As ticketed, I submitted in production rules that fixed the git
rules of that era. Then POF went 302. 'Plenty' miffed after plenty
of writing/testing them. Anyway, they are expected to be more useful
and complete for if POF reverts to the last known former case (where
replacing everything with HTTPS in fact worked).
Lastly...
POF's apparent cobbling together by amateurs shines through in their
site. Not to mention its behavior towards Tor's legitimate users.
Further, I'd wager that POF 302'd/hung HTTPS, not because the few
hundred HTTPS-E users spent a few more of POF's cpu cycles on HTTPS,
but because POF tired of their own error logs, or some such/config,
from it.
I'll happily collaborate on this set again when they pull their
head from their ass regarding, at minimum, HTTPS. Though I'd expect
and hope that their next move, perhaps driven from user outrage and
public shaming, will be to HTTPS the entire site such that no rules
are needed.
Either way and until then, users have no security with POF. Considering
the personal nature of such a site, that's really sad indeed :(
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6279#comment:5>
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