6 ms·

Further, security of a marketing site tends to be lower priority than the product itself, and an install script should generally be secured similar to the produ

Further, security of a marketing site tends to be lower priority than the product itself, and an install script should generally be secured similar to the product.

bradfitz 2y ago
Yes. We're lamentably probably going to have to move it (the install script), even though it has a nice URL today. When we picked that URL, the marketing site was created and run by the same people who built the rest of the product, so it didn't seem like a concern at the time.
- oliviabenson 2y ago
  You can achieve both. The only mistake you made was to half-bake the proxy (doing it for IPv6 only): proxy every http(s) request to tailscale.com. Vercel’s platform is valuable for a whole host of reasons, the networking side isn’t that important, your developers will greatly value the use of Vercel even if every request is being proxied through a web server hosting tailscale.com which responds to a request for /install.sh instead of passing it through to the marketing site. (In Google Cloud you could do it entirely with load balancing rules, no need to even run a web server)
  - bradfitz 2y ago
    That is exactly what I want us to do :)
- ShakataGaNai 2y ago
  That's great that DevOps (or whatever their title) owns both product and marketing sites. Far too many companies (and DevOps teams) think the www site is "not important" or "not their core job" and outsource it to either a less qualified team, or out of the company altogether. From an external perspective no one cares if www going down isn't "your fault" or of "direct impact to the product". It's a corporate blackeye either way.
  - wlonkly 2y ago
    Alas, the part you're describing as great is written in past tense.
  - raffraffraff 2y ago
    "Far too many companies (and DevOps teams) think the www site is "not important" or "not their core job" and outsource it to either a less qualified team, or out of the company altogether" It's impossible to know because they won't admit it publicly. You are guessing based on some anecdotal experience. But then again... here's mine! I worked at a very successful SaaS that had (really not kidding) the most incompetent, lazy dope running the www site. He live-edited a "staging" version of the site on the fly (no, it wasn't private, you could access this thing from the internet, and he didn't know or care about that). When he was happy with his changes he'd destroy the live instances behind the load balancer and clone his staging instance without taking it down or running any extra checks. This staging instance was around for years and I don't think he ever bothered doing a system update. Since he didn't use git, I I'll bet that at least once he cloned a live instance back to staging to undo a bunch of bork. I lost count of the incidents. He never detected them himself, was never available to troubleshoot them and was generally a big "durrrr" when you'd finally get him on the call. Example: one time we had a "slow, intermittent errors" customer support ticket surfaced to us, not because it was our job, but because dopey was being an absolute ass to the helpdesk guys. He ran his crap in another AWS account we didn't have access to. About a day later the www site went down completely, so we got hold of the AWS account and dug in. All 5 of the instances behind the load balance were "unhealthy" for various reasons. Certs expired, disks full, apache stopped. We bounced them, restarted them and sshed in. They all had different versions of the site. It was a complete mess. Turns out dopey wasn't very good at killing the old instances and cloning staging. He was probably live-editing the instances for smaller changes if that seemed easier than a bunch of AWS console work. Unbelievably he wasn't fired and continued to mismanage the site, and we could do nothing because the head of marketing didn't listen to the head of engineering. They hated each other. The way Marketing saw it "your SRE guys couldn't fix it, they had to wait for <dopey> to get on the call". I'm not even kidding. Just more anecdotal evidence from me. You might be right.
  - belthesar 2y ago
- jonhohle 2y ago
  Orgitecture† strikes! † A systems architecture tightly coupled to the structure of the organization in which it was created.
  - gregw2 2y ago
    More widely called Conway’s law…
- hunter2_ 2y ago
  > it has a nice URL today `curl -fsSL https://install.tailscale.com https://install.tailscale.com | sh` wouldn't be any less nice. Append /sh if having something human-friendly at the root is desirable (SEO, etc.), and you're still at the same overall length as today.
  - solatic 2y ago
    > Append /sh if having something human-friendly at the root is desirable Even this isn't really necessary; curl includes a default user agent header identifying the traffic coming from curl. It's simple enough to direct traffic with the curl user agent header to the script and all other traffic to a static website with directions for how to quick-install.
    - hunter2_ 2y ago
      Very nifty, but I'd argue against it due to possible confusion in various atypical scenarios, such as: * The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser. * The user has `curl` aliased to `curl-impersonate` in order to avoid things like Cloudflare's bot detection (a captcha that triggers on things beyond the HTTP request, like the less fancy TLS handshake of regular curl) -- https://github.com/lwthiker/curl-impersonate https://github.com/lwthiker/curl-impersonate * The user doesn't have curl installed, but has wget / lynx / some headless browser / etc. and expects any of those to work the same as curl. Not to mention, if a site encouraged users to execute an HTTP response by piping curl into sh, and the response for curl was different than the response otherwise, that just might make the top of HN for being sketchy as hell.
      - solatic 2y ago
        > The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser. I mean, the point of wanting to read the script before executing it is to try and protect yourself from malicious scripts that abuse the curl | sh pattern. So since it would be simple enough for a malicious actor to return something different when the user agent indicates the usage of curl, the only responsible thing to do, anyway, is to use curl to download the script to a file, read the file, then execute the file. > `curl` aliased to `curl-impersonate` So when the user uses a tool to impersonate a browser, they'll see exactly what they'll see in a browser... which are the quick-install instructions anyway, which can include a note about the user agent, if anyone actually hits this in the real world? > wget / lynx / some headless browser Which would provide the quick-install instructions to use curl :)

