Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#25985: Add AMP cache as another domain fronting option with Google
-----------------------------------+------------------------------
 Reporter:  twim                   |          Owner:  (none)
     Type:  project                |         Status:  needs_review
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------------

Comment (by dcf):

 I'm sorry for being harsh in my previous response. I don't mean to give
 the impression that I don't appreciate the work you're doing. I'm overly
 sensitive on this point because it was my failure to be firm with the
 flash proxy source code that led it to becoming an overly abstracted,
 tightly coupled mess.

 I'm not against refactoring, even as part of this ticket. But I have to
 insist on functional changes and refactoring changes being in separate
 commits. For one thing, it enables discussing the functional and
 refactoring changes separately. But for another, it helps me reconstruct
 your thinking to justify the changes. Look at it from my point of view.
 When I'm reviewing code I would rather see steps A→B→C, where B is simple
 but introduces some obvious code duplication, and C refactors the
 duplication; than see A→C where I have to mentally reconstruct B in order
 to fully understand the change. It's better for `git blame` purposes too.
 I know you know these things too; I'm not trying to explain it to you,
 just letting you know what I value as a code reviewer.

 WRT external interfaces, I know the programmer's instinct is always to
 generalize, generalize as soon as possible and promote interfaces to
 public APIs. I prefer to keep interfaces private whenever possible, not
 expose unneeded functionality, and only make an interface generic and
 external after it has endured some internal battle testing. You don't
 really know what you want from an external API until you have used it
 privately for a while anyway. And if it turns out that you never really
 need to make it public, that's even better, because every public interface
 is an ongoing maintenance burden. This is just my point of view and I
 respect that people can think differently. I'm not ''too'' worried about
 the external amper dep, because we can always remove it if we find it
 necessarily, when we eventually add TLS fingerprint camouflage or
 something like that. It just means an additional new sub-project in the
 Tor Browser build--it all adds up.

 Anyway, I already like your branch in
 [https://github.com/nogoegst/snowflake/commits/b75253ba55bde140be733c4cf5425fc1aab161c4
 b75253ba55] better. I'll find some time to look at it. Maybe arlolra or
 someone else can look too. My time for this is very very limited but I am
 excited about the AMP Cache development.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25985#comment:21>
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