[tor-bugs] #6279 [EFF-HTTPS Everywhere]: Rules: POF / Plenty Of Fish

[Tor Bug Tracker & Wiki]

#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