Author Archives: somehobbit

The DevSecOps Mindset: We Are Not Alone

I’m not going to argue about why “Security is Everyone’s Role” – we’ve already agreed that it is, and there is no point in continuing that discussion. Instead, I’ll try to explain how DevSecOps has been influenced by that mindset – and should also be everyone’s business.


Picture is from:

A Long Bit of History in Two Minutes

In the beginning there were mainframe-based batch processing applications created by Dev and Ops supporting big computers, but not apps

Then, light was seen coming from alphanumeric terminals that supported a client server architecture. App specific Ops was born somewhere around this time. Information security — at least the way how we know it today — was still nowhere close.

Then God DARPA said, “let there be Internet, be fruitful, and multiply, and replenish the earth with the streams of useful information available to everyone”. We all saw that it was all good, until we noticed one bad thing about it. There were bad guys trying to get access to information that they were not supposed to see. This is when information security was born.

At that time security has been completely separated from Dev and Ops. It was not embedded within any SDLC process. Newly created InfoSec companies were coming in to pen test systems and generate long PDF reports with findings and remediation suggestions. Security was a self-sufficient, black box kind of thing that didn’t care much about how those PDF reports would be used.

Meanwhile, business wanted software development practices to move faster, and Dev responded with Agile methodologies (but completely forgot about Ops, which was deeply rooted to the way new apps and systems were created at that time). It then became obvious that making Ops the part of this process was a must, and this is how DevOps was born.

All of that was good, but very soon everyone has realised that if security remained isolated, there was not much the DevOps movement could do to achieve the business goals mentioned above. Next, the DevSecOps term was coined.  (I could find the first use of it in a tweet published on 03/09/2012).

We Are Not Alone

The major question here is: have we included all necessary parties this time? An obvious answer coming from the title of this article is: of course not.

The thing is, while DevSecOps or DevOps concepts could be sufficient for small companies and startups, where any employee belongs to one Dev, Sec or Ops category — for bigger, well-established and heavily regulated companies, it’s never the case.

There are many other parties involved: e.g. risk, legal, compliance,  governance, change control (yes, it still exists), etc. Believe it or not, all of them are part of a software development process. I can recall a case when in the middle of Dev process engineers were asking attorneys questions like: “what will happen if we allow users on our system without asking them to agree with our terms”, or “how will this new feature impact our risk and compliance posture”.

Please note that in situations like these, risk, compliance, and legal pros become a part of the software development process.  And if a team runs in agile mode, these three groups don’t have the luxury to research a risk, compliance or legal issue for a month or two. They need to provide an answer fast to make sure that Dev, Sec, Ops meet their sprint deadlines.

If you think about all that, you will probably agree that in big organizations DevSecOps is really DevSecOps plus almost everybody else.

We’ve started with Dev, then realized soon that Ops and Sec should be included as well.  Now, let us think about how everybody else could be included to the process. It’s not only about integrating automation throughout development, deployment and security, it’s also about big changes in processes.  It is also about the way different — and not necessary technical organizations — are involved within a software development life cycle and their ability to respond fast to the needs of all other parties involved.

I think, the next big thing, which is coming after DevSecOps is DevSecOpsAndEverybodyElse.

Either do that in your organization, or admit that you can’t keep pace with the speed required by business (and that you are a show stopper party pooper).

Finally, I encourage you to read this year’s full set of responses from the 2018 DevSecOps Community Survey here.  The results are fascinating.

Privacy Policy for Android and iPhone Applications

Privacy Policy

Oleg Gryb built the GAC Services Android application (hereafter SERVICE ) as a free commercial app. SERVICE is provided by Oleg Gryb at no cost and is intended for use as is.

This page is used to inform website visitors regarding my policies with the collection, use, and
disclosure of Personal Information if anyone decided to use my SERVICE.

If you choose to use my SERVICE, then you agree to the collection and use of information in
relation with this policy. The Personal Information that I collect is used for providing and
improving the SERVICE. I will not use or share your information with anyone except as described
in this Privacy Policy.

Information Collection and Use

