Bazar rules of engagement

First things first, the Bazar rules of Phosphorus Five, is probably the by far most Nazi rules you have ever encountered in an app store. For instance, I do reserve the rights to not publish your app, simply because it’s Monday! I am in no ways obliged to giving you any explanation for why I choose to reject your app either, and I might choose to do so, simply because I “feel for doing it”. In my Bazar, I am “Der Fuhrer”. Don’t like it, go visit Apple’s AppStore!

Secondly, if you wish to let me distribute your app, through my Bazar, you’d better make sure it’s secure. Any data you retrieve from a source outside of your own app, should better be both properly URL encoded before it’s displayed, in addition to avoiding SQL injection attacks. In addition, I will as a general rule, not accept apps that in any ways seems to potentially violate my user’s privacy. Privacy is, after all, the by far most important USP in Phosphorus Five, and its eco-system. Hence, if you create as much as a single remote HTTP GET invocation from your app, to another location, outside of your own little app – Be aware of that this is probably in isolation, enough reasons for me to simply reject it, answering “Monday” as my reasons – Unless your reasoning for doing such, is so strong, and your arguments so sound, that I would allow you to convince me about that your reasons are valid, and accept it …

To put this Nazi regime into context, realise I even HTML encode data retrieved from my own Bazar, which actually is my own GitHub Phosphorus Five repository, before I display it to the user – To avoid HTML injection, by an adversary in the middle, among other things. Phosphorus Five is a server system, and if security is compromised, this could potentially lead to a security hole, for thousands of users – Making an iPhone virus seem like a freakin’ fart in the park in comparison!

Hint, I do not trust Google, Facebook, Twitter, or any website out there – Regardless of how “popular” it is in main stream usage. A simple static Facebook image button, loaded from a URL outside of your user’s main root server, or a CDN request – Might be enough for me to reject your app, assuming it’s intruding my user’s privacy, by logging these requests on the server endpoint, from where you fetch your image(s), and/or CSS files!

When your app is to be distributed, or upgraded for that matter, I will demand to scrutinise its entire source code, line by line. When I have done so, and (maybe) accepted it, I will cryptographically sign your .zip file, with my own private PGP key, and allow you to host the zip file any ways you wish. Which of course implies that if the zip file have been tampered with, after I accepted it, it will be rejected during the installation process. Hence, if you choose to create an update for your app, the process starts all over again.

Notice, I will also follow up on you, if your app is rejected, and give you feedback – Unless your app is so full of holes, that there is simply no reasons for me to believe you’ll ever be able to create a secure app, without me having to literally teach you coding, from the grounds up!

Thirdly, make sure you know Hyperlambda well before you start out. You can learn Hyperlambda here for instance. And stay away from “my stuff”. Which implies that I expect you to properly namespace your events, code and files, such that naming collisions are highly unlikely to occur. For the moment, I do not accept code written in any other languages than Hyperlambda, which means that you’re gonna have to exclusively create your app, using nothing but Hyperlambda.

Document your code, excessively, and make sure you follow my coding standard. Which can kind of be deducted by scrutinising Sephia Five. Create extremely clean code, easily read by me, and/or the rest of the world. If I feel that your code is somehow not easily understood, I’ll probably send you an email, without a body, and the subject of “Monday”!

Your entire app must be confined to a single folder, which includes your CSS, resources, Hyperlambda, etc. And this folder must be uniquely named, with some intelligently namespace’d name, such as “Sephia-Five”. “Email” or “files” is *NOT* acceptable!

Now that all the Nazi stuff is explained, I wish you good luck, and would love to accept your app, if it is well written, preferably obey by the design GUI guide line rules, which I have not yet written, but which you can kind of deduct, by examining Sephia Five for yourself. For the record; No ads or marketing. This point is non-negotiable! And preferably, to increase the chances of having your app accepted, don’t even display a logo! And if you do, make it so tiny and small, that it is almost impossible to see! User’s of P5 really don’t care about the name of your company, and/or app – They simply want to get to their data, without being tackled, by huge banners and ads. If you can’t obey by this, feel free to go to Apple’s AppStore! Also make sure you use as little resources as possible – Both on the server itself, in addition to bandwidth.

If you wish to discuss your ideas for your app with me, before you start, for such to reduce the likely-hood of that I reject your app – Feel free to toss me an email at However, if you treat security as priority #1, #2 and #3 – And you treat your customers as the Mother of God, and are insisting upon adding value for your customers, not interrupting them with ads and other “crapware”, and protecting their privacy with your life, if necessary – You’re probably gonna do very well, and I wish you the best of luck! Just remember these 3 simple rules …

  1. Respect your users privacy
  2. Respect your users privacy
  3. Respect your users privacy!!!!
  4. Respect your users privacy!!!!!!!!!!!!!!!!!!!!!!!!!!!!

And you’ll probably be fine …

