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:  new
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------

Comment (by dcf):

 Replying to [comment:11 twim]:
 > Replying to [comment:10 dcf]:
 > > I think this AMP cache idea is really viable and can be implemented
 quickly. twim, do you have the time and interest to work on an
 implementation in Snowflake?
 >
 > Yes, I think I can do that.

 That's great. I can devote some time to assistance.

 Do you have the infrastructure you need for testing? It looks like you
 have a way to make your own subdomains. The broker has automatic Let's
 Encrypt certificate support, but it requires you to have ports 443 and 80
 free. If you don't have a spare server set up, I may be able to get you
 one.

 > >  5. In the `<-time.After(time.Second * ClientTimeout)` case, we may
 have to think of some other way to signal a timeout, in case the AMP cache
 doesn't pass the status 502 (`StatusGatewayTimeout`) unmodified.
 >
 > Another idea I got here about it is to always reply with 200, so any
 changes to AMP will less likely break things. Thus we can abstract RPC
 away from HTTP in a way and use different pluggable roundtrippers (like
 POST, AMP). It would make it easier to plug other OSSes.

 Always using 200 for AMP is fine with me. If you need to add another layer
 around the existing JSON, that's fine. I don't want to overhaul the
 existing `/client` behavior though.

 > >     (Side note: if AMP provides a way to pass JSON through unmodified
 (maybe the `r` does this?), that would be ideal.)
 > JSON is probably fine if wrapped into <pre> but I haven't test it yet. I
 don't feel like using JSON will be as safe as Base64 in terms of
 survivability against modifications.

 I'm thinking about the [https://www.ampproject.org/docs/fundamentals/spec
 #the-amp-html-format <script type="application/ld+json">] block. Perhaps
 we can stuff arbitrary data in there and the AMP cache won't touch it. But
 realistically speaking, base64 in the page body is likely good enough.
 {{{
     <script type="application/ld+json">
     {
       "@context": "http://schema.org";,
       "@type": "NewsArticle",
       "headline": "Article headline",
       "image": [
         "thumbnail1.jpg"
       ],
       "datePublished": "2015-02-05T08:00:00+08:00"
     }
     </script>
 }}}

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