Amazon Is Downloading Apps From Google Play and Inspecting Them - <AUTHOR> http://blog.rajbala.com/post/81038397871/amazon-is-downloading-apps-from-google-play-and <comment><USER2> This seems to be the natural outcome of Amazon's excellent customer service policy, where they have on numerous occasions[0] refunded costs for hacked instances. When they commit to that policy, they have a huge incentive to limit customer security breaches.

I love examples like that where a company's policies result in incentives that are so well-aligned with those of their users. Does anyone have other good examples to share?

[0] [https://securosis.com/blog/my-500-cloud-security- screwup](https://securosis.com/blog/my-500-cloud-security-screwup) and [http://vertis.io/2013/12/17/an-update-on-my-aws- bill.html](http://vertis.io/2013/12/17/an-update-on-my-aws-bill.html) are two examples.

<comment><USER3> Credit card companies are a good example of the this too. Since they're responsible for fraudulent charges, there's a huge incentive for them to detect them.

<comment><USER4> Although Walmart in their lawsuit against Visa for fees pointed out that Visa is slowing the adoption of security features in the US. [http://www.foxbusiness.com/industries/2014/03/27/wal-mart- fi...](http://www.foxbusiness.com/industries/2014/03/27/wal-mart-files-suit- against-visa-for-m/)

</comment></comment></comment><comment><USER5> I don't think they are inspecting the app ; they don't need to. They can see that there are a higher-than-average number of API accesses from a given platform, using the AWS Secret Key as the login credential.

<comment><AUTHOR> I don't think they're looking for higher than average API calls for a given key because my charges were completely expected.

<comment><USER6> raj, just saw your post on here. I was wondering if you were the same guy Dennis in Delaware was trying to connect us to. We were doing the large scale touchscreen collaboration stuff

<comment><AUTHOR> Nope, not I. :)

<comment><USER6> Ok thanks lol

</comment></comment></comment></comment></comment><comment><USER7> Facebook does the same thing. I got a notice about an application I published years ago in March:

> Security Notice - Your App Secret

> We see that your app, XYZ, is embedding the Facebook integration's App > Secret inside the Android Play Store app bundle for your app. This is a > serious vulnerability that violates our published recommendations for proper > login security. Someone with access to the app secret for your app can act > on behalf of the app - this includes changing configurations for the app, > accessing some types of information associated with people who have granted > permissions to the app, and posting on behalf of those people.

> To mitigate this sizable risk, we have reset the app secret for your app. If > your app is mobile-only, this should not cause any issues. If it has a > server-side component, there is a greater likelihood that it has caused some > issues for your app that you will need to address. Going forward, please do > not include the app secret in your app bundle, or disclose it publicly. You > can read more about app secrets and how to secure your Facebook app here.

<comment><USER8> Now this is interesting. Could we imagine a service that would be in charge of protecting your customers secrets?

You would provide a list of secret strings, and ask to have them monitored on search engines but also from mobile applications, browser extensions, published JARs etc.

<comment><USER9> NOOOOOOOOOOO

But seriously, treat them like passwords.

Don't have the service store the secrets, have the service store hashes of the secrets with a regex for prefiltering (because hashing every word everywhere would be prohibitively expensive).

<comment><USER8> > Don't have the service store the secrets

Why not? You can use the service to make sure it doesn't leak its own secrets so it's safe ;-)

But seriously yes I really like your approach.

You could even provide a second set of API to do the opposite: given a block of text see if there's any sensitive string inside. Google & co could use it before publishing an app in their Store.

<comment><USER10> Either way you still have to trust another third party to keep your secrets safe. Even if the secrets weren't publicly leaked, any comrpomise to this service affects any service whose keys you have stored there.

</comment></comment></comment></comment></comment><comment><USER11> That's actually kind of awesome. Good on Amazon for taking security seriously.

<comment><USER12> That's exactly how I felt. And they wrote such a detailed email with helpful links and everything.

<comment><USER13> If they are really downloading apps to inspect, I suspect the email is an automated template.

<comment><USER14> But someone went through the trouble of writing the template. Most companies wouldn't even bother checking apps in the first place.

</comment></comment></comment></comment><comment><USER15> I understand perfectly how people end up mistakenly pushing credentials into public source repos when releasing server-side stuff. But I don't get how a seemingly sane person develops an application intended for distribution to the public which contains AWS credentials.

At what point in your development process do you say "I want this application, which will be distributed to unknown persons, to contain the means to control my AWS account."?

<comment><USER16> Some people don't realise their apps can be decompiled, it's not a question of sanity.

<comment><USER15> I don't think I've ever encountered that particular illusion in anyone making a living off writing compiled code, only very new developers and non-engineer managers. It's one of the few securityish things that seems to be successfully beaten into everyone's head pretty early on.

(And more often than not, they get there all by themselves -- such people usually appear on my radar asking questions showing they've figured out for themselves that it's a bad idea, they just need help turning that knowledge into practice.)

<comment><USER17> I give talks at development conferences where I mostly blow people's minds by showing how easy it is to pull information out of binaries (both statically and dynamically); there are always tons of questions from the audience afterwards about "but we do X? doesn't that make us safe?", so I have to sit there shooting down a ton of silly ways of obfuscating their data, showing how each one could be defeated, but it "clicks" for everyone that there is no safe way to do this.

</comment></comment></comment></comment><comment><USER18> Anyone who reads the article can see that the author is drawing conclusions from conjecture.

"We were made aware" does not equal "we are downloading apps and inspecting them."

If they were doing that, that would be great! But let's not leap to conclusions.

<comment><AUTHOR> They (or someone working with them) would have had to download the app and inspect it. They clearly tell me that they've detected access credentials in the app itself.

That's not conjecture.

</comment></comment><comment><USER19> I see nothing wrong here. They are probably doing this now because it in fact a major problem, even with large, professionally developed apps. About 8 months ago I did a brief analysis of the then-current Vine apk and relatively quickly extracted their S3 credentials (they were not stored in plain text, but close enough). Very bad idea.

<comment><USER8> The number of valid EC2 keys you can find with a simple GitHub search is mind- blowing (or was, at least, when I tried it a month ago).

</comment></comment><comment><USER20> MixRank analyzes mobiles apps (android and ios) and we often see apps with embedded api secrets, private keys, and passwords. It's really surprising.

If you'd like to send an email like this to your users, send me an email (in profile) and I can query our database and check to see if any of them are including their api keys.

</comment><comment><USER21> Couldn't they just look at the user agent and know that the hit to their API is coming from an Android device rather than a server?

<comment><USER22> [http://developer.android.com/reference/java/net/HttpURLConne...](http://developer.android.com/reference/java/net/HttpURLConnection.html) might not have a default User-Agent header that identifies android

<comment> brown9-2 Of course a developer could change this, but yes the default user-agent string for an Android app using HttpURLConnection identifies it clearly as Android: [http://www.gtrifonov.com/2011/04/15/google-android-user- agen...](http://www.gtrifonov.com/2011/04/15/google-android-user-agent- strings-2/)

</comment></comment></comment><comment><USER23> They did a good thing, title feels slightly misguiding. Could they have figured it out based on API access locations being random?

<comment><AUTHOR> What's misguiding?

No intention to misguide. I think it's completely accurate. They downloaded my app, inspected it, found AWS credentials and emailed me as a result.

<comment> brown9-2 I think the misguiding part (or at least, what the tone suggests) is that the order of events is 1) Amazon downloading and scanning all apps and then 2) looking for AWS credentials in the code.

<comment><AUTHOR> I think that is what's happening. They would have no other way to identify my app and my AWS credentials otherwise.

</comment></comment></comment></comment><comment><USER24> I wonder how they would identify a string that appears to be an API secret, and queries their database for it. For every plausible string in every app? I guess they decompile it and find string literals of the correct length?

<comment><USER25> AWS knows the clients that are connecting to it. All they have to detect is that a large amount of traffic is coming from a wide distribution of mobile devices. This is indicative they embedded the creds into the APK. If they got the creds from a server during runtime, it would be safer to proxy to AWS _through_ the server itself, and never distribute the sensitive data. This would result in only a few proxies connecting to AWS.

Amazon surely has automated this with monitoring. I doubt they ever scan Google Play and download the APKs and scan them. Not only is that extremely wasteful it's most definitely violating the Google Play terms of service.

<comment> brown9-2 It wouldn't even need to be a "large amount of traffic", just traffic using the AWS secret key from more than a handful of IP addresses in the same time window would be suspicious.

</comment></comment></comment><comment><USER26> This is probably a good thing and also automated.

<comment><USER25> It could have raised alarms and then personally investigated. You Could monitor distribution of AWS connections per client. You could easily determine that accessing the same account from many android devices is probably result of poor security practices.

</comment></comment><comment><USER27> I will think they inspect apps based on the number of hits generated to AWS.

The advantages of doing this are 1) showing Amazon thinks for the customers (well, also for itself) 2) proves it has pro-actively notified the customer and done its due diligence.

This step could serve as a solid proof in any dispute on later security issues or/and related costs.

Smart, I will say.

</comment><comment><USER28> I'm curious why some apps need API to access to AWS. What's the use case? Surely not to spin up an EC2 instance when the user clicks a button? Save files to S3? I'm not being sarcastic, genuinely curious. And what's the proposed solution suggested by AWS?

