Subject: Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Nov 2015 21:11:31 +1100

Hi George,

> I have a different perspective on this question Mark.
> 
> Firstly, I find use of .magic as the extreme RHS of a name, to force
> special behaviour architecturally disqueting.
> 
> I really do worry about what we think we're building when we encode this
> behaviour into name strings. It leads to all kinds of bad places. Some of
> them, like the homoglyph problems John Klensin has raised, simply don't
> have good answers (the assumption the string .onion is the literal ASCII
> 'o' 'n' 'i' 'o' 'n' is not well founded)

On the face of it, it sounds like that's a problem shared by any application of DNS names. 

> We were here a long time ago, when we had pre-Internet mail and used things
> like .UUCP as magic break-out signals in email. This rapidly becomes the
> problem: its bound to applications-level decisions about when to honour
> magic, and when not, and it certainly doesn't avoid lower level
> gethostbyname() calls everywhere. So the .magic label winds up being
> half-true, depending.

.onion was the chosen approach precisely because nothing else but lookup and subsequent routing has to change; there are no other application-level decisions about .onion, and that's a feature. HTTP still works, TLS still works (once you can get a cert), links still work, HTML still works. Same-origin policy still works. 

The one difference is that .onion asks that applications and resolvers not leak requests, to avoid privacy issues with misconfigured or misused clients. This is defence in depth, not a hard requirement (after all, .onion has been running for several years with the benefit of that requirement). 

This doesn't seem like "magic" to me, it's just fencing off part of the name space and asking others not to play there. 

> Secondly, While I think  I now understand some of the problems you have in
> web/apps layer (from talking to Wendy Seltzer) and I have sympathies about
> the syntactic constructs welded into code around URL forms, I think these
> problems are different to the architectural/layer violation explicit in
> forcing .magic names into the namespace.

"Architectural/layer violation" is not in and of itself a knock-down blow; what's important is whether the harm that's caused is greater than any other alternative approach available. I haven't seen much detail on that yet.

What is the actual harm, discounting aesthetics? I make that qualification because I very much acknowledge that this is messy. I don't yet see how it's creating technical problems, though. What you bring up is more akin to limitations of the approach -- limitations which the folks defining .onion chose to work within. Presumably, future approaches to distributed naming will make the same tradeoffs. 

> What really got me floored, was the qualities of cryptographic protection
> which a project like TOR needs, and the implication a public/commercial CA
> service embedded in the browser TA set is the right path. I'm frankly
> horrified, even under certificate pinning, that we've gone to a space where
> any TA can claim to sign over .onion, and excluding the pinned
> applications, lead people into paths where their assumptions of TLS backed
> security are simply not true.

Again, that's not unique to Tor and .onion; it's a problem shared by the whole Web. This is not new; it's unfortunately the result of many choices over the years, and there are many efforts to improve it (e.g., CT/TRANS, pinning, etc.). Considering what's happening over the "normal" Web (e.g., banking), that's just as bad, I'd say.

> As I understand things, TOR *wanted* .onion to get X509 PKI over the label
> in a browser, and the CA community refused unless its TLD status was
> confirmed. Is this the kind of rigour in technical process we expect, to
> make technical calls to pre-empt the namespace? (which btw, we passed
> otherwise to another body, reserving an RFC backed process to get names,
> but I think that was a hugely unwise decision)

Some would call this pragmatism. 

> To protect .onion certs, the TOR developers are going to have to code in
> cert pinning behaviour, all kinds of things, which frankly sound to me a
> lot like the cost of not having the name, or having a name buried under a
> 2LD instead.

Not necessarily. CT, pinning and similar approaches can help as well, and these are already getting deployed on the Web overall. Regardless, putting .onion into a 2LD doesn't help avoid these problems.

> So I come to a different place. I come to a place where requests for magic
> names look like violations of any spirit of an architectural view of the
> network, and where retaining some technical basis to reserve them looks
> like violations of the separation of functional roles between ICANN and
> IETF, absent very very clear, strong reasons to have the name held back.
> 
> I don't entirely see these reasons emerging. I see the opposite. I see
> expediency from apps communities, seeking to use .magic tricks to avoid
> cost explicitly in their layer, but at a cost of polluting the public
> commons.

