Thank you.

You're terminating the command at ; so bash is looking for the fox command, which it can't find. Quote the text.

Why don't you just start with the CIFAR-10 example and go from there? https://www.tensorflow.org/versions/r0.8/tutorials/deep_cnn/...

I definitely have to agree with this. It has lead to "it works in my sandbox" but breaks in our staging enviromemnt issues at work since everything in staging goes through a proxy.

Well, I don't agree. It is certainly a nice addition to make the web more secure. I hope my bank (and every other significant website) won't toss my auth tokens to different domains. And about reverse proxies: it's a browser feature, so how can reverse proxies be a problem? The browser doesn't care what's happening behind a reverse proxy.

Yes, let's make the web more secure!

This doesn't do that.

Instead, let's solve zero day advertising payloads.

Let's fund a cure for email spam and phishing.

Let's find a cure for site spoofing.

Let's find a cure for "this dialog means I have to click OK to get on with things."

Regarding "domains are controlled," that doesn't matter. If I want to serve pages from www.mydomain and static/CDN content from static.mydomain and services from api.mydomain, those are different domains.

The main solution for a big site is to build all the credential and security logic into the load balancer/HTTPS terminator, which is an almost-guarantee to get version skew and security holes.

All this "secure web" intention only works for small monolithic sites, and don't even solve the real security problems on the web.

Right. I said "nice addition".

I thought that an attacker's JS code can't read the response from a GET request in a CSRF attack. Or are you saying it's possible for the attacker to read the HTTP status code of the response?

I think you're correct here. Also, like POST-based CSRF, get-based CSRF is also a solved problem (issue a param in the URL)