<comment><AUTHOR> Save files to S3.

<comment><USER29> You can do that with signed forms and similar techniques, though. No need to have the key on the client side (and lots of reasons not to).

<comment><USER29> The flow is roughly this:

1) Client: "Hey, I want to upload a file."

2) Server: "Okay, here's a temporary key good for the next <n> minutes. The file has to be named <blah> and can't be more than <x> MB long" (there are other restrictions you can set, too, IIRC)

3) Client posts the form to S3 including the temporary key as a field.

4) Result.

</comment></comment></comment></comment><comment><USER30> great for them. i worked for an unnamed company who was shipping AWS credentials in clients for years. worse, they were not clients that required a packaged binary (no need to decompile). it's long since patched but i can't believe no one ever sniffed that out.

</comment><comment><USER31> We wrote a blog post that shows how you can authenticate your users and get temporary security credentials from AWS based on the user tokens to avoid putting your keys on the client (both JavaScript apps in the browser or native apps). This technique is using Auth0 so you don't have to deploy a TVM and it works with all the APIs (S3, EC2, SQS, SES, etc.). Behind the scenes what we do is generating a SAML Token based on the user JSON Web Token and exchange that for AWS Temp Credentials using AssumeRoleWithSAML AWS API.

[http://blog.auth0.com/2014/03/25/consume-aws-apis-from- the-b...](http://blog.auth0.com/2014/03/25/consume-aws-apis-from-the-browser- securely/)

</comment><comment><USER32> Does Google Play have a public API for downloading APKs? Does it work for paid apps as well? (I'm not able to construct good keywords for search here: Google thinks I'm looking for an APK for the store app instead)

<comment><USER33> > Does Google Play have a public API for downloading APKs? Does it work for > paid apps as well?

There's no "public API" but have fun: [https://github.com/kanzure/googleplay- api](https://github.com/kanzure/googleplay-api)

(because otherwise how does Google Play itself participate in downloading apps?)

</comment></comment><comment><USER34> Well, this is very cool and an approach that some security companies are taking at the moment. "Security outside your network" they call it.

I'm myself working (side/pet project so far) in something similar. I don't have any working software at the moment but some "INTEL" and it is incredible how easy anyone would be able to compromise/hurt people and companies just using available information published by themselves.

If anyone more technical (I'm looking at you, devs!) wants to team up to create a service like this please get in touch.

</comment><comment><USER35> I hope other developers see this and take action if they aren't properly securing cloud API keys. Data access by an unauthorized party is not something you want to deal with.

</comment><comment><USER36> I wonder if any malicious parties have been doing this as well.

<comment><USER37> That's exactly what Amazon trying to prevent.

</comment></comment><comment><USER38> I'm being dumb. I can see that it is preferable to embed credentials for a restricted IAM acct, not your root/master AWS account.

But how does using a TVM improve the situation? Surely you still need to embed creds which allow the app to use the TVM? In that case, an attacker can extract _those_ creds, and ask the TVM for a time-limited token any time they like.

How does using a TVM improve security over embedding the creds of a restricted account?

<comment><USER39> Your token service would authenticate users using their credentials for your system.

<comment><USER38> Still not sure how that helps. In both cases, we have creds embedded in the app which can be used (and only used) for access to the AWS resource.

In one case directly (via an IAM limited account), in another via a token they can request. In both cases, the acct is limited to one specific AWS resource. In both cases, the creds can be revoked centrally. In both cases the creds are embedded in the app.

Smart people who build these things (AWS) seem to think a TVM is a better solution. I don't understand why.

</comment></comment></comment><comment><USER40> What are common use cases for AWS in mobile apps? (where the app needs direct connection to AWS)

<comment><AUTHOR> Reading/writing to S3 was my use case. I'm sure there are others.

</comment></comment><comment><USER41> They also scan for Keys on github. They are proactive in terms of security!

</comment><comment><USER42> a free security audit of your app, pretty cool ;)

</comment><comment><USER43> Or somebody else found it and notified Amazon.

</comment><comment><USER44> Was your source obfuscated?

<comment><USER45> Does it matter? A constant string is a constant string.

<comment><USER46> Well, if you want to obfuscate a constant string in your code, you can, e.g. by generating it dynamically from summing two hardcoded integer arrays. Not to say you should, but you can.

<comment><USER47> That sounds an awful lot like DRM with all its failed approaches…

<comment><USER46> Sounds like? That's what obfuscation is (or more accurately, obfuscation is what DRM is). No one ever claimed, or ever will claim, that obfuscation stops people from seeing what you're doing.

</comment></comment></comment></comment></comment><comment><USER48> Kudos to Amazon.

</comment><comment><USER49> So am I.

</comment><comment><USER50> Ultimately, Web Identity Federation or Federated Identity is the only way to secure apps in walled gardens, which means aligning yourself with a virtual land Barron. I, for one, welcome our new fiefdom overlords. Everything else is just pushing new credentials through temp credentials and obfuscating it with protocol complexity.

</comment><comment><USER51> Go on you Amazon.

</comment><comment><USER52> is decompiling an app legal? does it not break someone's terms of service?

<comment><USER53> Decompilation isn't even needed. They know the credential being sent so an _if(strings | grep -c "foo") != 0 SendEmail()_ is all that is required.

</comment></comment><comment><USER54> One of the things that justifies the higher prices.

+1

</comment><comment><USER25> Conjecture, and I guess you're welcome? My guess is if you embedded your Google cloud credentials in your app and it was compromised Google would be happy to bill you, terminate your account, or otherwise provide zero latitude as a customer. At least they dropped their prices, right?</comment>


Ask HN: How to Be a Decent Manager? - <AUTHOR> As a technical person who's likely on the spectrum and who's very poor in the verbal communication skills department:  I recently started a position to lead a small development team.
This is my first foray into managing; after many, many years of development.
I have little in common with my charges—I don't really expect to be chummy with people at work—but it's 100% my goal to help my underlings succeed in their careers.
Any targeted advice?
There was a former topic that highlights the end goal: https://news.ycombinator.com/item?id=20230133
But do I account for poor verbal skills? <comment><USER2> Your number one role is to be a shit umbrella, protecting your team from all the shit that gets flung at them from all sides.

It's you who will have to say no to the higher ups when they demand that you drop everything and start working on quantum computers because their brother heard about it on a birthday.

It's you who will have to argue with other managers and team leads when they want to push work on your team.

It's you who will have to step up when team members get into bad arguments with each other.

You will have to accept that your job will leave less and less time for the technical side you've done before.

You are no longer the same rank as your team members, never forget that. Because they won't, and if you get into technical arguments with them they might follow your idea because you're the boss, not because you are right.

If you can't or won't want deal with these kinds of things, please don't take the job. Management is a real skill.

<comment><USER3> Not to mention exemplifying the 'company values' for whatever they're worth

<comment><USER4> Yes, the manager's sheen. No matter how you're feeling you should always strive to exude and instill positive energy into any interaction you have with the team.

<comment><USER3> Actually, most of my managers have dragged their asses behind low hanging blue jeans and shown overt contempt for the brand and any form of idealism; at one company I learned 'initiative is punishable' \-- they seem to squirrel themselves into a cozy position with a director and the 'sheen' you describe is more of a greasy film to which on accountability can ever stick

</comment></comment></comment></comment><comment><USER5> You will need to work on your verbal communication (most everyone need to) as it is one of the most critical aspects of being a good leader. But that doesn't mean you have to be super wordy or buddies with everyone.

You do need to be able to read people's body language and understand their motivations, goals and comments even when maybe poorly communicated (this is a learned skill). Good part is generally leading engineers is helped by having solid technical skills yourself as they will respect you more than just a people manager to start and give you more latitude.

I'd also start off with them one and one, and tell them humbly but direct that you sometimes can struggle with verbal communication and that if they see an issue or have a concern to just raise it with you so you can work on it together. Treat everyone as equals with respect and care, don't feel as the manager/leader you are above them, think of being a leader as it is your job to serve your team. If they need a bridge to accomplish their task, you build the bridge for/with them to facilitate.

You can be super successful as a leader, just takes practice and time. Be humble, honest and human and you won't have issues getting people to follow your lead. That said, do not allow people to take advantage of you, being kind and humble is important but that does not mean you are anyones doormat. :)

<comment><USER6> How do you tell difference between being used and being kind/humble ? Any references ti improve this

<comment><USER3> 'humbly' would come from nonverbal cues, and boy oh boy you're not ready to hear the truth but sometimes it's appropriate to dress up at work

<comment><USER7> What does dressing up achieve? I mean I probably already know it but your opinion is welcome.

<comment><USER3> There's no rational explanation but it's the right thing to do

Computing professionals trace their roots to primarily home computing enthusiasts, academics and video game nerds all of whom seem to prefer casual dress in their professional pursuits --

Look at the people working on UNIVAC [https://en.wikipedia.org/wiki/History_of_software#/media/Fil...](https://en.wikipedia.org/wiki/History_of_software#/media/File:Grace_Hopper_and_UNIVAC.jpg)

Do we all have so little in common with them we have to absolutely shun professional dress every day of the danged week?

Nowadays a bunch of half baked adolescents in hoodies would be moving fast and breaking tubes all over the linoleum, is it a wonder there's no diversity left when all one is allowed to wear is Jeans and printed T's in order to 'fit in'? T-shirts have no place in the professional world, they're the opposite of professional

The way I see it, there's a confirmation bias in place here which states 'software developers are a casual lot, to be become one I gotta be casual'

Of all people software developers should be aware of the central limit theorem as applies to these sorts of heuristics and end the games already, before we're walking around in togas and flip-flops looking look ancient romans at the agora

<comment><USER7> To me dressing up is suits as compared to business casual. I hate suits.

<comment><USER3> Anyway, I view dressing up more as to the `impeccableness` of the outfit and various outfits can only achieve a certain level before they plateau --

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Don't call your direct reports underlings for a start.

How do you have little in common with them? You've just spent many, many years performing their role. The key to success in this role, as is the case is most is to display empathy for those around you. Once you are able to do this, the correct choices with regards to the administrative particulars of the role will be easy to see.

Read How to win friends and influence people.

<comment><AUTHOR> Yes, that's a classic. It didn't help me years ago.

But maybe with age, it'll be easier to practice.

</comment></comment><comment><USER3> You should know, as a technical person, that the 'manager' can be considered an anti-pattern: [https://blog.codinghorror.com/i-shall-call-it- somethingmanag...](https://blog.codinghorror.com/i-shall-call-it- somethingmanager/)

You should also know from your education in technical matters that Conway's principle applies in practice and the software you create will ultimately reflect the communication structures within your organization

You'd better get hip to the the idea that people expect real human relationships at work and not some false corporate signalling disguised as casual engagement

I'm sorry but I don't like your prospects at all and it sounds like you're arrived at your Peter principle moment

<comment><AUTHOR> Not very encouraging, but the coding horror post refers to the name. Not the underlying need for the code.

One of my jobs is to mentor, which is something I liked doing in my prior job (different company).

I also understand the business reasonably well so hopefully there's something I can offer my people.

<comment><USER3> "Abandon hope all ye who enter here' is my best advice to you fellow, but that you actually care is a promising sign. Most managers I've had the displeasure to work with have gamed the heuristics until they've lost all meaning as if they'd never even stumbled upon Goodhart's law

</comment></comment></comment><comment><USER3> I'll explain something as a technical person to another technical person, assuming you have some level of civility and you weren't born in a cave and raised by an algorithm

Human beings communicate in many ways outside of words, so you're in luck, you don't have to have good verbal skills, you have to have better non-verbal skills

If I were in your position I'd rise to the challenge and understand that although becoming a manager is not a promotion in many senses of the word, there is an additional level of responsibility, and some people will consider you to be in a position of 'leadership' or even a 'boss' whether you like to admit it or not

As such, it is helpful and humble to apply a semaphore, a visible, definite cue that you accept this duty and wish to make the most of the opportunity, and that you're aware that people's careers are now interdependent with yours even more than before

One traditional cue that has been lost to the sands of time is the humble necktie -- it has been worn by such giants of computing and computer science such as Alan Turing, Vint Cerf, and Steve Jobs, Hewlett and Packard..

The reason I call it humble is because it is, contrary to popular opinion, wearing a necktie is not haughty or entitled, on the contrary it can also be humbling and genuine if done with a pure heart for the right reasons (of which I assure you there are plenty --)

It's a way to signal in a definite, visible, nonverbal way that you take your role seriously and are willing to put in that extra effort and expect more of yourself than your 'charges' 'underlings' 'reports' 'resources', 'assignments'.. call them what they are: 'people'

You can consider my words of advice to you and I'm sure you'll go with the hoi polloi and make a million excuses as to why it's inappropriate to wear a tie, as a manager, as someone who openly admits your own deficiencies

I say it's better to rise to the occasion

You'd think technical people would've figured these things out by now but I guess in some cases it's one thing to read about things in books and another to understand context still matters in real life

<comment><AUTHOR> Thanks.

It definitely helps to have some pointers. I can't wear a tie, but there are analogues that accomplish the same.

I took this responsibility on (new company) because I really want to take on the additional responsibility.

I know I have a steep learning curve—complicated by learning a somewhat different tech stack—but trial by fire is the only way to see if I can rise up to the challenge.

<comment><USER3> Yes, of course you can't

<comment><USER3> Let me guess at the analogues:

\- dusty old blazer with jeans \- socks that match your watch strap \- aloof haircut \- sweater vest with dress shirt \- T shirt with tuxedo printed on it \- pocket square in dusty old sports jacket \- button down dress shirt with crewneck t-shirt underneath \- canvas sandals \- tonsure \- facial tattoo

anything except an actual in fact necktie is equivocating in my view but ymmv as the young people say

</comment></comment></comment></comment><comment><USER9> As someone who is similar to your description, my honest advice is to set a date in the future where you evaluate whether you actually like this role. Think about what your plan is if you don't like it (can you step down or will you have to move companies?). Don't get trapped in it for years because you don't want to give up... if you're not that interested in people and talking, this role will probably make you miserable.

</comment><comment><USER10> I had a stint as a manager in my company at which i miserably failed. Team started leveraging technologies I didn't understand and some developer suddenly develop consistent passive aggressive attitude toward me which i had to deal with. Upper management eventually scrapped the project and critisized choice of technologies to build the project.

I survived.

Then my manager gave me a budget to hire outside consultants to do project.

I greatly succeeded in that because i didn't have to play politically correct diplomacy and follow infinite "proper" BS processes, standups, babysitting team, sprints, do agile scrum crap, etc...

Basicaly i found consultants, negotiated rate to fit available budget and told them to do shit or else.

They came back with shit done.

I reported to my boss that shit is done and ready for more.

Rinsed and repeat.

Skunkworks does wonders.

</comment><comment><USER11> Hi,

I think you should start by making sure you set clear directions, and everybody understands. Then, just also be open to listening when people have something to say.

A surprisingly low part of your time will be spent as a 'policeman'. Most people do not try to cheat or be lazy, they just want to understand and be listened to.

As a manager, you are not the dictator of a small country. You are a sailing boat captain who is looking at the waves, and asking his team for the state of the boat.

</comment><comment><USER12> Read: The Making of a Manager by Julie Zhou (VP of product design at FB)

It clearly explains what a manager is and what he is responsible for and how to be a good manager. It also reads easily as it's a well-written book.

She defines the main job responsibility of a manager as follows: to get better outcomes from a group of people working together.

</comment><comment><USER13> Ask your manager / HR for support and training on how to manage.

Read up on 1:1s and ways to manage people performance I.e make sure they are working in things they are engaged with.

</comment><comment><USER14> Well firstly, congratulations! This is a fun and interesting opportunity to grow as a human being. You will make mistakes and learn a ton. Your most important job is to be an enabler/force multiplier supporting the success of the team.

1) Make sure the team fully understand the goal and are directing their efforts at the simplest possible way to achieve the objective. Engineers are famous for spending time on bikeshed arguments that don't matter and making heroic efforts to do interesting wrong things rather than boring things which lead to success.

2) Related to the above, but try to ensure that people are pointed at tasks which enable them to grow while still leading to team success overall. This is an incredibly interesting optimisation problem that will occupy your mind and hone your judgement.

3) Act with absolute integrity. Don't succumb to the temptation to weasel out of tough situations. If you've made a mistake, own up to it. If something is hard, say it's hard, but don't use that as an excuse to not take the important decisions you need to take. You got the title now you need to do the job.

