Routers and Ethics - <AUTHOR> http://foohack.com/2008/07/routers-and-ethics/

<comment><USER2> The last statement, "As software and hardware engineers, if our defaults put users in an unsafe situation, where their credit and savings are placed at risk, then we've failed them, and we've acted unethically."

is excellent.

Unfortunately, it's not easy to get people out of the mindset described [plug it in, download porn, rinse, repeat].

Part of the issue is making it easy to initially connect, and as a corollary - easy to reconnect once you've changed settings. This seems to be the big issue.

There is however a standard established for doing this: <http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup>

My newish dlink router supports it. There's a button on the side that you push to put it in setup mode [I think you probably need Windows for the "easy" parts]. By DEFAULT it is setup secure, and requires you to change the password.

The trick of course is getting this pushed across the board.

</comment><comment><USER3> Sounds like an opportunity..

Why don't we design one that is foolproof? i.e. security is always enabled, and it requires a complex password? Perhaps there is even a readout + little keyboard built into it so the end user can go through a simple wizard to ensure security. The readout would give them the keys to type into their PC.

And on top of it there would be a large green + red indicators.. Red would glow if there was any security issue, with the error on the readout + sent to the end user as a text message. Green would indicate all is secure.

The only real question is what to name port forwarding. While I'm a huge fan of the obvious and clear "Applications and gaming", being a router manufacturer I would be obligated to create yet another new name for it, like "wormhole port" or "you fool, just call your geek nephew already".

Seriously, I have trouble going from a linksys to a netgear to a dlink, not to mention the OEM routers sold by ISP's now that often lock down features.. How can we expect these pieces of fail to be installed correctly?

<comment><USER4> AT&T already does the most important parts of that. In my complex every network is named and secured uniformly because AT&T sells cable models with built-in wireless routers. They have an installation process that is totally automated and automatically configures them for WPA or WEP. The users don't even (get to) choose the network name. As a result, I couldn't leech off another network even if I wanted to.

Secure networks make perfect business sense for internet providers; otherwise, they'd end up with customers with wide-open networks that neighbors could share together (unwittingly or otherwise).

As for port forwarding, typical users never need to configure that, and when they do, UPNP usually can do it for them.

<comment><AUTHOR> Yes, AT&T's DSL setups are a triumph of proper defaults. They come in, plug everything in, give you the password (or set up your computer), and go away once everything is working and safe. Easy setup, safe installation.

Of course, I've had WPA and WEP hacked enough times to not trust either of them. MAC address filtering is a bit safer if you want to lock down access to the internet, but _at least_ the password has to be changed. Default router passwords put users so badly at risk, there's really no excuse.

</comment></comment></comment><comment><USER5> I think many vendors may now use encrypted Wifi by default, but I wonder if doing something as simple as creating a "random" password and printing it on the user's manual would have done the job?

</comment><comment><USER6> His counterexamples are very bad. If you don't practice proper car maintenance, you can get into a very unsafe situation with e.g. underinflated tires. Prescription medication? My dad almost put "otic" (ear) drops in my eye when I was a kid -- I pointed out that there was a typo on the box and he gave it a second glance.

If users aren't going to put a minimal investment into using a product safely, there's only so much you can protect them.

<comment><AUTHOR> That's true, if you want to be as safe as possible, then it pays to be attentive to all the instructions you receive.

But, my point was that we receive so many complicated instructions about complicated things that we don't really have time to understand fully, and there are only so many hours in a day. You simply must prioritize. The fact is, I expect that my doctor and my mechanic are going to tell me what to do, and that I can pretty much just trust them. In this case, Netgear violated that trust.</comment></comment>


Ask HN: Do you think HN should add notifications system? - <AUTHOR> On one hand, I think it can be quite useful. When I sumbit a comment or a story, the only way for me to know someone replied, is to re-enter HN later. I miss a lot of replies this way. On the other hand, I think it can ruin HN simplicity and "purity". What do you think? <comment><USER2> There is no need thanks to this third-party service: <http://hnnotify.com/>

<comment><USER3> That's a nice service, but the developer could use this to find out the emails of subscribers. He does have a quick note about privacy: "I will not sell or share the email list with anyone." But this doesn't seem sufficient.

</comment></comment><comment><USER4> No. There's a problem with a few people who only ever submit articles that they've written (which are hosted on ad heavy websites) and who make no other contribution to HN. I don't want another set of people who only ever contribute to the threads that they've created to discuss some bit of blogspam.

If anything I think names of people commenting should be hidden for 24 hours, so that you don't know if you're responding to the same person within a thread or not. That might help to cut down snark. (And it avoids the problems we have of toxic-anonymity).

I also don't think that HN should do this stuff, but should have a nice interface to allow people to create extensions and plugins and user scripts. (There are very many such already. Someone creating a nice curated list with screen shots and user reviews would get huge amounts of karma.)

</comment><comment><USER5> I think there's plenty of room in the profile for, say, a list of most recent replies (or have a |replies| option show up in the menu.)

Simplicity is nice but I suppose YMMV as to the line where utility becomes unnecessary complexity. Email notifications might be too much but even then sending them out as a daily digest might not be so spammy.

</comment><comment><USER6> No.

<comment><USER7> +1 to No.

</comment></comment><comment><USER8> HN used to have this feature (natively, configured in your profile) by way of Notifo (a Y Combinator startup).

<comment><USER9> Notifo was shut down long ago. I just saw the goodbye post. Ironically their blog is hosted on Posterous.

</comment></comment><comment><USER10> Yes. And I would gladly pay 2 or 3 euros for such a feature.

</comment><comment><USER9> I think <https://news.ycombinator.com/threads?id=your_user_id> does a pretty good job.

Though never checked if the API is open for having such an app or one could monitor this by user-id and trigger custom notifications(out of HN I mean) when there are nested replied.</comment>


Re:publica 15: Google Promotes Privacy, But Not Too Much - <AUTHOR> https://tutanota.de/blog/posts/republica-google-promotes-privacy-but-not-too-much <comment><USER2> [https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html](https://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html)

In case anybody hasn't read it yet, Philip Zimmermann's essay on why he wrote PGP is very relevant to this discussion. Google is effectively saying _envelopes_ are not meant for common use.