What *exactly* is the cost? Everything you have brought up above (excepting "architecture") is regarding the potential impact upon applications -- impact that was considered and accepted by the people doing the registration of .onion. How does this affect DNS itself? 

And, are you really saying that anything that hasn't gone through ICANN is by definition "pollution"? 

Very thought-provoking analogy between Internet naming and enclosure there, BTW. 

> I am pretty firmly in the camp which says the revision of the RFC should be
> complete: we stop doing this, and people who want names go into ICANN
> process to establish them.

That's certainly a choice that can be made, but it seems pretty unilateral -- just as much as (for example) the W3C deciding that HTTP URLs in browsers don't always use DNS as a root of naming and setting up an overlay registry (as is seemingly already contemplated by the HTTP and URL specs). 

I'd hope that we could work together as a community to find some agreement here, rather than going straight to absolutist positions.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Philip Homburg <[email-masked]>
Date: Sun, 29 Nov 2015 13:22:08 +0100

>.onion was the chosen approach precisely because nothing else but lookup and s
>ubsequent routing has to change; there are no other application-level decision
>s about .onion, and that's a feature. HTTP still works, TLS still works (once 
>you can get a cert), links still work, HTML still works. Same-origin policy st
>ill works. 

Call me old-fashioned, but I think this is silly.

The purpose of the domain name system is to name things. We have IP
addresses and we want to refer to them using names. We do the same thing
with mail domains, etc.

In goes a name, out comes some lower level entity.

In this context an onion address should have been an 'IN ONION', i.e, 
www.example.com might have an 'IN ONION' address for use with TOR.

Now instead, .onion doesn't map to anything. In goes an onion address (and
not a name) out comes nothing. All, .onion does is signal a particular
transport protocol. 

So it is a clear abuse of the domain name system. It might be that it is the
best option. But my guess is that is was just the easiest hack to get it
working.

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 29 Nov 2015 12:38:18 +0000

> addresses and we want to refer to them using names. We do the same thing

That is not the sole purpose - we use DNS for keys, for time stamps,
for data of all kinds.

> www.example.com might have an 'IN ONION' address for use with TOR.

And that would also require special handling...

> not a name) out comes nothing. All, .onion does is signal a particular

The above is pretty much entirely false. It does map to things. It
does also do more than signal a transport protocol. It is also a
secure self authenticating name. The name is itself meaningful in a
global context.

> best option. But my guess is that is was just the easiest hack to get it

I'd hardly call all of this work easy but I hear your point.

All the best,
Jacob

---

From: Philip Homburg <[email-masked]>
Date: Sun, 29 Nov 2015 14:10:12 +0100

>That is not the sole purpose - we use DNS for keys, for time stamps,

In a well designed system, names are only used to name things.

>From the good old days, telnet and ftp are clear examples.
After looking up the name in DNS, you don't need the name anymore.
All you need are the addresses that were returned in the DNS lookup.

SSH with SSHFP also has that property. Lookup the SSH fingerprint in
the SSHFP record, lookup an address, connect, and verify the fingerprint.
No need for the name after the lookup.

(Storing other stuff in a naming system is not a problem, it is just a
big distributed database).

>From day one however, this principle was violated. SMTP does use the
domain name after the name lookup.

With the interduction of the http host header, http also violates this
principle. With the introduciton of SNI, TLS violates it.

However, SMTP, HTTP, and TLS have one in common, from the
network point of view, the name is not used for routing.

It is only later, at the application layer that the name is used again.

It is here that .onion goes one step further. Onion 'names' are derived from
public keys. So instead a name being independent of an address, the .onion
name is the address.

Unlike, TLS or SSH, where a network connection is set up and then the
crypto runs on top of it, in TOR this all integrated. For good reason,
however that make the .onion 'name' an address.

>And that would also require special handling...

Yes, but in a way that doesn't abuse the model.

If an 'IN ONION' would be stored on the host as a 'struct sockaddr_onion'
then all code can be cleanly adapted to support TOR hidden services.
Instead of adding pattern matching hacks to name resolution.

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 29 Nov 2015 13:50:39 +0000

Hi,

> In a well designed system, names are only used to name things.

I disagree, I think.