For a better experience while using our SERVICE, I may require you to provide us with certain
personally identifiable information, including but not limited to pictures and key used for 2-factor authentication.
The information that I request is retained on your personal devices and is not
collected by me in any way.

The app does use third party services such as Google Play that may collect information used to identify you. This use will is covered by Google Privacy Policies. The author of SERVICE is not associated with Google or its affiliates.

Log Data

I want to inform you that whenever you use my Service, in case of an error in the app I might collect
data and information (through third party products) on your phone called Log Data. This Log Data
may include information such as your devices’s Internet Protocol (“IP”) address, device name,
operating system version, configuration of the app when utilizing SERVICE, the time and date
of your use of the Service, and other statistics.


Cookies are files with small amount of data that is commonly used an anonymous unique identifier and are not use in SERVICE.

Service Providers

I may employ third-party companies and individuals due to the following reasons:

  • To facilitate SERVICE;
  • To provide SERVICE on our behalf;
  • To perform SERVICE-related services; or
  • To assist us in analyzing how SERVICE is used.

I want to inform users of this Service that these third parties have access to your Personal
Information. The reason is to perform the tasks assigned to them on our behalf. However, they
are obligated not to disclose or use the information for any other purpose.


I value your trust in providing us your Personal Information, thus we are striving to use
commercially acceptable means of protecting it. But remember that no method of transmission over
the internet, or method of electronic storage is 100% secure and reliable, and I cannot
guarantee its absolute security.

Links to Other Sites

This Service may contain links to other sites. If you click on a third-party link, you will be
directed to that site. Note that these external sites are not operated by me. Therefore, I
strongly advise you to review the Privacy Policy of these websites. I have no control over, and
assume no responsibility for the content, privacy policies, or practices of any third-party
sites or services.

Children’s Privacy

This Services do not address anyone under the age of 13. I do not knowingly collect personal
identifiable information from children under 13. In the case I discover that a child under 13
has provided me with personal information, I immediately delete this from our servers. If you
are a parent or guardian and you are aware that your child has provided us with personal
information, please contact [me|us] so that [I|we] will be able to do necessary actions.

Changes to This Privacy Policy

I may update our Privacy Policy from time to time. Thus, you are advised to review this page
periodically for any changes. I will notify you of any changes by posting the new Privacy Policy
on this page. These changes are effective immediately, after they are posted on this page.

Contact Us

If you have any questions or suggestions about [my|our] Privacy Policy, do not hesitate to contact


Real Cost of Imaginary Threats


Each time when security folks are asked to evaluate risks, the first thing that they would usually do is to create a threat model. Some don’t like the term “threat model” since it doesn’t really model anything, and suggest another name – “threat analysis”.

After going through many more or less formal threat modelling methodologies, I’ve realized that regardless of chosen methodology, in the end what your customers want is a simple table where threats are described in a plain human language, and a risk score is expressed in simple terms that everyone would intuitively understand, e.g. high, medium, low or HML.

That’s why I prefer calling my threat analysis “threat table”. What can be simpler than that? Anyway, I’m done with choosing “the best threat modelling framework” for today. Threat Table it is.

It’s not really about methodology though. It’s about what you put to that table, and this is where the art begins. No methodology will help you with understanding which threats are real and which ones are speculative or imaginary.

There are many ways to avoid the art component in this process, e.g. you can stick to company’s security and privacy policies, compliance or other regulatory documents and reduce your task to a simple checkbox marking exercise. In this case you are not different from external security auditors whose efficiency is questionable due latest significant security breaches in organizations that formally were considered as “compliant”.

Following company’s policies only can be even less adequate. The policies can be very generic or vise versa – very specific and obsolete because of that (technology evolves fast and so does threat posture).

Then there is a “common knowledge” problem, which is well known and is taught at business schools (I’ve personally learned it here): a fact or opinion known to many, no matter how questionable it is, will always prevail over less known fact or opinion, no matter how valid and important it could be.

Since security is very subjective and speculative, “common knowledge” becomes a bigger issue. In pre-Internet era securing your network and data centers was everything needed to keep external intruders out. There was no such a thing as “connected services” or service oriented architecture. Silos were the most common approach to building absolutely isolated and self-sufficient applications. To avoid inter-application data leak all you needed to do was to segregate networks.

