We've been doing it wrong.

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

We've been doing it wrong.

Post by indolering »

One idea that has popped up (again) has been to fork the major browsers. I, along with the other core contributors, thought that this was a bad idea because it is much more complicated than just creating add-ons.

However, I began thinking about some of the tertiary browsers and I realized that providing our own browser has three very large upsides:
  • It's a way for users to interact with Namecoin in a way that they are familiar with.
  • It masks the complexity of installing Namecoin.
  • It gives us a steady revenue stream that does not expose to liability for our end-users actions.
Think about it from a users perspective, if they want to go to a .bit website they just think of opening web-browser. There is no understanding of the underlying mechanics, they just want to surf the web and a web browser lets them do that.

Then consider how hard it is to setup a computer to surf .bit websites. Right now, the installation instructions for FreeSpeechMe is some 2,500 words. That's WAY more than what a simple browser download page entails: click here, run installer.

Finally, consider the kind of business OpenDNS has been able to build using 401 catch-pages. While we don't want to do catch redirects at the DNS level, we could customize the 401 error of the browser to include Google search results. It would provide us with ongoing revenue for code bounties, servers, and other costs. And, unlike operating a service such as a DNS server or a web proxy, we have no control nor any right to know what our users are doing (Basically, if you sue us for making money from search revenue then you have to prove Mozilla, Microsoft, and Google should be held liable for their users actions. This is the "right and ability to control" part of the three-part vicarious liability test.).

The reason Namecoin is so difficult to install right now is because of a lack of thin-clients for Namecoin. Once Namecoin gets some SPV/UXTO/SCIP implementations, we won't need to choose between legacy DNS servers or full-blockchain implementations and simple add-ons will become viable. However, even when those solutions come to fruition, we will still need special software to provide access to I2P and Tor hidden services. It also allows us to experiment with DANE, ID, and ways of evading censorship implemented using deep-packet sniffing.

Obviously, someone has to do this work and we are all over-committed as is. But I think it's a path that merits some discussion and it's something we should encourage new contributors to look into.
DNS is much more than a key->value datastore.

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: We've been doing it wrong.

Post by virtual_master »

'We've been doing it wrong.'
Oh man.
The title of the thread sounds to bad to bring something good out from it. :(
Do you want to say that our best developers Jeremy and Daniel are doing wrong ?
Better change to something positive like:
- how should we optimize .bit surfing
or
- future strategy for .bit domains - brainstorming

Just an idea.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

John Kenney
Posts: 94
Joined: Sat Mar 29, 2014 2:20 pm
os: linux
Location: Sheffield, England
Contact:

Re: We've been doing it wrong.

Post by John Kenney »

I was going to mention those freespeechme download instructions, they're far too long & scary, big red warnings about relatively minor technical issues, hard to find a link to the download. That page really needs cleaning up, it's not actually that scary & seems to work OK except in a few small edge cases.

Maybe something like the tor browser bundle, and/or aiming to get it supported in that should be a longer term goal. Email & other protocols are important too.

tosh0
Posts: 43
Joined: Sat Mar 22, 2014 6:48 pm

Re: We've been doing it wrong.

Post by tosh0 »

indoleering is just adding a new idea, get our own piratebrowser in this case bitbrowser or bitexplorer, with a one click install and use.
NMC: more stable than BTC!

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: We've been doing it wrong.

Post by indolering »

virtual_master wrote:'We've been doing it wrong.'
Oh man.
The title of the thread sounds to bad to bring something good out from it. :(
Do you want to say that our best developers Jeremy and Daniel are doing wrong ?
Better change to something positive like:
- how should we optimize .bit surfing
or
- future strategy for .bit domains - brainstorming

Just an idea.
:)
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: We've been doing it wrong.

Post by biolizard89 »

indolering wrote:One idea that has popped up (again) has been to fork the major browsers. I, along with the other core contributors, thought that this was a bad idea because it is much more complicated than just creating add-ons.

However, I began thinking about some of the tertiary browsers and I realized that providing our own browser has three very large upsides:
  • It's a way for users to interact with Namecoin in a way that they are familiar with.
  • It masks the complexity of installing Namecoin.
  • It gives us a steady revenue stream that does not expose to liability for our end-users actions.
Think about it from a users perspective, if they want to go to a .bit website they just think of opening web-browser. There is no understanding of the underlying mechanics, they just want to surf the web and a web browser lets them do that.

Then consider how hard it is to setup a computer to surf .bit websites. Right now, the installation instructions for FreeSpeechMe is some 2,500 words. That's WAY more than what a simple browser download page entails: click here, run installer.

Finally, consider the kind of business OpenDNS has been able to build using 401 catch-pages. While we don't want to do catch redirects at the DNS level, we could customize the 401 error of the browser to include Google search results. It would provide us with ongoing revenue for code bounties, servers, and other costs. And, unlike operating a service such as a DNS server or a web proxy, we have no control nor any right to know what our users are doing (Basically, if you sue us for making money from search revenue then you have to prove Mozilla, Microsoft, and Google should be held liable for their users actions. This is the "right and ability to control" part of the three-part vicarious liability test.).

The reason Namecoin is so difficult to install right now is because of a lack of thin-clients for Namecoin. Once Namecoin gets some SPV/UXTO/SCIP implementations, we won't need to choose between legacy DNS servers or full-blockchain implementations and simple add-ons will become viable. However, even when those solutions come to fruition, we will still need special software to provide access to I2P and Tor hidden services. It also allows us to experiment with DANE, ID, and ways of evading censorship implemented using deep-packet sniffing.

Obviously, someone has to do this work and we are all over-committed as is. But I think it's a path that merits some discussion and it's something we should encourage new contributors to look into.
So, it's been a while since I touched the FreeSpeechMe documentation (I have a habit of coding instead of documenting...), but to my knowledge there's not much in there that exists because it's a Firefox extension rather than a browser. I don't think much of that info would be removable if we switched to a browser bundle.

To my recollection, the main objections I had to a browser fork were (1) violates the Unix philosophy, (2) increases attack surface, (3) forces us to keep up with browser security updates.

Other than that, redirecting users to Google without their consent isn't a great idea; lots of users don't want Google to know anything about them.

All that said, it would be great to get Namecoin integrated into Tor Browser Bundle, as long as we're not responsible for the Firefox/Tor aspects. This is not feasible until some technical issues are dealt with (and even then there's no guarantee that the Tor devs will go for it).
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: We've been doing it wrong.

