New York Tech Journal
Tech news from the Big Apple

How to Build a Bulletproof #SDK

Posted on June 3rd, 2016


06/02/2016  @Yahoo, 229 West 43rd Street, NY, 10th floor

20160602_183850[1] 20160602_190336[1] 20160602_191143[1]

The speaker from @Flurry emphasized four main themes on the way to making happy developers using your SDK:

  1. Respect users (hardware, not people in this case)
  2. Respect developers (people)
  3. Clarify assumptions (more about developers)
  4. Things you can’t control

Within each theme

  1. Respect users.
    1. Be considerate of battery life. Actions include
      1. Limit network calls
      2. Illuminate the screen only when necessary
    2. Network time is expensive – keep it to a minimum by downloading once and keeping the download in memory
    3. Phone space is limited – when you are done with the data you have downloaded, delete it.
    4. Minimize startup time
      1. Use techniques to keep startup time to below 2 seconds
      2. Don’t block the main thread
      3. If possible defer loading until after startup
  2. Respect developers
    1. Don’t do anything that causes the app to be rejected from the store, such as renaming system variables in iOS or using Id’s in Android that you should not reference
      1. Don’t violate any store policies
      2. Don’t request information that is off limits
      3. Don’t call private APIs
    2. Don’t put all your good ideas in a single SDK
      1. Bloatware is not welcome (see phone space and startup time above)
      2. It’s often better to have several small SDKs
    3. Create slim SDKs and ones that don’t leak
  1. Clarify assumptions
    1. Document all your assumptions
    2. Even better, design the API’s so developers can’t violate assumptions
    3. If the SDK fails, complain LOUDly in the debug logs
  2. Things you can’t control
    1. You need to be vigilant for system changes
    2. There is nothing you can do about them, but react quickly

There are differences between #iOS and #Android that require some modifications in the SDK. One example is in the speed of the exit from an app. Apple devices tend to have less memory, so they are more aggressive in terminating apps quickly and reclaiming memory. This is less so in Android.

posted in:  Android, Apple, applications, iOS, Yahoo Tech Talks    / leave comments:   No comments yet

Computer #Security Basics – Lessons from a Paranoid

Posted on June 19th, 2015

Yahoo Tech Talks

06/17/2015 @ Yahoo, 229 West 43rd St, 10th floor, NY


With recent high profile system attacks on businesses (such as EMC) and the U.S. government, this talk is very timely. One of the attack methods (XSS) in this presentation was recently revealed to be a vulnerability of a commonly used WordPress plugin.