For the record, I do also allow you to distribute your app for a fee, commercially – However, if you’d like to create non-GPL code, you’ll need a proprietary license of Phosphorus Five. If you choose to do such a thing, please give me your app’s price, and I’ll setup a PayPal product page, which redirects the user’s to your zip file once they’ve paid for it. I will send you a monthly report of how your app has been doing, as long as there is at least one download of your app. This allows you to log downloads of your app, and for that matter reject any GET requests not being referred to by PayPal, giving you control over its download count, while I control the payment mechanisms.

If you distribute your app for a fee, I will charge 25% commission, sending you the rest of the money, over PayPal, having you pay any PayPal transferring fees. For the record, I encourage you to charge at least 2-3 orders of magnitude more for your app, than what’s normal to pay for apps in Apple’s AppStore. The Bazar is not the place for thousands of “flashlight apps”, not adding value to my user in any ways. It is also not a place for games and fun. It is a place where P5’s users can go to get web server applications, that would somehow significantly improve their lives. Sephia Five for instance, is probably the by far most expensive email client in existence today, simply because it is worth it. While I at the same time give it away for free to individuals. And unless your app is worth it, you should probably find alternative distribution channels.

If you’d like to distribute an Open Source app through my Bazar, you’re more than welcome to do that too – However, the rules are still the same, implying Adolf Hitler Nazi rules!!

Do what you love, love what you do, and treat your customer’s privacy religiously – And you’ll probably be just fine!

For the record, this blog explains a future feature of Phosphorus Five, which is to be released in the upcoming release of P5. However, if you’d like to get a head start, feel free to start coding!

You can expect Micro to be installed. Besides from that, you should not make any assumptions about additional modules being installed, and you must check for any missing other modules and/or apps, and lead users to the Bazar if these are not installed.

Is it safe to help the police?

I’ve been doing a lot of research and development into cryptography, and just for fun, I checked to see if I could find a public PGP key for the email addresses, that the Norwegian secret police is using to accept tips from the general public. Guess what, I found none!

This implies that it is actually impossible for the general public to securely help the Norwegian secret police (PST), by giving them tips, without potentially having a whole range of adversaries, being able to read these emails.

In today’s society, where terrorists and cyber criminals have infested literally every single aspect of our lives, this implies, that if a criminal adversary wants to, he could easily pick up the conversations the general public are having with the Norwegian secret police, and use this knowledge to his own advantage.

I do not mean to be rude or blunt to the Norwegian secret police (PST), but such a situation is of course unbearable, and not something a civilised society should be proud about. In fact, in theory, this implies that your neighbours could spoof your WiFi router hotspot, and verify whether or not you are talking to the secret police, and actually read the emails you are sending (and receiving) in plain text.

For the record, this is not unique for the Norwegian secret police, but actually something I have found to be almost consistently lacking, with all major secret police services I have studied. If you wish to verify my claims, you can type in your local secret police’s email address, at the following key server, and search for yourself.

Until this is fixed, I must unfortunately from a security perspective, encourage my readers to avoid helping their local secret police using email. However, you can still call them, or visit your local police station, and tell them in person about what you know. If the Norwegian PST wants to, of course, I hereby offer my help to them, such that they can accept emails that are encrypted with PGP. In fact, I have developed a system that allows for just that. Watch the video below for details about this system.

For the record, the Norwegian secret police, and any other police service, can (of course) contact me, cryptographically secured, with the following public PGP key.


How to avoid email phishing

Phishing is for instance when an adversary attempts to trick you into visiting a URL, which you believe is leading somewhere else, than where it is actually leading. Surprisingly, a lot of these phishing attacks can be avoided by simply displaying the actual URL, or more specifically its domain, to your users – Regardless of which anchor text the hyperlink contains. For instance, and adversary can create a hyperlink with the anchor text of “”, while the hyperlink actually leads to “”. Often simply clicking such a link, is a security risk.

However, in Sephia Five, we have been spending a lot of effort avoiding such security risks, and one of the things we have done, is to show the actual domain for hyperlinks in emails, regardless of which anchor text the sender is supplying. This simple feature makes you see which domain the link is leading to, and hence, significantly reduces the risk of that you will click a malicious link. See screenshot below for an example.

Not only do we display the domain, but we also emphasise it, with bold letters. We could have shown the whole URL, however, that would defeat the purpose, since the point is to show only the information necessary, to allow the user to do the intelligent action. If we had shown the whole URL, the domain would often “drown” in tons of other garbage.

Since a significant number of phishing attacks are created by adversaries sending you an email, leading to phony domains – This would significantly reduce the security risks for you, of becoming the next victim of a phishing attack.

In the image above, the first hyperlink is a simple inline hyperlink, written simply as a URL, where we display the domain emphasised. While the second hyperlink, is a true anchor hyperlink, with an anchor text of “Google”, where we append the domain after the anchor text, to such display it to the end user.

Such a simple trick, could potentially reduce the success ratio of a phishing attack towards your organisation, by orders of magnitudes. Simply since users can often understand they’re about to become victims, if you simply display the direction they’re attempted to be drawn towards. Basically, if the fish can see the hook, he won’t bite … 😉

