giergirey

Does it not seem plausible to you that perhaps one factor in the reduction of poaching was local people realizing there was more money to be made from tourists drawn to see elephants, rather than from poaching them? Government action helped too, no doubt.

Perhaps everything comes around again once sufficient people have forgotten the lessons from last time - e.g. maybe the story from the South Sea Bubble in 1720 of "a company for carrying out an undertaking of great advantage, but nobody to know what it is" was an early SPAC ... https://en.wikipedia.org/wiki/South_Sea_Company#Quotations_p...

I think you're missing option 3, which is to avoid drawing a conclusion either way - assume that there's no definite answer, and that the experts' expertise is too narrow to support using their consensus outside small studies on college students buying and selling chocolate bars.

In this case I'm happy to conclude that it's not clear if people do systematically make poor judgements on important issues due to an in-built "loss aversion" heuristic.

I agree you probably won't see much benefit if most of your transactions involve cash-in-a-bank-account or coins on non-Ethereum chains.

However, if:

- Ethereum continues to grow; and

- we continue to see more and more successful/useful coins/tokens built on top of Ethereum (especially if asset-backed ones are accepted as payment);

Then we're going to see a lot more coin-coin transactions that /can/ be done on-chain - at which point a smart contract exchange is attractive (no counterparty risk, no fees, no waiting weeks for document verification, no limits).

Right now today it's possible for me and you to trade millions of dollars worth of tokens such as WINGS, BAT, USD.DC, GNO with each other on https://etherdelta.github.io or https://oasisdex.com/ (and soon https://ubitok.io/) - without needing to get verified or sign up, and only needing to trust that the exchange smart contract behaves as claimed (well, and that we're interacting with the right contract!).

If you don't see smart contracts / decentralised apps working well here, are there any problems where you do see them as being a good solution? A distributed exchange always seemed to me like a bit of a poster child for smart contracts ...

Yes, that's been my worry with many blockchain projects - it all sounds great until it needs to interface with the messy real-world.

But - regardless of the merits of this particular project - I think there is still some benefit in having a decentralised cryptocurrency exchange even if it doesn't totally eliminate the need for trust. Provided it reduces the scope of what needs to be trusted, or makes it easier to audit, or reduces how often it needs to be trusted, then that's still an improvement.

Suppose you want to sell some ethereum-based FOO tokens for US Dollars in your bank account.

Now, you could trust a centralised exchange to do the whole thing and hope they don't get hacked / run off with your money / steal your identity docs / take weeks to verify you / get shut down by regulators. And cough up the 0.25% fees.

Or, with a decentralised exchange, you can split your problem into two problems:

1. finding someone willing to exchange your Ethereum FOO token for an Ethereum tethered-USD token

2. finding someone willing to exchange Ethereum tethered-USD tokens for bank account USD.

Part 1 is purely Ethereum-based, and this is where competition should drive fees down to near-zero. Because a smart-contract can run this, there's almost no need to trust - this can be done on-chain.

Part 2 is where you have a point - there is still some trust required. But we don't need to trust the tethered-USD processor in Part 2 nearly as much as a full-fledged exchange - and they're easier to audit. There's also a lot less to go wrong - they're not dealing with lots of different crypto-currencies and networks, all they have to do is burn Ethereum tethered-USD tokens in exchange for real USD in a bank account. Fees should be lower, you'd hope.

Also, eventually we might get to the point where part 2 isn't needed - if you can spend tethered-USD tokens in enough places, why would you need banking-system-USD?

Disclaimer: I'm involved with the https://ubitok.io decentralised Ethereum exchange so I do have a bit of a vested interest in decentralised exchanges! Would love to hear some counter opinions though ..

OK, suppose you want to sell Litecoins for USD cash in a bank account.

Now, admittedly, it might be that today a one stop centralised exchange is the best choice for you.

