ipapikas

Ok, maybe the initial position, mentioning endorsements, was very strict.

A tool, maybe in your case is a development or design tool, can become a generic skill. It is common to get a rating/review for something that it's not that personal and it can come from a stranger. Maybe we can think about ebay reviews or stackoverflow upvotes.

Although the problem from this point of view remains, it can be a large improvement in general ratings and reviews.

I hope this helps!

That's we are trying to solve, the underlying idea. It's broken because it's based on what you just described.

But, getting a rating (or an endorsement) from a stranger, it won't affect you really (it won't always go +1) as it's based on the person's knowledge about that tool. On the other hand, if the person knows that tool really well (has a good rating), then that's good for you, I guess :-)

Does this make sense?

1) You have a point. One 'Who we are' section coming up. :)

2) If you mean you have 1000 users across all websites you could create a different account for each of them. We know this might become a pain to manage so we are planning to allow users to manage multiple websites in future versions an each will be priced separately.

3) If you're talking about allowing users to give different access levels to their users then we already have that on our roadmap.

4) If anything happens to us we will be providing assistance to website owners to recover their data. We also support user export at any moment and this should cover you.

5) We verify users on signup by asking them to click a link we email to them. Social login also guarantees email verification.

6) Caching and custom login pages is a feature we support at the moment, so that you will be able to avoid calling the loginBox all the time. We are working against DoS attacks in parallel.

7) As long as both accounts have the same email you should be fine. We treat social logins as a verification for the email associated with it.

I will email you so we can meet and talk about them! Thanks a lot!

We have in mind that username can be a lot of things including email, a unique username or even a phone number. It depends on the approach but definitely under consideration in order to improve. Thanks!

It's a lot to do and think right now (as always for this kind of service) and we have to focus on making our uptime trustworthy and our architecture solid! This is just our first draft of our page and the loginBox demo is on its way this week along with the beta dashboard. We are going to make it more clear and answer to those questions in advance! Thanks a lot for all!

It's only our first draft and it's natural to have similarities. You can expect big changes and improvements in the future! As our first landing page for the product, we have to redesign a lot of things and this is exactly why we are here! We want to make it easier for people to understand what services we are providing. We noticed a demand on payments so we are planning a lot of effort into making it happen. Thanks a lot!!!

Thanks a lot! We will do our best to provide a valuable product and hopefully you'll decide to come and work with us in the future! ;-)

Thanks for letting us know! We will fix those links as soon as we have the documents ready. We just added a more explanatory text!

We'll change the background soon. Thanks for letting us know. As for subresource integrity, it's in our plans for future versions. Right now we are focusing on making our main features as secure as possible.

Thanks for the comment! At the moment we are focusing on frontend and mobile so we have to be able to access the authentication tokens from the javascript. However, localStorage is an option we are currently exploring to use instead of cookies. For mobile we agree that they have their filesystem to store the tokens securely.

As we replied to a previous comment, we just launched the website and we are getting our certificate right now. However, the underlying api is on HTTPS. ;-)

We just launched the website and we are getting our certificate right now. However, the underlying api is on HTTPS. ;-)

What we actually meant is that Multi-Factor Authentication is the same as Two-Factor Authentication but with multiple options for the second step. We are going to fix it ASAP to avoid confusion. Thanks a lot for bringing this to our attention.

We don't know why this is happening and we are on it. Meanwhile please try a different browser! Thanks!