Security starts out with simplicity, unless it’s simple, it’s not secure!

Encryption is a human right

Please exercise your rights!

Did you know that it is a human right to use encryption? Article 7 and 8 of EU’s human rights declaration, protects your right to privacy. Article 17 of United Nation’s human rights declaration, further protects your privacy, and hence also to use encryption in your communication. UN’s article 17, even explicitly states “protection of personal data”, and hence arguably states directly that nobody can break into your data, without violating internationally sanctioned human rights.

In America, the 5th Amendment further protects your right to privacy, and a court ruling from USA in November of 2007, actually concluded with that an individual who was facing criminal prosecution, could not be forced to give up his PGP password phrase, since it would violate the 5th Amendment.

These are fundamental rights you have, and nobody can legally coerce you into submitting your data – Not even the police.

Cryptography and privacy is a human right!

If you want to exercise your rights, you can contact us, and ask us how we can help you. We provide among other things a military grade cryptographically secured PGP webmail system, for individuals and corporations, that allows you to have your privacy. See the video below for details about our system.

If you wonder what’s at stake, feel free to watch the next video, that clearly shows you why you should care about your privacy.

How Facebook will collaps

Thank you Mr. Zucker. Greed is too easy, simply feed more … 😉 – And good luck with the Presidency, may you win. You are the best man, we love you, all of us!! 😀

I am fairly good at technical analysis, intended to predict the future, by interpreting current events. There’s nothing magical about my skills, it’s simply an ability to neutrally observe current events and facts, and extrapolate these into the future. Back in 2009 for instance, I predicted the collapse of both Silverlight and Flash, years before it occurred. I almost got it perfectly accurate, also in regards to the time axis, and only missed by a couple of years, as I predicted the timing.

Today I will make another prediction, which you can pinpoint down to a specific hour of a specific day, in the year of 2020, at which Facebook will completely collapse, and its shares end up on a fire sale. The day is the day of the presidential election of USA, and the hour is when it starts dawning upon people who won the election. To understand why, we must revisit recent history.

In 2011/2012 Facebook performed an experiment on approximately 300-600,000 of its users. They would fill these users’ news feeds, with particularly depressive news and updates. They wanted to see how much leverage they had in regards to changing the moods and minds of its users, and Facebook were flabbergasted by the results, to say the least. Basically, everyone targeted in this experiment, suffered from depression, anxiety – And a much larger percentage of these users than normally, would commit suicide, as a result of that they were only fed negative news about the world, creating a dystopian outlook for their own future, depriving them of all meaning and belief in their own future.

As Mark Zuckerberg starts his run for the US Presidency, he will use these powers to make Facebook into an echo chamber, silencing all opposition against himself, “punishing” anyone who raise critical opinions about his candidacy. Inevitably, a lot of people will initially be critical of having Mr. Zuckerberg accumulate that much power, and will hence raise critical voices, at least initially. Mr. Zuckerberg will at that time do what his nature dictates, which is to silence the opposition with any means possible, which will create an unbearable situation, for those having raised critical voices.

However, these people have neighbours, friends, and family, who can clearly see the pattern, and intuitively understand the reasons for their friends depressions and anxieties. Slowly, the rumour will start spreading, from mouth to mouth, the “old fashion way”, making everyone understand that if they criticise Mr. Zuckerberg on Facebook, they will be punished. Months before the election, it will hence seem to Mark Zuckerberg that he is about to win the US election by a landslide, because all of his statistical analysis concludes with that he has 90% of the votes in America. He will probably celebrate, prematurely, and the whole world will expect him to win – Without realising that while he have created an echo chamber on Facebook, where all critical voices have been apparently silenced, he still doesn’t control people’s actions on election day. Basically, people will at that time, in public, have bullshitted him so much, that Mr. Zuckerberg have started believing their bullshit!

Hence, 90% of the American population, will be thought to be voting for Mr. Zuckerberg, while they really went completely dark, and never shared with anyone who they actually supports. On election day though, the curtain is closed, and they can safely vote for the one they actually wanted to win, without fearing punishment by Mr. Zuckerberg – And hence they will do just that, and never admit publicly they did. As they vote, Mr. Zuckerberg looses by a landslide, and regardless of who the other candidate is, he’s just won the easiest walk over in American history! It could be “Roger Rabbit” on the other side, and he’d still win by a land slide! In fact, if you want to become the President of the USA, simply go up against Mr. Zuckerberg. They’ll basically vote for you, regardless of what you’ve done in your past. Simply because they’re not voting for you, they’ll be voting *against* Mr. Zuckerberg!

As the results of this election is publicly known, Facebook will have very publicly, made a complete fool out of itself, making the whole world realise, that they couldn’t even predict such an extremely easily predictable thing, such as the American President election. At which point advertisers’ will withdraw their support for Facebook, realising that Facebook knows absolutely nothing about its users, and hence are no longer able to target the demographic, that these advertisers pays Facebook to actually target.