Did you send everything by postcard back in the snail-mail days, only using an envelope when the contents was very-important? If someone saw you mailing an envelope, did they suspiciously ask what was so important that you needed to hide it? No, wrapping your mail in an envelope was commonplace.

This is what we need to do for digital messages: wrap them in an envelope (encryption). More importantly, we need a _culture_ that sees sending encryption as normal. You may not be sending anything important at the moment, but other people are, and if encryption is only used for "important" things, it invites suspicion.

If Google has a problem with this, I suggest they find a new business plan.

<comment><USER3> Not really a valid comparison. Encrypting a message is more like sending your letter in a titanium safe.

<comment><USER4> It isn't so bad. Tampering with mail is a federal crime.

</comment></comment></comment><comment><USER5> Does this surprise anyone? Google has contradictory interests when it comes to encryption and privacy.

It has been at the forefront of pushing SMTP to SMTP encryption and HTTPS everywhere. Google has to spread (and perhaps seriously believes in) the idea that they transfer data securely, unreadable by the Five Eyes. Because the perception that Google is in bed with the NSA et al. is seriously undermining their reputation (especially in Europe).

On the other hand, scanning content for ads requires that they have unfettered access to user data. If by implementing good end-to-end encryption e-mail would not be visible to them anymore, their abilities to do user profiling of those on and not on GMail would be impeded seriously.

If you want _real_ privacy, you should move out of the Google ecosystem. Their terms of use are too far-reaching and their interest in your data too large to assume that they would go all-in with complete end to end encryption of everything.

<comment><USER6> Unfortunately their services are too convenient. I use them for almost everything I can, my reason being that they already know enough about me from my google searches, so I might as well use every other service they have.

Plus they're encrypted so only they know it. Also, I'm not from the US so MY government doesn't have access to their data.

<comment><USER7> Same here. But I also pay Google for various services, and the lack of privacy bothers me enough that I would readily pay Google the relatively small amount I'm worth to them as a data source in order to get privacy.

THAT's where Google's position, or at least this Google spokesman's position is wrong: I'll give up both some convenience and some money to get more privacy.

<comment><USER8> But that's exactly the conflict: Google doesn't want your money, they want your data.

Paying for more privacy is not and probabably will never be an option.

<comment><USER7> Ehhhhh. "Google, would you trade ad revenue for the same or larger subscription revenue?" I think the answer would be yes.

<comment><USER8> Most companies, yes. Google, no.

It's completely against their current models. They're basically telling advertisers: You know that product we were selling you, that made us billions of dollars together? We're not selling it to you anymore, but it's still making us money.

</comment></comment></comment></comment></comment></comment><comment><USER9> I remember end-to-end vs. point-to-point from my crypto class back in the Pleistocene, so I thought I'd share the analogy my professor used just because I loved it:

In WW2, the Allied Navies faced two main naval code strategies: Germany's and Japan's. Roughly, the Japanese Navy sent their routing information in plaintext, while the Kriegsmarin sent it in ciphertext. Because the German routing instructions were encrypted, each node had to be able to decrypt universally. Capture one U-boat, and, well, we all saw the movie.

