It doesn't mean the «energy efficiency» rating is wrongfully stated, the statement is true, regarding electrical efficiency of the device, yet the cold produced by the device is not delivered to your house as you might think. It is split unevenly between your house and the Earth's atmosphere, where less than 1/2 is delivered to you, all the rest surprisingly enough is dumped into the atmosphere, no matter how many «pluses» they print on the energy efficiency label.

Forget about «A++++» — let's do some elementary physics

This beautiful picture is not true. Well, technically it is not entirely untrue, in absolutely dry air this picture is true, for example in Atacama desert or on Mars, but chances are the atmosphere of your house contains plenty of water, which is not mentioned on the picture. When your air conditioner cools air down it cools ALL components, of which the significant part is water vapour. The water vapour concentration is limited by the air temperature, lower the temperature lower is the maximum possible water content. That creates the dew point phenomenon. If you drop the air temperature below a certain level water condenses out, and your air conditioner heat exchanger operates most certainly below the dew point, this is why water comes out from the device. ...And goes straight outdoors carrying the cold produced on your expense to the earth atmosphere. So that the correct scheme should look like this:

Please, stop chanting «A+++++»

Even if we assume 100% efficiency of the device, it simply DISPOSES OF a significant part of its END PRODUCT. Now, let's us estimate how much significant is it.

Let's assume you want to cool a room down to comfortable 24 C, in a hot day (37 c, with 68% humidity, which is a typical July day in my home town).

Thus the air initially contains 0.03 kg of water per m^3.
If we now generously assume that the air pump operates at 11 C then we only need to cool 1/2 of the room volume in order to reach 24 C. It means that the heat exchanger produces 100% humid air at 11 C, which contains 0.01 kg of water per m^3.

Thus, the heat exchanger dumps 0.02 kg of cool water per m^3 of air.
Vaporization heat of water is 2257 kJ/kg, therefore your air conditioner dumps 0.02*2257 = 45.14 kJ/m^3
Let's see how big is this number.

Specific Heat capacity of humid air in our context is about 1.034 kJ/kg/K (with insignificant variation for such a rough calculation) and the density is about 1.2 kg/m^3. Thus the «consumer value» (pardon my language) of the air conditioning is roughly: 1.034*(37-24)*1.2 = 16.13 kJ/m^3

While the actually produced work consists of cooling half of the given amount of air from 37 to 11 C plus condensing water, which amounts to: (1.034*(37-11)*1.2 + 45.14)/2 = 38.7 kJ/m^3

Finally the ratio is: 16.13 / 38.7 = 0.42 — i.e. roughly 58% of the cold produced by your air conditioner goes straight outdoors.

Of course, it is a very rough estimation, but it gives you the order of magnitude of the phenomenon. Although I tried to give a conservative estimation, feel free to directly measure your air conditioner water output in order to get the precise number — I bet it will be even worse than «60%» stated in the title.

This loss does only seem inevitable!

The sad part is that this energy is completely recyclable for no cost — all you need to do is to vaporize this water on the heat exchanger of the condenser unit — BUT NOBODY CARES.

I often hear that randomness brings luck (therefore, unfair advantage for a weaker player) in a game. This idea is so strong and deep rooted in a general public that the words «luck», «randomness», «uncertainty» are often treated like interchangeable synonyms in discussions of game properties. Many people consider a game with a randomizer to be a low-grade push-your-luck childish trifle. I want to show you how wrong this judgment is.
Read more →

I decided to join flattr.com — a very neat donation platform. Isn't it reasonable to donate some money to the authors you like? Would it motivate you to donate if it leads to the elimination of ads? At least we can run this simple experiment. You are reading me (I know you do), and you are taking for granted the complete absence of ads on this clean and concise website. Please, consider making a flattr donation of any size if any article amused you. If it works sufficiently well to keep me from starvation, then ads will never appear on ithipster.com

Today I want to talk about ecology, in a very unorthodox manner, as I always do with any subject. There is one very necessary practice in the metallurgy all over the world: slag dumping. Of course, our cherished environmentalist buzz-makers know nothing about that, because steel and copper, just like coffee and croissants, grow on trees. And it is much better to keep them at their present state of ignorance, as long as we want a serious, intelligent, and productive discussion on the topic.