But by introducing intermediate Ethereum based tokens, you've broken down the task into three parts, potentally allowing more competition for each part:

1. finding someone willing to exchange your Litecoins for an Ethereum tethered-LTC token

2. finding someone willing to exchange your Ethereum tethered-LTC token for an Ethereum tethered-USD token

3. finding someone willing to exchange Ethereum tethered-USD tokens for bank account USD.

Part 1 is purely crypto-currency-based (albeit on different chains), and so should have lower fees than anything involving fiat transactions. It's also free of exchange rate risk, so doesn't need a fully-fledged exchange - should be easy to automated and audit.

Part 2 is purely Ethereum-based, and this is where competition should drive fees down to near-zero. Because a smart-contract can run this, there's (potentially!) zero risk of the exchange being hacked / running off with your coins / taking weeks to verify you / being shut down by regulators.

Part 3 still involves the ugly movement from crypto to banking. But now it's just going from tethered-USD to USD - so for the processor there's no exchange rate risk, or need to deal with weird and wonderful cryptocurrency networks.

And perhaps one day you'll be able to live without Part 3 - you might start to find you can spend tethered-USD in more and more places without needing to go to a bank account ...

Disclaimer: I'm involved with the https://ubitok.io decentralised Ethereum exchange so I do have a bit of a vested interest in decentralised exchanges! Would love to hear some counter opinions though ...

Yes, https://etherdelta.github.io/ were way ahead of everyone else, if someone asks me for an example of an Ethereum contract that's solving a real world problem right now then they're the first one I think of.

It's a shame that Ethereum tokens are getting a bit of a bad reputation, because an exchange like EtherDelta coupled with asset-backed tokens could really open up all kinds of possibilities.

Disclaimer: I'm involved with https://ubitok.io which are similar to EtherDelta (but /totally/ on-chain, no off-chain matching engine needed!)

Yes, I also think exchanging tokens is one of the (few?) situations where a smart contract really is a great solution to a real world problem (as opposed to blockchain hype).

Definitely an interesting area, I've been watching this space, here's some interesting ones:

On the tethered tokens side, https://decentralizedcapital.com seem to be offering tethered tokens backed by real currencies (and cryptocurrencies on other chains). Not heard much about them though.

Implementing full exchange matching rules is pushing at the limit of what's possible in an Ethereum smart contract - https://ubitok.io are working on it (disclaimer: I'm involved with them!).

As others have mentioned, https://etherdelta.github.io is one of the better known decentralised token exchanges - though they do use an off-chain matching engine so it's not totally on-chain.

https://oasisdex.com have gone the other way - they're 100% on-chain, but they don't try to do best execution / automated matching - you have to pick an order to trade with.

Perhaps that's kind of a limitation of the way Citus shards data across nodes - sometimes you have to denormalize a bit so it "knows" where a row should live?

(I mean, I guess you could imagine a system that followed the foreign key to todo_lists when you insert a todo_item to figure out which node it belongs in, but that seems tricky and/or slow ...)

Relative deprivation certainly seems a better explanation than requiring some mysterious "fundamental universal rights" that people never knew they had until 18th Century Westerners discovered them. Maybe they're a bit like "souls" for atheists?

adding unnecessary jewels definitely used to be a thing up until the 1970s - see e.g. https://en.wikipedia.org/wiki/Mechanical_watch#.27Jewel_infl...

If andai is just connecting a full-function laptop to the internet with some ethernet-over-audio bridge, then you're right.

But don't you think he has a point if he's talking about a simple, single-purpose device like an arduino - say - that can't connect to the internet, but allows keyboard entry of plaintext, then encrypts it, sends ciphertext to a PC via audio?

I which case I think there are some advantages in using audio; if the device used wifi / ethernet / USB then you have to trust a lot of code to be exploit free:

- ethernet driver code - wifi chip firmware - kernel network code - USB drivers etc