Post by virtual_master »

biolizard89 wrote: So, it's been a while since I touched the FreeSpeechMe documentation (I have a habit of coding instead of documenting...), but to my knowledge there's not much in there that exists because it's a Firefox extension rather than a browser. I don't think much of that info would be removable if we switched to a browser bundle.

To my recollection, the main objections I had to a browser fork were (1) violates the Unix philosophy, (2) increases attack surface, (3) forces us to keep up with browser security updates.
This may be valid arguments but the overwhelming majority of users wouldn't even understand point (1) and (2) anyway.
Its a tradeoff between security/anonymity and comfortability.
People are valuing very much the usability and comfortability of TBB even if it is not the most perfect solution.
They can go to work or to an internet-coffee and surf on a PC just by inserting an USB-stick with TBB and they don't need admin rights.
For 3 it is only valid if we let the update messages from TBB come through. But we can redirect to a check of our own new bundled version.
Tails also doesn't do differently and you cannot say it is less secure.
And here we came to the next point, another possibility with Tails. See the last points.
biolizard89 wrote: Other than that, redirecting users to Google without their consent isn't a great idea; lots of users don't want Google to know anything about them.

All that said, it would be great to get Namecoin integrated into Tor Browser Bundle, as long as we're not responsible for the Firefox/Tor aspects. This is not feasible until some technical issues are dealt with (and even then there's no guarantee that the Tor devs will go for it).
Many people use TBB but are not aware at all about Google. Having Google as startpage if they pay for it is not a big deal as anonymity is not much concerned anyway if using TBB and users can change anytime the starting page.
The technical difficulties integrating in TBB are valid and you can best evaluate this. However we have a technically easier solution. See the last points.

Integrating Namecoin in Tails
I mean a kind of Tails. I am meaning more a kind of combination between Tails and Khals Namecoin container.
So what exactly I am meaning ?
- Let us take Tails as basis and put it on an USB-stick.
- We put whatever program we need extra on the USB-stick like namecoind or namecoin-qt, a brainwallet, maybe even Electrum for Bitcoin.
- We put the downloaded Namecoin blockchain also in the newest version like in Khal's container.
- Now we re-brand the browser with our logo and will put whatever we need there.
The freespeach addon would be a possibility to preinstall for the browser but not even necessary - as we have all possibilities open to connect to external programs for .bit surfing like nmcontrol and Convergence for Namecoin. Now we have much easier - we have all programs working with Tor.
- Last step after all modifications we pack all together in an archive and we distribute it.
This construct is intended for USB-stick not for CD/DVD as the blockchain need to update and you need to boot with it.

Portable, non-booting solution
This would be created as the above version from Tails but would work like TBB in a highly portable way.
How:
- We take the above created version. However the .bit surfing can be implemented only with programs which doesn't require admin rights.
The freespeach plugin would be ideal. So it would be the above construction with the freespeach addon solution.
- We make it portable like TBB. This would be logically OS specific as it is started in the running OS without rebooting it.
Let us take Windows as example.
We could create a startup program which is starting when you insert the USB-stick and create a menu like it works by portableapps.com from where you could start the browser or Elektrum or a Brainwallet. Tor service and namecoind would start in the background.
Or it could be easier just a .bit surfing browser started. Tor and namecoind in background started also.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: We've been doing it wrong.

