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

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
---+
 Reporter:  twim   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 This ticket is meant to track progress on adding AMP cache fronting into
 Snowflake broker and client.

 This is a followup  of
 https://trac.torproject.org/projects/tor/ticket/25804#comment:25:

 > It turns out that AppEngine is not the only option for domain fronting
 with Google.
 > Google also provides a service called ​AMP cache for ​AMP pages. What it
 basically does is proxying random pages on the Internet and making them
 load faster (e.g. on Google search results). It requires pages to comply
 with some format though and also strips invisible content, resizes images,
 etc.
 > Despite it is being served via different domain names (one per real
 domain) it is still hosted at Google infrastructure which can be fronted.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:
---+
Changes (by twim):

 * type:  defect => project


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:
---+

Old description:

> This ticket is meant to track progress on adding AMP cache fronting into
> Snowflake broker and client.
>
> This is a followup  of
> https://trac.torproject.org/projects/tor/ticket/25804#comment:25:
>
> > It turns out that AppEngine is not the only option for domain fronting
> with Google.
> > Google also provides a service called ​AMP cache for ​AMP pages. What
> it basically does is proxying random pages on the Internet and making
> them load faster (e.g. on Google search results). It requires pages to
> comply with some format though and also strips invisible content, resizes
> images, etc.
> > Despite it is being served via different domain names (one per real
> domain) it is still hosted at Google infrastructure which can be fronted.

