Remember that some "censorship" is good. When FinFisher is being used by a repressive government against protesters and journalists, or a Zeus trojan has nabbed the credentials for your bank account, it's really nice for the security folks to be able to take down the domains being used for command and control.
Except that reasoning falls apart when you realize that the budget and start-up cost (in terms of money and otherwise) are significantly more favourable for a malware operation than for a legitimate but oppressed service.
There are a lot of very stealthy, non-obvious methods that are easy enough to do once you realize they're possible. Some people don't like always going full disclosure. I have some things I've thought up that I won't share even though I don't use them.
C&C over Tor has gotten some coverage in the last year, as an example.
I remember tracking down a bad BGP route advertisement in the 90s attributed to Cox. IIRC they ended up pulling a big chunk of some country's traffic into one of their routers. Realized then that the Internet was a fragile thing.
What you're describing as "good censorship" doesn't actually require any censorship at all. All you need is a mechanism to notify users (or their client software) that a name is designated as malicious. Then the user or the user's client can decide what to do with that information, including ignoring the designation and connecting to the address anyway. That way it can't be used for censorship but it can be used to put ye olde red screen of malware alert in front of the user.
You obviously need someone to maintain the blacklist. That party could sign their work. If they do a poor job (false positives / false negatives), users and makers of client software can switch to some other blacklist maintainer at any time.
Am I the only one who finds anything bitcoin/blockchain related to come off as so incredibly complex and buzz wordy and technical that the mainstream will never adopt it?
I feel like it would be a really valuable endeavor to try and make this all much more simple to understand. Right now it just reads like gibberish to anyone other than the sufficiently technical.
I agree with all of the above. It's difficult to see how useful this is among the deep technical explanation. The chart on the github page emphasizes features of DNSChain that the current system lacks, but perhaps a chart showing where the current system fails and where this fixes those issues would be more useful?
> The solution is to just not explain how it works, the public doesn't need to understand how it works to use it and to trust it.
Who is "public"? People with technical background or without technical background?
Let's first restrict our scope to people with technical background and assume people already have a degree of understanding on how blockchain is used. Then if a developer tells you the README doesn't convey the message clearly, take note of that and appreciate the feedback. Don't say "just trust me it works."
If this is to the general public, you better hire someone who can actually explain to user how it works from a high level giving analogy is always good.
In fact, you should never assume there are two groups of audience. This is not writing API documentation. A README should be really clear to user how to get started (understand what it does and how to start using it). Think about working with a manual. You can't assume everyone know what certain nail is called by nickname. You need to write the actual name with an actual picture. Don't assume. Be general.
"Trust me it works and it's secure" is the worst thing you can sell to anyone today. Of course I will never know how Dropbox handles my files on their server securely, but at least I can understand when my file is transferred over HTTPS it's encrypted in the communication and when they say they are over the cloud I know I can access it anywhere at anytime as long as I have an Internet access and the data center still exist.
And if I don't understand what the software does how can I trust you to deploy this on my own term? How do I even begin debugging problem during installation or configuring my service?
"Trust me" is not an option, especially when someone is trying to get people to use a software. The one thing we need to change is to teach people enough computer so they can make a judgement whether they should trust something or not ("trust me this photo tool is awesome and is free ... minus the free ad program install alongside with it) or trust me this version of browser is nice come to https://evil.com instead of https://mozilla or chrome
Perhaps we can learn from PGP adoption and evangelism. One reason why it's not widespread is it simply doesn't "just work" in the minds of a non-technical end user. Sure there are longer, detailed causes to debate over but that is the bottom line to a non-technical end user.
Mainstream doesn't adopt a technology, but services.
Want to send a message ? There once was (and still is) SMTP and IMAP, but now you also have XMPP and all its variants, the Skype protocol, something baked on top of HTTP, ... Who cares what's the technology, as long as the service is there.
Want to watch a movie/listen to a song? There were all those containers and formats, but as long as your movie player works mainstream doesn't care. You can use Napster, KaZaa, eMule, Bittorrent, USENET, direct download, and now there are those proprietary streaming things... Again, as long as the service is fulfilled, "Mainstream" doesn't care.
Same with HTTP and DNS. Very few people know how it works, as long as it works. And the goal of dnschain is actually in line with this: The goal is to use your existing software that already work, and migrate from old-style DNS to DNS-through-namecoin. All transparent from a user point of view.
okTurtles presented a demo video at EFF CUP at SOUPS 2014 conference that also explains the basics of DNSChain in what could be an easier-to-digest manner:
This is why I like ethereum. They take care of all the explaining, and give people a single concept for understanding an ethereum-backed altcoin. Then, any application built on ethereum can just refer people to the ethereum documentation.
Understanding how ethereum apps work has network effects, in the sense that once you understand ethereum, you understand every ethereum app.
More specifically, it uses namecoin and the information you store in there [0] [1] and makes it accessible to non-namecoin software through DNS and HTTP.
Best use-case, to me: put your TLS certificates with DANE structures, and you can be sure they aren't spoofed by anyone when someone gets your records. No need for the heavy and centralized DNSSEC.
The problem with this is that it requires you to download the blockchain to be secure, or trust a DNSChain server.
Why not make it so the client sends a list of trusted/non-trusted nodes to the DNSChain server, and the DNSChain server returns the DNS records in addition to signatures from all of the trusted/non-trusted nodes. As such, you will have far more ability to trust that the connection is secure as it would require tampering all of the trusted/non-trusted nodes.
For users who don't want to maintain a trusted node list, the browser could by default have a list (like we have a CA list at the moment). If all of the non-trusted nodes disagree with the trusted nodes, then the connection gives a warning message. If most of the non-trusted nodes agree with the trusted nodes, then it is a treated as a secure connection.
It's not a perfect solution, but this is lightweight, scalable etc.
Ofcause, the problem I see is the 48 hour synchronization as the updated DNS record signatures from the trusted node gets sent to the DNSChain server you make the request to. (DNSChain server would have a local DB which gets syncronised as signatures get updated as to provent multiple connections causing the DNSChain server to be slow).
I hope I've made sense. It could be as easy as installing a 'no restart' Firefox Extension, making it very user friendly.
A second problem with Namecoin, is that you can only register .bit domain names. Couldn't nodes check for an uploaded file on a server to 'give' them the Namecoin equivalent? So example.com can upload example.com/verify-namecoin.html and then it gets given a blockchain based example.com domain name.
28 comments
[ 2.7 ms ] story [ 78.5 ms ] threadIt's not worth it.
I won't describe the really good ones, because I don't want to proliferate them.
I want an invite: akr has an invitation available If you know akr, you can ask them for an invitation to Keybase.
C&C over Tor has gotten some coverage in the last year, as an example.
What you're describing as "good censorship" doesn't actually require any censorship at all. All you need is a mechanism to notify users (or their client software) that a name is designated as malicious. Then the user or the user's client can decide what to do with that information, including ignoring the designation and connecting to the address anyway. That way it can't be used for censorship but it can be used to put ye olde red screen of malware alert in front of the user.
1. http://www.aaronsw.com/weblog/squarezooko
I feel like it would be a really valuable endeavor to try and make this all much more simple to understand. Right now it just reads like gibberish to anyone other than the sufficiently technical.
If people who advocated for the web explained the entire networking stack every time they tried to get people to use it they'd miss how it helps them.
Who is "public"? People with technical background or without technical background?
Let's first restrict our scope to people with technical background and assume people already have a degree of understanding on how blockchain is used. Then if a developer tells you the README doesn't convey the message clearly, take note of that and appreciate the feedback. Don't say "just trust me it works."
If this is to the general public, you better hire someone who can actually explain to user how it works from a high level giving analogy is always good.
In fact, you should never assume there are two groups of audience. This is not writing API documentation. A README should be really clear to user how to get started (understand what it does and how to start using it). Think about working with a manual. You can't assume everyone know what certain nail is called by nickname. You need to write the actual name with an actual picture. Don't assume. Be general.
"Trust me it works and it's secure" is the worst thing you can sell to anyone today. Of course I will never know how Dropbox handles my files on their server securely, but at least I can understand when my file is transferred over HTTPS it's encrypted in the communication and when they say they are over the cloud I know I can access it anywhere at anytime as long as I have an Internet access and the data center still exist.
And if I don't understand what the software does how can I trust you to deploy this on my own term? How do I even begin debugging problem during installation or configuring my service?
"Trust me" is not an option, especially when someone is trying to get people to use a software. The one thing we need to change is to teach people enough computer so they can make a judgement whether they should trust something or not ("trust me this photo tool is awesome and is free ... minus the free ad program install alongside with it) or trust me this version of browser is nice come to https://evil.com instead of https://mozilla or chrome
Want to send a message ? There once was (and still is) SMTP and IMAP, but now you also have XMPP and all its variants, the Skype protocol, something baked on top of HTTP, ... Who cares what's the technology, as long as the service is there.
Want to watch a movie/listen to a song? There were all those containers and formats, but as long as your movie player works mainstream doesn't care. You can use Napster, KaZaa, eMule, Bittorrent, USENET, direct download, and now there are those proprietary streaming things... Again, as long as the service is fulfilled, "Mainstream" doesn't care.
Same with HTTP and DNS. Very few people know how it works, as long as it works. And the goal of dnschain is actually in line with this: The goal is to use your existing software that already work, and migrate from old-style DNS to DNS-through-namecoin. All transparent from a user point of view.
http://blog.okturtles.com/2014/07/okturtles-demo-at-soups-20...
Understanding how ethereum apps work has network effects, in the sense that once you understand ethereum, you understand every ethereum app.
Best use-case, to me: put your TLS certificates with DANE structures, and you can be sure they aren't spoofed by anyone when someone gets your records. No need for the heavy and centralized DNSSEC.
[0] https://wiki.namecoin.info/index.php?title=Identity [1] https://wiki.namecoin.info/index.php?title=Domain_Name_Speci...
Why not make it so the client sends a list of trusted/non-trusted nodes to the DNSChain server, and the DNSChain server returns the DNS records in addition to signatures from all of the trusted/non-trusted nodes. As such, you will have far more ability to trust that the connection is secure as it would require tampering all of the trusted/non-trusted nodes.
For users who don't want to maintain a trusted node list, the browser could by default have a list (like we have a CA list at the moment). If all of the non-trusted nodes disagree with the trusted nodes, then the connection gives a warning message. If most of the non-trusted nodes agree with the trusted nodes, then it is a treated as a secure connection.
It's not a perfect solution, but this is lightweight, scalable etc.
Ofcause, the problem I see is the 48 hour synchronization as the updated DNS record signatures from the trusted node gets sent to the DNSChain server you make the request to. (DNSChain server would have a local DB which gets syncronised as signatures get updated as to provent multiple connections causing the DNSChain server to be slow).
I hope I've made sense. It could be as easy as installing a 'no restart' Firefox Extension, making it very user friendly.
A second problem with Namecoin, is that you can only register .bit domain names. Couldn't nodes check for an uploaded file on a server to 'give' them the Namecoin equivalent? So example.com can upload example.com/verify-namecoin.html and then it gets given a blockchain based example.com domain name.