Contemporary applications are built differently. To be competitive and efficient, they need to be exposed not only to other internal networks, but to Internet as well. With that comes absolutely different approach to security: the app should take care of its safety, not the network. Contrary to what many think (here comes “common knowledge” problem again), it’s achievable and threat of not having enough network segregation becomes less valid. Moreover, grading that risk as “High” can completely disable a business deeply rooted to a connected services paradigm.

Another hidden cost is related to the fact that while all security resources are thrown on imaginary threats, the real ones like those attributed to 3rd party vulnerabilities remain unaddressed and can lead to gruesome consequences (examples are many and don’t even need to be quoted here).

There is no simple solution for this problem. Your threat table will change only after you move the needle in the area of “common knowledge” in your organization.

Good luck with that!

Real Top Ten in Security


I don’t know what the most important thing for you in Top 10 2017-Top 10 – OWASP is. For me it’s vulnerability ranking or the way how the vulnerabilities have been ordered in that list. There are a few reasons why it’s important:

  1. Metrics and KPI believers, whose population grows in business world very fast will immediately map the ranking to priorities
  2. I didn’t see too many businesses who can handle more than two or three priorities at a time well
  3. OWASP Top 10 are very broad and cover almost everything in application security

I think, from this point of view OWASP’s Top 10 are not perfect at all since the current ranking simply doesn’t match reality and doesn’t address real security breaches that caught everybody’s attention lately. Let us take a look at a few of them: “Injections” that were leading the OWASP charts for many years, “Component Vulnerability” ranked as #9 and “Insecure Configuration” ranked as #5 in the 2017 list.

In reality #9 and #5 should be really #1 and #2 in my view, given that breaches like Home Depot, Target, Equifax led to the loss of millions of records of highly sensitive data and have been attributed to 3rd party vulnerabilities, while the latest SMB and ransomware related cases (Anthem, banks, governments) could be related to both insecure components and insecure configurations. Multiple security incidents with AWS S3 (Accenture, Verizon, Dow Jones) can be categorized as “Insecure Configuration” as well.

On the other hand, I can’t recall any significant security breach related to “Injections”.

I think, the major reason of this disconnect is that the method used by OWASP was based on surveys. As somebody who has interviewed many people and teams for the last 10 years, I can say that whatever you get from those interviews could be very inaccurate. In the most cases people simply don’t know what they are talking about, in other cases it could be related to personal preferences and interests to certain security domains, or to ambiguity of questions leading to inaccurate answers. In other words, it’s all about opinions and not about data coming from real security breaches.

Another important factor – a survey fatigue. I’ve been in a situation when various security assessors asked me hundreds of very ambiguous question and answering all of them accurately was simply not possible.

Real top 10 should be coming from real security breaches and their magnitude, e.g. you could try evaluating a vulnerability’s rank using the following formula:

