Normally the person showing off something with Show HN also comes into the comments but I haven't seen anything. Is this yours, hkr_mag? Even one of your competitors showed up in the comments...
Some feedback (edited to add stuff twice):
- The pricing is confusing. The front page shows me how to install it and run but then another page mentions a free trial? Is that's what I'm doing when I install via apt-get or run via docker?
- What's Wallarm Cloud? It appears to me Wallarm is an nginx module that "protects" stuff, somehow, and for some (maybe all) things it sends them to the Wallarm cloud for analysis. What is the Wallarm Cloud and how does that protect all of my data that it's receiving? What if it's receiving HIPPA data? Is it stored / cached and if so for how long?
- When attempting to register I think it's best to provide a verify option for the password.
- When attempting to register I keep getting errors stating my password is too simple. Even after 50 characters. I assume this is doing a check for symbols or something but allowing any character and then me putting in 50 characters I think it's safe to say it's no longer "too simple"
- You're using CORS but it's a subdomain; you don't need to do anything with CORS at all unless you really want to (but who wants to preflight every single request if you don't have to?). Just set the document.domain to the same domain and you're done.
- I think you can make your registration services flow a little better. Since it makes a request to get a token from the backend and it provides nothing with the request (minus the session id cookie) then that means you're managing session state on the backend so why are you also managing state on the front end? I get the idea behind the token but you have a token and a session id and you're using token more like a session id as it doesn't appear to change when I make calls to it.
- Why do I have a "permissions":["admin"] in my profile? :)
- Clicking on "Profile" takes me to a profile page, it downloads all of the resources and makes REST calls, and then it redirects back to active. Why not do this server-side so it's immediate and less bandwidth intensive? Alternatively if I haven't activated and I entered the wrong email address or other information now I can't update it at all. I have to create a new account. I'd suggest letting profile information be updated.
- Seems too black-box-y to me. I'd like to see something more to the point. Then again I'm an engineer but typically for products like this I've found you need at least some engineer buy-in to sell it to a company.
BinaryIdiot — thanks for a great feedback! I'll answer in several posts.
# What's Wallarm Cloud?
A very good question! We can't run machine-learning stuff on the Nodes as it is performance consuming thing. But we can get all the metrics from all the node (some of our customers have 300+ of them) and craft blocking rules in our cloud. We don't get data; we analyze only statistics. So, we don't have sensitive data. Also, it's possible to deploy a standalone version of Wallarm Cloud.
Here's how it works:
1. All web traffic is proxied through Wallarm Nodes which instantly block any malicious/abnormal request preventing it reaching the application.
2. To get rid of false positives and for better protection, Wallarm Nodes like New Relic agents share application metrics in exchange for an updated blocking ruleset. Wallarm Cloud crafts application profile, its structure, normal user behaviour—and updates corresponding blocking rules every 15 minutes using machine learning. Updated blocking rules are distributed among all the Wallarm Nodes.
3. A built-in vulnerability scanner discovers security flaws in an application and checks the actual severity of each payload detected in attacks (is it targeting existing vulnerability?) allowing to prioritize company defensive efforts.
The only case when we're receiving the data from the request when we detect a malicious request. We need this request to show analytics in the user interface and get a payload to check if it's targeting vulnerability. To avoid situations when we get sensitive data with attacks details, it's possible to configure Wallarm Node to cut all the data from sensitive fields (cookies, password, SSNs, etc.). We have companies with HIPAA certificates.
Almost the whole team is almost paranoid about the passwords. But I totally agree that requirement for the password are not clear now. Will make it work smoother.
- Seems too black-box-y to me. I'd like to see something more to the point. Then again I'm an engineer but typically for products like this I've found you need at least some engineer buy-in to sell it to a company.
Could you elaborate on this. What details do we need to add the website to make it less blackboxy? BTW, did you have a look at docs.wallarm.com?
> Why do I have a "permissions":["admin"] in my profile? :)
Congratulations! :) You're admin of your company. You can add another admin who can deploy nodes or can add analyst guys who can only view data on attacks and vulnerabilities you have.
Some feedback (edited to add stuff twice):
- The pricing is confusing. The front page shows me how to install it and run but then another page mentions a free trial? Is that's what I'm doing when I install via apt-get or run via docker?
- What's Wallarm Cloud? It appears to me Wallarm is an nginx module that "protects" stuff, somehow, and for some (maybe all) things it sends them to the Wallarm cloud for analysis. What is the Wallarm Cloud and how does that protect all of my data that it's receiving? What if it's receiving HIPPA data? Is it stored / cached and if so for how long?
- When attempting to register I think it's best to provide a verify option for the password.
- When attempting to register I keep getting errors stating my password is too simple. Even after 50 characters. I assume this is doing a check for symbols or something but allowing any character and then me putting in 50 characters I think it's safe to say it's no longer "too simple"
- You're using CORS but it's a subdomain; you don't need to do anything with CORS at all unless you really want to (but who wants to preflight every single request if you don't have to?). Just set the document.domain to the same domain and you're done.
- I think you can make your registration services flow a little better. Since it makes a request to get a token from the backend and it provides nothing with the request (minus the session id cookie) then that means you're managing session state on the backend so why are you also managing state on the front end? I get the idea behind the token but you have a token and a session id and you're using token more like a session id as it doesn't appear to change when I make calls to it.
- Why do I have a "permissions":["admin"] in my profile? :)
- Clicking on "Profile" takes me to a profile page, it downloads all of the resources and makes REST calls, and then it redirects back to active. Why not do this server-side so it's immediate and less bandwidth intensive? Alternatively if I haven't activated and I entered the wrong email address or other information now I can't update it at all. I have to create a new account. I'd suggest letting profile information be updated.
- Seems too black-box-y to me. I'd like to see something more to the point. Then again I'm an engineer but typically for products like this I've found you need at least some engineer buy-in to sell it to a company.