A woman who is gay, in her early 20s, might be claiming online on Facebook, that she’s a male heterosexual bus driver, in her late 50s. A system developer, might claim he’s a surgeon, and a single mom, might claim she’s a little boy, 14 years of age – All out of fear for Mr. Zuckerberg getting to know the truth about them. Basically, Mark Zuckerberg, who started out his mission, with the goal of making everyone become, quote “more authentic”, will inevitably have resulted in, that out of 2 billion people, there’s not as much as a single authentic voice left in Facebook’s database.

If you want to have my personal financial advice, then buy shares in Facebook as Mark announces his candidacy, and clean out your entire account, 24 hours before election day! It’s a slam dunk! Basically, it’s money for nothing …

Facebook has implicitly confirmed they’re a Judas machine

Mark Zuckerberg, chief executive officer of Facebook Inc., listens as Narendra Modi, India’s prime minister, not pictured, speaks during a town hall meeting at Facebook headquarters in Menlo Park, California, U.S., on Sunday, Sept. 27, 2015. Prime Minister Modi plans on connecting 600,000 villages across India using fiber optic cable as part of his “dream” to expand the world’s largest democracy’s economy to $20 trillion. Photographer: David Paul Morris/Bloomberg *** Local Caption *** Mark Zuckerberg

Over the last couple of days, I have had our marketing director share a couple of Facebook critical blog posts, especially focusing on that Facebook is a “snitch machine”, incapable of keeping secrets, and securing your online life and privacy. Normally when my friend share funny things, and/or music videos, which I create, she will get dozens of likes, and lots of comments. However, on these latest shares, she has gotten 1 or 2 likes only, and only one person commenting, which is a pretty revealing fact by itself.

Facebook is not only a snitch machine, and the Judas of the IT sector, they’re also desperately de-emphasising everything that’s critical of their services. Their means to do this, is to have algorithms and bots, that will even go as far as listening to videos, using speech recognition, and internally “flag” everything, that is not compatible with the promotion of their walled paradise. This is to avoid having the masses becoming disgruntled with their services, and/or realise the truth about their “value proposition”.

Look at the screenshot attached to this blog, and realise that I have had my friend share a handful of music videos that I have previously created, and every time she does, she will get between 30 and 100 likes. This time however, she got 1 like, besides her own of course.


By internally “flagging” my video the way they did however, they have done me a great service, by implicitly admitting to that what I am talking about in my “rap video”, is largely true – Simply by avoiding that it shows up in my friend’s friends’ news feed, by having attached an “internal flag” to her posting, making it much less likely that anyone will ever see the video.

If you wish to test my theory, this is very easy indeed. Go through your own Facebook profile, and create a statistical average on the number of likes and/or comments on your 10-20 latest updates. Write this number down, and share my video, which you can find here, then wait a couple of days, and compare the average with the number of likes and comments you got on my video. I have included the video further down on this article, such that you can see it for yourselves.

In doing this paradoxically, Facebook and Mark Zuckerberg is arguably implicitly admitting that what I talk about in my “rap video”, is basically true!

Thank you Mr. Zuckerberg! Now if I only could zucker Mr. Zucker into having my local secret police knock down my door, my marketing campaign for Sephia Five would become perfect!! 😉

Security, how to create a good password

I have known for a long time, that ridiculously complex passwords, containing all sorts of special characters, doesn’t necessarily increase entropy – Or reduce the likely hood of that your account will be hacked.

Purely logically, and mathematically, it often makes for much stronger security to use a sentence as a password. Preferably a sentence that is highly localised, and not something such as “I love myself”. And also a fairly long sentence. Simply put, because due to the math behind password breakers, it makes the job of cracking your password much harder. A password such as “I freakin’ adore Lofoten, especially during summer”, creates an entropy of 248.2 bits, and is actually much harder to crack than a password such as “$€%fF25x”, which only creates 42.2 bits entropy.

Hence, the first password, is actually much harder to crack, and therefor safer. In addition, it is much easier to remember, and will therefor reduce the likely hood of the user having to reset his or her password. When WikiLeaks released Vault7, they chose “I will scatter the CIA to the winds of the world” as their AES password for its content.

Today, there’s an interview with the guy who “invented” these weird passwords, requiring special characters, small and capital letters, with at least 1 number in them, between 8 and 16 characters long – And he is confessing that he actually regrets it, since it is purely statistically less safe, than a password where the user is freely allowed to write anything he wants to write.

In fact, in P5 and Sephia Five, I have long since implemented the ability to create any passwords you wish. There are no special constraints on adding special characters, no demands to max or min length, no constraints forcing the user to use small or capitalised letters, and no constraints on adding at least one number to your passwords, etc. And according to the math, this purely statistically, makes it easy for you, to create more difficult to break passwords, than services that requires of its users to use all sorts of special characters.

