Move Snowflake proxy page somewhere devs can write

The Snowflake badge code is hosted at serene's site, https://keroserene.net/snowflake/embed.html. serene is the only one who can modify files there. It would be more convenient to move the code to another web server to which all the developers can push files.

Like in the past we moved the flash proxy files from https://crypto.stanford.edu/flashproxy/ to https://flashproxy.bamsoftware.com/flashproxy/. We could even use the same server for Snowflake (using a Snowflake-related domain name).

added component::circumvention/snowflake in Legacy / Trac owner::dcf in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac type::project in Legacy / Trac labels

Is there anything here that I/we can help with? Or is it just picking one and doing it?

Replying to arma:

Is there anything here that I/we can help with? Or is it just picking one and doing it?

If the Tor Project can provide a host, that could help. (I know historically Tor has not wanted to do that.) The only technical requirement is an HTTPS server serving static files. Otherwise I was thinking of registering some domain name and setting up a server.

The important thing is long-term name stability. The domain we choose will determine the URL that we tell people to paste into their pages, and once it's out there, we can't easily change it.

And there's also the question of shared administration of the server, in order to avoid a single point of failure. We can easily share SSH access to the server. But it won't do if someone needs to bug me to make a DNS change, just because I happen to be the one who registered the domain name. I don't know if there's a way to do shared administration of a domain name (maybe Team Cymru does something like that?).

Currently we're using subdomains of bamsoftware.com for certain snowflake services, for example the bridge at !https://snowflake.bamsoftware.com/. But that's different--the name isn't important, it only needs a name so it can have a certificate. And it doesn't really introduce a dependency on me. If I disappeared, some other team member could register another name pointing to the same IP address, reconfigure the bridge with a certificate for that name, and everything would work: even currently running proxies would restart themselves within 24h. I'm not nearly as concerned about permanence for easily changed domains like that. But the URL of the server actually hosting the proxy code does lock us in.

Trac:

This ticket is the root of a tree of dependencies for other tickets.