(# of stolen records) x (record’s sensitivity)

or something along those lines.

Are Your 3rd Party Components Secure?

What is in common between Target, Home Depot, and Equifax security breaches? They seem to be different, Black POS was a root cause for the former two and Apache Struts2 vulnerability CVE-2017-5638 was a reason for the latter. In essence, they are both attributed to 3rd party vulnerabilities: Target and Home Depot use POS that they didn’t create, Equifax relies on Apache Struts2 that they didn’t build either.

The way how contemporary software systems are build has changed for the last two decades significantly. I still remember overheated discussions when business and IT were arguing vigorously about possibility of using open source software in a “serious” financial organization, and the answer at that time was rather “no” than “yes”.

These days, it’s not even a question. Even “serious” companies can’t afford building their systems from scratch anymore. If they try to do it, they would simply lose competition to their peers. The change was so dramatic that up to 80% of a contemporary system can comprise of 3rd party components.

The problem here is that even though adopting those components could be easy and free, definitely easier and cheaper than developing the same from scratch, the security of the adopted component was never free. This simple truth is not always understood well. Probably it’s just a mentality issue: we usually care more about the stuff that we’ve created than about the stuff that we’ve got for free or almost for free somewhere. Probably it’s about not understanding the risks that are coming from the adopted components, I don’t know.

My thought and a call to security professionals are simple: if you have 80% of 3rd party components in your system, you should probably dedicate more than 10% of your time and resources to the security of those components. As for now, the reality is different. You can participate in this poll to provide your feedback and to see how the resource allocation looks like in other organizations.

Why Information security is seen as an inhibitor to DevOps agility

To answer this question we would need to take a quick look at differences between DevOps, QA and Security when it comes to automation issues. I will have to write about things that are probably obvious for any security engineer who was practically involved in traditional AppSec activities such as penetration testing, dynamic or static code analysis.

The problem is that for some security executives who came to security from infrastructure, networking or development domains and have never run a security scan,  it’s not obvious at all.

Since situation when security execs are coming from different non-security domains is rather common (due shortage of security professionals), explanation below is crucial to answer the original question. To put it short, the difference is that DevOps and QA are very much deterministic, while security is not. The picture below illustrates my thought.

Ops: run_script(input) –> $? (0, non-zero)

QA: assert(condition) –> {true,false}

Security: scan(app) –> {HML…,false positive}

where High Medium Low and False Positives are really a human’s decision

In the case of architecture review and threat modeling, which are two other important AppSec activities that are often required by compliance standards such as SOC 2, it becomes even more non-deterministic where the results of analysis could be absolutely unpredictable and very much determined by an assessor background.

Needless to say that automation is nowhere close for this type of activities. The best we can do here is to get rid of unnecessary complexity, pseudo-scientific approaches to evaluating risks (e.g. DREAD) and describe the threats in a simple threat table with severities that everybody would easily understand, i.e. “Low”, “Medium”, “High”.

Not understanding this simple truth leads to euphoria and to setting up wrong expectations, e.g. a CISO who came from networking domain can say that a good networking appliance is all we need to completely automate security, while a CISO with a developer’s background will say that writing a lot of code will make security just as fast as DevOps and CI/CD. Needless to say that both are wrong and will not last long – they will have to leave as soon as their CEO or CTO understand that those promises will never materialize.

Does it mean that there is nothing we can do to automate security and make it faster? Of course not. As security engineers we can and we should, and this is what I’ve been talking about for almost three years by now: first at LASCON 2015, then at AppSecCali 2016 and just recently at  RSA 2017 DevOps event.

However, we should always take into consideration a non-deterministic nature of security and set up expectations right when talk to our execs.

The bottom line, security is seen as an inhibitor to DevOps agility because it is an inhibitor in many ways, but there are always opportunities to improve it by researching new approaches of doing it. In this regard, my big hope is a deeper penetration of AI and machine learning to the security domain. It won’t be easy, but the progress in IDS/IPS space makes me think that it will eventually help automating traditional AppSec activities as well.

Integrity in Security




It’s difficult to write about integrity in security, because it’s not about technology anymore, can be very vague and speculative. At the same time, not having integrity in security can lead to fundamental flaws that will undermine all other security controls. To be more specific about “fundamental flaws” think about compromised cryptography, in which case everything else that you do would not matter much.

What is Integrity?

You can find many formal definitions of course, but for me it simply means doing the right things, no matter what. “Right things” can be tricky here especially when a security SME or executive don’t have much experience in protecting systems and data, but since I’ve covered this case here and here already, I would assume that SME or executive have enough experience, know what they do and how security should be implemented. I will not also consider honest mistakes, because honest mistakes are not necessary related to integrity assuming that a person doesn’t have problems with admitting them.

Perils for Integrity

Any SME or executive who worked in security long enough has probably experienced one of more perils that could jeopardize their integrity:

  1. Senior management doesn’t completely understand the treat, but is willing to spend some time with security to understand it better.
  2. Senior management understands the threat, but doesn’t have time, money or human resources to address it now.
  3. Senior management understands the threat, but never provides all resources necessary to address it.
  4. Senior management understands the threat, but never provides any resources necessary to address it.
  5. Senior management doesn’t understand threats and never has time to talk to security about it.

Please notice that motivation for these types of behavior can be different – from not having enough resources to possible conflict with business goals. Understanding the motivation well is important for making trade-offs while preserving integrity.

Addressing the Perils

The first case is the simplest one. A security SME would need to identify the key business stakeholders and tell them a story at the right abstraction level.  Choosing the right abstraction level is very important. If it’s too low, you’ll lose them and it will be completely your fault that has nothing to do with anyone’s integrity. If it’s too high and generic, your story might not be compelling enough and nobody will buy into it. Try using some numbers such as a monetized cost of a possible breach or real life stories demonstrating reputational and financial losses occurred in other organizations.

The second case is not hopeless either. Make sure that business commitments toward security last by reminding them frequently that this is still an important outstanding problem that needs to be solved. Meanwhile beef up mitigating controls such as monitoring for this particular threat and if you find its pattern unfolding in production, use it as a hard evidence that the threat is real and needs to be addressed soon.

The third case is rather typical – you will never get all resources to address all threats and vulnerabilities that you’ve reported. What you can do is a better prioritization and addressing the most important threats first while monitoring for others just like in the second case.

The fourth case is tough. As I’ve mentioned above, try to understand their motivation. Probably the business is in such a bad shape that nothing has left for security indeed, in which case you’ll need to leverage all human and technical resources inside the security team to help business, development and operations by delivering more automation and monitoring to mitigate the risks. If business is thriving on other hand, but you’re still not getting resources, that’s a good reason for a serious conversation with the top echelons of management in your organizations.

The fifth case is extreme and doesn’t happen in real life often. Try finding at least one ally in the management ranks and use each opportunity to escalate the issues. If that doesn’t help, your own integrity is important for you and you don’t want to be a security window dresser, consider changing an employer.

Inspirational and Demotivational Examples

Fortunately, we have enough inspirational examples demonstrating a high level of integrity in security when people chose what is right over what is required by incompetent bosses or even governmental authorities:

  1. Martin Hellman thought that improved security is more important than possible prosecution by law enforcement. He has published his PKI work in 70s in spite of all threats and warnings coming from government and was right – security has benefited significantly, his work was widely recognized and revolutionized cryptography. He had vision and courage to implement it.
  2. A strong privacy advocate and a well known security dignitary, Alex Stamos, was arguing vigorously with an FBI director about cryptographic backdoors explaining why it’s dangerous and how it can compromise security for everyone.
  3. The same Alex Stamos has resigned from his CISO position at Yahoo when learned about its government backed secret spying program and realized that he could not do much about it due lack of support from CEO and the board.
  4. A number of security folks, cryptographers, legislators condemned secret government spying programs at different public forums and requested more transparency, because they thought that it will degrade security and undermine privacy.
  5. I’ve also seen many other honest folks in security leaving their well paid positions, because they didn’t agree with how security is handled in their organizations.

I don’t want to write much about demotivational examples, but unfortunately they are many as well. Just look at the inspirational examples above and think about adversaries of those decent folks that have been mentioned there.

Final Thoughts

Integrity in security requires a lot of courage, perseverance and intelligence. I think, to be a successful security professional, one should absolutely have it. On the other hand, employers who don’t understand it can undermine the whole security program in their organization, drive professionals out and create an environment where flourishing complacency kills everything good and real, while promoting “security as a window dressing” phenomena.


Biggest Security Problems

Credit: Thinkstock

Credit: Thinkstock


Contrary to what many might think, hackers are not the biggest security problem. As I’ve mentioned here, getting priority right is very difficult in security and the major security problems are related to that. Without pretending to be a single source of truth, I could formulate the first problem as:

Opportunistic Approach to Security

As described in Security Manifesto, there are many domains of security that an organization would need to address to make it right. However, a number of security executives who understand all of them well is very limited. There are two common ways for a security executive to become a CISO: (1) SME path, where an executive gets promoted to CISO, because he was very successful in one or two security domains, e.g. infrastructure and networking; (2) managerial path, where an executive becomes a CISO, because he was a successful engineering, operations or compliance manager.

The second case is the worst, because an executive will most likely try solving all security problems by means that she’s comfortable with, e.g. if she comes from a s/w engineering realm, she would say: “let us write a lot of code and it will solve all our problems”. The latter approach can be perceived by security neophytes as a new “revolutionary”, “one size fits all”, “silver bullet” solution and will make everything even more complicated and dangerous for the industry.

The first case is bad enough too, e.g. if CISO comes from law enforcement circles, he’ll focus on creating and enforcing policies, while a networking and infrastructure guy will immediately spend all security budget on very expensive networking appliances and neglect all other programs.

Security as a Window Dressing

The second big problem is lack of real support from senior management. It’s not common at all for any sane CEO, CTO, CIO or board of directors to say that they don’t care about security or that security is not their priority. I’ve seen only one VP of engineering in my life who had said openly that “security is not a priority” for his team. I would give this person all credits for his honesty, at the same time, I think that many executives who say that security is their priority are not necessary committed to it enough and are not willing to provide resources to implement the security at the right level.

This trend shows up when you talk to an engineering organization asking for resources – either people or money, or time dedicated solely to security tasks. They will never say “no”, but always come up with the excuses like:

  1. An important release is coming and we can’t jeopardize its deadline.
  2. They can lecture a security SME about importance of partnership. It can go like this: if s/w engineers don’t do what you’ve recommended, probably you, as a security SME, didn’t explain threats or mitigation plan well, you should not be policing or dictating anything to the engineering team, you need to be a partner and explain everything well to them and then they will implement everything you wanted. Needless to say how invalid these statements could be especially when significant engineering resources are required – no engineering team will embark on this kind of tasks without a proper authorization coming from a senior management, no matter how articulate the security SME was in explaining the threats and a proposed solution.
  3. Finally, they can declare the whole security program as a low priority or cancel it all together, because a new CISO told them that there is another, more important program that should be given the highest priority (see “Opportunistic Approach to Security” above).
  4. Some executives think that since they hired a CISO and a security team, security is not their problem anymore and is completely owned by the security organization.


Hiring CISO with the right skills is extremely important. An ideal CISO in my view should have broad knowledge in all security domains. Hiring CISO without any prior security experience is dangerous and doesn’t make much sense to me.

It’s primarily CISO’s responsibility to get resources and real senior management support. CISO should be vigorous and consistent in getting this message across and escalating issues related to lack of such support to the highest level if necessary.

Non-security executives should participate in making important security decisions and support security team with resources in other teams (operations, engineering, QA, etc.). A security program in any organization can’t be successful until everyone understands that security is a team game, where team is the whole company.


Security Manifesto

What is Security About

Security is about breaking and building. Building includes resilient systems with security embedded by default and security tools helping to automate the whole security process. Breaking is about reviewing the systems trying to understand where vulnerabilities could be found and proving that they could be practically exploited using commonly available tools and methodologies.

Common Security Myths

Common approach used by business often, namely – let us address “critical few” and all our security problems will be solved, doesn’t work in security and is dangerous, because security is just as strong as its weakest link, which most likely will not be included to the “critical few”.

Other common myths related to that are:

  1. Our system is secure, because we’ve implemented good security policies.
  2. Our system is secure, because we are compliant with all regulations where our organization is a covered entity.
  3. Our system is secure, because we’re using the most advanced and contemporary security tools placed by Gartner to the top right quadrant.
  4. Our system is secure, because we’ve written a lot of code to automate our security processes and integrate them well with all our automated security tools.
  5. Our system can not be defeated even by zero day attacks, because we use machine learning for fast intrusion detection and prevention.
  6. Our system is secure, because we have the best in the world security team and researchers.
  7. Our system is secure, because we have implemented a comprehensive threat intelligence program and are always one step ahead of any hacker group in the world.

What is Really Important in Security

  1. All of the above (see “Common Security Myths”).
  2. Being aligned with your organization’s business needs and building adaptive security by identifying the most important threats for your business and addressing them first.
  3.  Maturing and expanding your security tools, processes and coverage as your business grows and matures.
  4. Taking reasonable risks to allow business to be competitive and agile. Implementing a comprehensive security and losing competition to your peers because of that is not really an option.
  5. Always walking the fine line between security and usability. That’s the only thing that can make security implementation efficient.
  6. Being critical towards “well established” standards (think of DUAL_EC_DRBG) and “common practices” (Target was compliant with regulations and did what is “common”, but still got compromised)
  7. Assessing your threat posture well and understanding that your business might have specifics that others do not have. At the same time, always looking around to find solution that fit well your organization.


Be critical, understand that there is no “one size fits all” solution in security, look around to learn how other people and organization do it, but select only those solutions that fit your organization well. Analyze your organization’s security threats carefully before deciding what your short and long term priorities in security should be.




MPD Client for Tizen, Gear S2

This native Tizen application implements a traditional MPD client functionality that was built for Tizen Gear S2 devices. We tried to use the same code for Gear S, but unfortunately Native API is not available for this model yet. You can install the MPD Client to your Gear S2 device using Gear App running on your smartphone.

Few Quick Notes about MPD Server

We’ve tested it with MPD server’s versions 0.16.7 and higer and it worked well. Playlists must be created on your MPD servers, because that’s the only objects that the client can select and play.

I’ve found playlists very useful for selecting and playing my favorite Internet radio stations along with MP3 stored on a hard drive of my MPD server.

Here is how a typical radio station playlist looks like:

# more /var/lib/mpd/playlists/RadioKievLounge.m3u

As you can see from the example above, all you need to create a radio station playlist is a URL of the station’s stream. In the case of a more traditional playlist with songs stored on a hard drive you would need something like this:

# more /var/lib/mpd/playlists/Queen.m3u
mp3/Queens/Queen – Body Language.mp3
mp3/Queens/Queen – Bohemian Rapsody.mp3
mp3/Queens/Queen – Bohemian Rhapsody.mp3
mp3/Queens/Queen – Crazy Little Thing Called Love .mp3
mp3/Queens/Queen – I Want To Break Free.mp3
mp3/Queens/Queen – I Want to Ride My Bicycle.mp3

The path to an MP3 file is relative to a root MP3 folder, which needs to be provided in your MPD config file, e.g. here is mine for a server running in Linux environment on Raspberry PI:

music_directory     “/var/lib/mpd/music”
playlist_directory      “/var/lib/mpd/playlists”
# User under which MPD daemonn runs
user                “mpd”
# For network
bind_to_address     “”
# An example of an ALSA output for Linux:
audio_output {
type        “alsa”
name        “My ALSA Device”
device      “hw:0,0”    # optional
#   format      “44100:16:2”    # optional
mixer_type      “hardware”      # optional
mixer_device    “default”   # optional
mixer_control   “PCM”       # optional
mixer_index “0”     # optional

# An example of output for Windows
#audio_output {
#  type “winmm”
#  name “Speakers”
#  device “Speakers (Realtek High Definition Audio)”
# You can also try “libao” instead of “winmm” on Windows

# An example of output for Mac
#audio_output {
#       type            “osx”
#        type            “ao”
#        name            “My Mac Device”
#        mixer_type      “software”

The config file can be provided as a parameter when you run your MPD server, e.g.

#mpd ~/.mpd/conf

On Linux environment there is a default location for the config file – /etc/mpd.conf

Using MPD Client

After you’ve configured your MPD server and installed MPD Client to your Gear S2 device running the client is simple. The first thing that you need to do is to connect Gear S2 through WiFi to the same  network where your MPD server runs. After that you’ll need to provide the IP address and port of your MPD server:


The default MPD’s port is 6600, so you should use this one if didn’t change it in MPD’s config. There are some additional and self-explanatory parameters on this screen. If you find difficult toggling the check boxes, just click on the containing rectangle to get a bigger view:



After you’ve entered a correct IP and port, press OK button on the bottom and you’ll be taken to the next page with all playlists created on your server:


Now you can select your favorite playlist and start listening to it. If you tap the speaker button the previously selected playlist will be played.


You can navigate to the next/previous song in the list by tapping the buttons on the screen, or you can navigate between playlists by rotating the bezel.

To zoom the player’s view simply tap the rectangle with the song info:


You can still navigate between songs in the playlist by swiping the title left or right or you can toggle a current playlist by rotating the bezel.

“Back” button functionality is available and can be always used to go to the previous page. Connection icon included to all screens is used to indicate if a connection with MPD server is alive.