Of course, you could also utilise the best from both worlds, and create a password such as “1 am a mean a$$ security machine from Narvik”. The 1 and the $$ are basically substitutes for the letter “I” and the letters “s”, and hence becomes easily remembered. Now of course, typing that password on a phone, is difficult – However, you can easily choose for your client to remember your password, without significantly reducing your security, due to the way password vaults are normally implemented.

To the rap mobile

I’m a hobby musician, playing all sorts of instruments. Among other things, I play the guitar, saxophone, drums, and literally tons of other instruments. However, yesterday I created my first rap.

Before you listen to it, please realise it’s my first rap ever. However, I kind of think it’s a nice first attempt. The beat could probably be richer, and deeper – But I didn’t want to steal focus from the lyrics – Therefor I made it as simple as I could, and decreased its volume, to make the lyrics “pop out” at maximum level. Of course, I couldn’t resist to do it in such a way that it became also an ad for Sephia Five.

Anyways, have fun 😀

Sephia Five’s technical security implementation details

This is a fairly technical blog, mostly intended for developers, such that they can verify the security measures in Sephia Five. Hence, it is intended as a starter guide, for people interested in checking up how strongly secured Sephia Five actually is.

I make some pretty bold claims in some of the material I have created for Sephia Five, and some developers might be suspicious about some of them. However, it is actually quite easy to understand, once you understand the details of the implementation. Below are some of the security measures I have taken while creating Sephia Five.

SQL insertion attack

This is a big one in our industry. Many novice developers aren’t even aware of the problem, and it comes from the fact that developers tends to concatenate input from users directly into their SQL statements. This creates a whole range of problems, based upon the fact that you can never guarantee that the user is not providing malicious data in his forms. Imagine something like the following for instance running on the server.

var sql = string.Format("select * from contacts where name like '%{0}'", searchQuery);

The problem with the above approach, is that the searchQuery might contain data such as the following.

foo';\r\nselect username, password from users;//

If the user supplies a search query such as the above, instead of retrieving the contacts, the end user will retrieve all usernames and passwords. Simply because the above SQL command will transform into two commands, looking like the following

select * from contacts where name like '%foo';
select username, password from users;//'

Hence, you will very effectively have created a security breach in your application. Few novice developers are aware of the above problem, and hence it is a very real and common problem in our industry. A couple of months ago, a research laboratory in Telemark, Norway was plagued by the problem illustrated above.

Sephia Five completely avoids this, by never concatenating SQL with data supplied by the user, but instead uses what’s commonly referred to as “SQL parameters”, which will completely avoid the above problem.

HTML injection

Any app that is intended to run in the browser is a potential candidate for HTML injection. This allows a malicious user to inject HTML into your client, by for instance sending you a dubious email. This could be done by creating an email with a subject, which is actually a JavaScript inclusion directive, executing some malicious piece of JavaScript, that compromises the client reading the email.

This is avoided in Sephia Five by always making sure that we HTML encode everything from received emails. This makes it impossible to create malicious HTML, that will compromise the client. In Sephia Five, HTML encoding is performed on everything we show in the browser, that originates from a received email. Including the email address,  sender’s name, subject, body, etc.

In addition, the few places where Sephia Five actually needs to display HTML, such as when converting Markdown to HTML, it will run the resulting HTML through a “whitelist”, excluding all tags, that are not considered 100% safe. This makes it impossible for an adversary to include malicious code, in some email, that creates a security breach once the email is displayed.

Server side salted hashed password storage

Sephia Five is built on top of Phosphorus Five, which is an extremely defensive full stack web application framework, built from the grounds up with security in mind. Among other things, no passwords are ever stored in clear text, but rather as server side saltet hashed strings, implying even if an adversary should physically gain access to your user password file, he can still not find out what the passwords for your users are.

This file is not accessible for any “non root” account in Sephia Five, which further reduces the risk of having passwords spread out in the wild. Many software vendors will simply create a “users” table in their database. This implies that every single user that has access to execute SQL queries towards your database, has access to also your authentication and authorisation database. In Phosphorus Five, the user objects, are stored outside of the actual database. This implies that even if an adversary could get physical access to the database, he would still not have access to any credentials for its users. This is “yet another layer of defensive coding”, created with the assumption of that “everything that can go wrong, will go wrong”. When you add that fact on top of that the passwords are stored as salted hash values, it becomes almost entirely impossible, even on a theoretic level, for an adversary to gain access to passwords that belongs to your users, without applying social engineering.

We are also working on further tightening this area of P5 constantly.

Virus protection

A friend of mine told me that my “100% perfect virus protection” claim sounded too good to be true, so I thought I’d take the time to explain it, such that you can understand its technical details for yourself.

First of all, assuming you’ve guarded against the above problem; HTML injection – Virus is spread to a client exclusively by having a user download an attachment, which is able to execute code on the client. One of the most notorious type of attachments spreading virus, is actually (surprise) PDF documents, since the PDF format contains support for scripts. In fact, PDFs are according to a study I once saw somebody reference responsible for more than 50% of all malware on the internet! This means that an attachment that might otherwise seem to be innocent, can sometimes include malicious scripts, that compromises the client.