Whereas if he's written his own simple bytes-to-audio converter in a few hundred lines of code that can be audited, then I can be be more easily convinced that it's not possible for an adversary to remotely install a keylogger or extract keys from my little encryption device.

Another interesting similar idea - http://what3words.com/ .

One more personalisation data-point ... I get the Ping Pong Dim Sum restaurant chain as my top result when I google for ping pong! Not entirely unreasonable since I am in London where their restaurants are located and I do eat dim sum more often than I play table tennis ...

The television delay for "live" sports seems to be surprisingly high (and has got worse since the advent of digital TV); we're talking 5-10 seconds here. Probably even more for streaming video.

Where do you draw the line? Some retail investors still rely on reading stock quotes in the financial section of their daily newspaper - should we force everyone to only change prices once a day?

Odd - if I go to https://support.coinbase.com/customer/portal/emails/new I get an untrusted connection warning since the SSL certificate is for *.desk.com, not support.coinbase.com.

Here's one security concern - What procedure do you follow when accepting files for inclusion in jsdelivr?

I mean, what's to stop this scenario: 1. attacker uploads a poisoned version (say, with an XSS vulnerability) of a popular library to an official-sounding github repo 2. attacker raises a github issue with you asking you to put it on jsdelivr 3. you assume the attacker is a legitimate contributor or user of the library and add it to jsdelivr 4. other sites start using the poisoned version of the library 5. attacker can now carry out XSS attacks on the sites using the library

I have another security concern about www.jsdelivr.com (which I hope is totally separate from the CDN?) but I'll email that to you.

Are you including the time taken to make the parser produce helpful error messages? That always seems like the hard bit to me ...

It is an exciting idea but the two obstacles I can see are:

1) When asked, people may say they want security and privacy - but in practice convenience and functionality win.

2) Among people who genuinely need secure communications, encrypting the content of calls/texts is good, but isn't normally sufficient - they're still vulnerable to traffic analysis.

By traffic analysis I mean that even though the adversary can't read the content, they can still figure out things like:

"Mr X is the ring-leader of the freedom fighters since his phone is used to send encrypted messages to several other phones, which then send messages on to several other phones."

"Mr Y is guilty of orchestrating the protests since we saw a strong correlation between the times of the protests and messages coming from his phone."

So I'm not sure how popular the product would actually be. Unless we can somehow solve the traffic analysis problem.

You're probably right about what's involved in building a truly secure smartphone from scratch that we can trust.

It's an interesting thought experiment, but I wonder if we can satisfy many use cases without having to build a truly secure smartphone.

For example, if I just want to have voice calls to a handful of people with the content of the calls encrypted, then perhaps I can just plug in a "scrambler box" between my untrusted off-the-shelf phone and my audio headset?

So rather than designing a secure phone where we trust the wifi stack, the baseband stack, the bluetooth stack, the graphics stack, the USB stack, the flash storage stack because we've designed them from scratch, all we have to design is a little scrambler box that just has audio in, audio out, some mechanism for key generation and exchange, and only needs a laughably modest CPU to do the encryption.

Don't really need an OS at all - single process and static memory allocation should suffice.

The audio encoding/decoding and encryption/decryption don't sound too hard to implement from scratch. It's the interoperability with the rest of the world and the UI that makes implementing a whole smartphone so hard.

[I do wonder though how well our scrambled audio will make it through the phone network which is applying lots of clever compression designed for speech.]

If we assume we can mostly trust hardware designs that are at least 30 years old then we can probably avoid designing all the hardware from scratch - e.g. there's probably some sort of Z80 clone CPU we can copy.

The mechanism for key generation and management sounds a bit tricky though. The user would need some way to add his contacts' keys to his scrambler box.

A keyboard and LCD display to type keys in by hand would be secure but impractical for long keys.

The level of tech needed to read a key file from a FAT filing system on a USB stick might be too high to be easily implemented securely. Any ideas?