First of all, there is nothing wrong with the metallurgy in general and the slag in particular. However, there is some room for a significant improvement that benefits our «environment», unlike bullshit «carbon taxes» or «wind turbines». In order to understand the basics of the problem watch any of the «slag dump» videos on youtube, like this one www.youtube.com/watch?v=zKOENNXsSBQ This «molten lava» is slag, an inevitable byproduct of any metallurgical process. It has no use in the industry, it contains no precious components, and it has to be removed from furnaces, in order to keep them running.

The first thing that must strike you as you see the action is: «what a waste of energy!!!» Indeed, slag is hellishly hot, where «hot» means two important properties: abundant and high potential, which makes the energy easily CONVERTIBLE. But, hold on, this shit is solid under normal conditions. When you extract energy from molten slag it will solidify, incapacitating any conceivable heat exchanger.

Let's apply some IT reasoning here. While it is difficult to take energy away, how about taking an energy consumer in? Picture that, you have to heat something, so you mix it into hot slag. The output will very likely to be total garbage… Yes! GARBAGE! Put garbage in, melt it by the heat contained in the slag, and then shape it in building bricks, or fillers, or whatever you need to build artificial islands…

In the end you get a pretty normal solid waste processing plant running on free energy.

Once I stated the title I immediately realized that there are many distinct dimensions having their own «bottoms» and «ups». So I must specify. The «bottom» is a set of elementary data manipulation operations available to you as a programmer or a data security specialist (although it is often the same «you»). The «top» is a transitive closure of this set. The set of operations available for a user is rather close to the «top», and mapping them into the basic data handling operations constitutes the essence of the programmer's job. The «bottom-up» approach to data security is a job of defining all the necessary data access rules in terms of the basic data handling operations — you apply certain restrictions to various data elements and they affect the data system overall behavior, namely data accessibility in the high-level terms used by the end users. The most elaborated text-book example of this approach is SQL — it gives you very low-level security bricks to build a custom building without specifying explicitly this building emergent properties.
Read more →

Assume you are a technically savvy person who knows the basics. You never install random crap from the internet. A typical phishing email makes you laugh, you almost pity the mankind which can be fooled by scammers as silly as those. Your phone screen is locked by default, and you use a password manager.

In multiple ways (sometimes inevitable, oftentimes obscure and cryptic) you depend on things (software, data, hardware) you do not own nor control locally (unless you are extremely paranoid and have accepted huge operational overhead). And I do not mean continuously bleeding “digital trail” of metadata and behavioural tracking. Let’s talk about a risk of being really hacked.

Understand (and prioritize) your assets

You obviously give the top priority to your bank accounts and launch codes, but some other things might be more expensive than you imagine at a first glance.
«There is nothing secret and I have all that information elsewhere» might lead you, in case of a loss event, spending a whole weekend handpicking it from… from said «elsewhere», and sorting everything in the precise OCDish way it use to be. Some other things may be of sentimental value and little interest to anyone but you certainly do not want everyone to see it (and you are likely underestimating the importance of your feelings, until said «everyone» see those files). You better archive all conversations with your ex-es and don't leave it hanging in your chat history (which would not help much unless other parties do the same). Ah, and, if you own some cryptocurrency, I hope you keep it on a local wallet, otherwise you do not really own it.

Understand (and prioritize) your attack surface.

A computer is not that unsafe unless you physically lose it (while having no disk encryption in place) or forgot (you did not, right?) to remove Adobe Flash from your system. If you adopted a good habit to handle MS Office and PDF documents with web-based services (as long as the content of said documents are not secret) you further improve the overall security of your local system.

Thus, your chances to get hacked via a 0day exploit (unless you do really store actual launch codes on your computer) are negligible.

Portable devices, I mean iOS and Android… Really, you cannot be serious. Android malware? Which requires your consent, like, three times to run, (ok, or just one if you have a system which is 5 years old with unpatched security bugs)? Again, your worst-case scenario always implies someone getting your device in physical possession.

Third party services (I want to avoid using the word “cloud” because the worst things aren’t even cloud, see below) are your only real concern. It is something completely outside of your control. It is not necessarily bad, but they may be vastly distributed, prone to breaches, accidental social engineering attacks and all those factors are unpredictable. To add insult to injury, they often actively encourage, just a little bit short of enforcing, “questionable" security practices. So the rest of the essay will be dedicated to them.

Build dependency graphs and rebuild it wisely