In contrast, the Japanese navy sent the routing information in the clear, so transceiving stations only had to read the routing information and transmit the ciphertext verbatim: capture a Japanese sub and you can only decode messages sent to that sub. _However_ , because the routing information was visible in all transmissions, a lot of sideband avenues were opened up (you may not know _what_ Yamamoto was sending to the Coral Sea fleet, but you're damn sure interested in the fact that he was talking to them at 2am this morning, particularly since you can then watch what they do.)

Anyways, not directly relevant to the article but a cool example of how far back this question goes.

<comment><USER10> Why not encrypt the routing separately?

<comment><USER11> Remember that those were different times. Computer science itself was born by trying to break that crypto, and modern cryptography wasn't available.

A different key for each vessel would mean several passes through the encryption machine, key tables distributed through several places, and the requirement of specialized workforce where otherwise just typing stuff in a machine would do. And all the errors that come with manually dealing with that, all during a major war.

<comment><USER9> _Computer science itself was born by trying to break that crypto, and modern cryptography wasn 't available._

^^^ That.

</comment></comment></comment></comment><comment><USER12> "Because translation."

If they really said that, that's amazingly weak and clumsy.

I would have been impressed if they had openly said it's because they can't analyze your email for ads and targeting.

In fact I'd be very impressed if they said up front, briefly and not implied in a ToS book, that the reason you get free email is so they can read your email.

<comment><USER2> If they really believe in their business plan, they should admit their real motives; dissembling with such a weak excuse just gives Google that "shady used car salesman" look.

The fact that they went with a dodge suggests they know that they risk a lot of blowback if people started to learn about their actual business plan.

</comment></comment><comment><USER13> I don't need the extra security provided by end-to-end encryption for the vast majority of emails I receive and send. I value that ability to search/filter these emails far more than I value the security.

For the few emails I send where the value of the security provided exceeds the lost value due to being unable to search I can, using their extension, enable end-to-end encryption.

This system suits my needs perfectly, I appreciate that others may want all the emails they send to be encrypted but why should Google cater to this - they cannot make any money from encrypted emails.

<comment><USER14> Agreed. The question is. Can you perfectly, always and with regard for potential future changes to what may be sensitive information decide which ones to encrypt?

One email sent the wrong way when tired. One change in legislation (to e.g. retrospectively criminalise an activity or legalise a certain type of snooping). Now your company's IP is compromised. Or now your in jail. Or now you can be blackmailed.

Furthermore the idea that you will be encrypting the mail may cause tired future you to write something you wouldn't put on a post card.

So unless you are perfect and never ever click in the wrong place good luck in this brave world of ours.

<comment><USER15> What insane law system makes an action retrospectively criminal ? Does the US law system allows this ?

<comment><USER16> At least in the US, 'ex post facto' laws are specifically forbidden by the Constitution: [http://en.wikipedia.org/wiki/Ex_post_facto_law](http://en.wikipedia.org/wiki/Ex_post_facto_law)

<comment><USER17> True, but the US government doesn't even pretend to follow the Constitution anymore.

Also, the Constitution can be amended. We can't guarantee that ex post facto laws will remain unconstitutional for the duration of your lifetime.

Also, states are technically not obliged to abide by the US constitution.

<comment><USER18> The first and last paragraphs are incorrect; you may disagree that the federal government actually follows the Constitution, but that's a different issue. And while many provisions of the Constitution address only the federal government, States are still bound by it to the extent it addresses them, as it does, among other places, in the 14th Amendment.

<comment><USER17> The first paragraph is correct because I clearly meant it in figurative language, not literal language. Regardless, my point is this: the US government does not obey the US constitution.

The last paragraph is correct in context. Specifically, with regards to encryption, states are allowed to do whatever they want because the Constitution doesn't mention encryption and because of the 10th amendment, which states:

The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.

The last paragraph is also correct because the ex post facto law clause of the Constitution only applies to Congress, not the states [1]

[1] [https://en.wikipedia.org/wiki/Article_One_of_the_United_Stat...](https://en.wikipedia.org/wiki/Article_One_of_the_United_States_Constitution#Section_9:_Limits_on_Congress)

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Just brainstorming here. Here are a few ways in which you can get in trouble with the law because of unencrypted online communications (these are ordered from most likely to occur within 1 human lifetime to least likely to occur within 1 human lifetime, IMO):

1\. You could travel to another country where they arrest you for something unencrypted you did online in a country where it was legal. This has already happened. [1]

2\. Your communications could become evidence in court that you "always had radical leanings." So while you're not convicted for what you did online, it still becomes evidence against you. I suspect this has already happened.

3\. You could travel to another country where retroactive laws are allowed, and get caught because of something you said in the past in the US.

4\. The US could eventually allow retroactive laws, and catch you for something you did before retroactive laws were allowed.

Note: these are just ways you could get in trouble with the law; not mentioned are things like your reputation being destroyed, death threats, identity theft, or malware due to lack of encryption. I also have not mentioned ways in which your friends could get in trouble because of something unencrypted you did online.

[1] [http://www.cnn.com/2015/03/05/middleeast/american- arrested-i...](http://www.cnn.com/2015/03/05/middleeast/american-arrested-in- uae/)

</comment><comment><USER19> For what it's worth, I spoke at re:publica right after Eric, and commented a bit on Google's privacy goals.

Video: [http://youtu.be/pbF0sVdOjRw](http://youtu.be/pbF0sVdOjRw)

<comment><USER20> That should likely be a post in its own right.

</comment></comment><comment><USER21> Anyone who says that PGP is not meant for common use has 20+ years of history clearly proving them right. Moxie doesn't believe it in[1], even PGP's own creator doesn't use it any more[2]. OP is trying to make news out of nothing.

[1] [http://www.thoughtcrime.org/blog/gpg-and- me/](http://www.thoughtcrime.org/blog/gpg-and-me/)

[2] [http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails- bi...](http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy- problem-qa-with-silent-circle-co-founder-phil-zimmermann/)

<comment><USER22> Actually, I suspect PGP usage is increasing right now. It's very commonly used in darknet markets, and they are growing very quickly and will probably continue to do so.

</comment></comment><comment><USER23> From my perspective, what I miss with decryption only in the client (where the mail database is stored encrypted) is search. That's also the primary value of Google Apps for me. Easy encryption across the Internet would be more valuable to me than encrypted storage, but the option to have encrypted storage for things that are really private would make sense. I tend to opt for alternate channels with no storage in those cases though.

<comment><USER2> > what I miss with decryption only in the client ... is search

Yet another casualty of "software as a service". There could be better search tools on the client, but the fad for the last decade has been to push vendor lock-in and data mining instead of installable client apps. So now the full consequences of those choices are starting to be recognized.

<comment><USER23> Installable client apps just don't work from me. I need to access the same email database from 4 different devices, including some I don't own and don't want the data on.

<comment><USER2> Then your requirements are in conflict with security. You cannot trust the network to do your encryption for you, and you can't trust a a computer you don't own to handle your private key.

You may want to reconsider either dedicating some sort of portable device to be your email that you carry with you, a multi-account system the separates private email from the the email you can access remotely, or resigning yourself and those communicate with to sending using only postcards (non-end- to-end-encrypted email).

</comment></comment></comment></comment><comment><USER24> I tried to use PGP (gnupg) but it doesn't seem to be simple even for an advanced user. Since I use Debian already it means that I implicitly trust Debian maintainers. So I explicitly trusted one Debian maintainer in gnupg. From there I thought that verifying other keys would be a breeze since I have a trusted guy in the strong set. While there are online tools (at least one) to find trust paths between IDs I didn't find a tool that does this automatically and verify signatures through this. This should be seamless without manually tracking down trust paths, manually importing keys that I don't want just to verify an ID 2-4 hops away.

Here is my concern with the WOT: it's not clear what signatures mean. It could mean "This guy can give out valid signatures" or "I verified that this guy's name is John Doe" or "This is the key used to sign Debian isos", but these are all implicit. Typically it's the first two which makes it hard to use PGP with pseudonyms. When you verify a signature in PGP you want the following chain:

o--I trust this guy's signatures-->o--I trust this guy's signatures-->o--I know this guy-->o

Other concerns: any way to rotate the master key would be nice. I wouldn't assume that my master key won't be compromised in the next 50 years .Then I would have to rebuild my whole WOT and revoke my previous master key (If I can). Key distributon should be decentralized.

Maybe I'm missing something, but this is my takeaway and I really tried to like PGP and gnupg. Maybe Google will solve some of these concerns on their interface but I wouldn't bet on it. I'm not surprised that PGP isn't widely used. I would really like a safe end-to-end encryption implementation that is easy to use.

</comment><comment><USER25> Duh. If everyone encrypted their mail then Google wouldn't be able to personalise their ads to mailbox content, and they'd lose a huge commercial advantage over other ad networks. Advocating end-to-end encryption would be Turkeys voting for Christmas.

<comment><USER26> Have no worries ... full email encryption is two years away. Also has been that way for the last couple of decades.

</comment></comment><comment><USER27> Talk: [https://www.youtube.com/watch?v=DJdGblrWX9o](https://www.youtube.com/watch?v=DJdGblrWX9o)

</comment><comment><USER28> More convincing than translation would be spam filtering. I think end-to-end encryption would make spam filtering a lot more difficult.

<comment><USER29> Proof of work. Every email the spammer sends out would need to be properly encrypted (or else the target wouldn't see your ads). This would actually put a lot of control in the hands of the user - set the amount of work required to mail you through key strength. Spammers would absolutely hate this, it would be like the USPS requiring bulk mailers to prove they aren't spamming by including the recipient name (not "Current resident" or "Our friend at").

</comment></comment><comment><USER30> neither is electronic surveillance

</comment><comment><USER31> How's Tutanota any better? "End to end" but client side JS where you plop your key into the form they serve up. It's only as good as their TLS/server security, and your trust in them. In face of real opponents, it breaks down just as much as gmail-to-gmail emails.

</comment><comment><USER32> I wish there was a real quote here, because I find it hard to believe his only example of a Google value add is translation. Personally I'm happy to use Gmail for insecure communication as long as I can keep search - it'd be utterly unusable without.

</comment><comment><USER33> Sadly, they're not wrong. End-to-end encryption products are written for expert use and hard to set up by mere mortals.

<comment><USER34> Are you sure this isn't just another way of saying that decentralized authentication is too hard? ;)

</comment></comment><comment><USER35> If I need to translate using Google Translate, copy & paste will do. I don't need to do this directly in Gmail.

</comment><comment><USER36> I say it is.

Who's right?

<comment><USER37> 20 years of history at least provides evidence for you being wrong.

<comment><USER34> Paper envelopes dating back to 2300 years ago in China at least provides evidence for you being wrong.

User-unfriendliness ≠ "not meant for"

<comment><USER37> Fine. End-to-end crypto requires key authentication. This means that users must have some way of authenticating a key.

For the majority of people, this is too much. People should not be expected to spend time manually checking the signatures on a key, and should likewise not be expected to get signatures for their key. They should not have to worry about key revocation. If a solution is not as easy as email is at the moment, it's not a solution.

So, the problems that need to be solved _in an automated manner_ :

Finding a public key, verifying it to be authentic beyond all reasonable doubt, making it so that a new user can be trusted. Revoking the key if the device is compromised.

These problems are not new - they've been around since PGP was invented. Yet, there is seemingly no compelling answer to them that doesn't involve bringing your passport to a key signing party.

All of the end-to-end encryption systems I've seen either have some complicated handshake process before one can communicate with another, or are unauthenticated.

So, anyone who argues for widespread end-to-end encrypted communication must provide evidence that such a system can actually be produced in a way that is totally transparent to the user.

Google's doing well with this software - they're massively reducing the barrier to entry for PGP; I just don't see why people are complaining about their preaching of security gospel.

<comment><USER34> > Yet, there is seemingly no compelling answer to them that doesn't involve > bringing your passport to a key signing party.

The only reason I trust the source of an email by its "from" address is because of the history of correspondence with that person from that address. Yes, if it is compromised, I may not realize it right away, or I may (see: phishing emails from virus/malware infestations), but by and large it works as advertised.

Same thing with usernames in forums. There's a certain cred that is eventually attached to a username over time.

If I use the same public key to represent myself in all my communication "for a while", then there's implicit trust that it's me there, for the same reasons.

Key revocation is admittedly not as simple, if I want to continue to maintain my "trust balance" somehow. What happens if I switch email addresses? "Hi guys, this is my new email address." What if I was compromised and someone else did that? (Well, how often does that happen in real life?)

Perhaps you could keep one key super secret (and offline) and sign all new day-to-day keys with it. I don't know.

What I'm saying is- Treat it like email. Forget trying to centralize who owns what key. Forget trying to exercise absolute control over trust in a given key. The key(s) I use "most of the time" is "me". If I need to revoke it, I will suffer some in the short term, but I will quickly build my cred back up by using a new one.

If it was more widespread then perhaps we could centralize SOME third-party signing. Say I could go to a bank and they could sign my key saying "this key definitely belongs to lectrick", and it would work because the bank's public key is known-trusted.

<comment><USER37> I'm afraid that fundamentally doesn't work (though at first glance it does). Email is not a forum - it's person to person. When someone emails me, I might not know anyone else who has also had a conversation with them.

In order for anyone to trust your key _at all_ you need to make it available out of band.

This is because otherwise, your email provider could simply man-in-the-middle you (or them); and they have no way of working out.

The first time they email you, their key is already compromised. You then build up your trust for them; but you've trusted an attacker. The system is worse than useless.

This is worse than (say) TLS because TLS, you generally do not connect through a single access point. Email is far more centralised.

So, they need to get your key from outside the communication system, somehow.

</comment></comment></comment></comment></comment></comment><comment><USER20> Is Google's Eric Grosse familiar with anonymous authentication techniques over Tor?

Because there are at least two projects which address this: FAUST and Fair Anonymity:

[http://arxiv.org/pdf/1412.4707v1.pdf](http://arxiv.org/pdf/1412.4707v1.pdf)

[https://gnunet.org/node/1704](https://gnunet.org/node/1704)

I _very_ strongly encourage Eric to have his team look at these, or other options, and back the motherluving frell out of whatever seems viable.

Listening to his Re:publica conversation with EFF's Jillian York, the topic comes up, but best I can tell he doesn't know of these.

At 17m 50s in the presentation, the question of using Google services over Tor is raised.

That's ... an issue I've had some experience with:

"How to kill your Google account: Access it via Tor"

[https://www.reddit.com/r/dredmorbius/comments/2w618r/how_to_...](https://www.reddit.com/r/dredmorbius/comments/2w618r/how_to_kill_your_google_account_access_it_via_tor/)

First off, I totally get the abuse angle. Most of my specific complaint with my own experience wasn't over Google's _challenge_ process to my attempted Tor access. Rather, it was over the company's policies and procedures for account recovery. Multi-factor auth is well and good, but I've _yet_ to find a way to activate an option _other_ than phone-based auth _without providing Google with a phone number_. Which for a number of valid reasons I cannot or will not do.

(Grosse states that "you should not even have to give us a phone number", and that there are internal debates on the subject. Yay.)

More specifically, the problem is that the question _" Who are you?"_ is proving to be the most expensive operation in all of computing. Because you're fucked either way you get it wrong. Lock someone out when you should let 'em in, and you're fucked. Let someone in when you should've locked 'em out, and you're fucked. And all you get to look at is 1s and 0s on the wire.

I detail that in more length in this comment to my dreddit post:

[https://www.reddit.com/r/dredmorbius/comments/2w618r/how_to_...](https://www.reddit.com/r/dredmorbius/comments/2w618r/how_to_kill_your_google_account_access_it_via_tor/conz50f)

(I'll also note that Grosse specifically notes that PKI works great, ahem, Yonatan Zunger....)

So: first, Google's _really_ got to revise and fix its account recovery processes.

But that identity thing: Grosse goes on at length noting that Tor exit nodes aggregate a lot of traffic activity, and that Google effectively relies strongly on IP address as an indicator of identity.

The fair, and anonymous, reputation systems mentioned above are _specifically_ intended to work over Tor. Which is to say, people are tackling the problem. Nothing in Grosse's presentation gave any indication that he's aware of this fact. For sheer technical competence reasons, he should be.</comment>


Show HN: Lambdaway - <AUTHOR> I am working on this project, http://epsilonwiki.free.fr/lambdaway/, and would be happy to get your opinion back.
Thanks a lot.
Alain Marty <comment><USER2> I had a look at your link, and this page in particular: [http://epsilonwiki.free.fr/lambdaway/?view=lambdatalk%20one](http://epsilonwiki.free.fr/lambdaway/?view=lambdatalk%20one)

If I understand well, it seems that you wrote some kind of lisp dialect with the following particularities (some of my observations might be wrong, so please correct them):

\- it's somehow executed in javascript, so when I load in page with lambdaway code in it, js executes the code and the output is displayed on the page

\- braces are replacing parenthesis

\- you allow unicode variables (like \Phi)

\- by default, an expression is a string, unless it's preceded by a colon (my first opinion is that it's not the best and it would be better to use the quotes for the strings like other languages do, but I can be wrong)

I happen to be writing at the moment a blog post (it's not finished yet, but here is the beginning: [http://eskatrem.github.io/Newton- Raphson](http://eskatrem.github.io/Newton-Raphson) ) that uses some mathematical symbols - it will also talk about lisp by the way. I guess it's something that could be - better? - done with lambdway?

<comment><AUTHOR> Yes for the three first points. Not at all for the last: as it can be seen in [http://epsilonwiki.free.fr/lambdaway/?view=lambdatalk%20one](http://epsilonwiki.free.fr/lambdaway/?view=lambdatalk%20one), lambdatalk's code is made of sequences of words skipped by the parser and forms (S-expressions) evaluated by the parser. Colons are used to prefix arguments in lambdas. You can see an example of Newton method in [http://epsilonwiki.free.fr/alphawiki_2/?view=stock_maths_new...](http://epsilonwiki.free.fr/alphawiki_2/?view=stock_maths_newton). Thanks for your interest :)

</comment></comment><comment><USER3> Please next time explain the thing being shown in the post itself.

        Welcome in the {lambda way} project, a workshop built as
        a thin overlay on top of any modern web browser, and
       devoted to writing, composing and coding on the web, where
       the markup, styling and scripting are unified in a single
       language, {lambda talk}.

<comment><AUTHOR> I will, thank you.

<comment><USER3> This is brilliant by the way. Definitely show it to more people and get feedback, it is so outside of the norm that it will take time for the idea to spread.

</comment></comment></comment><comment><USER4> Clickable: [http://epsilonwiki.free.fr/lambdaway/](http://epsilonwiki.free.fr/lambdaway/)

</comment><comment><USER5> I suggest the home page explains what lambdaway is for in a nutshell. Digging around it looks like some kind of math markup for the web?

<comment><AUTHOR> You will find some elements of an answer to your question in [http://epsilonwiki.free.fr/lambdaway/index.php?view=overview](http://epsilonwiki.free.fr/lambdaway/index.php?view=overview) where you will find links for a more precise introduction. In the previous workshop, [http://epsilonwiki.free.fr/alphawiki_2/](http://epsilonwiki.free.fr/alphawiki_2/), you should find numerous examples of math calculus, web design and not only math markup, even if math markup can be easily built on the language. You can even play with lambdatalk in a console, [http://epsilonwiki.free.fr/lambdaway/index.php?view=console](http://epsilonwiki.free.fr/lambdaway/index.php?view=console), or install your own copy in your web account (simply running PHP) You are welcome in lambdaway

</comment></comment><comment><USER6> You might want to edit and add a short description that people can read without clicking the link. Alternatively, "SHOW HN" is usually a direct link to your project.

<comment><AUTHOR> I can't find any button "edit" in order to follow your advice. Can you help me?

</comment></comment><comment><USER7> I tried clicking on this link while in India. Strangely enough, I'm getting this intriguing message-

"Your requested URL has been blocked as per the directions received from Department of Telecommunications, Government of India. Please contact administrator for more information."

<comment><AUTHOR> I had such a similar behaviour trying to access " [http://epsilonwiki.free.fr/](http://epsilonwiki.free.fr/) " from a school where the administration had blackboxed websites belonging to "free.fr", I don't know why. Did you try an access elsewhere?

</comment></comment><comment><USER8> It's cool. Why using the braces rather than ()?

<comment><AUTHOR> Because we are in a wiki, it's 95% standard text where () are frequently used (like that), not for bracketting S-expressions. I choose braces because they are rarely used in a standard text. So you can write things like {b Hello {u (brave new)} World} without any conflicts.</comment></comment>


Vim: Copying to and retrieving from the clipboard - <AUTHOR> http://www.markhneedham.com/blog/2011/02/14/vim-copying-to-and-retrieving-from-the-clipboard/

<comment><USER2> For the record, Vim's "+ register reflects the contents of the X11 primary selection (used for X11's middle-click-paste functionality) while "* reflects the system clipboard (used for Edit menu cut/copy/paste in most GUI apps).

Type ":help quoteplus" in Vim for more information.</comment>


BGP and RPKI - <AUTHOR> https://www.aa.net.uk/etc/news/bgp-and-rpki/ <comment><USER2> Andrews & Arnold are the best UK ISP I've used in 20 years of being online.

As well as going above and beyond when it comes to sorting problems with BT, I appreciate that like with this post they are not afraid to stick their neck out and say what they think.

<comment><USER3> I have recently (within the last year) joined AAISP, and I am in agreement with you on this.

One thing it does show to me is that, even though the site was made available by Cloudflare only recently, my ISP has already acknowledged and responded to the post. Given that they have explained the situation, what it means, and that they are actively looking into it. The trust they built up with me since I started with them, means that I do trust that they are looking into this.

BGP as a whole does need a solution, and this may be one of a few ways to achieve this.

I am glad they are not rushing their solution so that my connection stays online while I have to stay isolated.

On the flip side, I do agree that some ISPs will drag their feet, and try to ignore everything for the sake of "money" or "can't be bothered" types of excuses. These are the ones that really should be pushed hard against to make the changes that are required. - I am just glad AAISP isn't one of them.

</comment></comment><comment><USER4> I have been an A&A customer for years and so this is disappointing because it's exactly the sort of crappy response I'd criticise other ISPs for. Hopefully in the not too distant future we can talk some sense into RevK and co.

The choice to block one route to make isbgpsafeyet apparently pass is bogus, it's like silencing a fire alarm (which is also something I see far too many businesses choosing to do, oh Zone A keeps alarming, we'll just disable it even though now that means more danger, engineer calls are too expensive)

Those familiar with my work will know that I read a lot of accident investigation reports, and a recurring theme in maritime accidents involving large vessels is that the BNWAS (a technology which alerts sleeping crew elsewhere on a vessel that for some reason nobody on the bridge is paying attention, probably because they're asleep) is "somehow" muted, with its logging disabled or even entirely switched off during an incident. That might not seem like a big deal but big ships are _slow_ and so these incidents often take place over many minutes or hours, thus there is plenty of time for somebody to wake up, realise there's a problem, wake someone else up to help fix it, and fix the problem before you smash the ship into an island clearly marked on your chart.

If Cloudflare has any sense they'll change the bogus route up every week or two so that outfits like A&A keep getting these "annoying" alarms and concerns from customers never cease.

> This is marginally better than routing to somewhere else (some attacker) but > it still means a black hole in the Internet.

No. It's the difference between an inconvenience (routing problem which can be reported and then corrected by a human) and a grave security problem (data is being sent to completely the wrong place because you didn't bother with the mechanism to prevent that).

Also, this glosses over the _very common_ scenario where the bogus routes are more specific than legitimate ones. If AA doesn't have a route to one specific /24 containing secure.bankofamerica.com that has "somehow" been advertised by a Taiwanese ISP for the past hour, that data will be bundled along with the rest of the /16 or whatever else (BoA's assignment is old and a mess) to the Akamai boxes (I think) which actually serve it anyway. Rather than a "black hole" there was no problem except for the bogus advertisement, which RPKI would have helped block.

</comment><comment><USER5> [https://isbgpsafeyet.com/](https://isbgpsafeyet.com/) is a bit misleading. They mention both IRR filtering and RPKI. Both of them are needed. RPKI currently only is used to validate the origin. When a peer only relies on RPKI, it is trivial to announce a route you are not authorized to announce: just append the legit ASN at the end of the AS path. That's what IRR filtering prevents.

Both are therefore useful. RPKI protects from mistake and mitigate a bit the ability to spoof a route (adding the legit ASN makes the AS path longer and less preferred).

</comment><comment><USER6> > and also our feelings about Cloudflare attempting to build support in this > manner, especially now, during the Corona Virus situation.

Weird angle. Unless the RPKI standard is somehow actively encouraging people to violate social distancing policies, I don't see any connection with Covid-19..

To me this whole article just reads like a network operator complaining that someone else is trying to hold them accountable.

<comment><USER7> It's a small business. Their staff could be infected or furloughed, or worse.

In terms of our day to day lives it might feel like the proverbial _month of Sundays_ right now, but for operations teams it's more like an unending stream of Friday afternoons in terms of sensitivity to making big infrastructure changes.

<comment><AUTHOR> Yeah, that was how I read it - the impact of getting this wrong is that you break the internet for your customers (and staff, if they're all or mostly WFH) at a time when they're potentially depending on it to eat (e.g. if you're in a vulnerable group and need to order food for delivery) or work.

We've known BGP's been vulnerable in this way for years, so it's a bit of a weird time to actively encourage people to publicly shame their ISPs for being "unsafe".

<comment><USER8> Cloudflare's BGP activism isn't exactly a new thing, so critiquing their exact timing here seems misplaced perhaps?

<comment><AUTHOR> isbgpsafeyet.com only appeared at 4 p.m BST yesterday, a Friday [1]. It's the timing of _that_ which I took the OP to be commenting on. The GGP mentioned that we're in a month of Friday afternoons, this page dropped literally towards the end of the working day on a Friday afternoon!

As you say, Cloudflare have been promoting RPKI for a couple of years now and it's disappointing that more of the big players haven't implemented it yet but is _now_ the time?

1: [https://blog.cloudflare.com/is-bgp-safe-yet-rpki-routing- sec...](https://blog.cloudflare.com/is-bgp-safe-yet-rpki-routing-security- initiative/)

> 17/04/2020, 4:00:00 pm BST

> Today, we are releasing isBGPSafeYet.com, a website to track deployments and > filtering of invalid routes by the major networks.

<comment><USER9> For some, it's never the time they should do something. ISPs are notorious for dragging their feet and they'd just find new excuses if CF had delayed the publish.

<comment><AUTHOR> I mean, the bigger ISPs will just ignore it like they've ignored IPv6 ¯\\_(ツ)_/¯

On the other hand, AAISP started automatically assigning IPv6 addresses ~9 years ago, so you can hardly accuse them of dragging their feet. The OP was published on a Saturday, after all.

<comment><USER7> ...and /48s at that too.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Cloudflare approach is pushy, but many companies need a push. No RPKI and also no DNSSEC support. When will Andrews & Arnold do something about it?

<comment><USER11> Hopefully never, on the DNSSEC side. Of course, very few other ISPs (or tech and telecom companies of any sort) use DNSSEC either.

<comment><USER12> Yay, let's leave DNS pwned because we have some disputes and the alternative isn't perfectly technically pretty. /s

<comment><USER11> This is snark but it's snarking up an interesting architectural issue, that being: "where do we draw the line?" Say we protect DNS (we could, with a better protocol design). But other redirection protocols aren't protected. Do we similarly authenticate OSPF? IP options? ARP?

The easy response to your snark is "no, people are just going to use DoH".

<comment><USER12> We've had decent authentication in OSPF for ... decades.

Most of the egregious problems with IP options have been worked around well, again for decades.

ARP is problematic, but only within a segment. Your attacker has to be close. For IPv6, we have SEND, but it is not without problems.

> The easy response to your snark is "no, people are just going to use DoH".

DoH doesn't prevent someone from poisoning well-trafficked DoH resolvers to redirect individual domains. DNSSEC does. I run it on my zones, and it's not so bad... About 40% of resolver traffic to my domains is verifying, too, so we're getting there...

<comment><USER11> DNSSEC does nothing to protect queries on the wire on their way to resolving servers (it collapses down to a single bit in the header), unlike DoH, which does protect those queries. Those queries are the most likely attack vector against DNS. Meanwhile, however many resolvers are validating queries to your own domains, virtually none of the most important (ie, well-trafficked) domains on the Internet are signed, or likely ever to be signed. At the same time, browsers have _removed_ DNSSEC code. DNSSEC is moribund. DoH has already protected more people in the brief time that it has existed.

<comment><USER12> > DNSSEC does nothing to protect queries on the wire on their way to resolving > servers (it collapses down to a single bit in the header), unlike DoH, which > does protect those queries.

Yes, and DoH does nothing to protect queries between resolving servers and authoritative servers, unlike DNSSEC, which does protect those queries. Together, you end up with end to end protection.

<comment><USER11> That's true: DOH doesn't protect outbound communication from caches, until authority servers expose DOT or DOH endpoints for them to talk to --- which should happen, and is likely to happen long before DNSSEC. But DNS attacks almost always target endpoints (DNS attacks are rare, and heavily mitigated by the rest of the networking stack, which is why practically nobody deployed DNSSEC).

<comment><USER12> DOH resolvers don't recurse via HTTPS, and there are few/no authoritative DOH authorities. DOH just exposes much larger, more dangerous targets for poisoning at this point.

Something like 30% of domains in .COM have DNSSEC, in part because of things like Cloudflare making it so dang easy. Yes, the top domains / services tend not to, and this is unfortunate. But we're well on our way.

And the possibility for poisoning worsens other attacks (it's still trivial in many cases to steal email with DNS cache poisoning... 25 years after I first played with the idea).

There's no reason not to deploy DNSSEC today. The DOH resolvers you're enamored with are almost all validating, so it's a way to get end to end validation right now.

<comment><USER11> Nothing resembling 30% of the domains in .COM are DNSSEC-signed. The number is much closer to 1% (like, it may by now be 2%; it is not 4%). This is an easy stat to look up, but it's often presented misleadingly; you may need to look at whatever chart you're looking at knowing in advance how many domains are in .COM.

And, of course, that 1-2% is almost entirely a bunch of random tiny zones nobody cares about. You can quickly discover that for yourself by feeding any list of the Internet's most popular zones (the Moz 500 is an easy one to download) through a bash for-loop against "host -t ds".

There is no evidence of any cache-poisoning attacks on DoH servers that I'm aware of. DNS attacks are in general far rarer than you'd think given the attention they've received in the past (again: there isn't much you can do with a DNS cache-poisoning attack other than trying to get a certificate mis- issued, and CAs have multiple levels of defense against that attack).

It's interesting that you played with DNS cache poisoning 25 years ago. So did I! Small world. I wrote a QID-brute-forcing cache poisoner in late 1995 (to get onto IRC from funny domains with). Towards the end of 1996, I wrote the DNS cache poisoning checks for Secure Networks Ballista scanner, which did QID stuff a la Johannes Ulrich, and the DNS authority record caching tricks Kashpureff used, plus some others.

It's fun stuff! There's not much to do with it anymore, though. In 1995, reliable domain forgery would get you past rutils filters and NFS exports; it was a very big deal, so much so that people took the time to do crazy things like elaborate source-routing attacks. But just a year or two later, everything was SSH; a few years after that, and most sensitive things on the web were SSL (it wasn't good SSL, but DNS wasn't the low-hanging fruit).

It's been hard times for people who wanted to spend their careers protecting the DNS.

There are, of course, lots of good reasons not to want to deploy DNSSEC. A good starting point would be that it drastically harms the reliability of all your sites, because when DNSSEC fails, every site in your zone vanishes as if it was never there. That's what happened to HBO the week they rolled out HBO NOW.

But there are strong architectural arguments against it, too.

I end up saying a version of a bunch of this stuff any time people complain about DNSSEC not being available on this or that online service. I appreciate the opportunity to write a new and hopefully more interesting version of the comment. Thanks!

<comment><USER10> My Logs, for the last 30 days, domains validated with DNSSEC was 5.34%. In general, it feels that ISPs like to be slow adopting standards, e.g. IPv6 it is still rolling.

<comment><USER11> Just look it up on dnssec-tools. As of March of this year, there were ~1.7MM signed domains in .COM. As of Q3 of last year, there were 144MM domains in .COM. Wherever you got that "30%" stat from, it was _wildly_ off. Even I was overcounting.

And ( _I 'm ninja-editing this in, so sorry if I caught you while replying_), as you noted, much of the growth in .COM signings is attributable to Cloudflare auto-signing --- which is the same thing that is happening in places like .NL. But registrars auto-signing domains is security theater. Ironically: attacks against registrars are far more common than attacks on the DNS protocol itself; the recent spate of "DNS attacks" from the end of last year turned out to have been phishing attacks.

<comment><USER12> Yes, I slipped a zero. Still, your argument is: It's not adopted much, so we shouldn't adopt it--- plus it doesn't matter if naming isn't trustworthy? :P I don't find that a very good argument.

Your same argument seems to imply that since we have good TLS on many protocols, we shouldn't be too heartbroken about people stealing traffic with BGP, either.

<comment><USER11> So, that's actually not my argument. But, though you're trying to dunk on it, it is a solid argument. Here's why: the cryptography in DNSSEC is obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit, with an outlandish hack that combines spoofing and a KDF to prevent zone enumeration). The protocol "supports" P-curve ECDSA signatures, and, of course, both the P-curves and the NIST DSA signing algorithm are themselves outmoded --- and that's the _frontier_ of crypto in DNSSEC; Geoff Huston did studies of this and found a substantial fraction of deployed DNSSEC verifiers can't even handle _that_. The point being: it will take _decades_ , literal _decades_ , to get the baseline level of cryptographic competence we expect from secure messengers (to say nothing of modern signing crypto) into DNSSEC.

 _And every new deployment of 1990s-grade DNSSEC makes that problem harder_.

If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. The entire protocol would be drastically cleaner, easier to deploy, and, of course, much more secure.

This is _not_ the core argument I have against DNSSEC (for that, just Google [against DNSSEC]). But it's a good one. What they say about PHP holds true for DNSSEC: it's a fractal of bad design.

I don't know what BGP has to do with any of this except to say that DNSSEC obviously doesn't do anything to prevent BGP hijacking attacks; attackers who control BGP control IP addresses, the things DNS maps in the first place.

I'm doing my best to keep these responses varied and interesting, because an HN search will show this is an argument I've made here a lot. Hopefully I'm doing an OK job of that.

<comment><USER12> > So, that's actually not my argument. But, though you're trying to dunk on > it, it is a solid argument. Here's why: the cryptography in DNSSEC is > obviously outmoded (it's PKCS1v15 RSA signatures, most of them 1024-bit,

Root zone has been signed with 2048 bit keys since 2016. Large numbers of domains are signed with 2048 bit keys, too.

> If we started from scratch, the very first thing that would change would be > the notion that cryptography is too expensive to support online signing, > which is one of the two original sins of DNSSEC.

Online signing still looks really expensive. Asking an authoritative server to do a 2048 bit signature per answer is costly, given the other conversation you've followed me into and argued basically the other side of. Especially since work you do to make DNS authoritative servers verify things is easily used for DOS, unlike work done for prefix verification in BGP).

> don't know what BGP has to do with any of this

Because we're in a thread talking about preventing BGP hijacking of prefixes with crypto, and the tangential discussion of preventing DNS hijacking of names with crypto (DNSSEC) came up. Some arguments you presented against caring about DNS security work equally well wrt: caring about BGP security--- who cares if someone intercepts our traffic, we're probably using TLS!

<comment><USER11> No. All modern DNSSEC implementations _are online signers anyways_ , because the BCP mitigation for zone enumeration, "whitelies", depends on that. So what we in fact have is the worst of both worlds: a protocol that makes painful compromises to work in an offline-signer model, and all the operational concerns of online signers. A DNSSEC that was designed for online signers from the jump would be cleaner and more secure.

That the root zone was signed with 1024-bit RSA in 2016 is its own dunk, and I think you for making it for me, but of course the root zone isn't the only zone; the 1024-bit root just meant every TLD was capped at that level of security. Now they're not, but the rest of the DNS is still littered with them. See: every DNSSEC survey.

And, of course, you've addressed only a small part of that previous argument --- just the key sizes.

I don't know what point you're trying to make about BGP. I think you think I'm opposed to RPKI. I'm not.

<comment><USER12> We don't exactly need signatures that will stand forever to greatly mitigate DNS interception.

I agree DNSSEC isn't wonderful, but perfect is the enemy of good. I'd take 768 bit RSA over "doing nothing"\-- it raises the difficulty level of a successful DNS attack enormously.

Some of us don't care about enumeration. If we do, there's whitelies, as you say, and eventually NSEC5 will be around.

> I don't know what point you're trying to make about BGP. I think you think > I'm opposed to RPKI. I'm not.

You argued earlier that worrying so much about redirection isn't justified: "Say we protect DNS (we could, with a better protocol design). But other redirection protocols aren't protected. Do we similarly authenticate OSPF? IP options? ARP?"

In which case, maybe we should just ignore RPKI, too. :P And unfix source routing, not bother with SEND, etc.

<comment><USER11> If DNSSEC were free, rather than a many-tens-of-millions-of-dollars proposition, and if it were safe, rather than a demonstrated reliability nightmare, and if it was a well-contained solution to a specific problem, rather than a transparent attempt to bootstrap a government-controlled PKI, and if complicated new protocol deployments weren't a giant source of new bugs to exploit, sure. Sure, it would make sense to deploy a little bit of 768-bit RSA to fix some marginal problem the rest of the stack already heavily mitigates.

<comment><USER12> I don't think it's a many tens of millions of dollars proposition. It was about 45 minutes of my time to get it deployed on my zones, tested, automated, and then installed by my registrar.. and it's been reliable for 3 years since. I understand the tooling is better now, too, so some of the crap I fiddled with is probably not necessary anymore. And it's even mechanized entirely for you if you use Cloudflare DNS, etc.

<comment><USER11> No. TLS is a many-tens-of-millions proposition, demonstrably so, and TLS is easier than DNSSEC. You're intuiting global cost from a single extremely simple test case; I think you're mistaken both about the multiplicand and the multiplier.

Further evidence on this is easily obtained both from survey papers that collect DNSSEC misconfiguration statistics (they're hilarious) and from the IANIX collection; many of the organizations IANIX notes are extraordinarily clueful operators.

I'm right about this. It's feasible to get DNSSEC deployed globally (it would be a catastrophe, but we indeed have the tools to make that catastrophe happen). But it would be very, very expensive.

This has been a fun thread, but we are way into the right margin now and are probably the only two people reading it, so I suggest we tie it off at whatever your next response is.

<comment><USER12> If you're stating a global cost, make it explicit. Because most organizations can deploy DNSSEC cheaply, and who knows the global cost for total deployment of anything.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I am not a fan of RPKI since it's centralized. I guess better than nothing, but what I find annoying is that IP protocol has the ability for source routing. So instead blinding trusting routes in BGP, clients/nodes who knows the route could avoid BGP entirely. It also allows the internet to be more resistant to censorship. Yet network operators seem to hate the idea of source routing because someone can spoof an ip address. So they just disable it so they don't have deal with it. Also smaller network operators seem to disable it as well to make firewall rules simpler

IPv6 implements source routing too, but again is hardly used. However it does include an other standard that also works like source routing for mobile networks, but is no where as powerful.

</comment><comment><USER14> I'd like to see what the potential issues with RPKI are (if there are any), this seems like a blog post that would address those but anything about the protocol isn't mentioned, outside of "it takes time to implement and we'd rather our upstream do it".

</comment><comment><USER15> Possibly related: [http://rpki.me/](http://rpki.me/)

</comment><comment><USER16> Do not trust any centralised authority. But if PKI Involved, what are those and what is meant by court in the article? We have to be aware certain countries (China, Russia) may not be of best interest of humanity in mind.</comment>