• 2020-01-27

    Existential Threats

    The World Economic Forum, not an organization easy to rock the establishment, summarizes a speech by pundit Yuval Harari at this year’s meeting with the title “Read Yuval Harari’s blistering warning to Davos in full”. Choice quotes:

    Three problems pose existential challenges to our species …:

    • nuclear war,
    • ecological collapse and
    • technological disruption.

    Technology risks dividing the world into wealthy elites and exploited “data colonies”.

    Those who fail in the struggle against irrelevance would constitute a new “useless class” – people who are useless not from the viewpoint of their friends and family, but useless from the viewpoint of the economic and political system.

    … some corporations and governments will be able to systematically hack all the people. We humans should get used to the idea that we are no longer mysterious souls – we are now hackable animals.

    We are facing philosophical bankruptcy. The twin revolutions of infotech and biotech are now giving politicians the means to create heaven or hell, but the philosophers are having trouble conceptualizing what the new heaven and the new hell will look like.

    The global order is now like a house that everybody inhabits and nobody repairs. It can hold on for a few more years, but if we continue like this, it will collapse.

    Agree or disagree, go read the whole thing.

    Link to article

  • 2020-01-23

    100 Billion Tons of Materials a Year

    Add up all the stuff we, that is humany, take out of the ground, or harvest from nature, for a year. How much is it? Apparently, that amount just hit 100 Billion Tons. (Yes, it’s still rising.)

    How much is that? Assuming they are talking about a metric ton (other definitions of ton are not the same but similar):

    • 1 liter of water is 1kg
    • 1 cubic meter of water is 1 ton
    • 1 cubic kilometer of water is 1 billion tons
    • So we are talking about a volume that is 10 km long, 10 km wide, and 1 km high.

    That’s what we take from nature every year.

    (Yes, some things we take from the ground have higher density than water, like iron ore. Some are less, like oil or wood or many crops. But that won’t change the big picture.)

    10 km takes you two hours to walk. Walking around this block of material would take you 8 hours. And it’s 1 km high: about the height of El Capitan.

    Raise your hand if you think that’s sustainable.

    Link to Guardian article

  • 2020-01-16

    Union Square Ventures Has Started Working On The Climate Crisis

    Union Square Ventures announced in a blog post (below) this morning that they are now making investments to “fight the climate crisis” (“and earn returns for our limited partners”).

    Bravo!

    But it gets better. They have published their entire research slide deck on the subject that they have used internally to make their case to themselves. It talks about the major themes, trends, numbers and opportunities that they see! So as an entrepreneur in the space, you know exactly what they are thinking – good, bad, ugly, warts and all.

    Of course, you will look at the deck and nod in some places and think they missed the point completely in others. Which is the point! Everybody learns – as an entrepeneur, from these very smart people who have already done some work for you (I know from first-hand experience). And they will learn from you when you pitch to them and disagree with them, and nobody wastes much time on reiterating what all agree on already. I’m also fully expecting that they will update their slides as they learn, and acknowledge major influences on their thinking as they go, such as in their blogs.

    I wish more people practiced this. On the climate and on any other subject. Not just in VC.

  • 2020-01-15

    Comments and questions on the JLINC protocol for Information Sharing Agreements

    Updated 2020-01-24 with answers from Victor, slightly edited for formatting purposes. Thanks, =vg!

    My friends Victor and Jim at JLINC have published a set of technical documents that show how to implement “Information Sharing Agreements” – contractual agreements between two parties, where one party receives information, such as personal information, from the other party and commits to only use the received data in accordance with the agreement.

    This is basically a respectful, empowering form of today’s widespread, one-sided “I must consent to anything” click-through agreement every website forces us to sign. It’s respectful because:

    • it is negotiated, rather than unilaterally imposed as it is the default on the internet today;
    • the existence of the agreement, and which parties it binds, can be cryptographically proven by both parties;
    • there’s a full audit log on both sides, and so it would be difficult to “wiggle out of” the agreement;
    • it can’t be unilaterally changed after the fact, only terminated.

    So as I read through the documents, I had some questions, and as usual, I blog them :-) in random sequence. ~~~I will add answers to this post as I find out about them.~~~ Answers in-lined.

    • Q: Why is a separate DID method required? I don’t quite understand what is unique about JLINC DIDs that are forms of DIDs can’t do, too.

      • A: The W3C DID working group has specified a “common data model, a URL format, and a set of operations for DIDs, DID documents, and DID methods.” This by itself does nothing - individual DID methods conforming to this model then need to be specified and implemented. See here. There are various DID methods (including `did:jlinc``) listed in the DID method registry. We believe our method is better for -our- needs and use cases – and besides, we understand that one ;-)
    • Q: To create a JLINC DID, I need to post something to which URL? The spec says /register but doesn’t identify a hostname. Can it be any? Or is that intended to be a centralized service, perhaps run by JLINC, the company?

      • A: Anyone could read our public spec and create their own registry, but we have put up a testnet and made it available via an open source Node module](https://github.com/jlinclabs/jlinc-did-client). The example config file in the above repo contains the correct testnet URL. When we feel the W3C DID model has stabilized sufficiently we will make available a production-version public registry.
    • Q: How do the identifiers that the two parties use for the JLINC protocol relate to identifiers they may use for other types of interaction, e.g. some other protocols within in the decentralized / self-sovereign identity universe? Is a given user supposed to have a variety of them for different purposes?

      • A: This is a question that is being addressed by the W3C DID-resolver community group, in which we are participating. We will make available a JLINC DID resolver when that spec has been published. Every DID contains a (presumably registered) DID method as its second colon-separated value (e.g. “did:jlinc:SOME-UNIQUE-STRING”) so you will be able to resolve any DID whose method your resolver is configured for.
    • Q: Why is a ledger and its associated ledger provider required? (Actually, maybe it is optional. But the spec says “may submit it to a Ledger of their choice to establish non-repudiation”, so that implies the ledger is required for that purpose.)

      • A: Supporting audit ledgers is part of our plan but has not yet been implemented.
    • Q: There is already a previousId in each exchange. Wouldn’t that be sufficient for non-repudiation if the two parties keep their own records?

      • A: Theoretically yes, but a third-party audit record contemporaneous with each data-transfer event would guard against any nefarious record manipulation that might become possible if there should turn out to be some cryptographic weakness discovered.
    • Q: There is also the role of an “audit provider”. How is it different from a “ledger provider”? And if it is, why do we need both?

      • A: Those are two names for the same thing.
    • Q: Are, by virtue of the ledger, the Information Sharing Agreements themselves, essentially public or at least leaked to an uninvolved third party? Can I use JLINC to privately agree on an Information Sharing Agreement without telling others about it? If so, what functionality do I lose?

      • A: For most purposes we envision using Standard Information Sharing Agreements (SISAs) that are published publicly, and we are looking for a suitable standards body to work out a format for those and perhaps publish some useful ones, modeled along the lines of Creative Commons. But JLINC will work fine with any agreement, most likely identified with a content-addressed URL, but conceivably even a private legal agreement between two parties, identified only by its hash value.
    • Q: When an AgreementURI is used to merely point to the legal text that defines the agreement, rather than incorporating it into the exchanged JSON, would it make sense to also at least include a hash of the agreement text? That way, a party cannot so easily wiggle out of the agreement by causing the hoster of the agreement text to make modifications, or claim to have agreed to a different version of the agreement.

      • A: Yes, ISAs are always identified by their hashes, usually via a content-addressed URL like IPFS or some similar scheme that includes a hash of the content as part of the address.
    • Q: There’s a field descendedFrom in various examples, which isn’t documented and is always the text string null. What might that be for?

      • A: The JLINC protocol has been rapidly evolving as we build stuff and discover ambiguities and possible efficiencies in it. That field is obsolete.
    • Q: How would a permissionEvent work in practice? Wouldn’t that require the underlying legal text to change? Is there a description somewhere?

      • A: The ISA should specify that the data-custodian agrees and will respect the rights-holder’s choices as they are transmitted via permission events. Then each permission change event is transmitted under the existing ISA, same as with data events.
    • Q: Could one use JLINC to govern data that’s much longer, or much more complex, than the typical small set of name-value pairs used for user registration data on consumer websites? Can I use it, say, for the first chapter of my Great American Novel I am sending to a publisher, permitting them to only read it themselves but not publish it yet, or to send my MRIs to a new doctor?

      • A: Yes, absolutely.
    • Q: In a successful relationship between a Me and a B, to use the Me2B Alliance’s terminology, it appears that the “data kimono” is gradually opened by the Me to the B. For example, the Me may first visit a website without an account, then register (and provide their name and e-mail address) and a month later, buy something (which requires a shipping address and a credit card number, but only until the purchase is delivered and the data can be deleted again). In the JLINC world, does this require a different Information Sharing Agreement on each step? (particularly for the deletion after shipment?)

      • A: No – see the permissionEvent question above.
  • 2020-01-13

    Want to buy an aged Twitter account?

    From a spam e-mail:

    Aged Twitter 2009 to 2015 Accounts For Sale - check new thread for new prices

    The accounts are empty or with less than 50 followers.

    2008 - 10$ Per Account
    2009 - 9$ Per Account
    2010 - 8$ Per Account
    2011 - 7$ Per Account
    2012 - 6$ Per Account
    2013 - 5$ Per Account
    2014 - 4$ Per Account
    2015 - 3$ Per Account

    Assuming those accounts actually exist, I can think of some political maneuverers who would likely be interested. I’m a bit surprised at the prices.

  • 2020-01-13

    Downloading all your data and new security risks

    I’ve been playing around with the new data download features major on-line providers like Twitter, Facebook or Google have been forced to provide to us Californians since January 1, 2020, under the California Consumer Privacy Act.

    It’s amazing what kinds of data they have. For example, from the Facebook download I learned that dozens of car dealerships all over the country (like, say, in Texas, where I definitely have never gone car shopping) have my name and address. How – I have no idea.

    But speak about putting all your eggs in one basket. In Google’s case, a single ZIP file contains all your e-mail over a decade or more, your pictures, your private messages, your location history – everything you ever used any Google product for, and many things you never thought Google recorded about you.

    If this one file fell into the hands of somebody nefarious, you’d probably be in serious trouble – from possible financial fraud to blackmail on multiple levels, in particular in less-liberal countries, of which there are unfortunately more and more. The trouble would likely be much bigger than if somebody “merely” logged into your account: because all the info is there in one place, you don’t have to look for it, you can write scripts against it and immediately analyze it.

    As Andrew Carnegie, and then Mark Twain, said: “And Then Watch That Basket!”. The trouble is … do we? I mean … before I started jotting down this post, I don’t recall having seen a single discussion of this threat anywhere, and I usually pay attention to this kind of thing.

    It’s hard to secure that kind of access. To be sure, I’m all in favor of me and you being able to know every last bit of what big companies record about us, and get that data and use it somewhere else. But that power sure comes with a lot of potential dangers.

    I fully expect a wave of “GDPR” and “CCPA attacks” to occur, all focused on getting your full archive from major service providers and “monetizing” this in various ways, plus enabling whatever any secret police in some jurisdiction – and I use the word “juris diction” loosely here – can come up with.

    What’s the alternative? Well, those service providers not having all that data about me in the first place! Instead, they should only be “borrowing” it from me; well, the parts they need for something I agree to for as long as they actually need it. Then, no bulk upload or download is necessary, and we don’t have this high-risk security problem in the first place.