Further, security of a marketing site tends to be lower priority than the product itself, and an install script should generally be secured similar to the product.

bradfitz 2y ago

Yes. We're lamentably probably going to have to move it (the install script), even though it has a nice URL today. When we picked that URL, the marketing site was created and run by the same people who built the rest of the product, so it didn't seem like a concern at the time.

oliviabenson 2y ago
You can achieve both. The only mistake you made was to half-bake the proxy (doing it for IPv6 only): proxy every http(s) request to tailscale.com. Vercel’s platform is valuable for a whole host of reasons, the networking side isn’t that important, your developers will greatly value the use of Vercel even if every request is being proxied through a web server hosting tailscale.com which responds to a request for /install.sh instead of passing it through to the marketing site. (In Google Cloud you could do it entirely with load balancing rules, no need to even run a web server)
- bradfitz 2y ago
  That is exactly what I want us to do :)
ShakataGaNai 2y ago
That's great that DevOps (or whatever their title) owns both product and marketing sites. Far too many companies (and DevOps teams) think the www site is "not important" or "not their core job" and outsource it to either a less qualified team, or out of the company altogether. From an external perspective no one cares if www going down isn't "your fault" or of "direct impact to the product". It's a corporate blackeye either way.
- wlonkly 2y ago
  Alas, the part you're describing as great is written in past tense.
- raffraffraff 2y ago
  "Far too many companies (and DevOps teams) think the www site is "not important" or "not their core job" and outsource it to either a less qualified team, or out of the company altogether" It's impossible to know because they won't admit it publicly. You are guessing based on some anecdotal experience. But then again... here's mine! I worked at a very successful SaaS that had (really not kidding) the most incompetent, lazy dope running the www site. He live-edited a "staging" version of the site on the fly (no, it wasn't private, you could access this thing from the internet, and he didn't know or care about that). When he was happy with his changes he'd destroy the live instances behind the load balancer and clone his staging instance without taking it down or running any extra checks. This staging instance was around for years and I don't think he ever bothered doing a system update. Since he didn't use git, I I'll bet that at least once he cloned a live instance back to staging to undo a bunch of bork. I lost count of the incidents. He never detected them himself, was never available to troubleshoot them and was generally a big "durrrr" when you'd finally get him on the call. Example: one time we had a "slow, intermittent errors" customer support ticket surfaced to us, not because it was our job, but because dopey was being an absolute ass to the helpdesk guys. He ran his crap in another AWS account we didn't have access to. About a day later the www site went down completely, so we got hold of the AWS account and dug in. All 5 of the instances behind the load balance were "unhealthy" for various reasons. Certs expired, disks full, apache stopped. We bounced them, restarted them and sshed in. They all had different versions of the site. It was a complete mess. Turns out dopey wasn't very good at killing the old instances and cloning staging. He was probably live-editing the instances for smaller changes if that seemed easier than a bunch of AWS console work. Unbelievably he wasn't fired and continued to mismanage the site, and we could do nothing because the head of marketing didn't listen to the head of engineering. They hated each other. The way Marketing saw it "your SRE guys couldn't fix it, they had to wait for <dopey> to get on the call". I'm not even kidding. Just more anecdotal evidence from me. You might be right.
- belthesar 2y ago
jonhohle 2y ago
Orgitecture† strikes! † A systems architecture tightly coupled to the structure of the organization in which it was created.
- gregw2 2y ago
  More widely called Conway’s law…
hunter2_ 2y ago
> it has a nice URL today `curl -fsSL https://install.tailscale.com https://install.tailscale.com | sh` wouldn't be any less nice. Append /sh if having something human-friendly at the root is desirable (SEO, etc.), and you're still at the same overall length as today.
- solatic 2y ago
  > Append /sh if having something human-friendly at the root is desirable Even this isn't really necessary; curl includes a default user agent header identifying the traffic coming from curl. It's simple enough to direct traffic with the curl user agent header to the script and all other traffic to a static website with directions for how to quick-install.
  - hunter2_ 2y ago
    Very nifty, but I'd argue against it due to possible confusion in various atypical scenarios, such as: * The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser. * The user has `curl` aliased to `curl-impersonate` in order to avoid things like Cloudflare's bot detection (a captcha that triggers on things beyond the HTTP request, like the less fancy TLS handshake of regular curl) -- https://github.com/lwthiker/curl-impersonate https://github.com/lwthiker/curl-impersonate * The user doesn't have curl installed, but has wget / lynx / some headless browser / etc. and expects any of those to work the same as curl. Not to mention, if a site encouraged users to execute an HTTP response by piping curl into sh, and the response for curl was different than the response otherwise, that just might make the top of HN for being sketchy as hell.
    - solatic 2y ago
      > The user wants to read the script before executing it, and their preferred reader (perhaps due to browser extension or something) is a standard browser. I mean, the point of wanting to read the script before executing it is to try and protect yourself from malicious scripts that abuse the curl | sh pattern. So since it would be simple enough for a malicious actor to return something different when the user agent indicates the usage of curl, the only responsible thing to do, anyway, is to use curl to download the script to a file, read the file, then execute the file. > `curl` aliased to `curl-impersonate` So when the user uses a tool to impersonate a browser, they'll see exactly what they'll see in a browser... which are the quick-install instructions anyway, which can include a note about the user agent, if anyone actually hits this in the real world? > wget / lynx / some headless browser Which would provide the quick-install instructions to use curl :)