New description:

 This ticket is meant to track progress on adding AMP cache fronting into
 Snowflake broker and client.

 This is a followup  of
 https://trac.torproject.org/projects/tor/ticket/25804#comment:25:

 > It turns out that AppEngine is not the only option for domain fronting
 with Google.
 > Google also provides a service called
 ​[https://developers.google.com/amp/cache/ AMP cache] for
 [https://ampproject.org/ ​AMP pages]. What it basically does is proxying
 random pages on the Internet and making them load faster (e.g. on Google
 search results). It requires pages to comply with some format though and
 also strips invisible content, resizes images, etc.
 > Despite it is being served via different domain names (one per real
 domain) it is still hosted at Google infrastructure which can be fronted.

--

Comment (by dcf):

 twim's library for tunneling through AMP:
 https://github.com/nogoegst/amper

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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):

 The way I picture this working for snowflake is, we add a new route to the
 broker, like `/amp/client`. It will work exactly like the existing
 `/client` route (which is where clients POST their ICE offer)--with the
 only difference being that `/amp/client` will wrap the response in the
 additional AMP markup. The client side will have to know how to strip off
 the extra markup. It's probably not very much work.
 https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/tree/broker/broker.go?id=10ad59fc9d26900ded6456f50ea6adf4cb58be9d#n146

 Here's a diagram of how it works now:
 https://www.bamsoftware.com/papers/thesis/#fig:snowflake-rendezvous
 Imagine an AMP node between the client and broker. In Step 1, instead of
 domain fronting, the client will just do a normal request for
 !https://www.google.com/amp/snowflake.example.com or whatever. In Step 3,
 the broker will append the extra AMP markup. Everything else is the same.

 twim, can you give a brief guide on what is needed to set up AMP? I
 presume you at least need a Google account; is it something you set up in
 the Google Cloud Platform? Is there a fee? I've seen different kinds of
 AMP URLs, like
 
https://www.google.com/amp/s/amp.reddit.com/r/OutOfTheLoop/comments/56euau/whats_with_google_amp_quite_annoyingly_being_used/
   https://amp-reddit-com.cdn.ampproject.org/
   https://amp.reddit.com/
 Do you know what the difference between all these URL styles is? Are they
 basically interchangeable? The first one looks like the best, if we can
 use it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

Comment (by twim):

 > twim, can you give a brief guide on what is needed to set up AMP?
 Sure. One needs to
 On the server side:
   Setup a web server accessible via domain name and preferably using TLS.
 This server has to wrap some *text* data inside the AMP markup. The text
 should be "visible" as AMP cache strips unnecessary content.
 On the client side:
   Assemble a special URL which contains:
 * correct AMP-styled host
 * random part (to go around caching)
 * the outgoing payload (as only GET requests can be made)
   Fetch the URL using some front and extract (and decode) data from the
 AMP page back.

 In a way it is pretty similar to meek except GET instead of POST and extra
 encoding/decoding thing.


 > I presume you at least need a Google account; is it something you set up
 in the Google Cloud Platform? Is there a fee?

 Curiously enough you don't need a Google account for that because the AMP
 project itself isn't solely a Google thing. It is just a special HTML
 markup that can be accelerated by any party incl. Google. You just set up
 an AMP version of your pages at your host and it just works. No GCP
 involved. There is no fee at the moment for page loading, there will only
 be on API calls (not our case). As IANAL, I am not aware whether this
 usage violates ToS. I couldn't find any.

 > I've seen different kinds of AMP URLs...
 > Do you know what the difference between all these URL styles is? Are
 they basically interchangeable? The first one looks like the best, if we
 can use it.


 I haven't managed to make URLs like
 https://www.google.com/amp/s/amp.reddit.com/blablabla to not redirect to
 the full article. I am probably just do not understand how this kind of
 links differs from others.

 > ​https://amp-reddit-com.cdn.ampproject.org/

 This is the kind of links I am using in amper. I guess that in theory
 *.cdn.ampproject.org can resolve to non-Google IPs as well. These hosts
 can be fronted by typical Google server names.

 > https://amp.reddit.com/

 This is the host from which one is serving their AMP pages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:
---+
Changes (by cypherpunks):

 * status:  needs_information => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:5 twim]:
 > > I presume you at least need a Google account; is it something you set
 up in the Google Cloud Platform? Is there a fee?
 >
 > Curiously enough you don't need a Google account for that because the
 AMP project itself isn't solely a Google thing. It is just a special HTML
 markup that can be accelerated by any party incl. Google. You just set up
 an AMP version of your pages at your host and it just works. No GCP
 involved. There is no fee at the moment for page loading, there will only
 be on API calls (not our case). As IANAL, I am not aware whether this
 usage violates ToS. I couldn't find any.

 Thanks for this great info. It's a lot easier than I imagined. The Google
 AMP cache will issue GET requests to arbitrary URLs on your behalf (going
 back to the [https://www.bamsoftware.com/papers/oss.pdf OSS] idea). I
 tried it with my web server, which I haven't done anything to set up for
 AMP:
   !https://www-bamsoftware-
 com.cdn.ampproject.org/c/s/www.bamsoftware.com/amptest
 This resulted in an HTTP request to my server:
 {{{
 64.233.172.149 - - [03/May/2018:10:59:20 -0600] "GET /amptest HTTP/1.1"
 404 3726 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P)
 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile
 Safari/537.36 (compatible; Google-AMPHTML)"
 }}}
 Probably because the page doesn't pass AMP validation (i.e., doesn't
 exist), the AMP cache's response was a status-200 meta/JavaScript redirect
 to the original URL:
 {{{
 HTTP/1.1 200 OK
 Location: https://www.bamsoftware.com/amptest
 Cache-Control: private
 X-Content-Type-Options: nosniff
 Date: Thu, 03 May 2018 17:05:10 GMT
 Content-Type: text/html; charset=UTF-8
 Server: sffe
 Content-Length: 361
 X-XSS-Protection: 1; mode=block
 Alt-Svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432;
 quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000;
 v="43,42,41,39,35"

 
 
 Redirecting
 https://www.bamsoftware.com/amptest";>
 
 https://www.bamsoftware.com/amptest'+document.location.hash)">
 Redirecting you to https://www.bamsoftware.com/amptest
 }}}

 > > I've seen different kinds of AMP URLs...
 > > Do you know what the difference between all these URL styles is? Are
 they basically interchangeable? The first one looks like the best, if we
 can use it.
 >
 > I haven't managed to make URLs like
 https://www.google.com/amp/s/amp.reddit.com/blablabla to not redirect to
 the full article. I am probably just do not understand how this kind of
 links differs from others.

 The trick with these is you have to use a mobile User-Agent. Press
 Ctrl+Shift+I to open the browser console, click the "Responsive Design
 Mode", and choose a phone from the menu.

 > > ​https://amp-reddit-com.cdn.ampproject.org/
 >
 > This is the kind of links I am using in amper. I guess that in theory
 *.cdn.ampproject.org can resolve to non-Google IPs as well. These hosts
 can be fronted by typical Google server names.

 Okay yeah, I found these guides to the URL format. The `c` means content
 (can also be `r` for resource or `i` for image) and the `s` means use TLS.
   https://developers.google.com/amp/cache/overview#amp-cache-url-format
   https://www.ampbyexample.com/advanced/using_the_google_amp_cache/#amp-
 cache-url-format

 > > https://amp.reddit.com/
 >
 > This is the host from which one is serving their AMP pages.

 I see; so "amp" in the name here is just a convention, not a requirement.

 I found this description of the three kinds of URLs:
   https://www.ampproject.org/latest/blog/whats-in-an-amp-url/
 The "*.cdn.ampproject.org" ones they call "AMP Cache" URLs and the
 "google.com/amp" ones they call "AMP Viewer" URLs. It seems like the "AMP
 Viewer" URLs are only produced automatically by Google in search result
 pages. But yeah, in any case, you can domain-front the "AMP Cache" URLs.

 How these all link together is you have the original non-AMP page:
 
https://www.reddit.com/r/OutOfTheLoop/comments/56euau/whats_with_google_amp_quite_annoyingly_being_used/
 In the source code, there is a `` that points to the
 AMP version:
 
https://amp.reddit.com/r/OutOfTheLoop/comments/56euau/whats_with_google_amp_quite_annoyingly_being_used/
 The AMP URL (or any URL) can be mechanically converted to an AMP Cache
 URL:
   https://amp-reddit-
 
com.cdn.ampproject.org/c/s/a

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

[Tor Bug Tracker & Wiki]