4) Your poor verbal skills are going to be present some challenges but here's some specific tips \- always start with a verbal conversation whenever you can (even if doing so makes your skin crawl) and immediately follow up by email setting out specifics and allowing them to comment. This prevents all kinds of misunderstandings and ensures you are in complete sync. The harder the conversation, the more important you do it face to face first \- Learn some patterns which help to ensure people don't misunderstand key conversations. \- Start with the important part and state it as plainly as possible. \- Don't attribute intentions, but talk about impact. Say "When you do x, the effect on the team is y and that's bad because z", not "you're always x, I think that's because a b c". \- Be as specific as possible about what your expectations are and what people need to do to fix things. eg "I need to see x by Friday and if that doesn't happen, the consequences will be y". \- If you're giving someone a verbal warning or other feedback that could lead to changes to comp, affect future promotion or lead to dismissal _make sure the person can not possibly be in any doubt as to the gravity of the situation_ even if it seems heavy- handed. I have started conversations with "thanks for coming. We need to talk about something that will affect your future at Yoyodyne Inc." and follow up with an email ccing HR.

5)Following on from that, don't surprise people. They should always know whether they are doing well, poorly, what they need to do more, less of, what your expectations are etc. Don't assume they know. I always assume people can read my mind and they really cant.

6)Think strategically about your team and how they can be even better than they are: more/less/different people, more/different support and interaction with other teams, fewer meetings wasting time/more investment in getting in sync preventing time wasted doing the wrong things.

7)Think strategically about your people: What they like/hate doing, what they are good/poor at, where their blindspots are, what the right next step should be for them. Getting good at this will make you into a superhuman zen master of a manager.

8)Read "Managing Humans". It's fun and you'll find it helpful, and I consider Rands (Michael Lopp) to be a friend so you'll be giving him a small royalty.