In a "well designed" system, a name is meaningful to different parties
differently. We can use it as a person's easy to remember name, or we
can use it to express a relationship, or we can use it to ensure that
related things are seen as related in a mathematical sense, or other
things or all of these things and then more.

I'm in favor of the DNS serving as a global petname system. When we
use DNS to exchange keys as a kind of hack, we're using it badly as a
petname system. We also do so without query privacy in most cases, so
we find ourselves having bad petname system and with terrible privacy
properties.

> All you need are the addresses that were returned in the DNS lookup.

Those are not protocols that do not provide confidentiality, integrity
or authenticity. They do not solve hard problems. Once they start to
solve harder problems, we start to see the problem with treating a
name as *just* an easy to remember string, which it isn't.

> big distributed database).

I think the idea that it is considered primarily a naming system is a
bit strange once you make the above concession. It is effectively a
government and corporate distributed database with almost no privacy
or security protections against those operating or monitoring the DNS.

> network point of view, the name is not used for routing.

The name in HTTP and SMTP are most certainly used for routing. It is
just a very weak, non-cryptographic routing. With TLS, it is a
stronger kind of cryptographic routing but still weak to an adversary
performing surveillance.

> public keys. So instead a name being independent of an address, the .onion

The name is not an address per se. It is a self-authenticating url -
this means you can prove that you're talking to who you intended to
speak with all along. It says nothing of the routing, except that you
are routed by public key and IP addresses are not as relevant. They're
still used in some cases but the system is designed to fail closed.

This is not exactly the same as the .onion name being an address. The
*publickey* is also not an address. In the Tor Hidden Service
protocol, we have descriptors and other things that are more akin to
the address. They change often and are authenticated by the public key
that you would expect to authenticate them. Those authenticated bits
are the address in my view.

> however that make the .onion 'name' an address.

It can be done in stages - transparent setups work differently from a
local Tor client, for example. A resover can be Tor enabled, as a
network, as a browser, etc.

I guess I have a hard time calling the name an address. It is a name
and it is a kind of name with security properties. See also Zooko's
triangle for what I mean - the normal DNS and self-authenticating
names are not the same mapping on Zooko's triangle.

> Yes, but in a way that doesn't abuse the model.

Perhaps.

> Instead of adding pattern matching hacks to name resolution.

I'm skeptical but I do look forward to you expanding on how this would
work with *less* work than our current approach. I'd also be curious
what work would need to be done and how it could be done in a way that
fails closed and does not harm the user's privacy.

Part of my motivation for this work comes from the following revelation:

  http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html