Post by biolizard89 »

This may be valid arguments but the overwhelming majority of users wouldn't even understand point (1) and (2) anyway.
Most users also don't understand buffer overflows and bounds checking either. That has no bearing on their importance when developing something.
For 3 it is only valid if we let the update messages from TBB come through. But we can redirect to a check of our own new bundled version.
I don't understand your argument. Update alerts from Tor's servers aren't the issue; the issue is that we would have to commit to quickly releasing a new stable build immediately after Tor releases a new TBB. That's a major commitment. This is a particularly bad issue when we're maintaining our own fork of the Firefox code, which is what I was discussing earlier. Even the Tor devs don't want to maintain forks of major codebases, and they have astronomnically higher resources than we do.
Its a tradeoff between security/anonymity and comfortability.
People are valuing very much the usability and comfortability of TBB even if it is not the most perfect solution.
That's not why the TBB exists. Tor started with a Firefox extension called TorButton, but they were forced to fork Firefox because anonymity features required a Firefox fork. It was not a decision they took lightly. In general, it is agreed that a Firefox extension would have been cleaner and more user-friendly.

As I have stated many times, the most robust method of enabling .bit browsing is probably with a TUN device. This works for all applications on the system, and would support the full .bit feature set. I have a fairly good idea of how this would be done; it's on my to-do list. For just Firefox or TorBrowser usage, an extension is probably the easiest method for the user to install.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: We've been doing it wrong.

Post by indolering »

Let me back up by saying that I certainly didn't mean this as an insult to anyone, I myself rejected the idea of a forked browser out-of-hand at first. But I think we are getting too deep into the meaning of a "fork" - of course a browser add-on is the correct development path. We should just bundle a download with the Namecoin browser add-on preinstalled. We could add some other bells and whistles (meta-links and torrent downloads) and maybe the option for a custom skin, but nothing that couldn't be automated and covered by unit testing.

Tor was a rather minor part of the above proposal and after a quick rethink I agree with Jeremy. The right way to go about integrating with Tor or TAILS is to upstream our changes. I2P does encourage direct integration but we shouldn't take that on unless there is an existing Firefox add-on for it.

A TUN or TAP device might be the simplest solution and if we package it up similar to how OpenDNS packages up it's software, I see no problem with that. When it comes to NXDOMAIN catches, it should be implemented at the application level and have an opt-out option should be clearly presented on each and every NXDOMAIN catch.

We should only add our referral code to whatever search engine the user already uses.

And Jeremy, I agree with you that the documentation is probably necessary, but 2,500 words of dense technical writing is a solid college level thesis paper. Whether the functionality is implemented as a browser add-on or as a TUN server, we need to get a lite-client working first.
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: We've been doing it wrong.

Post by biolizard89 »

indolering wrote:Let me back up by saying that I certainly didn't mean this as an insult to anyone, I myself rejected the idea of a forked browser out-of-hand at first. But I think we are getting too deep into the meaning of a "fork" - of course a browser add-on is the correct development path. We should just bundle a download with the Namecoin browser add-on preinstalled. We could add some other bells and whistles (meta-links and torrent downloads) and maybe the option for a custom skin, but nothing that couldn't be automated and covered by unit testing.

Tor was a rather minor part of the above proposal and after a quick rethink I agree with Jeremy. The right way to go about integrating with Tor or TAILS is to upstream our changes. I2P does encourage direct integration but we shouldn't take that on unless there is an existing Firefox add-on for it.

A TUN or TAP device might be the simplest solution and if we package it up similar to how OpenDNS packages up it's software, I see no problem with that. When it comes to NXDOMAIN catches, it should be implemented at the application level and have an opt-out option should be clearly presented on each and every NXDOMAIN catch.

We should only add our referral code to whatever search engine the user already uses.

And Jeremy, I agree with you that the documentation is probably necessary, but 2,500 words of dense technical writing is a solid college level thesis paper. Whether the functionality is implemented as a browser add-on or as a TUN server, we need to get a lite-client working first.
I'm not certain what you mean about NXDOMAIN catches, can you elaborate? Basically what I was envisioning was having the Tun device forward .bit traffic to a local SOCKS proxy (like the proxy part of FreeSpeechMe) via something like Tun2Socks.

Automating builds of a "Namecoin browser" is one thing, making sure they're reproducible is something else, because ideally you would need multiple developers running the builds on their own machines. That's difficult to automate. Maybe I'm unaware of something, but I believe even the Tor Browser Bundle is not built automatically.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply