beeker87

At the moment, it's mainly just price. We try to offer the same services but with much more affordable plans.

One spot where we do differ greatly though is our bulk email verification. We check for more risk factors and information about an email address compared to other companies.

This companies directory part of our site though is more just a service for easily finding the main contact information and emails for a company, without having to be a member of MailDB. Being a member is free, though! :)

Thank you for your code, I will be definitely be referring to this as I build the base of my current project.

Diving back into Node though, just so I can get my current portfolio up to par and job-ready, it makes me realize how broken this whole process is.

It seems like bi-annually, either Node.js is changing, Webpack is changing, React is changing, or possibly all three have changed. What you learned just a year ago has been modified and 'updated', usually with configuration and API changes. This leads to a whole slew of new articles and tutorials and boilerplate GitHub projects being created, only to be somewhat legacy less than a year down the road.

Then the plugins you have to learn, all of which separately might have configuration and API changes from one version to the next... Then you have to learn server side rendering because all of this is built for the client, so it's time to incorporate some weird page loading query string hacks to get that working...

All of this feels like it's just one hack put on top of another, to try and achieve what browsers have been doing since the 90's, just without reloading the page.

I think the updates to JavaScript in ES6 like arrow functions, classes, the spread operator, etc are great, but even this I could see going down the C++ route of just trying to add every single feature a programmer can think of to the language.

This is why I prefer Go so heavily. The core language keywords and features have not really changed since its inception. I hope one day this can all be condensed and simplified, much like Go is doing for backend languages.

I'm sorry, this is a mistake!