In Sephia Five we have fixed this, by allowing the sys-admin of an installation choose which attachments are legally allowed to be downloaded. This means that a sys-admin could allow only file types that cannot contain virus, not even in theory. There exists some few file formats that are considered to be 100% safe. Some examples are given below.

  • Most image formats such as .png, .jpeg and .gif, assuming your image library doesn’t have a buffer overflow bug
  • Plain text files, such as .txt
  • Most video formats, such as .wav and .ogg, assuming the same as with images

If you create your whitelist to only allow filetypes that are considered to be 100% safe, it is impossible for a user to download a file, that might potentially contain a virus, or some other malware. And you get “100% perfect malware and virus protection”.

Of course, this would for most practical concerns render Sephia Five very difficult to use, since for instance .pdf files would not be possible for your users to download. We have therefor created two such “whitelists” in Sephia Five. One which contains all safe file types, and another that contains all potentially dangerous file formats, which most users still would probably want to download none the less.

If a user tries to download a safe file, everything is all cozy and warm. If he tries to download a file that is on the “warning list”, he will be properly warned, hopefully resulting in that he thinks a couple of additional times, before he actually opens this attachment.

So even though Sephia Five is possible to configure such that it is indeed 100% perfect in regards to virus protection, such a configuration would probably be considered “too much” for most users, since it would not allow even pdf files, not to mention Microsoft Office files, etc. However, this doesn’t stop the user from configuring Sephia Five into such a configuration, which would basically imply that Sephia Five would have the same extreme security measures that were expected out of military grade email systems.

Hence, if somebody like the CIA, MI6, etc, where to install Sephia Five in their most top secret environments, I would not be surprised in fact. Simply since Sephia Five can easily be setup such that it indeed is a military grade email system, intended to run in top secret environments.

Phishing protection

Most security breaches today are variations of what is commonly referred to as “phishing”. For instance, I often get emails that apparently originates from PayPal, attempting to have me “verify my account”, or “upgrade my security”. Often these emails originates from domains such as “”.

In most other email systems, you wouldn’t even realise that these emails originates from a different domain, than that which you’d normally expect from emails coming from PayPal. This is because these URLs are rendered with anchor text, displaying stuff such as “”, actually leading you to “”.

Sephia Five will never display HTML emails. This means that a URL like the above, will reveal itself for what it actually is, and not be able to masquerade itself as something else. Implying that before the user clicks the URL, he can clearly see with his own eyes where the link will lead him, further reducing the possibility of that he’ll actually click it.

A lot of security breaches can easily be avoided, by revealing that which is hidden, and attempts to trick the mind of your users, into doing something they falsely believed would yield a different result, than that which it actually gives them. This is a mindset first and foremost, and a mindset that we have developed to the extreme!

No leaking business logic

There are never any “business logic” executed on the client. Most Ajax web apps of today, are built with lots of JavaScript, doing a lot of wiring, and often even business logic on the client. In Sephia Five, there is not as much as a single line of “business logic” JavaScript ever being executed on the client. This makes it literally impossible for an adversary to compromise a client, and such become capable of indirectly compromising the server, through the compromised client.

This means that all relevant data for usage of Sephia Five, is exclusively stored on the server, eliminating a whole range of problems, that would often surface in other systems, built with other types of architectures. This is due to the design of Phosphorus Five, and its concept of “Managed Ajax”.

RNG entropy

Literally every single famous last words on the planet is a variation of “I trusted it”. According to the maintainers at Bouncy Castle, which Sephia Five is using internally for all things related to PGP, their random number generator is rock solid. Bruce Schneier recently wrote a blog about this problem, where a group of adversaries, could predict when a slot machine would pay out its next winner – Simply because their random number generator was predictable.

When you deal with cryptography, random numbers are always a problem. If an adversary could predict the random numbers generated by a specific system, he could predict things such as for instance the creation of your PGP key pairs, etc.

We have fixed this, by adding to the entropy of Bouncy Castle whenever it is creating a PGP key pair, in such a way that two different systems, would never be, not even in theory, capable of creating the same random numbers. We do this by adding the server salt to the RNG as a “seed”, in addition to several other things, which all in all, adds an extreme amount of entropy to your RNG. However, in addition, when you create a PGP key pair, you can also explicitly seed it yourself, through the GUI, by adding any number of characters. This would not “set” the RNG’s seed, but rather “add” to it, and hence make it possible for you to create 100% perfectly unpredictable random numbers, making the process of “guessing” your key pairs configuration, literally impossible. Assuming the RNG in Bouncy Castle does not have some dubious bug though!

This is referred to as “defensive coding”, where you assume that “everything that might go wrong, will go wrong”. Hence, the art of security becomes to eliminate any potential places where things might go wrong.

PGP key pair strength