Here the hell begins. Common consensus dictates that the general public is totally incapable of managing their own access credentials without either losing access or leaking it to a malicious entity. Thus said, it all revolves around "recovery methods" which make your access credentials tightly interdependent and susceptible to a cascade failure unless you take special care of that. Let's do a simple dissection.

Worst of all is your phone number used for verification. Because the phone number is something you do not actually own in any way. Even the SIM card is legally the property of the cellular operator which provided it to you for lease (just like your bank card is). You do not own the number, you do not even own the network authentication key (try to reprogram or extract it!). As a practical consequence, not to mention slightly more complicated SS7 attacks, any cellular operator employee may issue a replacement SIM card on your behalf to anyone looking credible enough to them.

The funniest part is it is the sole ultimate trusted method for many services, including some banks, instant messengers and — Facebook. On Facebook, you cannot deny it from providing SMS recovery codes unless you remove the phone number from the system completely. Google is a bit less persistent, it just keeps whining about how insecure it is not to have an SMS recovery option (UPD: no, you need to remove the phone number there, too).

Then there are email accounts. You may have multiple ones, you may consider different threat models which would either convince you to stay on Gmail (at least it is really hard to divert anything in transit there) or to use your own mail server (think BGP hijacks, domain hijacks, and all that nasty stuff, email is generally not designed to be very secure). Anyway, once one of your critical email accounts gets compromised, things can get very nasty. It is one more «recovery method» you often cannot simply turn off (and in most cases, you do not really want to).

There are social network logins. Not to mention the direct problems you would have, many services would let you in on email/phone match without additional checks. Say, if you log into Booking.com with Facebook, you do not provide any authorization on the Booking.com side to recognize your Facebook login: you just let Facebook share your email and phone number and you are instantly connected.

Security questions should be, without any doubt, nominated for one of humanity’s stupidest inventions. Just imagine how attractive would it be to give up access to your account to any person who happens to find out some trivial fact about you. Especially one of those facts you can find in a public database. Yet you can suppress your disgust and treat it as usual recovery codes. Make sure you use a decent random string generator. You may use questions that are really private — but they are non-reusable and you should keep that in mind.

To minimize dependencies and maximize security, you need to turn off all unnecessary recovery options (especially phone numbers), turn on a second factor (one-time passwords, definitely not SMS!), and generate recovery codes and store them in a safe place. Offline and on a hardcopy, preferably.

It does not guarantee anything. Security models for most of the services are incredibly stupid, because they are ad hoc and lack consistency from ground up. I designed a better one for a customer a while ago: it was simple as that:

* every authentication factor that is not under the direct control of the user is considered insecure
* no combination of insecure authentication factors may be ever treated as secure
* recovery procedures that rely on insecure factors should be implemented with extreme caution.

Is it hard to understand or hard to implement? No. Does it impair user experience? Unlikely. Yet it does not scale well enough for services with billions of customers, unfortunately for them. Therefore, when you accept Google or Facebook policy, you are solving their problem on your own expense.

Have a contingency plan

There are no silver bullets, and my advice are not panacea. Anything can fail. Be prepared.

Some useful links:
On second factor: ithipster.com/blog/unorthodox/34.html
On NIST warning not to use SMS: www.theregister.co.uk/2016/12/06/2fa_missed_warning/
On cascade failures in authentication: https://www.cs.uic.edu/~polakis/papers/sso-usenix18.pdf

One more hopeless rant I was engaged in, like, for last 20 years or more. What is totally broken, however, is UX decisions that mark them «evil». Self-signed TLS certificates possess no more intrinsic evil qualities than your beloved ssh and gpg keys.

The intent behind ostracising self-signed certificates is noble: everybody should do… should be forced to do things the one proper way: for intranet you should deploy our own private root CA and distribute its certificate to all the clients, for internet there are affordable solutions like letsencrypt to save you from calamities of certificate management and huge expenses.

Yet it is nothing but wishful thinking and thus is rotten to the root. Every, I repeat, every single company network I ever seen (with a few exceptions that qualify as hobbyist projects) had tons and tons of self-signed stuff, regardless if they had internal CA or not. Most of it was just «temporary» yet you know most permanent things are those «temporary» ones. Smaller companies just do not have an internal CA at all.

(I intentionally leave out the question if it is always a good idea to get a «trusted third party» involved, and, moreover, to give infinite total trust to vast and vague amount of «third parties», for now at least)

