4 ms·

This is a impressive amount of work to keep things fast and to avoid hammering GitHub with redundant requests, which can get you rate limited[1] pretty quickly.

This is a impressive amount of work to keep things fast and to avoid hammering GitHub with redundant requests, which can get you rate limited[1] pretty quickly. Couple questions: * I'm assuming you are using the actual end user's token for auth, so at least you have the 5000 requests per user per hour? * It sounds like the Ship server has a lot of (potentially private) user data sitting around to keep things fast. What sort of security do you have in place to prevent data leaks or malicious access? [1] - https://developer.github.com/v3/#rate-limiting https://developer.github.com/v3/#rate-limiting

weaksauce 10y ago
> Ship isn't just another GitHub API client app. Ship's custom server code listens and watches for changes from GitHub, and pushes efficient delta updates to clients. Looks like you connect to their servers for updates.
- stephenr 10y ago
  I'm not really a GitHub user anyway, but that to me is a complete red flag. Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term. Honestly the 'server' part sounds like a solution looking for a problem.
kogir 10y ago
> I'm assuming you are using the actual end user's token for auth Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests. > What sort of security do you have in place to prevent data leaks or malicious access? We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries. I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.
- tptacek 10y ago
  For whatever this is worth to anyone: there are not a lot of people who run bug tracking services that I would trust with my Github credentials, but Nick is one of them.

weaksauce 10y ago

> Ship isn't just another GitHub API client app. Ship's custom server code listens and watches for changes from GitHub, and pushes efficient delta updates to clients. Looks like you connect to their servers for updates.

stephenr 10y ago
I'm not really a GitHub user anyway, but that to me is a complete red flag. Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term. Honestly the 'server' part sounds like a solution looking for a problem.

kogir 10y ago

> I'm assuming you are using the actual end user's token for auth Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests. > What sort of security do you have in place to prevent data leaks or malicious access? We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries. I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.

tptacek 10y ago
For whatever this is worth to anyone: there are not a lot of people who run bug tracking services that I would trust with my Github credentials, but Nick is one of them.