According to conventional knowledge in our industry, 1024 bits keys are not considered safe. 2048 keys are “probably” safe, and 4096 bits keys are “definitely safe”. In Sephia Five you could, if you wanted to, create PGP key pairs as strong as 8192 bits key strength. This is probably overkill, and way more than what’s necessary. However, in an extremely paranoid environment, “probably” doesn’t exist. As you create these extreme PGP key pairs, you can also provide your own RNG salt, which further eliminates an adversary’s ability to break your key pair. All in all, resulting in an extremely defensive environment, having some extreme security measures, allowing you to have an environment for your email communication, probably outperforming anything else out there in existence today!

Sephia Five is not identifiable

This might come as a surprise to my readers, but all attacks on a computer system, starts out with attempting to figure out what you’re dealing with. Hence, a simple logo, giving away the name of the system, is actually a potential security breach. Sephia Five does not even give away its name, not even in its GUI – And definitely no places in the data it transmits to other systems, such as when it sends an email.

Sephia Five will never identify itself when it sends an email, and even if an adversary physically bends over your shoulders, as you are reading your email at a coffee shop, he will understand what system he is dealing with. In fact, we also encourage all of our customers to never brag or tell anybody what email system they are using. Simply because if you do, you have reduced the potential candidate systems an adversary needs to investigate, and/or test for, down from a “gazillion” to _ONE_!

Facts are, nobody outside of your most trusted colleagues should know “jack shit” about anything within your organisation’s IT structure, including probably also most of your employees, since they simply don’t understand these risks. If you “brag” about your security, and its technical specification, you are unwillingly giving a potential adversary valuable information, which he can use to break into your system. This is true for not only email, but also every other aspect of your IT infrastructure.

Now of course, for us the situation is different, simply since we would want other developers to know as much as possible about Sephia Five, such that they could help us out, and find potential security breaches in it. But for you, the game is to never even let an adversary know where to even start looking!

Do me a favour, and check out this website, and/or other material from us, and see if you can find a single reference to our customers. Facts are, you will never find a “happy customer testimonial” on this website. Simply because it is a potential security breach. We encourage you to treat us the same way as we treat you, which is basically; Don’t say shit!

For the record

We also have other security counter measures, which we don’t publicly speak about, which are of non-technical character, intended to further reduce the possibility of a data breach. Hence …

Can you keep a secret? Me too, so fuck off! 😉

Some of these security measures are of a nature, that only allows for us to speak about them, in a one to one conversation with our customers. See below if this is of interest to you …


If you wish to use a configuration such as illustrated above, to create a security configuration, matching that of the CIA, MI6, etc – You would probably want to be extremely defensive when installing Sephia. Sephia Five is built on top of 3rd party libraries and components, some of who might contain security holes. Hence, if you’d like to go this route, I would for instance recommend you to not exposing the system to the internet, but rather install it on your local area network – In addition, to configuring the system much “tighter” than what would be feasible for most other users. This would also eliminate a whole slew of other potential user errors, such as people bringing out top secret material, in the form of simply being able to read their emails on their phones, while having adversaries simply peeping over their shoulders, etc. However, all in all, in an extremely defensive environment, Sephia Five could easily perform within “MK-Ultra requirements”, if it was being setup by an extremely skilled sys-admin, to perform to the point which you would expect out of even the most heavily secured systems, intended to run in extremely top secret environments.

In the end though, no system is more secure than its weakest link – Which is almost always humans. For instance, a whole range of problems might arise simply by the way you’ve configured your MySQL database, and Apache – Which is completely out of our control when you simply download it yourself, and install it on your own server. If you’d like to be extremely defensive in these regards, and make sure your system is correctly configured, we do provide help with this for professional customers, wanting to ensure their security and privacy.

We also provide training of staff and employees, which in the end, regardless of how secure your IT infrastructure is, becomes the defining factor of how secure your organisation actually is! All we ask of you, is to give us a simple declaration of good faith, such that we can be certain of that we don’t get in trouble by helping you! We provide security services and products, at a level previously unseen in the commercial market, which creates a situation for us, where we need additional compliance in order to make sure we do not break international law!

If you’d like to hear more about our offerings in these regards, feel free to toss us an email using the form below.

ProtonMail and Sephia Five, a comparison

ProtonMail was the first main stream available cryptographically secured Open Source webmail system, that became popular amongst the common population, and was practical in usage for the masses. Andy Yen, one of its founders, even held a TED speech about it in 2015. Since I predict that a lot of potential users of Sephia Five will argue that “ProtonMail already exists, what’s the point with Sephia Five” – I thought I’d create a comparison between the two, to illustrate why I think Sephia Five definitely has the right to live.

First of all, I must say that I am fundamentally in agreement with Andy Yen, and I too believe that privacy is the number one issue in the 21st Century. I sincerely hope that ProtonMail succeeds, and helps us reinstate privacy among the general population of the Earth. Me and Andy’s visions are almost perfectly aligned in such a regard. I admire Andy and his colleagues for what they have done, and I wish them all the best!