We need to accept this situation, understand it and adapt accordingly. The pretty narrow vulnerability window for a self-signed certificate exists just for the very moment you engage into an «initial» contact with the resource (or when the certificate changes, which is quite uncommon scenario). If no evil actor intervened at this moment you are safe from now on; there are numerous scenarios where there is actually no need of any trusted third party. The same way it works with ssh (unless you deployed that complex set of scripts, you know). Oh, no. You would be safe, if that stupid broken UIs did not complicate things, distracting you with a flood of pointless warnings that never stops, effectively concealing the actual attack when it happens.

For now, however, we see a lot of totally unprotected resources susceptible to MITM attacks because you know, self-signed certificates were proclaimed evil and you should not use it anyway, mkay? And that's why nearly all small/home office wireless environments are contaminated with hideously misdesigned WPA2 PSK (until we have WPA3 on the horizon), because WPA2-enterprise requires complicated «certificate management» — you cannot just say «remember this access point» on the client and no vendor bothers to have a builtin Radius server on the wireless controller therefore.

Every time I add a self-signed certificate to Safari I get a scary dialog about «changing my trust settings» which always makes me doubt — did I just add a site certificate to the trust store? Or was it Honest Achmed's root CA that I granted with full permissions right now? With current workflow it is hard to tell.

Generator, simply, this is a function that returns the iterator. It's applicable in case of when you do not need to load all data in memory before processing or in cases when we can not receive all data at once or we generate it on the go. In some languages mainly used special keyword yield what returns some value until the next call of the next value from the iterator.

Let’s create the generator.

def gen(steps):
	for i in range(0, steps):
		yield i * i

The yield will generate something like this
Read more →

When the creators of golang were developing the architecture of the language they were caring out about developers which will use it in real work. One of the most important processes of development it's the testing, and they did it very convenient and easy to use as they use it themselves.

To create the test enough to declare ".go" file with "_test" postfix in the name. This file will be ignored by the compiler when you will assemble your application. When you run the test every module in the project «go» compile the module with "_test.go" files as independent application and run the test cases one by one.

Let's make simple GO test

First of all, we need what exactly will be to test.

// fact.go
package fact

func Fact(v int) int {
	switch {
	case v < 2:
		return 1
	case v == 2:
		return 2
	}
	return v * Fact(v-1)
}

Read more →

I prepared a few simple recommendations for you.

1. Do not rush to break your software and business, unless you are deep into advertisement or social profiling or your IT processes imply dumping every piece of data you have on an unprotected file server. If you are doing personal data processing for a legitimate business purpose in a reasonable manner, it is safe to assume you can stand your ground under any GDPR related scrutiny.

I know a retail company that ceased CCTV recording in all their warehouses. The hell broke loose, even before the theft. The company turned completely unable to find misplaced items. Why? Because there was a guy «responsible» for GDPR compliance who had authority to handle it that way. When anyone opposed him, his answer was simple: fines are huge, risks are high and is your advice to do otherwise backed with any willingness to cover possible non-compliance issues from your own pocket? Ah, you do not have enough money anyway, so get lost.

What this guy was essentially doing is covering his own ass on INSANELY HUGE company's expense. Don't do it. GDPR is not about ruining your business (unless your business is very questionable already).

2. Do not buy shit. GDPR fearmongering is a goldmine for people selling «compliance solutions». But the truth is, there is no «compliance solution» you can buy. Under this hot GDPR sauce you would only buy things you do neither need nor want to buy. Less creative «solution providers» will sell to you some firewall-antivirus-encryption stuff for twice the regular price. More creative ones will sell to you data intelligence and audit tools of the most expensive variety, that won't help you at all. GDPR is not about buying anything (unless you neglected your basics before).

3. Do not pay for any certification. Currently there is no GDPR certification, which literally means any certification you get is totally irrelevant for GDPR. The idea «there must be some checklists and papers, so it is worth to get your ISO27K or whatever until more specific requirements would be in place, because ISO27K is a default way to prove to everyone you are a good citizen» sounds appealing, but the appeal of the idea is in its deceptive psychological comfort and nothing more.

Of course it is not all that simple. Some minor organisational effort is still required — as described by countless howto's: remove everything you do not actually need (and stop gathering it «just in case»), get consent when appropriate and keep track on what you do both for yourself and for data subject.