brissmyr

Castle.io (YC W16) | First Sales Hire | San Francisco, CA | ONSITE, Full-time

We are looking for our first sales hire to join our founding team and help protect millions of users from account takeover hacks.

You will work directly with the me and close new business for Castle by running the complete sales cycle for all deals. You will help with marketing, product, training, and scale the sales team.

Job description: https://jobs.lever.co/castle/d083fb7a-92de-4180-8a1a-50e32ee...

Castle (YC W16) | Sr. Data Scientist | San Francisco, CA | ONSITE

I'm one of the co-founders at Castle (https://castle.io), a seed funded cybersecurity startup. Castle uses machine learning to protect millions of consumers from account hacks.

We are hiring our second data scientist. We’re looking for someone who would be owning the core piece of our business -- our risk engine -- and who thrives in a fast-paced environment. The ideal candidate would have experience in fraud detection and/or security, and building real-time machine learning algorithms at scale.

Our office is located in San Francisco (SOMA), close to Civic Center BART Station. If you're looking for a small, close-knit startup with an opportunity to have a huge positive impact, please email me at johan@castle.io.

If you would block the analytics script for a user that normally have it enabled, that looks fishy to our detection. We don't (only) compare the collected data with known fraud profiles, but also with how the current user normally accesses the service.

Thanks, this is valid feedback. You're right, account takeover is not the best description unless you're a big financial institution. When working with startups they use us for the (risk-based) authentication, and we're working in that direction, offering 2FA flows, security emails among other things.

Hey! Johan, co-founder of Castle here. My and my co-founder used to work in a financial startup and couldn't find any easy-to-use solutions for account monitoring. We built Castle to be a drop-in solution against account compromise. You track events in your web and mobile apps, and we analyze device, location and usage patterns to make sure they are consistent for each user.

We have lots of plans for improving the product: more 3rd-party integrations, built-in 2FA/captcha, APIs to build your own "security page" with device and session history. Would love to hear the feedback from the HN community!

Worth mentioning is that JWT is used in the OpenID Connect standard, which is built on top of OAuth 2) for the authentication part. We use it in https://userbin.com to smoothly transfer user sessions between different platforms. Previously we used to roll our own (de-)serialization, signing, session expiration and encryption schemes, but JWT solves a lot of pain and makes it more obvious for developers to understand how this part of our authentication flow works, and are able to use the JWT libraries available in most programming languages.

"Selective JPEG Compression" was a new one for me.

For PNG, always run your images through ImageOptim (http://imageoptim.com) before committing your work.

And for large PNGs, ImageAlpha (http://pngmini.com) lets you reduce bit depth, keep transparency and maintain a decent image quality.

Not aware of an interactive modelling tool. There are visualization tools like http://railroady.prestonlee.com which generates graphs showing your model layout. Don't expect too much on the cosmetic side though.

What are the pains you primarily want to solve?

Would be interesting with more recent data on Kaggle.com usage. Anyone?

Hi, I'm co-founder and dev at Userbin. We want the integration of Userbin to feel somewhat similar to what you're used to when working with your favorite Ruby, Node or PHP auth library, rather than being a provider of a cloud-based database of user records. To be in the cloud is not the essence of Userbin, more a vehicle for providing a common configuration interface and suite of management tools.

View Userbin as a kind of aggregator of all the boring and tedious things involved in setting up OAuth connections, designing login flows and tweaking transactional emails. For every new user that signs up through your Userbin account, you create your own local copy of its Userbin profile, much like you're used to when integrating an OAuth provider.

With the rise of more and more clever authentication methods, e.g. fingerprint (Apple Touch ID), facial recognition (http://mashable.com/2013/07/25/facial-recognition-payment) and clicking in pictures (http://pixelpin.co.uk), we thought that why not take this trend to the next level:

Whistle-based Authentication: http://popdevelop.com/whistle

The project uses HTML5 audio (in Chrome) together with some basic signal processing to detect notes that are whistled in a certain order. Only the order is important, so no need for perfect pitch.

And kids, don't use this in anything close to a production environment. This project was developed during the Malmoe Music Hack Weekend 2013 and supports only the two demo users. However feel free to fork the project and add your own users and melodies.

Snap.svg being able to parse existing SVG:s I've generated with Sketch is totally awesome. Even more awesome would be the day when Sketch lets me play around with animations and timelines and then generate Snap.svg instructions.

I agree to some extent. My hypothesis is that during a project you take a lot of shortcuts, because solving that last part of a task sometimes involves a lot of work to get everything perfect and working for every user. It could be making a responsive website work in legacy browsers, or it could be a script I know works in my dev environment but I haven't yet tested in production,. Even so I close my eyes, mark these task as done and move along.

So the last 20% is actually a bunch of 0.5 percenters pushed to the end of a project. At least for me.

Yeah, I saw your service on Heroku a couple of weeks ago. Haven't tried it for our API's yet but I recall you had a pretty nifty approach. Good work!

Webhooks are in need of some standardisation for sure, so moving towards something like PuSH is a step in the right direction. However this technology has been around for a while, so whether this will become standard or not remains unclear.

PuSH solves a couple annoyances with webhooks that comes to my mind:

- Lack of debuggability: the inability to subscribe to events forces me to explicitly set up callback URL(s) on service providers' dashboards or in query strings in requests. IF I managed to set them up correctly, data will come crashing in any day in the future, throwing exceptions, or bouncing on unspecified routes. And all these POST catchers and local tunnels developers play with to get this right in the first place.

- Ad-hoc verification schemes: Every service comes up with their own way of ensuring the data originated from their servers. Signature hashes as 'X-*'-headers, a number of extra fields inside the JSON body, etc.

There are more, but these two has annoyed me for quite some time.

Love the way they are heading with the JSON stuff http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-...

The backend will always be my comfort zone. Even though I've been involved in everything from hacking Linux kernel drivers to designing e-commerce checkouts, the backend still feels like home. Actually I've given this a lot of thought, since I also see this pattern in other full-stack developers. When a group can't make a decision on a frontend strategy, people tend to drop off, start hacking and refactoring backend stuff. Tinkering with the backend is also what we do to get up to speed in the morning, or when we're idling during the day. Maybe it's just me, but even after more than 15 years on both sides, I'd pick the backend any day when it comes to feeling comfortable and seeing progress. These are just feeling however, not proof for any real progress whatsoever...