When that is said, I thought I’d illustrate the difference, such that people can weigh the systems neutrally up against each other, and help make an informed decision. Below I have created a comparison between the two, on a point to point basis, illustrating the value proposition of Sephia Five, compared to that of ProtonMail.

Server side versus client side cryptography

Andy Yen argues that cryptography shouldn’t occur on the server, but rather on the client. This is based upon the assumption that the server is not owned by the end user, and/or entity that needs cryptographically secured email systems. In a “Google and GMail world”, he is right. However, web servers are becoming cheaper every day, and in fact, you could easily convert a 10 year old laptop, into becoming a personal web server, and have it run blistering fast today. And with cheaper and faster internet connections being delivered by our ISPs every day, setting up a “home server”, over a plain home internet connection, would only require a fixed IP address, which most ISPs would be willing to give you for less than $5 today. Hence, the argument is (almost) mute.

This would allow you to create a private web server, which you could put in your home, expose to the web, and use to access your email using any device, from anywhere in the world. This means that your private PGP keys would be much safer, since you wouldn’t have to put them on every device you use to read your email. This would increase the availability, without increasing the attack surface. Arguably, this is more difficult than to simply register at ProtonMail’s website, and start using it – However, that will soon also be a mute point, since creating a secured Linux web server, becomes increasingly easier for every day that passes, thx to among others Ubuntu.

Besides, JavaScript is notoriously infamous for security holes, and hence the probability of that a private PGP key could be compromised when stored on the client, is much larger than if you had your private PGP key on the server, never allowing access to it from the client.

With Sephia Five your private PGP key is probably orders of magnitudes more safe, than with ProtonMail – Sorry Andy …

Searching emails would also be more difficult, since the server won’t know the contents of the emails, and if you wanted to perform a search of every email you have in your inbox, you’d have to download every email to the client, decrypt it, and then perform a search. Needless to say, but this would literally explode your bandwidth consumption. On a server based key solution, you could simply decrypt the email once when it is received, store it in your database, which is secured on your server, and run a simple SQL when you want to search through your existing emails. I must admit that I don’t know how ProtonMail have solved this, but the search problem, is definitely a hard one for them I would assume.

Hence, the usability of a webmail system based upon client based private PGP keys, would highly likely significantly decrease, if you’re only allowing for decryption on the client side.

In addition, I would assume that a server side C# written PGP decryption library, would probably be able to encrypt and decrypt an email, several orders of magnitudes faster. Not to mention, it wouldn’t have to download any attachments in these encrypted emails to the clients, before the user explicitly requested them. Please feel free to correct me if I am wrong here though …

Business model

Sorry, but I cannot see ProtonMail’s business model. Either they have none, or I am simply too dumb to understand it. Sephia Five has what I feel is a very strong business model, which is based upon the needs of corporations for securing their email. This allows me to have corporations “pay for the fun”, while letting the people in general enjoy the benefits. Simply put, because our business model is to deliver additional addon services and products, which only would make sense for corporations and professional consumers, and charge for these. While allowing the general public reap the benefits by being allowed to use the core of Sephia Five for free.

This gives us the best of two worlds, where we would (hopefully) be able to create a community of devoted individuals, help us maintain and develop the system – While at the same time, allowing companies to reap the benefits, creating a symbiosis between the corporate world, and the home world. While ProtonMail would (probably) not be of interest to corporations, since paradoxically, these corporations would highly unlikely allow a cryptographically secured email system to be used in their organisations, which would not permit the management to have access to the emails of their employees.

The last point is crucial, since with ProtonMail, the decryption would occur on the client (correct me if I am wrong) – Which would not permit the employer to have access to emails sent by their employers. After all, when you use your corporate email address to send out emails, you are using the property of your employer – And the data you send in these emails, are ipso facto the property of your employer. In such a regard, ProtonMail would probably be useless for most companies, I would assume …

Arguably, the lack of business model, would I believe, makes ProtonMail into a fad, unless they’re able to pull a “WikiPedia” model out of their sleeves somehow …


This is probably the point where Sephia Five would come out as loosing. It is obviously easier to create a username and password over at ProtonMail’s website, create a private PGP key pair in JavaScript, and start sending and receiving emails – Than it is to setup your own web server, and install Sephia Five.

However, this is also Sephia Five’s main selling point, since we actually charge for helping companies and corporations setup their own servers. Hence, what seems to be the losing point for Sephia, is actually what ensures we have a business model, and are able to sustain further development, by making money doing what we love! Which is the one thing we have in common with the guys behind ProtonMail.

Privacy matter!!

Addendum; For the record, ProtonMail’s main selling point seems to be that they’re located in Switzerland. With Sephia Five you could install your server, and host your data where ever you wish. Including Switzerland, Bangladesh or the Bahamas for that matter …

Sorry Andy, we won that last one … 😉

Yet again, I wish ProtonMail good luck, and would like to finish up with a personal encouragement to Andy and his guys over at ProtonMail.

Give em’ hell bro!!