I'm using MailChimp for building the email list, and I'm using the same MailChimp account as I do for my main SaaS, MailDB (https://maildb.io).

This is completely separate and has nothing to do with that site - I thought the settings were different for this specific list.

I'll double check now, thank you! And no worries, you will never be emailed regarding that site - this list is only for SaaScriber and this idea alone.

Edit: fixed, thank you again!

The way I was looking at it, this is something we want to form a real team around and build in 4-6 months time.

While we could try to leverage our own idea, without having this site known and heavily trafficked, the subscriptions will be minuscule and probably not enough to achieve our goals - look at early Kickstarter. An influx of cash would help get the word out.

Plus, we're hoping to work with SaaS companies who sign up and see which products/ideas want to launch with us.

I do see your point though. Maybe this is something where it needs to start small, using the idea itself as proof.

Within the member panel (for now).

Sorry just saw this, it's the autocert package bradfitz linked to.

Just want to say, I'm not affiliated with LE, but I think it makes a lot of sense to donate to them if you use their services regularly.

From my own use case, integrating TLS for my site via LE and the autocert package in Go has been seamless. It's completely free (if you want it to be), and it looks like I won't have to worry about renewing certs anymore. The service LE is providing is amazing. Just thinking of the millions of dollars they're collectively saving everyone, yearly, is pretty crazy.

If anyone at LE reads this, thank you for your work!

My previous SaaS product, Navilytics, I built from scratch and ran completely on my own (minus a couple of blog posts from a friend). It very well could have been successful, but I made the mistake of thinking the product would sell itself and never did any real promotion leading up to launch. I paid for this as another competitor, who had the same idea I had at the same time and built their own version of the product, starting marketing it before it was even in beta. They're doing > $1 mil per year now in revenue.

Previous one before that was an affiliate network I ran with a buddy of mine, so just two people. We did very well with this one (but only mildly when compared to other large affiliate networks at the time).

My new project, I'm working with a buddy of mine who's good at the things I'm not so good at. While I think it's 100% possible to be a sole founder and do very well, having a solid team makes the entire process a lot easier. Plus, having people to bounce ideas off of usually leads to making better decisions.

Is anyone else seeing the possible security risk shown in the 'Vision and Face Recognition' section?

The main concern I would have is someone spoofing the visual recognition system with something as crude as photographs, or something more advanced like a mask.

He states in that section, "Once it identifies the person, it checks a list to confirm I'm expecting that person, and if I am then it will let them in and tell me they're here." My first thought is someone could see if there's a friend/acquaintance who routinely visits, and then spoof their face with a mask. Let alone if the system automatically lets Zuckerberg in, then that's all that would be needed.

To be honest, we probably won't try and filter out spam traps. Our service is really meant to aid you in finding specific emails.

Given that, we will be implementing multiple verification and confidence checks for each email address. This is to help ensure a given email address is for a real person, with multiple legitimate web sources listing it, before you ever send a message.

Usually you'll see someone release site data, such as a database dump, via sites like pastebin. Either that or the release is zipped and hosted somewhere for download. We're most likely going to have crawler skip potentially risky sites, such as pastebin. Our crawler also will not have the ability to download and view actual files.

Also, we are probably going to implement specific pages that allow anyone to delist their domain and/or email address from our service.

Awesome. Our goal is to create a quality, enterprise level piece of software, which is affordable for everyone and actually makes sense to use given the price point and benefits.

If you ever want to talk about business/startups or anything, send me an email.

Not a bad idea, could have it work on the same principles as the robot exclusion, but just have a simple web submission form for domains. To prevent malicious use, could maybe have it send a confirmation link for delisting to an email address associated with the domain.

We'll discuss this for beta, thank you!

This is true, but you may have to go through hundreds of search results in order to find the right email. Also, we use extensive pattern matching which would be very hard to mimic through a search query.

In a sense, our service just saves you a lot of time from finding and then verifying an email.

Yes, our service will not return any webmail addresses such as Gmail, Yahoo, MSN, and the like.

We will most likely have a specific page which lets users delist their email.

Exactly, our goal is to make this service something affordable for everyone. The current solutions, imho, are charging an insane amount for what they offer.

We haven't discussed this yet but it seems like a good idea, so we'll probably have a page dedicated to this where users can tell us to remove their email from our database.

Once we're in beta, our crawler will operate under a specific name which you can refer to in your robots.txt exclusion rules. We'll have an info page for this.

I agree that an email address is something very valuable.

With our service though, it's simply storing emails found through a vast search of the web. If, for instance, a CEO at a company doesn't give out their email publicly, you'll never be able to find it using us because we will never find it. However, if they did post their email somewhere, chances are you could find it with enough time and clever searching.

Our service aims to minimize the time spent for the latter. In that sense, we simply give you an advantage. Not everyone will be using our service.

We only track emails that have been publicly posted on the web.

Using emails that have been submitted to us through our signup form would obviously be a huge violation of privacy. We don't do this, and we never will.

You can view our privacy policy here https://maildb.io/privacy

Thank you!

For spammers specifically, you're correct in that our service could possibly be used to gather emails by someone with the intention of spamming. This is true though really for any lead generation type service.

While we will be offering a free plan level, it will be very limited in terms of the number of emails you can find. In order to get more requests, there will be paid monthly plans. To be honest, the crawler part of our service is something sophisticated spammers have probably been doing for awhile now, and wouldn't see the benefit of paying for, for their specific uses.

With regards to the privacy concern, our crawler only finds emails that have been publicly posted. It also follows the standard rules expected of web crawlers today. For users to find emails, they must do so by a specific domain name, so for instance you couldn't just search for John Doe and find a Gmail address.

100% agree.

With Angular, you're basically having to learn an entirely new MVC framework, complete with a mess of its own methods and definitions, which is built on an already existing MVC framework (a web browser).

When I took some time maybe four years ago or so to study Angular, I came to the conclusion that it's just the wrong way to go about web development. I started thinking hell, I'm just gonna write my own library which strictly handles the view portion. Low and behold, I find React, and it's everything I was hoping for.

If anyone is thinking about trying out Angular, save yourself time and headaches and use React or Vue.js

I think the transition could have been much smoother and did not require engineering a new MVC framework on top of an already existing MVC framework. The only thing needed to make a page mobile ready is responsive CSS. What is more of a concern for mobile, and especially was back in 2009, is how much processing power a page needs to render and function fluidly.

The truth is React isn't doing anything that requires new technology, it could've been built in the early 2000's. I guess ideas like Angular taking off are just the natural way of things when you have a big company supporting it. It goes to show though that even the largest companies on the planet sometimes get it wrong (but also get many things right, Google with Golang and Facebook with React). Did it really take 4-5 other inferior frameworks though to see the simplistic idea behind React and build it out? If so, people who see these bad practices happening and are capable of doing something about it should do so immediately, for the sake of the development community.

I truly feel sorry for those who started learning web development somewhere between 2009 and 2014.

During that time, it seems like what would be accepted as the new standard for creating web applications was completely up for grabs. You had Angular, Backbone, Ember, and probably many others that just didn't get noticed.

Can you imagine being a new developer during this time, trying to learn how to create a web application with no prior knowledge?

When I started getting serious about this in 2006 or so, it was difficult enough just learning the basics of HTML, CSS, JavaScript, and how everything worked together. I have been into computers and programming my entire life, had learned C and a few other languages, and it still took me years to become an intermediate 'full-stack' developer. Again this is before any of these MVC frameworks were out.

I think the main problem comes in when you try to engineer a completely new standard on top of an already existing standard.

Whatever happened to using servers and browsers as they were meant to be used? Why are we constantly trying to reinvent the standard and giving these libraries which make everything more complicated attention? Is the reduction in requests to the server by having everything on client side really that beneficial with today's computing power and language capabilities (Golang http://marcio.io/2015/07/handling-1-million-requests-per-min...)? The logic here escapes me.

Angular wants you to basically use a new language and web architecture, complete with hundreds of pages of documentation specific to Angular, on top of the standard. I didn't hear about Angular Material until now, and it's even more mind boggling - are we trying to have every site look and function just like the Google platform now? There's already a standard for that - no styling on inputs (granted it will look different from browser to browser).

Luckily though, after half a decade, it seems like the community has a better understanding of what would be best and the tools have been built for it. I think in the near future, we'll see Golang and React take the lead in their respective areas of web development.

In your paper you say,

"When using the headless configuration, we are able to run up to 10 stateful browser instances on an Amazon EC2 “c4.2xlarge” virtual machine."

Also it seems like you ran the crawl only in the month of January this year, and crawled about 90 million pages. Were you able to do that on the single AWS instance, using Firefox via Selenium? What do you think the performance would have been just issuing raw requests?

Just interested because I'm currently building a crawler and am trying to decide if Selenium would be worth it performance wise.

Wouldn't it be a lot easier and more secure if you simply looked up the code in these packages you're using, reviewed the code to make sure it's legitimate, then copied it to say, your own utils.js package? I'm not even talking about the left-pad package, which shouldn't even be part of the discussion... If you're worried about including 2-4 lines of code on your own then you shouldn't be making an application other people will use in the first place.

Apparently it's not obvious that having a ton of dependencies on 3rd party packages, of which can change at any time on the whim of the owner, is pretty insane in terms of security and minimizing complexity of your application.

You do realize that even though you reviewed the 20 different packages you use at one time, they can change at any time?

I would love to hear what a senior dev at any reputable, long established technology company thinks about including tens, if not hundreds (and some apps, thousands?) of 3rd party packages from strangers on the internet with no validity checks in place. Sign me up!

No problem, and yeah I only tested simple player vars like jumping, nothing harm wise that would affect other players. Doing the server side check on that is perfect though, so it's obv you guys are aware of it (thought as much given the level of code).

I'll definitely let you know if I find anything else, was just messing with it for an hour or so today :) I apologize too if you don't want this up here and let me know if you want me to delete it.

Saw this posted over on PH and checked it out, extremely impressive game and I'm sure there's a ton of dev time on this. Good job and props to the creators.

I wanted to notify you guys though of some security flaws within the game.

Probably the biggest issue I see is the lack of server side checks against changes coming from the client. I only tested this out on the player object as a PoC, but it only takes changing a variable within the player object to modify things like player speed, mountable craft speed, etc.

For instance, while you obfuscated the name of the player object within the ig.game object, it was easily found by checking for modifications to the health variable, where another function listed it as ig.game.O1376. This name for this player object is also static for every game instance, so it's easily referred to every time.

Once the player object was found, it's easy to modify the variables and the world (server side) accepts it. It was also easy, for the most part, to identify what certain variables did as they were in plain text. To change player jump height for example, all it would take is this piece of JavaScript:

window.ig.game.O1376.altJumpReducedGravityFactor = 0.1;

Now the player can super jump and the server is fine with it (verified by numerous 'holy sh!' and 'wtf!?' comments from other players).

The second thing I see is just obfuscating the code more.

I would suggest first and foremost to do the server side checks. Even if you left all your code in plain text, any modification someone tried to make from the client would be seen, verified, and handled accordingly by the server. Second I would try obfuscating all variable names that you can, especially the class definitions like EntityPlayer. To go further on it, I would have it produce the obfuscated names randomly on each load of the game script so they're not easily referred to.

Just wanted to bring the issue up to you guys after finding it.