Stuart Larsen, a penetration tester (#pentest) @Yahoo talked about the technology of system security concentrating on threats posed by server attacks. Stuart’s presentation covered four main topics

  1. Thinking about attacks and responses
  2. Common web vulnerabilities
  3. Tool to improve security
  4. Modern attacks
  5. Thinking about threats
  6. Analyze security from the attacker’s perspective
    1. Map the system
    2. What are the trust boundaries
    3. Assets that the attacker might be interested in
    4. Who interacts with the system
    5. Trust level – who has what access rights
  7. Types of attacks: Spoofing – pretend to be someone else, etc.
  8. Assess the level of risk by each type of attack : e.g. likelihood x impact and the costs, etc.
  9. Consider range of mitigants : do nothing –vs– transfer risk –vs– mitigate –vs– terminate the server
  10. Common web vulnerabilities
  11. Cross Site Scription (XSS) – embed JS in a social message; Mitigant – use frameworks: e.g. convert < into “<” have a content security policy so an HTTP header is only allowed access to some resources: limit use of JS and CSS.
  12. Cross Site Request Forgery (CSRF) – confused deputy problem; can steal money from banks and more; can be used as a HTTP post as well as an HTTP get (for clickable images); Mitigant – all forms have nonce/token (hidden token sent as part of an input tag from a bank, which is needed to complete a transaction); use frameworks protection; don’t allow GET to change state (need a POST); short cookie expiry time
  13. SQL Injection – adjust a SQL query so that the query executes not only the response, but any additional code such as a “Where” statement that always tests “true” . NOSQL is also vulnerable; Mitigant – parameterize queries and programmatically extract and insert a string as the password; use stored procedures within DB; escape the user-supplied input to filter out “=” for example; be explicit about allowable types such as forcing a response to be a string.
  14. Command injection (Stuart considers this potentially to be the most damaging attack). Here, a web page takes the input and executes a command. This means that an attacker can insert additional commands after the required input. Mitigation – use the actual command, not the user inputs; filter and escape all inputs so they are treated as arguments, not commands
  15. Forced browsing / improper authorization– use DirBuster a tool for brute forcing urls to get to a monitoring panel; Mitigation – proper authorization also non-guessable resource IDs and passwords.
  16. Exposed Services – Mitigation – scan the network (including printers, cameras) to see if they hold viruses that can jump to the network; set up Jenkins Servers to avoid a backdoor for command injection; password protect everything
  17. Sensitive Data Exposure – a reset-password email contains a token, but this can make it possible for others to reset the password in the future; Mitigation – use transport encryption; identifiers should not be guessable; encrypt sensitive information (SSN); authenticating information should not be contained in return emails; only keep the logs you need since logs are often not protected, but may contain passwords, etc.;

Tool to improve security

  1. Static analyzers – look for potential problems
  2. Vulnerability scanners e.g. Nessus
  3. Spidering – follow all he links
  4. Network scanning e.g. Nmap – port scanning
  5. Fuzzing – feed garbage to a system and see what happens

Modern Attacks

  1. Social engineering – best way to protect is by getting everyone to be aware of vulnerabilities
  2. Finding, selling and exploiting 0day – attacking your browser, office software and phones;
  3. N-day botnets; take recent attacking methods and replicate them across the net
  4. Ransomware – “will tell the FBI about ___ unless you send $$$$”
  5. Advanced Persistent Threats (APTs) – persistent on your network and be quiet.

posted in:  security, Yahoo Tech Talks    / leave comments:   No comments yet

Building mobile apps at Yahoo

Posted on March 4th, 2015

Yahoo Tech Talks

03/04/2015 @Yahoo, 229 West 43rd St., NY

20150304_194311[1] 20150304_184758[1]

Pierre Maloka moderated presentations on #MobileApps development by six designers, developers and testers at #Yahoo. The speakers described their process from setting goals to product delivery.

The mobile development team at Yahoo was assembled two years ago and all speakers emphasized the importance of differentiating their product from those of their competitors.

Differentiation starts with a user-friendly design that emphasizes images, links to easily explore the news, and is responsive to user requests. The speakers talked about tools, organization, internal communication and testing.


  1. Keynote PDF – can extract images for manipulation
  2. Flinto – make prototypes easily for early testing
  3. Pixate – tool to build animations and interactions in native apps
  4. NodeJS and Express a web application framework
  5. Redis – data structure server to speed data from server to client
  6. Flurry – capture session, session length, active users, new users, retention, frequency of use Also use to monitor events (match to Key Performance Indicators)
  7. Slack – instant messaging which can be grouped into ad hoc channels
  8. Vidyo – video conferencing.
  9. Yo/yo link shortening. Links to documentation and dashboards.


  1. Quarterly development and review cycle
  2. Planning stage sets the goals and prototypes ideas along with initial user testing.
  3. Development stage iterates on regression and integration testing and testing by all Yahoo employees (dogfooding). It culminates in a technical and design review before being released to the public
  4. Client server tasks can be changed without re-installing the app so it contains tasks that are being evaluated or functions that will be changed frequently
  5. Tasks are broken into a presentation layer and a data layer for ease of maintenance and debugging

Internal Communications:

  1. Developers collaborate with design to figure out what to do and what is easy
  2. Get feedback as early as possible
  3. Yahoo has a pod structure so all decision makers sit together.
  4. Solicited feedback throughout all of Yahoo in the dogfood phase.


  1. Conduct testing early and often
  2. Major updates are reviewed and certified for best practices
  3. Instrument all products to monitor what users are doing

Additional comments included

  1. Most testing is manual and uses internal tools.
  2. Use Jenkins for testing on iOS. Don’t use UI testing built into XCode.
  3. Virtually all development is native on both Android and iOS, but the Android group might take advantage of web login when security is updated.
  4. The UI sticks to the format for the platform (iOS or Android). Visuals stick to the Yahoo web style.
  5. On the iOS side, they have tested Swift, but will stay an Objective-C shop for now. The main issues involve the need for more development in the IDE tooling. Also the compiled files tend to be large as Apple wants to insure backward compatible across new versions of Swift.

posted in:  Android, iOS, Yahoo Tech Talks    / leave comments:   2 comments