9)Get really good at interviewing and learn from your hiring mistakes. You're looking for people who add to your team which means not everyone is going to have the same strengths and weaknesses. Try to think about where the gaps are and what the missing jigsaw pieces look like. Recruiters will try to influence you to hire someone who looks exactly like the last person they placed with you. That leads over time to a team who all do and think exactly the same.

The fact that you understand the job of a developer is great. Try to avoid the easy temptation to play up "us vs them" ("team" vs "management" or "product" vs "sales" or whatever) and instead help your team to see how their work fits into the broader mission and how the work of non-technical colleagues (eg salespeople) is important too.

Finally: Having stuff in common with your team is completely unnecessary and often unhelpful, leading to groupthink and bro-management nonsense in the worst case. As you grow your team it should become less and less of a uniculture over time anyway. I make it a rule to seldom if ever socialise with my team- their downtime/drinks/whatever can be spent moaning about me and blowing off steam if they want. I'm not trying to be people's friend- this can be very uncomfortable and as the power dynamic widens can lead to lots of very difficult situations that are best avoided entirely.

<comment><USER6> > leading to groupthink and bro-management nonsense in the worst case I'm not > quite sure how to interpret this, could you give examples ?</comment></comment>


Mark Zuckerberg should try living in the real world - <AUTHOR> https://www.theguardian.com/commentisfree/2017/may/07/mark-zuckerberg-should-try-living-in-real-world-facebook <comment><USER2> I think Mark has a hidden agenda, and it will be sometime before we all figure it out. As for my personal opinion, I do not trust him, and I am deeply suspicious of everything he says and does.

<comment><USER3> Doesn't everyone have their own hidden agenda? It's funny how most of the time people assume these things are nefarious, when each and every one of us see something positive coming out of our own agendas being achieved.

I too read his lines and watch his moves closely, because he has the potential to affect things substantially towards things that go against my own agenda, not because of some universal distrust of people in high places. A little distrust is healthy, but to do so unconditionally risks forcing people like Mark or anyone for that matter becoming the monster you fear they can be.

<comment><USER4> The difference is the public figure of Zuck we see, enthusiastically posting selfies of eating chili dogs in red states and attending black churches is pretty at odds with the character we know from other stuff like his Harvard chatlogs. Not to mention he has done a bunch of things which coincidentally make him more relatable including spontaneously renouncing his athiesm without any clear reason

Either he has changed in massive massive ways to the point he genuinely has love for middle America and can relate to them or (more likely) there is a big dissonance between the persona he is putting on and the real Zuck

</comment></comment></comment><comment><USER5> Zuck: Yeah so if you ever need info about anyone at Harvard

Zuck: Just ask

Zuck: I have over 4,000 emails, pictures, addresses, SNS

