FredericJ

Just a quick warning though. A lot of those flights are not originating from the city or main airports. For instance, the "Brussels" flight they suggest taking is from an airport that is one hour away from Brussels (in Charleroi). It means that you will need to spend some more money to get to the city centres. These additional costs from "low cost" airports to the cities do add up to a significant amount on that entire itinerary. Just something to keep in mind.

If those kind of devices interest you, I'm quite intrigued by the IDQuantique ones that are based on quantum physics to generate randomness. They have a USB product that has a random stream of 4Mbits/sec and is used by lotteries and gambling sites.

http://www.idquantique.com/random-number-generation/quantis-...

It was originally going to be called "Whisper" (by Open Whisper Systems) ==> https://whispersystems.org/blog/a-whisper/

The name was changed after Whisper was launched https://whisper.sh/

This issue is intrinsic to the security model of Android before Marshmallow.

If an app is going to be able to send a contact, share a location, make a phone call ... all these permissions need to be demanded upfront, which I understand can be scary.

You also need to keep in mind that nobody is going to use "secure messaging" if it's a pain to use. You obviously don't want to be copy pasting contact information in the app for instance.

I'm glad to see that Android is following iOS's permission model where permissions are only asked at run time.

Isn't it ironic to see so much inline assembly while Apple is telling third party devs that they can't distribute binaries on WatchOS and that iOS apps are moving towards Bitcode too?

Apple's crypto people definitely know that assembly is key in performance and side-channel resistance of cryptographic implementations. They use it constantly. I guess at some point they will just ask 3rd party devs to call corecrypto methods if they want to use encryption in Bitcode apps.

But this means that you'll have to wait for Apple to implement whatever primitive you need for your app. Good enough in most cases but encryption apps with special needs will find this annoying.

Especially since a few implementations are actually borrowed from open-source projects. The 25519 implementations are from DJB's supercop for signing and Adam Langley's Donna for ECDH, both available online with open source licenses.

Important: The headline was modified since I submitted this. Apple didn't actually open-source the code. They give you a 90-day licence to read the code.

> Apple grants you, for a period of ninety days from the date you downloaded the Apple Software, a limited, non-exclusive, non-licensable license under Apple's copyrights in the Apple Software to make a reasonable number of copies of, compile and run the Apple Software internally within your organization only on devices and computers you own or control for the sole purpose of verifying the security characteristics and correct functioning of the Apple Software;...

In this specific case, DMCA doesn't apply. But it's interesting to read GitHub's policy about taking down forks.

> GitHub will not automatically disable forks when disabling a parent repository. This is because forks belong to different users, may have been altered in significant ways, and may be licensed or used in a different way that is protected by the fair-use doctrine. GitHub does not conduct any independent investigation into forks. We expect copyright owners to conduct that investigation and, if they believe that the forks are also infringing, expressly include forks in their takedown notice.

https://help.github.com/articles/dmca-takedown-policy/