We have a few partners who use our infrastructure (e.g. Mozilla), but we're not trying to dominate as a white-label solution. In fact, we've said no to a few well-known brands who wanted to white-label our infrastructure.
We want to make online mass surveillance and censorship ineffective. Mullvad is political action through entrepreneurship. We're reinvesting a lot of our profit into open-source software and hardware projects that benefit both Mullvad and the wider community.
I really don't want us to "corner the entire market" because that would make us a single point of failure. I would like to think that our hard work help push the market to keep improving.
I really like the "to plant trees in the shade of which we will never sit" statement. My pessimism only comes from watching trusted giants like Google and Cloudflare turn into critical infrastructure that in turn dictates the web.
May you continue to be the beacon of trustworthiness and hope that we all need right now
- protecting your privacy from your local ISP, WiFi, school, government etc
- protecting your privacy from some forms of online tracking
- circumventing censorship
- circumventing geographical restrictions
If you combine masking of your IP address with a web browser that protects you from various types of browser-based fingerprinting, you are more in control of your privacy online. You get to decide, to a greater extent, who you share very personal information with. That doesn't seem very silly.
(disclosure: I'm one of the deeply silly cofounders of Mullvad)
There's a niche fifth reason. Roaming between upstreams while not having open TCP connections drop. I use multiple ISP's and on mullvad I can swap which wifi/ethernet I'm on and all my connections stay up since wireguard is stateless.
Hi! Thanks for your deeply non-silly reply; it's nice to (virtually) meet a cofounder.
If you have time, I'd love to hear your thoughts on Mullvad's campaign here in Seattle.
For what it's worth, I suppose my perspective boils down to: the first three issues aren't issues here in town, or can be addressed in more direct ways (we have a wide choice of providers; 1st party browsers and services cover the gamut of tracking concerns; etc). Circumventing geographical restrictions is useful, but -- perhaps understandably! -- doesn't appear to be what Mullvad is advertising on the trains I ride.
Yup, when you're not using a VPN, even with encrypted DNS and HTTPS, you're still sending hostnames (e.g. wikileaks.org) over plaintext in TLS SNI for every HTTPS connection. I believe most firewall appliances now even prefer to use SNI for deep-packet-inspection since it's so reliable.
2018 video by Ian Pratt covers Xen, uXen and AX (2005-2015), https://news.ycombinator.com/item?id=44135977#44141164. Citrix acquired XenSource. Pratt left to work at Bromium, acquired by HP (which previously acquired BIOS company from Bromium co-founder). The former CTO of XenSource co-founded Qumranet (KVM), acquired by RedHat.
AWS began with Xen, then migrated to a subset of KVM. Nitro used Arm hardware to virtualize I/O (storage, network) paths, leaving KVM responsible for x86 CPU and memory virtualization, https://www.youtube.com/watch?v=e8DVmwj3OEs & https://news.ycombinator.com/item?id=24515019#24516523. Parallels could be drawn to the Apple T2 enclave (Arm) coprocessor being used for disk encryption on x86 Apple Macbooks.
Under the "Confidential Computing" umbrella, Intel has TDX and a new (closed?) hypervisor on servers, using SGX and new hardware privilege levels.
Apple recently added Secure eXclaves to iOS, and Apple Silicon hardware supports nested virtualization, which is what Google pKVM uses on Pixel (and upcoming ChromeOS?) devices, https://news.ycombinator.com/item?id=43314657
For production code, pKVM deserves attention because it's open (upstreamed to mainline Linux), exists in the real world (Pixel phones), stands in stark contrast to Apple's neutered iPads and has the potential to improve upon TrustZone security, https://news.ycombinator.com/item?id=41523758.
Finally, to bring this thread back to Barrelfish, Google OpenTitan open silicon root of trust (OCP servers, Chromebooks) is partly under Pulp Platform research, alongside Snitch (descended from Barrelfish research) open hardware from ETH Zurich. So progress is being made in both mainstream-compatible systems software and greenfield hardware cores.
(hopefully readers can correct any errors or gaps above)
The virtualization of I/O is fascinating, and VirtIO's progress from the Linux kernel to hardware implementations. My only wish is that Linux would support inter-VM shared memory as a VirtIO transport in addition to pci and mmio.
Thanks for the pKVM tip, and the connection between OpenTitan and Barrelfish.
Speaking of security and open-source hardware, shameless plug of stuff I work on:
- dev.tillitis.se (FPGA-based OSHW RoT)
- system-transparency.org (related to CC, TDX, SNP)
Yes. I've used Qubes on and off since 2012. What I'd love to do is run Linux on top of seL4, and virtio-backends in VMs. There is a patch for ivshmemv2, but it seems abandoned.
Thank you! I realize now that I was thinking about a different aspect of systems research, but failed to say so.
Barrelfish (multikernel) and your username made me think of manycore systems and the scheduling challenges we will surely face as systems become more heterogeneous. I'm in a period of trying to learn more about that. Any and all recommendations are much appreciated.
> compute.. is handled by 140 of Tenstorrent's Tensix cores, each of which is composed of five "Baby RISC-V" cores, a pair of routers, a compute complex, and some L1 cache.. Tensix cores account for 700 of the 752 so-called baby RISC-V cores on board.. TT-Metalium low-level programming model.. kernels themselves are plain C++ with APIs.. Tenstorrent aims to support running any AI model on its accelerators using commonly used runtimes like PyTorch, ONNX, JAX, TensorFlow, and vLLM.
> A novel mapping interface provides explicit programmer controlled placement of data in the memory hierarchy and assignment of tasks to processors in a way that is orthogonal to correctness, thereby enabling easy porting and tuning of Legion applications to new architectures.. Legion is developed as an open source project, with major contributions from LANL, NVIDIA Research, SLAC, and Stanford.
> there's definitely been a lottery win or a series A
We have neither won the lottery nor taken on outside investment. We've been growing for years, and we've reached a point where we can afford campaigns like this. It is an interesting experiment by our marketing team. Still, I think people on HN overestimate the cost of campaigns like this.
> Did they get a cash infusion? Why all of the sudden are they expanding?
No cash infusion. We've been growing for years, just like many other VPN services. We're still quite a bit smaller than e.g. Nord and Express though.
As for our choice of advertising, we don't run an affiliate program, nor do we want to track our customers through online ads, so we're trying this instead. It's cheaper than you might think.
Sorry for hijacking the thread, but I'm too curious not to ask: is having censorship circumvention out of the box a non-goal for Mullvad?
Because there are VPNs with good censorship circumvention tech, and there are VPNs with good privacy guarantees, but I know none which can provide both. What Mullvad offers now is either a decade old stuff which is blocked even by subpar DPI solutions, or a set of (more modern) protocol bridges which are painful to setup and sometimes IP-banned.
Mullvad's mission is to make mass surveillance AND online censorship ineffective. So yes, we do intend to offer excellent censorship circumvention out of the box.
Having said that we have clearly prioritized privacy for a long time. For what it's worth we have several censorship improvements on the roadmap. Stay tuned.
I already see shadowsocks which is nice. I'm still forced to use V2ray and xray-core in some rejoins though so I route traffic from my device -> xray -> my server -> wireguard mullvad. Works for now I suppose. Also been experimenting with routing small amounts of traffic through the syncthing relay network since they have relays running locally which may be in less restrictive provinces
Interesting. Try reaching out to Mullvad's support as well if you haven't done so already. If I'm not mistaken they conduct censorship circumvention experiments from time to time together with customers. I'm sure they'd also be interested to hear about any long-term resilient low-bandwidth channels you've found, such as the syncthing relay network. Those are very useful for bootstrapping and configuration updates.
Hey. Silly thought. I used to have the idea that Mullvad is the only VPN I trust because the founders seemed ideologically motivated (I guess from some interview I read, don't remember for sure). But advertising seems to undermine that view. Maybe I was just naive.
Hi! I used to think that the product should speak for itself, only grow by word of mouth, and that it was wrong to do any advertising. Part of me still thinks that.
On the other hand we ran a very political advertising campaign one-two years ago when we protested a new EU law proposal. We plastered Stockholm's airport in billboards targeting EU politicians and journalists. We published a book and sent copies to several hundred politicians. It was quite a success. Incidentally our office was raided by the Swedish police a month later - the first time in 14 years.
I really appreciate your feedback. Are you able to pinpoint more exactly why you feel that our advertising undermines trust in our brand? Is it simply the fact that we're advertising at all?
Our marketing team works hard to ensure that our advertising doesn't make security guarantees we can't keep, or sell the product through fear-mongering. I feel that we've found a set of advertising messages that work, but clearly it still causes some unease and skepticism.
Perhaps it's simply a worry that we'll change because Mullvad is growing up and is no longer an obscure underdog?
I assume you're referring to this[1]. I don't think it's necessary to bring all of that into the Go runtime itself, or ask the Go team to maintain it. It would be part of your application, and similar to a board support package.
TamaGo already supports UEFI on x86, and that too would be part of the BSP for your application, not something that would need to be upstreamed to Go proper. Same for AMD SEV SNP.
As for you (nanovms) supporting new instance types, wouldn't it be nice to do that work in Go? :)
Edit: I wonder how big the performance impact would be if you used TamaGo's virtio-net support instead of calling from Go into nanos.
> This proposal seems to be taking that approach to the extreme - not even a kernel.
To be fair, there is a kernel - the Go runtime. But since there is no privilege separation it classifies as a unikernel. Performance gains should be expected compared to a system where you have to copy data to/from guest VM kernel space to guest VM user space.
> I wonder if it could run on cloud VMs?
Yes. TamaGo currently runs in KVM guests with the following VMMs: Cloud Hypervisor, Firecracker microvm, QEMU microvm.
> How tiny could the image become?
Roughly the same size as your current Go binary. TamaGo doesn't add much.
I like Anil Madhavapeddy's definition for such setups. A compiler that just refuses to stop:
MirageOS is a system written in pure OCaml where not only do common network protocols and file systems and high-level things like web servers and web stacks can all be expressed in OCaml but the compiler just refuses to stop ... compiler, instead of stopping and generating a binary that you then run inside Linux or Windows, will continue to specialize the application that it is compiling and ... emit a full operating system that can just boot by itself.
reply