Specifically from the XKeyscore ruleset we published (
http://daserste.ndr.de/panorama/xkeyscorerules100.txt ):

// START_DEFINITION
requires grammar version 5
/**
 * Aggregate Tor hidden service addresses seen in raw traffic.
 */
mapreduce::plugin('anonymizer/tor/plugin/onion') =
  immediate_keyword(/(?:([a-z]+):\/\/){0,1}([a-z2-7]{16})\.onion(?::(\d+)){0,1}/c
: c++
    includes: {{
      #include <boost/lexical_cast.hpp>
    }}
    proto: {{
      message onion_t {
        required string address = 1;
        optional string scheme = 2;
        optional string port = 3;
      }
    }}
    mapper<onion_t>: {{
      static const std::string prefix = "anonymizer/tor/hiddenservice/address/";

      onion_t onion;
      size_t matches = cur_args()->matches.size();
      for (size_t pos=0; pos < matches; ++pos) {
        const std::string &value = match(pos);
        if (value.size() == 16)
          onion.set_address(value);
        else if(!onion.has_scheme())
          onion.set_scheme(value);
        else
          onion.set_port(value);
      }

      if (!onion.has_address())
        return false;

      MAPPER.map(onion.address(), onion);
      xks::fire_fingerprint(prefix + onion.address());
      return true;
    }}
    reducer<onion_t>: {{
      for (values_t::const_iterator iter = VALUES.begin();
          iter != VALUES.end();
          ++iter) {
        DB["tor_onion_survey"]["onion_address"] = iter->address() + ".onion";
        if (iter->has_scheme())
          DB["tor_onion_survey"]["onion_scheme"] = iter->scheme();
        if (iter->has_port())
          DB["tor_onion_survey"]["onion_port"] = iter->port();
        DB["tor_onion_survey"]["onion_count"] =
boost::lexical_cast<std::string>(TOTAL_VALUE_COUNT);
        DB.apply();
        DB.clear();
      }
      return true;
    }});

/**
 * Placeholder fingerprint for Tor hidden service addresses.
 * Real fingerpritns will be fired by the plugins
 *   'anonymizer/tor/plugin/onion/*'
 */
fingerprint('anonymizer/tor/hiddenservice/address') = nil;
// END_DEFINITION

Please note the first comment in that source code:

  "Aggregate Tor hidden service addresses seen in raw traffic."

How do we blind XKeyscore (and similar systems such as the Russian
SORM!) in a way that ensures users don't find themselves in such a
database? In browsers, with pre-fetching, I think the answer is
outlined in RFC7686. In other applications, I think the answer, if
someone cares about the user is also outlined in RFC7686.

I think that since DNS is not a private system so your suggestion
won't be done as easily as possible. If we had query privacy, I could
imagine a world where such a suggestion could be workable. We don't
live in that world though and so application developers can choose now
to protect users from harm or they can pretend that it isn't their
department. Or that another department could handle it better and so
the buck is theirs to pass.

Pervasive monitoring is an attack (per RFC 7258) and RFC7686 is an
attempt to mitigate, imperfectly, a failure exploited by surveillance.
Personally, I would have preferred a much stronger RFC that forbids
the transmission of any unencrypted DNS queries with additional
restrictions that again, protect actual users.

All the best,
Jacob

---

From: David Conrad <[email-masked]>
Date: Sun, 29 Nov 2015 10:26:33 -0800

Mark,

> What is the actual harm, discounting aesthetics?

For one thing, names not supported by the underlying infrastructure will _always_ leak.

In the bad old days, when an application got a string ending in .UUCP, .BITNET, .CSNET, etc., it had to know that those strings had to be treated differently. Various hacked libraries did different things to deal with those endings, and usually imperfectly. Worse, the universe of endings was local policy specific but the use of those names was global in scope, so there were a never ending series of issues where a string would work in one locale but not in another, resulting in user complaints, general confusion, and much gnashing of teeth. After a number of years, we (re)learned that maybe using the name of something to distinguish its underlying infrastructure requirements wasn't the best idea.

.LOCAL, .ONION, and 6761 in general allow us to repeat history yet again, since we seemed doomed to be unable to remember earlier lessons.

Regards,
-drc

---

From: str4d <[email-masked]>
Date: Sun, 29 Nov 2015 19:57:32 +0000 (UTC)

Jacob Appelbaum wrote:
>> It is here that .onion goes one step further. Onion 'names' are 
>> derived from public keys. So instead a name being independent of 
>> an address, the .onion name is the address.
> 
> The name is not an address per se. It is a self-authenticating url 
> - this means you can prove that you're talking to who you intended 
> to speak with all along. It says nothing of the routing, except 
> that you are routed by public key and IP addresses are not as 
> relevant. They're still used in some cases but the system is 
> designed to fail closed.
> 
> This is not exactly the same as the .onion name being an address. 
> The *publickey* is also not an address. In the Tor Hidden Service 
> protocol, we have descriptors and other things that are more akin 
> to the address. They change often and are authenticated by the 
> public key that you would expect to authenticate them. Those 
> authenticated bits are the address in my view.
> 
>> Unlike, TLS or SSH, where a network connection is set up and
>> then the crypto runs on top of it, in TOR this all integrated.
>> For good reason, however that make the .onion 'name' an address.
> 
> It can be done in stages - transparent setups work differently
> from a local Tor client, for example. A resover can be Tor enabled,
> as a network, as a browser, etc.
> 
> I guess I have a hard time calling the name an address. It is a 
> name and it is a kind of name with security properties. See also 
> Zooko's triangle for what I mean - the normal DNS and 
> self-authenticating names are not the same mapping on Zooko's 
> triangle.

I concur with Jacob. An I2P Destination (the public keys defining a
particular client or service) is essentially equivalent to an IP
address, and .i2p domain names do essentially "resolve" to
Destinations. Furthermore, a .b32.i2p is functionally equivalent to an
.onion - it is a self-authenticating name, that has a one-to-one
correspondence with an address-like network object (the Destination).
But just because the .b32.i2p or .onion is derived from the address,
IMHO does not mean it is not a name. For one thing, a .b32.i2p cannot
be used in isolation to connect to an I2P HS - it must be looked up
in-net to obtain the Destination.

>>>> In this context an onion address should have been an 'IN 
>>>> ONION', i.e, www.example.com might have an 'IN ONION'
>>>> address for use with TOR.
>>>> 
>>> 
>> If an 'IN ONION' would be stored on the host as a 'struct 
>> sockaddr_onion' then all code can be cleanly adapted to support 
>> TOR hidden services. Instead of adding pattern matching hacks to 
>> name resolution.
>> 
> 
> I'm skeptical but I do look forward to you expanding on how this 
> would work with *less* work than our current approach. I'd also be 
> curious what work would need to be done and how it could be done
> in a way that fails closed and does not harm the user's privacy.

I actually looked into doing this for I2P several months ago ago (long
after .i2p and .onion were proposed in the P2PNames draft, but before
.onion was separately proposed and accepted), because the I2P network
model would map well onto the existing getaddrbyhost() mechanisms.

I concluded that defining AF_I2P (necessary to enable all code to be
"cleanly adapted") would require patching the Linux kernel, the
Windows kernel, and probably the kernels of any other OS you wanted to
run it on, because none of them provide any way to define additional
AF_* or PF_* either in userspace or via kernel modules. You *can*
define the 'struct sockaddr_i2p' in a module, but it would have to
co-opt some pre-existing and maybe-or-maybe-not-unused AF_*, which is
a laughable approach.

Now wind back ten years, to when I2P's decision to use .i2p was made.
The network was far smaller then (a few hundred nodes, c/f ~40k
today). Am I really expected to believe that the small group of
pseudonymous developers at the time could have got AF_I2P supported
across every OS they wanted I2P to run on (which was every OS that
supported Java), in a reasonable space of time (e.g. shorter than this
ML has been debating the P2PNames drafts)? When actually using it
would require a per-OS kernel module that talked to a user-space
usually-not-installed Java process? And when the alternative was to
simply use an HTTP proxy that listens for .i2p addresses, which
required very little work, was compatible with anything that supported
HTTP proxies, and was functional for users immediately?

I believe that without the backing of a major business or organization
it would not happen now, and it certainly would never have happened
back then.

If I am wrong, and it *is* possible to define a 'struct sockaddr_i2p'
with *less* work, I eagerly look forward to you explaining how :)