I'm aware of the famous "trusting trust" paper, but I'm not sure we need to worry too much about the compiler used to build the software running on our scrambler box. All we need to do is choose a compiler released before we started out project and never upgrade it. It is hard to imagine a compiler backdoor that would automatically recognize that the intent of our code is to encrypt data and undetectably comprise it (though it would be wise I guess to avoid any existing implementations of cryptographic primitives).

Sounds like a hardware kickstarter project :)

Pedant's note: Contrary to popular belief, witch hunts were rare in the Middle Ages. They took off in popularity during the Renaissance.

One thing the (otherwise thorough) article doesn't mention is whether to provide a machine-readable schema for the API or not. Some integrators do seem fond of being able to generate stub client code automatically ...

I agree - whenever interview processes come up, commenters mostly criticise the interview processes for excluding good candidates.

But that's only one part of the equation - the number of unsuitable candidates that slip through is normally more important.

Suppose that somehow we magically know that 20% of candidates would be good hires - and the other 80% are unsuitable. But we don't know which are which!

As an interviewer, I'd be very happy with an interview process that discards 50% of the good candidates and 99% of the unsuitable candidates, because that leaves me with 10 good hires and 1 unsuitable hire for every 100 candidates.

On the other hand, if a different interview process discarded 20% of the good candidates and 80% of the unsuitable candidates, that would result in 16 good hires and 16 unsuitable hires - which would be disastrous!

Even from the point of the interviewee, one probably wouldn't want to work somewhere where 50% of your colleagues are not suited to their jobs!

Summary - it's a shame to discard good candidates, but it's worse to let too many unsuitable candidates slip through ...

I agree, it would be good to see Google setting the trend here by going HTTPS everywhere. Personally I think the next website I create will be all-HTTPS.

The main reasons I encounter for not going HTTPS everywhere are:

1) Possible negative effect on search engine ranking during transition period.

2) 3rd party content from analytics tools and advert networks not supporting HTTPS.

3) Slower initial page load over mobile due to SSL handshake.

4) No-one else is doing it.

Hopefully these reasons will become less valid over time!

Are you sure that the Google authentication token(s) sent over HTTP can actually be used to perform sensitive actions (e.g. reading/sending mail, changing settings)?

That is, perhaps Google require an HTTPS-only token for sensitive actions and the authentication token sent over HTTP is only used for basic personalization (like showing your username) and some unimportant actions?

Though I guess we know that someone who has stolen your HTTP authentication token could ask embarrassing baraza questions on your behalf ...

I rather like this quote attributed to Carl Sagan:

"They laughed at Columbus, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."

I think "Mail Boxes Etc" is probably our UK equivalent of UPS Stores. Amongst other things, they can do packaging and labelling and act as a broker across the various couriers. I've had good experiences with MBE but I've only used them to ship high value items internationally - I don't know how cost effective they are for other stuff. And obviously, they're still at the mercy of the couriers (though you can at least tell them which ones you want or don't want to use).

I was under the impression though that the 30-40 years average life expectancy is commonly misunderstood?

The mean life expectancy at birth might well have been 35 years but that's dragged down by massive infant and child mortality in the first 5 years of life - if you made it to adulthood, you had a reasonable chance of making it to 60.

I'm not sure claims about a topic such as happiness can ever be "indisputably" true.

Would you not even entertain the possibility that your "median inhabitant 1000 years ago" was actually quite happy with her unvaried subsistence diet, since it was a little bit more varied than her that of her poorer neighbour, and not much less varied than her much richer cousin's?

I doubt he would feel unhappy or unfulfilled for being illiterate - in his sphere of existence, what would he have read? To whom would he have written? Do you feel constantly unfulfilled though being unable to communicate with dolphins, or through being unable to interpret Tibetan Prayer Flags, or (perhaps more topically) through not regularly listening to oral poetry passed down from bard to bard? I suspect not - because you have no expectation of being able to do these things.