A stable proxy URL means that we can start asking people to put a proxy badge on their pages (legacy/trac#20813 (moved)).

Hosting that we can actually write to will allow us to point the proxy to the standalone broker (legacy/trac#22874 (moved)) instead of the App Engine one. A standalone broker that's independent of App Engine means we can use alternate domain fronts (legacy/trac#22782 (moved)).

A stable proxy URL means that a browser extension (legacy/trac#23888 (moved)) will be able to reference code that is being maintained.

That doesn't mean we can't make progress on the other tickets. legacy/trac#22874 (moved) is 99% done, and you can write most of legacy/trac#23888 (moved) and plug in a proxy URL at the end. We could switch clients to the standalone broker immediately. It's just that none of these changes will have an effect, because the in-the-wild proxies (not that there are many of them) are still using the keroserene.net proxy, which isn't being updated and still points to the App Engine broker.

Trac:
Priority: Medium to High

To be clear, this is a static website that serves javascript-or-whatever files, and the goal is to have a long term host name so folks who put badges on their website can bake the name into their badge, and so folks who write browser extensions that let people pretend to always have a snowflake tab open will have a reliable place to fetch the code from at each browser startup?

If so, I think the best plan is to add this new site to our www rotation. That way it gets served by six or so hosts, so it has good reliability and load balancing. It would be editable by whoever we select to be in the ldap-style group, meaning the people who can edit it will need ldap accounts (I think arlo and dcf both qualify, and serene too for that matter).

What hostname would we like it to be?

Trac:
Cc: dcf, arlolra to dcf, arlolra, brade, mcs

Great. In the meeting today we picked "snowflake.torproject.org", and I've just filed legacy/trac#25724 (moved).

We also had a chat about cookie risks today, where the consensus was that [javascript from] snowflake.tp.o should feel free to set snowflake.tp.o cookies, but it should please avoid setting top-level torproject.org cookies. Seems straightforward enough -- hopefully we didn't misunderstand some basic principle of cookies in this decision. :)

Ok, legacy/trac#25724 (moved) is complete. I was about to open a new ticket, "Populate https://snowflake.torproject.org/" but then I realized we can just continue on this ticket. Please feel free to make new ticket(s) if at any point you realize doing it all on one ticket has become crazy. :)

I think three steps remain here:

(1) David and Arlo should each confirm that they are able to edit the current website. I am able to, so it's just a matter of making sure they're in the right groups and have the right permissions and so on. I'll post instructions for that shortly.

(2) Build a plan for how we want to handle website content. Do we want it in revision control? For example, we could make a snowflake-web git repo, kind of like the research-web git repo: https://gitweb.torproject.org/research-web.git/tree/ and then we'd have some history to it, some visibility to others when changes get made, the ability to separate "can edit website content" from "can push changes to the actual website", etc. If we decide on this option, I'm happy to make the ticket to get the new git repo on its way to existing. If we decide on another option, that's cool too.

(3) Actually pick the content, e.g. by migrating something over from previous pages. I plan to leave this one to Arlo and David for now. :)

Replying to arma:

(1) David and Arlo should each confirm that they are able to edit the current website. I am able to, so it's just a matter of making sure they're in the right groups and have the right permissions and so on. I'll post instructions for that shortly.

Here's what I did, using https://help.torproject.org/tsa/doc/static-sites/ as my cheat-sheet:

(0) Have an ssh key set up for my Tor ldap account. Hopefully you have both done this already for other reasons.

(1) ssh staticiforme.torproject.org, using cupani.torproject.org as my jump host: https://help.torproject.org/tsa/doc/ssh-jump-host/

(2) cd /srv/snowflake.torproject.org/htdocs/ and edit index.html to say "Hi mom" or whatever you want for your test.

(3) Run "static-update-component snowflake.torproject.org" and wait for it to complete.

(4) Go to https://snowflake.torproject.org/ and see if your next text is there.

These steps are all easy (ok, other than step 0), so if any of them turns out to be super complicated, it's probably because something is broken on the back-end that we should fix.

Oh, and if while doing it you find bugs with the help.tpo tsa pages, here's the place to fix them: https://gitweb.torproject.org/project/help/wiki.git/tree/tsa/doc

(1) David and Arlo should each confirm that they are able to edit the current website.

Works for me.

(2) Build a plan for how we want to handle website content. Do we want it in revision control?

There's https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/static

Replying to arma:

Replying to arma:

(1) David and Arlo should each confirm that they are able to edit the current website.

Thanks for the instructions. It worked for me. ️

Oh, and if while doing it you find bugs with the help.tpo tsa pages, here's the place to fix them: https://gitweb.torproject.org/project/help/wiki.git/tree/tsa/doc

I hit one little snag. I wanted to check the fingerprint of staticiforme. But ssh shows a hash of the public key and https://db.torproject.org/machines.cgi?host=staticiforme shows the unhashed key:

The authenticity of host 'staticiforme.torproject.org (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:Zey+40am+p8jbz6QMUkVNzpxvSkGGGKE8EB5Oxqiw1w.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINaYC2kGzFeqQtmZp7UGYjqxcymHn9ujYlKBbf1x6pnF root@staticiforme

There is probably some ssh option or subcommand I could have used, but it turns out that hashing it manually works.

>>> hashlib.sha256("AAAAC3NzaC1lZDI1NTE5AAAAINaYC2kGzFeqQtmZp7UGYjqxcymHn9ujYlKBbf1x6pnF".decode("base64")).digest().encode("base64")
'Zey+40am+p8jbz6QMUkVNzpxvSkGGGKE8EB5Oxqiw1w=\n'

Replying to arlolra:

There's https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/static

Well awesome.

The way I do it with research-web is that I do a git clone in my homedir on staticiforme and then I do a git pull and cp stuff manually into /srv/

Ya'll're welcome to do it that way too, or you could come up with some slightly more automated approach like a script that takes a git checkout as input and arranges stuff into /srv/ the way you like.

Replying to arma:

I think three steps remain here:

(1) David and Arlo should each confirm

Done

(2) Build a plan for how we want to handle website content

Also done: Arlo's got one already.

(3) Actually pick the content

I'll let you two take it from here. Feel free to close the ticket when you've got a website up. Or note any further problems here.

Trac:
Status: new to assigned
Owner: N/A to dcf

Trac:
bug23947.patch

I copied the web files to https://snowflake.torproject.org/.

cake.coffeescript build
rsync -rv build/ staticiforme:/srv/snowflake.torproject.org/htdocs/ && ssh staticiforme 'static-update-component snowflake.torproject.org'

Here is a small patch for review. bug23947.patch The first part changes references to !https://keroserene.net/snowflake/ to references to !https://snowflake.torproject.org/. The second part changes to the standalone broker (legacy/trac#22874 (moved)). I changed to snowflake-reg-test.appspot.com, a domain front I had previously set up for the standalone broker, even though it doesn't work currently due to legacy/trac#25804 (moved).

I tested this by loading a browser to https://snowflake.torproject.org/, removing the -front option from client/torrc to work around legacy/trac#25804 (moved), and running tor -f torrc SOCKSPort auto. The badge started animating and the bootstrap got to 100%.

I also inspected the cookie set after opting in. The domain of the cookie was snowflake.torproject.org.

Trac:
Status: assigned to needs_review

Here is a small patch for review. bug23947.patch​

Looks like you missed:

proxy/static/options.html:  <a href="https://keroserene.net/snowflake">here</a>.

and maybe

proxy/static/index.html:<a href="https://github.com/keroserene/snowflake" target="_blank">Snowflake</a>

should point to https://gitweb.torproject.org/pluggable-transports/snowflake.git/

Replying to arlolra:

Here is a small patch for review. bug23947.patch​

Looks like you missed:

{{{ proxy/static/options.html: here. }}}

and maybe

{{{ proxy/static/index.html:Snowflake }}}

should point to https://gitweb.torproject.org/pluggable-transports/snowflake.git/

Oops, good catch. For the second one, I think the intention was to show the project README, so I changed the link to point to the wiki page rather than the source code repo.

All committed: https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=a762becbaa4b3e75b1e42e782f4cd426b4e345e9 https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=a9630a82343f13b101dc4fc8ac7be3b94eb69cf3 https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=947636ae817fdb393b4fcb2901bf52bca36cef65

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Replying to dcf:

I copied the web files to https://snowflake.torproject.org/. {{{ cake.coffeescript build rsync -rv build/ staticiforme:/srv/snowflake.torproject.org/htdocs/ && ssh staticiforme 'static-update-component snowflake.torproject.org' }}}

dcf: careful here! This -rv means that if you ever remove a file from git, it will persist on the website until somebody notices it and deletes it.

Maybe you want something more like "-rvz --delete". (Though that could have surprises of its own, if anybody ever puts something in the website directory on staticiforme and expects it to not get blown away.)

closed

mentioned in issue legacy/trac#25724 (moved)

moved from legacy/trac#23947 (moved)

added Project label and removed 1 deleted label

removed 1 deleted label

changed the description