str4d

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Nov 2015 13:56:49 +0000

I'm glad to see this thread on the list.

First, a plug for this draft which is an attempt to lay a foundation for
the discussion.  There's at least one outstanding edit for it, it's not
complete and is intended to be changed via discussions like this.  The
document hasn't been considered for WG adoption, I'm not sure whether it
is mature enough or if it really belongs in a DNS working group.

https://tools.ietf.org/html/draft-lewis-domain-names-01

There are a few points in the thread I want to address, based on what I've
learned in assembling the draft to date.

1) The fact that ONION names are created by the result of cryptographic
functions, as opposed to the way the way the DNS manages names through a
zone and zone administrator model is pretty significant in an
architectural sense.  A lot could be written about this, where each model
has its advantages over the other.  They are in parallel universes, I
can't say one is necessarily better than the other.  I'd venture that the
DNS model is simpler to implement, hence it emerged first.

2) "Everything can be solved by yet another layer of indirection."  I see
this emerge in the discussion between the merits of attaching special
meanings to top-level names (".magic" per GGM) versus the discussion of
"struct sockaddr-onion" (appearing in Philip Homberg's message).

The former talks about changing within what has been considered the remit
of the IETF (protocols) and the latter talks about changing something
external to the IETF's remit (API).  Because of this, arguing in different
remits, I don't see this as a solvable difference.  (I.e., let's move the
discussion one way or the other.)

IMHO, I believe that there can be a way to attach resolution semantics to
top-level names and implement this in the API level.  IOW, for DNS "above
the DNS" in the software stack.  This is just a belief, not a certainty.