#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 twim):

 Replying to [comment:7 dcf]:
 Thanks for breaking it down!

 > Okay yeah, I found these guides to the URL format. The `c` means content
 (can also be `r` for resource or `i` for image) and the `s` means use TLS.
 >   https://developers.google.com/amp/cache/overview#amp-cache-url-format
 >   https://www.ampbyexample.com/advanced/using_the_google_amp_cache/#amp-
 cache-url-format

 Strange, I've seen this docs to find out what /s means, though I took the
 URL itself from desktop Google search results. This URL (in amper) uses
 /v/s/ location instead of /c/s/. I don't see any docs on that. Maybe it is
 a deprecated format, however it doesn't explain why Google still use it
 then.


 >   https://www.ampproject.org/latest/blog/whats-in-an-amp-url/
 > The "*.cdn.ampproject.org" ones they call "AMP Cache" URLs and the
 "google.com/amp" ones they call "AMP Viewer" URLs. It seems like the "AMP
 Viewer" URLs are only produced automatically by Google in search result
 pages. But yeah, in any case, you can domain-front the "AMP Cache" URLs.

 Also this google.com/amp viewer seems to use iFrames to download content
 from the CDN anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:8 twim]:
 > >   https://www.ampproject.org/latest/blog/whats-in-an-amp-url/
 > > The "*.cdn.ampproject.org" ones they call "AMP Cache" URLs and the
 "google.com/amp" ones they call "AMP Viewer" URLs. It seems like the "AMP
 Viewer" URLs are only produced automatically by Google in search result
 pages. But yeah, in any case, you can domain-front the "AMP Cache" URLs.
 >
 > Also this google.com/amp viewer seems to use iFrames to download content
 from the CDN anyway.

 Aha, you're right. So the Amp Viewer URLs don't really buy us anything in
 terms of blocking resistance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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):

 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?

 This is the design I am picturing:


 == In the broker ==

 Add a new route `/amp/client`. This is similar to the existing `/client`
 (`clientOffers` function), except that it conforms to AMP requirements.
 Specifically, when a request arrives:
  1. Take the final path component in request URL, decode it using the
 base64 URL-safe alphabet, and store that as `offer`.
  2. If `ctx.snowflakes.Len() <= 0`, return an AMP-appropriate "not found"
 response (in case AMP does not pass our current status 503
 `StatusServiceUnavailable` unmodified).
  3. Keep the same logic up to `answer := <-snowflake.answerChannel`.
  4. When writing the answer, instead of writing it directly to the body,
 encode it using base64 and wrap it in the necessary AMP markup.
 (Side note: if AMP provides a way to pass JSON through unmodified
 (maybe the `r` does this?), that would be ideal.)
  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.

 We can discuss alternatives paths to `/amp/client`. We could even perhaps
 overload `/client` if something else in the request marks it as being AMP
 (but there's no need to be cute if we don't have to).


 == In the client ==

 Add a new command-line flag `-amp` that sets a global AMP flag. My
 thinking here is that the AMP use case is similar enough to existing
 domain fronting use case that we can use the same conventions. These are
 the use cases I think should be supported:

  access broker directly::
  `client -url https://snowflake-broker.bamsoftware.com/`
  access broker through a domain front::
  `client -url https://snowflake-broker.azureedge.net/ -front
 ajax.aspnetcdn.com`
  access broker via AMP cache::
  `client -amp -url https://snowflake--broker-bamsoftware-
 com.cdn.ampproject.org/`
  access broker via domain-fronted AMP cache::
  `client -amp -url https://snowflake--broker-bamsoftware-
 com.cdn.ampproject.org/ -front www.google.com`

 In `BrokerChannel.Negotiate` (rendezvous.go), when the global AMP flag is
 set,
  1. Instead of appending `"client"` to `bc.url`, append
 `"c/s//amp/client//"`.
  2. Use GET with an empty body, instead of POST.
  3. In the `http.StatusOK` case, read the body and strip out the AMP
 markup before deserializing the answer.
  4. In the `http.StatusServiceUnavailable` and `http.StatusBadRequest`
 cases, do whatever is needed to match how those errors are represented in
 the broker.

 As a bit of perhaps premature optimization, we can probably remove the
 cache-inhibiting `` from the URLs, because the client offers
 already contain `ice-pwd` and `fingerprint` fields that (I think) don't
 repeat.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 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.

 > This is the design I am picturing:
 >
 > == In the broker ==
 >
 > Add a new route `/amp/client`. This is similar to the existing `/client`
 (`clientOffers` function), except that it conforms to AMP requirements.
 Specifically, when a request arrives:
 > ...
 >  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.
 >
 > We can discuss alternatives paths to `/amp/client`. We could even
 perhaps overload `/client` if something else in the request marks it as
 being AMP (but there's no need to be cute if we don't have to).

 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.
 Also we can't pass headers as we do in meek.

 > (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  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.


 > As a bit of perhaps premature optimization, we can probably remove the
 cache-inhibiting `` from the URLs, because the client offers
 already contain `ice-pwd` and `fingerprint` fields that (I think) don't
 repeat.
 I thought about it too, but it might be a slippery slope as you have to
 ensure that paths never repeat. Random prefix doesn't introduce such a bit
 overhead to worry about.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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  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 ] 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.
 {{{