[mahmoudimus]

(disclaimer: I work for VGS)

Hi robert204,

Your question has two specific parts that I want to address:

1) Single Point of Failure

2) Larger target for malicious actors

Regarding point #1:

- We have invested significant amount of resources in making our product as stateless as possible and our core product can live on different cloud providers' edge networks.

- We conduct failover tests every 2 weeks to ensure we have the capability to respond to any blips in downtime. Our SOC2 Type2 report is available to discuss the availability and disaster recovery items in detail.

- As a side note: We solve the issue of the "vendor is down" problem -- for example, we have customers who seamlessly switch between providers, say credit score checks, when one of them is down without the liability of storing that data themselves.

Regarding point #2:

- This is our core focus. We take on the liability. The idea here is if this is the core focus, we can do this better than a lot of folks out there.

- We also broker access to different Fortune 500 institutions that visit our offices and constantly pen-test us, audit us, etc.

I think it's important to acknowledge that as developers security is always important, but never prioritized until its urgent. We are trying to change that @ VGS.

Please, email me directly and I'm happy to have a further chat: mahmoud @ ${COMPANY_NAME}.com

[fefe23]

You had me at "cloud providers". If you store the data on some cloud provider, then you are just as bad as what your prospective customers are doing.

I don't want any of my sensitive data stored on "some cloud provider".

Also, your security strategy apparently boils down to "we'll be REAL CAREFUL, pinky swear!"

That strategy does not work, and has never worked before. The whole reason why you think your product is needed is because your prospective customers do it just like that.

I'm stunned you found investors with this proposition.

[drexlspivey]

> Also, your security strategy apparently boils down to "we'll be REAL CAREFUL, pinky swear!"

Case in point: T Mobile Austria. https://nordvpn.com/blog/t-mobile-passwords-hacked-twitter/

[wepple]

I’m curious, what’s wrong with storing this type of data in a cloud provider?

Also, security aside wouldn’t a16z have invested because the business isn’t “do it more securely”, but “outsource PCI compliance entirely”?

[raesene9]

If by outsourcing PCI compliance entirely, they mean "ensure you don't store cardholder data by tokenizing it and we store the real stuff" this is very much not a new solution, so I'd struggle a bit to see the value of a new entrant.

There's already quite a few payment gateways where an e-commerce site can iFrame the payment page (or similar) to ensure that they never see the real cardholder data.

(the fact that this shouldn't really make them out-of-scope for PCI is a different problem)

[twelve40]

This is not a payments gateway. We use them for something entirely different than processing payments or credit cards. I haven't seen a general PCI-compliant transparent PII tokenizer proxy service like that. If you know of one, let me know, maybe we'll even switch. But this is not a payment gateway solution, and it's offering many more use cases than an iframe or credit cards.

[nodesocket]

I can think of a few:

  1.) Shared resources, and exploits like meltdown and spectre 
  2.) Cloud provider employees potentially have access
  3.) Cloud providers are subject to law enforcement requests

However, there are benefits. Typically Google Cloud for example is going to have much better systems and security that a home-rolled data center setup. They've been working on it for years and essentially have unlimited resources (time and capital).

[grenoire]

Here in HN, we all know what happened whenever a large actor took on the liability. The answers here are almost insulting given the category of the service provided; dismissive even.