[Redacted Friend's Name]: What? How'd you manage that one?

Zuck: People just submitted it.

Zuck: I don't know why.

Zuck: They "trust me"

Zuck: Dumb fucks

Source:[https://en.wikiquote.org/wiki/Mark_Zuckerberg](https://en.wikiquote.org/wiki/Mark_Zuckerberg)

</comment><comment><USER6> I don't really understand the point of this article. The only conclusion this draws is that Mark Zuckerberg (and Eric Schmidt, apparently) are naive. Does this matter? Does a billionaire's understanding of the world really affect anyone at all?

This feels mostly like a personal attack. The author asserts that Zuckerberg doesn't know what a community is, but doesn't explain this further. Nor does he present any real reasoning beyond "my interpretation of this message is that he doesn't know what a community is." Is the point that we should abandon technology? That technology can't augment human interaction or provide a platform for discourse? I can't see any other proposition by the author. The cheap shot at Schmidt at the end implies, to me, that we shouldn't have a networked world where communication is universal and free. The author implies that we _do_ live in "a comprehensively networked world," and that Schmidt's hypothesis has fallen flat. Does anyone actually believe that communication is a solved problem? Hell, we can't even agree on whether OSS projects should use chat rooms or not.

> There is also, I am sorry to say, a less charitable explanation. It is that > he has concluded that what is wrong with the world – all the fanaticism, > cruelty, warfare, myopia and xenophobia – is because some parts of the world > are not yet on Facebook. If only they were all part of that mythical "global > community" then everything would be OK.

I think that's a very reductive way of reading Zuckerberg's comments. Certainly, he is writing from a very privileged position atop his piles of cash. But I think it's silly to assert that "In times like these, the most important thing we at Facebook can do is develop the social infrastructure to give people the power to build a global community that works for all of us," translates to, "if we're all part of a global community, everything would be OK." Of course everything wouldn't be okay! But it's certainly better than nothing, I'd think.

Let Zuck go on his little The Simple Life experiment and let's worry about, I don't know, net neutrality being destroyed or whatever.

<comment><USER7> How do you square this question: _Does a billionaire 's understanding of the world really affect anyone at all?_

With this later comment?

 _Let Zuck go on his little The Simple Life experiment and let 's worry about, I don't know, net neutrality being destroyed or whatever._

Honestly how? There is a "billionaire" currently tearing apart net neutrality because he doesn't know about (or care about) the internet other than as a way to make money and to bully people.

</comment></comment><comment><USER8> Hilariously along these lines is "When Seinfeld met Zuckerberg".

The world weary Jerry is counterpoint to Mark's fresh faced idealism.

The bit about staff prepping Jerry not to mention Marc's 'broken arm' had me in stitches.

[https://www.youtube.com/watch?v=0mkR3BkuKCI](https://www.youtube.com/watch?v=0mkR3BkuKCI)

Seinfeld : "You and I showing up would ruin everything he likes about that community."..."Your goal was to take the social experience and put it online; my goal was to take the actual human social experience and get away from that."

Zuckerberg : "Get away ?"

Seinfeld : "I would like to eliminate the entire social experience."

</comment><comment><USER9> One need not be a billionaire to have no idea at all what is going on in other peoples lives. To live in a bubble is more the rule than the exception.

Although I suggest everyone delete facebook, let's be fair to Zuckerberg. If the people on facebook were better, facebook would be better. Much of the problems of facebook come from the problems of the people on it. Sadly facebook seems to amplify these problems by optimizing for time on site, making hidden decisions about what you see and what you don't, etc.

A billionaire trying to make the world a better place is usually better than those that could care less. I know that there's surely exceptions (perhaps putin, koch brothers, etc.) It's not the status of billionaire that's important per say, but the quality of their charitable endeavors.

"Connecting" the world is just a tactic, a means to an end, advocating for better ends is superior. Sometimes people take the power you give them and do worse. Technology on its own can be used for good and bad, you must advertise hard for the good if you want the good.

In the end, I think if the world deleted facebook, it would be far better off than any charitable deployment of funds the facebook founder could make.

</comment><comment><USER10> Who actually thinks those statements reflect Zuckerberg's real views?

Its just PR talk.</comment>


My Favorite Product from CES is a Ford - <AUTHOR> http://www.itworld.com/mobile-amp-wireless/92455/my-favorite-product-ces-a-ford <comment><USER2> Here's more information about the "tool tracking" RFID reader from the company that makes them: [http://www.thingmagic.com/applications-overview/toollink- by-...](http://www.thingmagic.com/applications-overview/toollink-by- dewalt/8-applications/40-toollink-by-dewalt%20class=home_splitcol_module)

(I work with ThingMagic's other readers, but haven't gotten the chance to try that one yet)

</comment><comment><USER3> Apart from the tool tracking, there's doesn't appear to be anything it can do that a regular laptop with 3G connection can't do better (and cheaper). And since their liability concerns mean that it's inaccessible while driving, the guy in the passenger seat can't do any work while traveling between sites, while he could with a laptop.

<comment><USER4> A truck's harder to lose or steal than a laptop, and it won't run out of charge in 3 hrs. And as a part of a truck, there are more financing options available.

Also, there's now plenty of space in the passenger. Even for a laptop.

</comment></comment><comment><USER5> At one point I was customizing software for contractors, and they would all inevitably ask about getting computers in their trucks. As long as it is easy to use, it should sell extremely well in that niche.</comment>


Zircon Fair Scheduler - <AUTHOR> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/zircon/docs/fair_scheduler.md <comment><USER2> > A NOTE ABOUT DEADLINES: While fair scheduling is appropriate for the vast > majority of workloads, there are some tasks that require very specific > timing and/or do not adapt well to overload conditions. For example, these > workloads include low-latency audio / graphics, high-frequency sensors, and > high-rate / low-latency networking. These specialized tasks are better > served with a deadline scheduler, which is planned for later in the Zircon > scheduler development cycle.

Those seem like important workloads. Does this imply that the deadline scheduler runs concurrently with the fair scheduler? Otherwise, what's the point of developing an ideal scheduler for common workloads if it cannot be used for critical workloads. Is it common to run two different schedulers in the same system?

<comment><USER3> Different scheduling algorithms and implementations have tradeoffs. Pick one based on your workload. No need to have only one for all applications.

You can approximate the choice down to two dimensions, latency vs. throughput. Pick your poison.

<comment><USER2> For instance, I assume for instance a common workload that would otherwise benefit from the fair scheduler has a fair chance of wanting to do low latency audio. I believe Android has had this issue. As soon as the platform cares about low latency audio it would need to abandon the fair scheduler?

<comment><USER3> Low latency audio would fit for doing live or studio audio production, not necessarily watching videos, listening to music or doing video calls (where there is already network delay an order of magnitude larger than the scheduler would impart). "Low" will have context-dependent meaning.

If you're doing low latency audio or flight controls on an aircraft for example, you would absolutely need to abandon the fair scheduler for one that could guarantee the deadlines you need are met. Sacrificing "performance" that is throughput/efficiency/etc of your processor for timing performance.

Think of the difference between doing statistics on a billion lines of data and flight controls on a missile. VERY different needs for scheduling, why not have a selectable algorithm?

<comment><USER4> > (where there is already network delay an order of magnitude larger than the > scheduler would impart)

Not the right way to think about it; the connection latency is irrelevant. What is relevant is that you need to play audio in sync with the video, and that audio is coming to you approximately simultaneously with the video it's meant to be synced with.

</comment></comment></comment></comment></comment><comment><USER5> There are many references to multiple cpu systems throughout the document. Maybe I missed something, but I didn't know Fuschia was aimed at systems like that. I am no expert, but aren't the vast majority of multiple cpu systems servers or high-rnd workstations? If google can supply their own server os, Linux could lose a lot of support and funding

<comment><USER6> "cpu" is "core". Almost all phone CPUs are multi-core. The low end of phone (and Raspberry Pi 2 V1.2 and newer) CPUs is quad core ARM Cortex A53, which is a small slow in-order design, similar to the original Intel Pentium from 1995. Older low end phones used the 32bit quad core ARM Cortex-A7. single core ARM11 phones are extinct.

They don't mean multi-socket systems, and I don't see mention of NUMA, which is the interesting case for servers where RAM is connected to some memory controller in a socket and to reach it from a CPU in a different socket you need to do extra hops, so some memory addresses are more distance than others and schedulers should take that into account to achieve good performance.

<comment><USER7> And phone CPUs can be more complex than most desktops, afaik big.LITTLE is fairly common (multi core, with different performance / power tradeoffs between the cores).

[https://lwn.net/Articles/501501/](https://lwn.net/Articles/501501/) has some pointers.

<comment><USER8> big.LITTLE is fascinating, and I'm somewhat curious to see if Apple tries to do something along those lines as it supposedly pushes towards ARM chips in their machines.

Google have added some interesting stuff to Android to help it learn over time if tasks should be allocated to the bigger cores or the lower powered smaller ones, based on all sorts of metrics, and I believe this stuff is making its way upstream. There's certainly some really interesting potential around that.

<comment><USER6> Apple chips are big.LITTLE too, at least since the 2016 A10 in the iPhone7.

[https://en.wikichip.org/wiki/apple/ax/a12](https://en.wikichip.org/wiki/apple/ax/a12)

[https://en.wikichip.org/wiki/apple/ax/a10](https://en.wikichip.org/wiki/apple/ax/a10)

[https://www.anandtech.com/show/13392/the-iphone-xs-xs-max- re...](https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-review- unveiling-the-silicon-secrets/2)

<comment><USER8> Sure, I should be clear I was thinking about OSX and laptops/desktops, rather than mobile devices.

</comment></comment></comment></comment></comment></comment><comment><USER9> [https://cchalpha.blogspot.com/2019/03/bmq-scheduler-call- out...](https://cchalpha.blogspot.com/2019/03/bmq-scheduler-call-out-for- testing.html?m=1)

Someone made a scheduler on linux based on some of the ideas here. Its included in the postfactum (linux-pf) patch set i believe, which might have packages for your distro.

<comment><USER10> No, that's based on the deprecated multi-level round-robin scheduler, which we find tremendously amusing. :)

<comment><USER9> Oh gosh well thank you for pointing that out

</comment></comment></comment><comment><USER11> This post has sky-rocketed to the top! I'm genuinely curious: can someone explain what's cool/interesting/important about this (maybe EL5)? Thanks!

<comment><USER12> Well, Google intends for this new OS to replace Android. They'll need to convince the public that this new OS is somehow better than Android, which everyone has come to know and love. It seems that they believe the best way to do that is a grassroots approach beginning with tech discussion hubs like HN and Reddit.

Of course, they could have just meme'd hard about the fact that they're moving away from evil Oracle technology and we'd have already all been on board.

<comment><USER13> > Android, which everyone has come to know and love.

Haha, honestly now. If my Android didn't cost $700 I would long since have smashed it to bits. It's scheduler is totally garbage, to the point where Google's own media apps like YouTube and Music drop samples while the screen is redrawing. Who "loves" Android? To me it is the Win98 of mobile operating systems.

<comment><USER14> When you only have two real choices, each with their own significant set of distinct problems, I think the term "love" can be substituted for "hate the least". Android, which everyone has come to know and _hate the least_. Well, not _everyone_ , but my point is the same regardless.

<comment><USER15> I left Symbian for Android 2.1, after several Android devices, became part of the 10% of WP share in Europe, now still using one of them as secondary device.</comment></comment></comment></comment></comment>


Nginx direct file upload without passing them through back end - <AUTHOR> https://coderwall.com/p/swgfvw/nginx-direct-file-upload-without-passing-them-through-backend

<comment><USER2> It blows my mind! Can you upload a file just through Nginx with no plugins???

<comment><USER3> It seems so, have you tried that?</comment></comment>


The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007) - <AUTHOR> http://www.schneier.com/blog/archives/2007/11/the_strange_sto.html <comment><USER2> There was significant discussion and concern in the academic community[1][2][3] during the early 90's in response to NIST's draft standard for digital signatures (DSS). The academic community was concerned that field parameters could have been carefully selected such that they contained hidden properties (weak primes, etc). This is why "nothing up my sleeve numbers"[4] must be used in cryptography. The same issue impacts the selection of prime field parameters for use in ECDSA/ECDH (TLS, S/MIME, etc). Worth noting is that NIST P-256 and NIST P-384 elliptic curves were selected from "verifiable random numbers" generated in accordance with ANSI X9.62. This standard is not freely available so I am not sure which PRNG was used to generate the curve parameters and why the PRNG seed is considered a "nothing up my sleeve number".

[1] Daniel M Gordon. Designing and detecting trapdoors for discrete log cryptosystems (1993). [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.3...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.3546)

[2] Yvo Desmedt, Peter Landrock, Arjen K. Lenstra, Kevin S. McCurley, Andrew M. Odlyzko, Rainer A. Rueppel, Miles E. Smid: The Eurocrypt '92 Controversial Issue: Trapdoor Primes and Moduli (Panel). 194-199. [http://link.springer.com/content/pdf/10.1007%2F3-540-47555-9...](http://link.springer.com/content/pdf/10.1007%2F3-540-47555-9_17.pdf)

[3] Miles E. Smid, Dennis K. Branstad. Response to Comments on the NIST Proposed Digital Signature Standard. [http://link.springer.com/content/pdf/10.1007%2F3-540-48071-4...](http://link.springer.com/content/pdf/10.1007%2F3-540-48071-4_6.pdf)

[4] [https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

</comment><comment><USER3> This is one of my favorite examples showing the need for 'Nothing up my sleeve' numbers. [https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

I believe NIST learned their lesson, and it was applied in the design of SHA-3: [http://crypto.stackexchange.com/questions/6444/why-are- the-c...](http://crypto.stackexchange.com/questions/6444/why-are-the- constants-so-simple-in-keccak/6449#6449)

<comment><USER4> Nothing up my sleeve numbers are very hard to create for asymmetric crypto. Asymmetric crypto is filled with mathematical relationships and it's almost impossible to prove that a certain set of parameters have no "hidden" properties.

<comment><USER5> In this case, it could have been done. Dual_EC_DRBG hinges on the discrete log of two points being unknown; P and Q could have been both generated verifiably at random.

<comment><USER3> Perhaps something like "The smallest prime number not less than the base-2 expansion of pi*2^(n - 2)".

</comment></comment></comment></comment><comment><USER6> I'm no mathematician, so this is probably a dumb question that will serve as a great example for why random programmers shouldn't write cryptosystems. However, here goes anyway.

Could a cryptographer please explain why it's not feasible to use multiple such PRNG algorithms in both series and parallel, perhaps even shuffling their order dynamically, at, err, random?

Surely most attacks on PRNGs are based upon the assumption that their state can be modelled to expose weaknesses. By viewing an entire, shifting, 'topology' of PRNGs as a single polymorphic source for pseudorandom data, surely this class of attack becomes much more difficult and we avoid either placing absolute trust in a single PRNG author, input entropy source, or a single mathematical approach.

I suppose this has already been done to the extent reasonable and that tradeoffs versus performance and available entropy input rates are probably responsible. But I'd still be keen to hear someone thrash this out in understandable prose.

<comment><USER7> Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. - John von Neumann

The very definition of a pseudo-random number generator is that it's deterministic, i.e. an algorithm. If you know in what the state of the algorithm is, you know what the next number will be. Attempting to add some ad hoc behavior on top of crypto has two common issues:

First, adding of deterministic behavior to deterministic behavior does not in any way spontaneously add randomness (see quote). In fact, it can expose additional state on which an attack can be focused. For instance, perhaps when I learn that the system you are using is an interleaved set of numbers, I can use the starting set from each to guess the seed on which all PRNGs started. Second, crypto PRNGs that are well vetted are already at the top of the game for being apparently random in output. There shouldn't be a need to do anything like what you're suggesting, ever, with a valid PRNG. What Schneier is pointing out is that good crypt doesn't have a whiff of smell. Dual_EC_DRBG does. And, badly. Just use the others, instead.

Importantly, learn the first rule of crypto: Unless you're well versed in crypto, presume you will do a very bad job of trying to implement something yourself. Understand for what the crypto library is meant to be used, understand how to use it properly, and don't try to do something on your own. It is hard for even the experts to do it well. Some simple "why don't I just.." is practically guaranteed to have a flaw. Adding your own deterministic behavior is a sin.

<comment><USER8> How about using a stream of true random numbers and putting it through a set of deterministic functions that "multiply" the quantity of random numbers.

e.g. make thousands upon thousands of functions, where the function names are sequential. Use the data itself to determine which of the functions will be called. Allow functions to call each other based on the random number values it calculates from its true random input. To figure out how much random data to produce, simply add an extra bit that is passed along to all the functions that indicates depth (how much show the true random data be processed before returning it to the program that needs a random number). This approach would produce a lot more random data that could only be determined if you knew the original true random data input and the amount of entropy that was required at the time since you'd need to know the depth used to know when to exit the functions.

<comment><USER6> Err, I think you'll find what you described is roughly the definition of a PRNG (though usually more mathematical in its verbiage). The problem is, we don't trust any particular PRNG. My question was, why not combine them so as to remove the need for absolute trust in any given PRNG.

<comment><USER7> When part of your system becomes flawed (part or whole), the whole can be attacked. Thus, adding more deterministic behavior doesn't add more randomness (i.e. more safety). Generally, when crypto falls down, it falls somewhat gracefully (i.e. there are a class of known attacks under certain particular situations.) As Crypto is an on-going war between those creating the security and those trying to break it, expect to have to change your crypto over time.

<comment><USER6> > When part of your system becomes flawed (part or whole), the whole can be > attacked.

This is the most concise and meaningful argument against the proposed approach thus far. Hats off.

</comment></comment></comment></comment></comment></comment><comment><USER9> The most important thing to know about Dual_EC_DRBG is that practically nobody uses it (I'd say "nobody ever uses it", but who knows, maybe something did?). It's a CSPRNG that involves bignum elliptic curve point multiplication. It's not something that's maybe slower than an alternative; it's something noticeably, horrendously slower than its alternatives. Even systems that use number theoretic crypto use it sparingly; nobody uses it to generate random numbers.

</comment><comment><USER10> Intercepting signals is only half of the NSA mandate, the other half is securing national communications against interception by foreign governments and organizations.

It is possible that the NSA want other nations to have the impression that NSA audited communications protocols _are_ insecure or _may_ contain backdoors. They have never expressly come out to deny any of these accusations.

The involvement of the NSA thus doesn't imply that they wish to weaken standards. Perhaps they want people like Schneier to question the security of these protocols and create a false aura of potential vulnerability so that their opponents don't make use of them.

</comment><comment><USER11> _NSAKEY discovered two years before patriot act is passed? coincidence? i think not!!1

said another way, what relates the two events in the editorialized title? Just an end of the innocence type vibe? Trusting the sigint guys to design your crypto has always been a well acknowledged double edged sword.

<comment><USER12> The Patriot Act was passed in late 2001. It was renewed in 2009.

<comment><USER11> [http://en.wikipedia.org/wiki/NSAKEY](http://en.wikipedia.org/wiki/NSAKEY)

</comment></comment></comment><comment><USER13> So either the NSA wanted a backdoor, in which case we learn that even the NSA can't build a backdoor that academic cryptographers can't detect.

Or, much more likely I think, it was just a project that some NSA employees had sitting around and they wanted to get something out of it. In that case we learn that the NSA isn't so far ahead of academic cryptographers that their designs will always be better.

Either way I don't find this as scary a story as Schneier does.

<comment><USER14> They might be able to build backdoors that academic cryptographers can't detect, but this backdoor was special - even after the academics figured it out, the NSA are still the only ones that could use it because it requires a secret key whose public counterpart was baked into the Dual_EC_DRBG specification. Backdoors with that special property are going to be much harder to create.

</comment></comment><comment><USER8> Out of curiosity, why can't we just use a series of sensors on the computer to generate random numbers? Between mouse movements, touch inputs, video camera input, microphone movements, the behavior of applications in your system and how they use resources like RAM, CPU, hard-disk, listening to all the wifi + bluetooth signals around you and munging them, etc. I would imagine that there is enough entropy coming in through input and being generated by whatever the computer is doing to be able to have lots of unpredictable random numbers.

I don't know much at all about cryptography, but why aren't all the natural sources of entropy an adequate source of random numbers?

<comment><USER15> This sort of thing is used, e.g. [0]. It collects entropy at a limited rate, though, so for demanding applications (SSL servers, say) you want dedicated hardware: [1], [2].

[0]: [https://en.wikipedia.org/wiki/Hardware_random_number_generat...](https://en.wikipedia.org/wiki/Hardware_random_number_generator#Using_observed_events)

[1]: [https://en.wikipedia.org/wiki/RdRand](https://en.wikipedia.org/wiki/RdRand)

[2]: [http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

<comment><USER8> How do those Entropy Keys work? What sort of environmental random data does it rely on for creating random bits?

<comment><USER16> Thermal noise of various kinds, usually.

(Edit: that is, the noise introduced in a circuit by the fact that it's not at absolute zero, e.g. Johnson noise. Not just gathering entropy from a temperature sensor reading or something like that.)

</comment></comment></comment></comment><comment><USER17> OK I have a probably naive/nonsensical cryptography question. It seems that one good way of transmitting a secret would be to do so with everyone thinking it is encrypted one way (or possibly believing it has not been encrypted) when the truth is it has been encrypted some other way. I.e. it would be a difficult problem to know when the message has truly been decrypted. So basically there would be multiple decrypted versions which are plausible as the true decrypted message. Is there any parallel to that sort of thing in modern mathematical cryptography?

<comment><USER18> Encrypted traffic should be indistinguishable from random numbers. A quick test is trying to compress it, as true randomness has no patterns and hence nothing to compress.

In general you can tell exactly what compression was used because protocols start out in the clear and include some sort of negotiation. [https://en.wikipedia.org/wiki/Transport_Layer_Security#Proto...](https://en.wikipedia.org/wiki/Transport_Layer_Security#Protocol_details)

However both ends can separately agree that if they select one cipher suite, they will be secretly using a different one.

</comment></comment><comment><USER19> I'll always question any cryptographic standard adopted or advised by government.

I have an hard time even trusting AES.

[http://crypto.stackexchange.com/questions/579/how-can-we- rea...](http://crypto.stackexchange.com/questions/579/how-can-we-reason-about- the-cryptographic-capabilities-of-code-breaking-agencies)

Honestly I think those issues (like cryptanalysis) are totally out of reach by the public to comprehend, it's hard to really know how to make strong assumptions.

</comment><comment><USER20> Can anyone confirm that 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is not the the backdoor sequence?

Seriously though, have we the people figured out this sequence yet? If there is a base sequence, and a relationship to a second sequence, I feel like this can't be too difficult to figure out mathematically, or through brute force means. Can someone who actually knows what they're talking about properly rebut me?

</comment><comment><USER21> The ANU Quantum Random Number generator [http://qrng.anu.edu.au/](http://qrng.anu.edu.au/) can be used as a source of additional randomness for your server's pseudo RNG, or directly. They monitor quantum fluctuation of a vacuum to generate the random numbers at a high rate.

<comment><USER22> While it's an interesting project (I had fun playing with it) you really shouldn't be relying on remote sources of entropy for security purposes.

Generally the entropy needs to be secret to be effective so sourcing remote entropy reduces your security to that of the transport security (if any). It's hard to imagine a situation where you have a secure transport mechanism but do not have enough entropy since most encryption schemes that you might use to secure the transmission require secure random number generation.

Disclaimer: I am not a cryptographer, cryptology frightens and confuses me.

<comment><USER23> > _most encryption schemes that you might use to secure the transmission > require secure random number generation._

If I understand this correctly, most channel securing schemes require RNG for key exchange (e.g "no prior knowledge" DH key exchange) or pair generation (RSA), then you can move on to a symmetric cipher (whose key is derived from the resulting DH shared secret, or exchanged encrypted via RSA), which requires no RNG (until you want to change the key for PFS).

So one can assume scenario where only a quantum of entropy is needed to establish a secure connection, then refuel the entropy bucket with random data transmitted over the now secure yet "non entropy consuming" channel.

</comment></comment></comment><comment><USER24> Much of the discussion in previous comments has to do with the generation of true random numbers. Does this need to happen on a client or on a server? If it's on a client, then isn't a cell phone an ideal source of randomness, due to all of the sensors on board?

</comment><comment><USER25> This random generator is found in some versions of Windows:

[http://www.schneier.com/blog/archives/2007/12/dual_ec_drbg_a...](http://www.schneier.com/blog/archives/2007/12/dual_ec_drbg_ad.html)

I don't know if it's in Windows 8 or not.

<comment> w-m The link to msdn in your post is still working.

 _> The dual elliptic curve random-number generator algorithm. Standard: SP800-90

> Windows 8: Beginning with Windows 8, the EC RNG algorithm supports FIPS > 186-3. Keys less than or equal to 1024 bits adhere to FIPS 186-2 and keys > greater than 1024 to FIPS 186-3._

</comment></comment><comment><USER26> Great reading. Have you any idea how things evolved after that with those 4 proposed methods?

</comment><comment><USER27> No mention on authors from nsa or reviewers from nist...</comment>


Diagram as Code - <AUTHOR> https://open.evry.blog/2020/01/05/diagram-as-code.html <comment><USER2> Isn't this backwards? I read "X as code" as "you can execute X (and observe some result)". But you can't execute these diagrams. What you can do is to "execute" _code_ and observe visual _diagrams_ as a result. So I think this should be "code as diagrams". Or simply "some diagram description languages".

<comment><AUTHOR> I agree that it is not entirely self explaining. I ended going with Diagram as Code based on the Infrastructure as Code [1] principle which is the same concept; you write code to generate your infrastructure.

[1] [https://en.wikipedia.org/wiki/Infrastructure_as_code](https://en.wikipedia.org/wiki/Infrastructure_as_code)</comment></comment>


DVD Jon Hacks iPhone: No Activation Required - <AUTHOR> http://blog.wired.com/gadgets/2007/07/dvd-jon-hacks-i.html <comment><USER2> I guess if someone got skype on it and the price fell, this might make sense to some people. Still nice to know you can develop on it (kinda of) without needing to get a contract.

</comment><comment><USER3> I remember the dude at the Apple store convincing me that this wasn't hackable. Still, the SIM card hack is where it'll be really valuable.</comment>


Blackout Bug: Boeing 737 cockpit screens go blank if lands on specific runways - <AUTHOR> https://www.theregister.co.uk/2020/01/08/boeing_737_ng_cockpit_screen_blank_bug/ <comment><USER3> Is someone dividing by zero somewhere?

"All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected."

cos(270°) = 0

<comment><USER4> angle = arctan(dy/dx) where dx=0.

I guarantee this is the mistake they made.

In some languages you can use Math.atan2(dy,dx) to easily avoid this.

<comment><USER5> >> I guarantee this is the mistake they made.

No. East-West runways are very common.

If I may speculate... the blanking of 5 displays is probably not a bug. Maybe it's a (misguided) feature meant to keep people from landing at certain restricted airports and they coded the logic incorrectly?

<comment><USER6> My guess is that it's not just any old "Runway 27", but it's runways where the coordinates of the endpoints of the runways have precisely the same latitude down to whatever precision is in the database. It's probably quite rare to have a runway that's this perfectly east-west.

<comment><USER6> Looking at the coordinates of the runways in the FAA database, they are all perfectly east/west within about 2 feet of deviation N/S. This would round to zero if the calculations were done as lat/long as single precision numbers.

<comment><USER7> Are there other runways that are so dead-on?

</comment></comment></comment></comment></comment></comment><comment><USER8> That reminds me of the C-130 avionics failure when flying at negative altitude.

[https://www.popularmechanics.com/military/aviation/a26598/c-...](https://www.popularmechanics.com/military/aviation/a26598/c-130-sea- level-dead-sea/)

<comment><USER9> > The lowest airfield in North America, for the record, is Furnace Creek > Airport, Death Valley at minus 210 feet below sea level.

So, then I guess it's 210 ft _above_ sea level? (SCNR)

<comment><USER10> Been there. Almost nobody uses it. But from what I read in the newspapers, the few times it does get used, it seems to have more than its share of crashes.

</comment></comment></comment><comment><USER11> While it is easy to blame Boeing these days, I suspect we have survivorship bias here. Dig into Airbus software and all sorts of similar scary bugs will pop up. For instance, one may remember inconsistencies between airspeed measurements that resulted in the loss of AF 447 on June 1, 2009. Overall, it's great that at least some airliner's closed software finally gets more eyes looking at it.

<comment><USER12> I seem to recall Airbus having different engineering teams across EU using different versions of the CAD tool and then when they went to build the plane the wires were too short because one version of the CAD tool accounted for the radius of wires turning a corner while the other didn't.

[https://www.nytimes.com/2006/12/11/business/worldbusiness/11...](https://www.nytimes.com/2006/12/11/business/worldbusiness/11iht- airbus.3860198.html)

<comment><USER13> Had only the version that didn't account for turning a corner used, would things have worked out ? I don't follow

<comment><USER14> The measurements would have been the same in both cases: therefore it would have been a) designed correctly and implemented correctly, or b) designed incorrectly, but caught in the design phase, looping back into a). This way, you get c) designed correctly, but implemented incorrectly or d) designed incorrectly and the design implemented as specified, in both cases leading to an unworkable implementation.

</comment></comment></comment></comment><comment> awinter-py The first F-22 they delivered to japan had serious trouble when it crossed the international date line

Sounds like nobody was hurt & they didn't lose any planes, but there was some period of time where the onboard computers were not good

[https://www.defenseindustrydaily.com/f22-squadron-shot- down-...](https://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the- international-date-line-03087/)

Yet another reason to exercise low-level math functions with a wide range of inputs -- maybe not on every run, but at least in pre-release integration tests

There are only 4 billion floats

[https://randomascii.wordpress.com/2014/01/27/theres-only- fou...](https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion- floatsso-test-them-all/)

<comment><USER15> F-22 weren't exported, it was probably just at Okinawa

</comment></comment><comment><USER16> I'd like to learn how Boeing's software delivery practice has changed. Sounds like there may be some lessons learned we can all learn from.

<comment><USER17> I would hazard a guess: their process became "agile."

<comment><USER18> You should clarify what you mean by "agile". It means so many different things in different contexts.

A large part of this is likely the cost-driven pressure that lost the CEO his job. Agile can be abused certainly.

<comment><USER19> > Agile can be abused certainly.

... where "abused" appears to cover most good-faith efforts to implement Agile in practice. When it works it's Agile—despite the fact that these implementations have very little in common. When it fails the mantra is always "Agile wasn't implemented properly". Agile has every characteristic of a utopian ideal that cannot survive contact with reality, or at least the realities of safety-critical software.

<comment><USER20> Big-A Agile is often described in Utopian terms. Which is unfortunate, but little-a agile is understood to be a thing you grow towards with constant improvements and changes to both the process and the system being developed based on frequent, ideally continuous, feedback. Boeing, in my experience, didn't want to change their processes, they wanted to run the same processes faster. Which is decidedly _not_ agile (and I hate Scrum for this).

The form that I've seen them adopt on programs I've been involved with is heavily inspired by Scrum. So they have sprints, they accept product releases from the subs and will, ostensibly, test it (running the integration lab they have the more complete test infrastructure, in theory). But, in practice, the released code isn't tested for months, but development continues, monthly or bi-weekly releases continue, and no feedback is ever provided to the developers. Finally, 6-12 months later most of the builds are discarded, the most recent one is tested, and it's discovered that, true-to-Waterfall, the wrong thing was built. Patches are quickly developed and applied, tests pass, and something is released to the customers.

Months or years later, the software is found to be defective, the test suite is found to be insufficient (again), and the process repeats.

<comment><USER19> > ... little-a agile is understood to be a thing you grow towards with > constant improvements and changes to both the process and the system being > developed based on frequent, ideally continuous, feedback.

Agreed, and I have no objection to the feedback and continuous improvement aspects of agile development. Or anything in the Agile Manifesto, for that matter. In my experience, however, when projects "go Agile" they tend to cargo-cult simplistic, visible changes like Scrum instead.

> Boeing, in my experience, didn't want to change their processes...

Yes, this is generally the issue. On the other hand, those processes are strongly influenced by industry standards such as DO-178 which codify "tried- and-true" practices established in the early days of software engineering—it isn't just a matter of corporate culture. It's not _mandatory_ to follow these processes, but if you do then certification is basically assured, which is much simpler and more reliable than arguing the case for a brand-new process with no established history in the industry. For the most part these standards treat software as just another "component" to be integrated into the hardware, like an extra-complicated combinatorial circuit, rather than what it is: the design of a iterative, stateful process to be carried out _by_ the hardware during flight. Novel development and certification processes are a huge risk; understandably, no one wants to go first, even when they agree that change is needed.

</comment></comment></comment></comment></comment></comment><comment><USER21> Edit: the airports noted aren't along the same magnetic declination, so maybe not that.

Given that this applies to a few US airports and some S. American ones, maybe it has to do with magnetic declination calculations gone awry.

Maybe only airports along one of these lines gets impacted:

[https://en.m.wikipedia.org/wiki/Magnetic_declination#/media/...](https://en.m.wikipedia.org/wiki/Magnetic_declination#/media/File%3AWorld_Magnetic_Declination_2015.pdf)

And magnetic declination changes all the time. Maybe different systems are using different sources of truth?

Maybe when they did initial testing, they included some airports at the extremes, but when the declinations got updated, they were no longer good test cases?

</comment><comment><USER22> I guess the automated test suite just got larger. Testing all approaches on all runways on all airports worldwide...

<comment><USER23> In the automotive and aerospace world, of course tests in the real world cannot cover all cases (cost, time make it impossible).

Even most (not all, but almost none for meaningful applications) computer program cannot be proved to come to an halt [0], so complete testing is impossible by essence. We can only use more restrictive rules for programming but cannot formally guarantee anything.

As those systems are tied to the physical world, a whole lot of complexity is added by uncontrolled parameters.

Yet we love testing things. So a lot of techniques exist, such as SIL [1] and HIL [2].

So you could imagine using a real dashboard hooked up to a plane simulator. Which would enable testing the device in a wide array of conditions.

[0] [https://en.wikipedia.org/wiki/Halting_problem](https://en.wikipedia.org/wiki/Halting_problem) [1] [https://www.quora.com/What-is-Software-in-the-Loop- SIL](https://www.quora.com/What-is-Software-in-the-Loop-SIL) [2] [https://en.wikipedia.org/wiki/Hardware-in-the- loop_simulatio...](https://en.wikipedia.org/wiki/Hardware-in-the- loop_simulation)

<comment><USER24> > Even most (not all, but almost none for meaningful applications) computer > program cannot be proved to come to an halt

That is not true. If you can demonstrate that every loop or recursion is bounded, then the program must halt as a necessity. Loops of the form for (i = 0; i < N; i++) are trivially bounded, unless you're resetting i in the loop. If you have containers that are not being modified in the loop, the finiteness of your data structures is usually sufficient to form the lemma that the loop will terminate.

Recursive datastructures (such as cyclic graphs) are much more challenging to prove, and most challenging are fixed point algorithms (do { } while (changed);), as will be noted by them frequently being the causes of actual infinite loops in my experience. But if you had mandatory annotations to declare lemmas for termination, it is doable. With that feature, a programming environment that forbade you from writing code that couldn't be proven to terminate is probably sufficiently feasible to allow you to write large, complex applications.

<comment><USER23> My POV here was very cautious, as I didn't exclude programs which can be proved. The problem is that even if control flow is "provable", a lot of algorithms use number computations and is much harder to deal with from a formal POV :

"In cooperation with the University of Iowa and Rockwell Collins, this research focuses on the verification of safety properties on Lustre pro-grams. SAT or SMT, based verification approaches such as k-induction give good results on programs with a mostly discrete state space (boolean, bounded integers). However, when numerical computations are involved (real/float computations) the formalization of the property to be proved often needs to be strengthened using auxiliary lemmas to make it inductive with respect to the system's transition relation. When attempted manually the discovery of such lemmas is time consuming and hinders the efficiency and scalability of formal verification. Automating lemma discovery hence appears crucial to allowing end-users to apply formal verification on industrial cases."

Taken from [0]

The seminars I attended to, from the creators of coq (a formal verification language), didn't disagree with this point of view. Of course, formal verification is not the only thing we can do [0].

In any case, what you propose seem interesting, if the halting problem was the only problem to solve to have a formally proven system.

[0] [http://www.aerospacelab- journal.org/sites/www.aerospacelab-j...](http://www.aerospacelab- journal.org/sites/www.aerospacelab-journal.org/files/AL04-10_1.pdf)

</comment></comment></comment></comment><comment><USER25> Apparently another plane went down in Ukraine according to this article. That seems like a much bigger story. Maybe I happened to miss that one yesterday?

Edit: A Ukrainian airline in Iran.

<comment><AUTHOR> It's a different model it's 737-800. Different plane model while still within the 737 family.

<comment><USER25> When I say "another" I was referring to that previous incident where a passenger plane was shot down in Ukraine and not the Max plane problem. Any passenger plane crashing seems like a significant story. I hope we aren't numb to that already.

<comment><USER26> What makes you think it's being treated as insignificant? It's all over the news.

<comment><USER25> Now that I think about it I'm not sure where I got that impression. You are probably correct.

</comment></comment></comment></comment></comment><comment><USER27> Isn't this something that would be discovered through flight simulation? Does Boeing run their software and hardware through automated testing?

</comment><comment><USER28> That is an awfully specific bug. I can see how it went undetected. But what could trigger this?

<comment><USER29> From reading the article, it seems like it occurs when the runway is precisely running east to west and the airplane is coming in westward. And also the latitude/longitude is somehow involved. You can see one of the airports here. Notice how it is exactly horizontal, i.e parallel of latitude. [https://www.google.com/maps/place/Wiley+Post- Will+Rogers+Mem...](https://www.google.com/maps/place/Wiley+Post- firstname.lastname@example.com,-156.7756877,14.08z/data=!4m5!3m4!1s0x50c327fff620aae7:0x936de8c8fd2d094b!8m2!3d71.2874212!4d-156.7802701)

<comment><USER21> My thought is some combination of that and magnetic deviation.

Runway headings are always magnetic headings, so what the runway says and what GPS calculates (at the lowest levels) are two different things.

So maybe the issue only occurs at airports where you're landing on 27 AND mag deviation is some specific value?

Would explain why it happens at only some US and some S. American airports:

[https://en.m.wikipedia.org/wiki/Magnetic_declination#/media/...](https://en.m.wikipedia.org/wiki/Magnetic_declination#/media/File%3AWorld_Magnetic_Declination_2015.pdf)

<comment><USER30> > Runway headings are always magnetic headings...

This is incorrect, while most runways are aligned with the magnetic heading, that changes when you have a field with multiple parallel runways. Atlanta Hartsfield comes to mind first, with its five parallels in the East-West directions, 8L/26R, 8R/26L, 9L/27R, 9R/27L, 10/28\. One would naively expect these to be not parallel by just reading the name, while in fact they are all in line.

<comment><USER21> Okkkk, good point.

And they're only magnetic until they get updated because the declination changes over time.

Other exceptions: near the poles where the magnetic declinations change rapidly, so they use something else.

</comment></comment></comment></comment></comment><comment><USER31> don't land on those runways!

</comment><comment><USER32> I'm getting happier and happier that my usual airline (Swiss) has a mostly- Airbus fleet.

<comment><USER33> To quote Han Solo, "Don't get cocky, kid"

Boeing and Airbus both source avionics from the same third parties. The 737NG uses Smiths, but everything else in the Boeing fleet (and all newer Airbus airframes that I'm aware of) come from Honeywell. While you can fault Boeing for not finding this, the vast majority of the fault lies with the OEM.

<comment><USER32> Even if this particular problem is not Boeing's fault, but Smiths', the whole 737MAX saga still puts Boeing in a pretty bad light – cutting corners on security, outsourcing their software to dubious vendors, etc.

<comment><USER34> The Daily podcast (NYTimes) did an episode last week called "Boeing's Broken Dreams" where they interviewed a former Boeing safety manager turned whistleblower. Definitely sounds like there was a major cultural shift over the past decade or so.

<comment><USER35> That podcast ep re-airing was based on this story[1].

[1] [https://www.nytimes.com/2019/04/20/business/boeing- dreamline...](https://www.nytimes.com/2019/04/20/business/boeing-dreamliner- production-problems.amp.html)

</comment></comment></comment></comment></comment><comment><USER36> I for one will never ride on a 737 again, even if they manage to get them back off the ground. For every problem that's come to light there are probably two more than haven't been discovered (or disclosed).

<comment><USER37> Fact is: there are around 10,000 737s around, each if them starts and lands multiple times a day, by far mostly without problems. Risk is similar to you slipping while getting out of bed in the morning or being overrun while crossing a street. (Excluding Max versions, which are grounded)

<comment><USER38> Maybe if I have a heart attack or seizure during those activities...

I have 0 past history of slipping. Also, can't avoid walking.

I can avoid flying on something I know could be fucked.

<comment><USER39> Are you saying you have literally never slipped before? I'm quite impressed if so.

<comment><USER38> Straying from point, haha, but only once, in a new set of footwear - <USER2> over a car.

</comment></comment></comment></comment></comment><comment><USER40> Oh, it is going to be fun to see them get re-certified.

Did someone forget to run the fuzzer, maybe?</comment>


Proposal: Darpan – People Directory for companies - <AUTHOR> https://github.com/ankitjaininfo/Darpan

<comment><AUTHOR> Startups/companies (50+ ppl): What problems are you facing in people management?</comment>


Setting up a Payment Gateway - <AUTHOR>

Hello everyone,
For anyone that's an online payments expert:
I am in the process of researching the process of creating a payment gateway. At this moment, we're thinking of developing a gateway in a region that does not have a single online payment gateway, with huge e-commerce potential and with many, many online solutions out there that are too expensive and just a terrible cheap alternative to a payment gateway.
I already know all about IPC compliant and that's not an issue. My question is what would be the best way to reach the dozen or so payment processor platforms? Is it the best way to just reach to an arm acquiring bank in the region, or is there any other ways/companies that assist in doing so?
Thank you! <comment><USER2> You mean setup a service similar to stripe to be all all in one service, or the kind where your clients still need to open a merchant account with a bank and you're just the interface?

<comment><AUTHOR> I'd say closer to Stripe than open a merchant account with a bank. Any thoughts?</comment></comment>