105 karma · joined March 22, 2008
I think one of the best things we can do as security professionals is to identify or work to create security measures that have outsized ROI and advocate for those. Using battle-tested software is one, as are, I believe, measures like MFA.
We would love to get your feedback and we hope you find it useful.
We'd love feedback from anyone who is interested in adding annotations, and especially those working on teams who could benefit from being able to share annotations.
We definitely understand that a lot of data is currently siloed, so to that end we're also interested in the annotation formats that we should be looking at. We currently export our own json format, but we would love to work well with existing tools.
There are tradeoffs, but I found it to be an overall net positive in addition to the technical assessment. Doing this effectively requires that the interviewer have a pretty broad exposure to lots of different technology, otherwise you can't distinguish between someone BSing their role vs something you just don't know a lot about / can't ask intelligent questions about. It's also incredibly subjective, which would make me hesitant to rely on it without more objective criteria.
Our hope is that much like policies around code review, where often you can commit to master, but by policy you don't and request a review first, your coworkers will see the value in everyone contributing so that everyone is kept aware and the log is maintained.
I put together a gist with the currently supported services: https://gist.github.com/gsoltis/302b3e60d385854a9a5158d0c071...
Edit: I'm not affiliated in any way.
If anyone has the time and inclination, I'd love some feedback.
RxJava: https://gist.github.com/gsoltis/86210e3259dcc6998801 RxJS: https://gist.github.com/gsoltis/ee20138502a4764650f2
Also, is ReactiveCocoa what most people would use to do this in ObjC? https://github.com/Reactive-Extensions/Rx.ObjC doesn't seem particularly active.
You can also use the REST API (https://www.firebase.com/docs/rest-api-quickstart.html) to interact with Firebase from any platform.
You can also observe arbitrary data changes and log any info that is relevant to you.
As for passwords, we have a few details here at the bottom of the page here: https://www.firebase.com/docs/security-quickstart.html
The short answer is that we use bcrypt for password storage.
Hope that helps!
If this is something you're looking for, my recommendation is to look at either large companies that have large infrastructure needs (Google, Facebook, Twitter, Amazon, LinkedIn, etc.) or small infrastructure-related startups, depending on your preferred working environment. If the hard parts of your job are offloaded to the database/language runtime/middleware, look for companies that work on databases, language runtimes or middleware. And in the interview, ask them for examples of hard problems that they have solved.
Also, I have absolutely nothing against the companies that don't do this kind of work. In fact, Firebase exists so others don't have to do this kind of work. This is just an observation that occasionally, the skillset tested in these interviews is not in line with the responsibilities a successful candidate will end up having, so make sure you ask.
We use a mix of different methods to maintain a connection. We normally start with our custom long polling implementation and move to websockets when they are available. We do not currently make use of any flash sockets.
It might be interesting to try something like this with a generator, so that "for response in process_request(request): send_response_to_client(response)" would work.
I would hope we all recognize by now that even running all lines of code (100% test coverage) is insufficient to find all errors (especially semantic ones). In any language.
It's worth making the distinction between legal rights and natural rights. Obviously, if a particular draconian and unjust law were passed that guaranteed the right to secure your 3kb of data, then you have the legal right to do so. That fact has mostly no bearing on your natural right to do so.
It's also worth noting that sharing between friends and someone making a large profit off of sharing are not the only options. It is not hard to envision a situation with a large amount of sharing and no one profiting directly the way kim dotcom did. It has the scale of the profiteers, but the intent and profitability of the between-friends sharing. I think it is a lot harder to find someone worthy of being called a criminal in such a situation.
Speaking to the philosophical issue that pg raised, I believe people have a right to attempt to make money from their efforts. I also believe that they most definitely do not have a right to be successful in that attempt, regardless of how much effort they have put in. They also do not have a right to continued success if the world around them changes. What works on Monday may not work on Friday, and the fact that it worked Monday should not serve as a guarantee that Friday's endeavor has a right to success. If the effort it takes to secure a number of the size required to represent a 3 minute song becomes a burden on society, then I do not think they have a right to be successful in doing so. The same goes for the software I produce. If my securing it from copying that I do not approve of becomes a burden on society, then I do not have a right to be successful in securing it. Personally, I interpret a circumvention of due process and an attitude of "guilty until a successful appeal is filed" as a burden on society.
The problem is, someone out there isn't doing at least one of the above suggestions (or others that I've forgotten), or someone will intercept the original input while it's in flight (no one uses unencrypted connections on open public wifi, right?) or make use of some other arbitrary way that passwords can currently get stolen. And once they get that original digital representation of your typing style, you're done. That method will never be secure for you again for any service, unless you spend the time to change your typing style (and remember your new style should not be at all predictable to someone who knows your old style).