←back to thread

Tailscale raises $100M

(tailscale.com)
854 points gmemstr | 2 comments | 04 May 22 13:17 UTC | HN request time: 0s | source
Show context
pilif ◴[04 May 22 13:42 UTC] No.31260250[source]▶
With such a huge investment comes the obligation to eventually pay it back. Is this another one of my favourite tools going the way of Dropbox, 1Password and all other companies that were formed around what should be a platform feature, which took on way too large investment sums and were eventually forced to become the everything, losing sight of their core values?

I sincerely hope not, but there's so much bad precedent.

replies(6): >>31260318 #>>31260351 #>>31260537 #>>31260737 #>>31261295 #>>31264059 #
YPPH ◴[04 May 22 14:01 UTC] No.31260537[source]▶
How has 1Password lost sight of its core values?

Perhaps you refer to loss of local vaults? If so, they were never really a viable option for me - I needed the app syncing across multiple devices, including mobile, and doing so with a third party sync solution wasn't suitable.

replies(2): >>31261102 #>>31261681 #
criddell ◴[04 May 22 14:39 UTC] No.31261102[source]▶
For me, it was their switch to an Electron app. "High security" and "built from dozens of third party libraries and running on a browser" don't belong together.
replies(2): >>31261528 #>>31264784 #
danenania ◴[04 May 22 19:31 UTC] No.31264784[source]▶
Electron actually offers some of the best dependency-isolation capabilities of any language/platform given that you can set a content-security policy and leverage Chrome's extremely robust sandboxing to prevent front-end dependencies from accessing the file system, making network calls to untrusted domains, making system calls, calling 'eval', etc.

A fully native app will offer you no such protection. If a dependency used for styling or animations or whatever is compromised, it will have total access to the system and be able to exfiltrate at will to any location. In Electron, the equivalent dependencies can instead run inside the CSP sandbox, preventing them from doing any serious harm.

Supply chain vulnerabilities also aren't unique to npm. Any project that uses dependencies (in any language) has the same issue.

replies(1): >>31267960 #
girvo ◴[05 May 22 00:50 UTC] No.31267960[source]▶
> Any project that uses dependencies (in any language) has the same issue.

While that's absolutely true, the Node ecosystem (which I use, love, and make my money in) definitely takes the sheer dependencies of dependencies of dependencies problem to a rather fascinating extreme, compared to nearly any other language I use.

replies(1): >>31268328 #
danenania ◴[05 May 22 01:39 UTC] No.31268328[source]▶
It would be interesting to see some data. Node definitely has that reputation, but every other language I’ve worked in—ruby, python, golang, clojure, hell even objective c—all have rich library ecosystems and most libraries include other libraries. They also all have plenty of small, single-purpose libraries. Perhaps node is a bit worse, but it’s not like it’s in a different category. Most popular languages/ecosystems are like this.
replies(1): >>31268882 #
1. fastball ◴[05 May 22 03:01 UTC] No.31268882[source]▶
Node/JS definitely is a lot worse and in a different category by several orders of magnitude.

My theory is that this is because there is no standard library in Node.

My JS frontend has something like 20,000 packages that need to be installed to build the app. The next highest-dependency lang I use is python, where my average python app will have approx 100 packages all in. And then it only goes down from there with other systems.

replies(1): >>31269264 #
2. danenania ◴[05 May 22 03:57 UTC] No.31269264[source]▶
I suppose a lot of that can be chalked up to the overall size of the ecosystem (and also the complexity of frontends).

There's an exponential effect at work based on the number of libraries that do any one thing. If in python you have (for sake of argument) an average of 5, and in node an average of 25, the downstream effect is that you have massively more dependencies in your tree (many, many, more than 5x), just like you're seeing.

I still don't think the O(n) properties of dependency trees are any different in other languages though. Node just has the largest scale. If python had as many total packages as node, and was also as popular for building frontends, I think you'd have exactly the same situation. That's what I meant by "not in a different category". Node's scale/popularity is in a different category than python's, but its approach to dependencies is basically the same.