3) That URLs do not have DNS names, per Mark's thread kick-off
message...if this isn't clear in my draft, it should be.  My draft also
tries to look across as many protocols/applications as possible for how
the use of identifiers/domain names have evolved over the past two decades.

4) When comparing naming systems, it's tempting to sound competitive.  The
DNS is an established system with many practices built around it and a
considerable economic (non-tech) investment in it.  Newer systems ought
not try to compete with DNS but emphasize coexistence with it.  And
discussions about the DNS ought to keep in mind that there is room for
innovation in this space.  ('Cuz, frankly, the protocol running over port
53 is pretty old and cranky.)

---

From: "John Levine" <[email-masked]>
Date: 30 Nov 2015 20:01:12 -0000

>the DNS" in the software stack.  This is just a belief, not a certainty.

Well, sure, that's how .onion and .local work now.  But there's no
general name resolution API other than the DNS, so anything else is
specific to whatever applications the API supports.

For .onion, the usual API is SOCKS (RFC 1928).  That works if you want
a TCP-like byte stream or a UDP-like packet stream, but you're out of
luck if you want to do service discovery with MX or SRV or NAPTR, or
certificate management with TLSA, or anything else the DNS does beyond
returning A and AAAA records with addresses to be used in a connect()
call.

To me, this is the worst problem with names that look like DNS names
but aren't in the DNS.  People will claim that they work fine, but
"fine" inevitably means some small set of applications, and they don't
care about (or aren't even aware of) everything else.

R's,
John

---

From: Philip Homburg <[email-masked]>
Date: Mon, 30 Nov 2015 21:06:10 +0100

>things or all of these things and then more.

Yes, a name has no direct connection to what is named. And the system
doesn't encode any semantics in the name.

DNS gets pretty close to that. Which is quite amazing for such a large
scale distributed naming system.

And to be clear, the .onion domain violates that. The .onion suffix 
directly encodes that this name is to be used for onion routing. Also
the label in front of it has semantics to the system, instead just being
a user chosen name.

>we find ourselves having bad petname system and with terrible privacy

Solving the key exchange 'hack' in context of DNS is quite easy. In the
context of secure connections, the identifier for the remote party is a 
hash of the public key. In this setting, a network address is mostly
a locator.

So define an new 'IN PKhash_AAAA' type for DNS that combines the hash of
a public key with an IPv6 address and you can directly set up a secure
connection. No problem there because DNS can name arbitrary things.

You are completely right that DNS has no regard for privacy. However, the
way forward there is to come up with a naming system that has those
properties in addition to those of a naming system.

Maybe that can be done be extending DNS, maybe something else is required.

However, it is very clear that .onion is not such a naming system. It may
provide privacy, but it's not a naming system.

>name as *just* an easy to remember string, which it isn't.

Naming is almost never easy. But name has to be just an easy to remember
string. Otherwise, you have a broken naming. In particular, encoding meaning
in names almost always leads to a lot of pain.

>stronger kind of cryptographic routing but still weak to an adversary

Viewed from the Internet, HTTP and SMTP do hardly any routing based on 
the domain name. Of course, very large sites may still have complex routing
but that is hidden within that site (or in application layer tunnels, 
proxies, etc.).

>still used in some cases but the system is designed to fail closed.

In the context of a document identifier, a URL is an address and not a name.

A URL decribes how and where to find the document. It is not the name
of the document.

A 'self authenticating' anything implies that system level meaning is
encoded. And therefor it is not a name.

>fails closed and does not harm the user's privacy.

I'm not at all suggesting that it would be less work. A quick hack is
in the short run almost always cheaper. It is in the long run that
the real costs start to show up.

>the buck is theirs to pass.

I completely agree that either DNS should get query privacy or that 
DNS should be replaced by something that has.

However, that mostly unrelated to the current discussion, which in my
opinion is mostly giving users access to tor hidden servers with minimal
changes to existing software. Instead adding direct support for tor
(even if that would just be: forward anything with 'onion://' or
'http://[onion:' or whatever we can come up with, to a proxy).

Anything that places onion 'names' where they belong, as the level of
addresses and not at the level of domain names.

>restrictions that again, protect actual users.

I hope that once the dust of DNSSEC settles a bit, there will be time and
energy to solve the privacy problem.