Skip to Content.
Sympa Menu

discuss - Re: [opennic-discuss] Browser extension

discuss AT lists.opennicproject.org

Subject: Discuss mailing list

List archive

Re: [opennic-discuss] Browser extension


Chronological Thread 
  • From: Al Beano <albino AT autistici.org>
  • To: discuss AT lists.opennicproject.org
  • Subject: Re: [opennic-discuss] Browser extension
  • Date: Wed, 04 Oct 2017 08:42:49 +0100

Thanks for looking into this! I'll read the native messaging docs when I have
time.

The issue with B-DNS is that it doesn't support https on opennic domains… not
exactly ideal.

I'll be online on irc from 1700 - 2300 UTC most days. My nickname is albongo.

albino

On 4 October 2017 00:52:18 BST, Rouben <rouben AT rouben.net> wrote:
>I saw Chrome extensions that simulate editing a hosts file (web
>developers
>that need to switch between production and dev environments for
>example),
>so that’s a start, but not the same... one could in theory implement
>their
>own caching resolver like so:
>
>1. Implement a lightweight hostname to DNS resolver using JSON or just
>plain text HTTPS calls. For example:
>GET query: https://www.example.com/opennic_resolve?hostname.example.net
>Response over HTTPS (text/plain):
>
>192.0.2.123 86400
>
>2001:DB8:C0:FF:EE:EE:: 86400
>
>
>The 86400 following the IPs would be the TTL in seconds of the
>corresponding record (e.g. if hostname.example.net was actually a
>CNAME,
>you’d get the TTL of the CNAME, not the underlying A or AAAA records).
>
>2. The extension would query the above web service, and store these
>values
>in an internal data store (sqlite or whatever is available to the API).
>Something like this:
>hostname IPv4/IPv6 TTL queryCTime (when query was made represented as
>ctime)
>
>3. When a request for a domain name is made, and results in failure,
>the
>extension would then take over as follows:
>- check against its own DB/cache and if not found query the web
>service,
>update DB/cache as needed
>- if entry is in cache already, if (currentCTime - entryCTime) >= entry
>TTL
>then update cache from web service. Else, use cache.
>
>The above is very very very rough, please understand.
>
>Anyway, how to do it? One way is native messaging, available on both
>Firefox and Chrome:
>https://developer.chrome.com/extensions/nativeMessaging
>https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
>Even Edge!!
>https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/native-messaging
>
>The issue is that now we have to build binaries or scripts that will
>run on
>ALL major platforms in order for the extension to work, but honestly, I
>don’t see any other way to do it...
>
>Maybe it would be best to exchange thoughts on IRC. Is there a good
>time?
>
>On Sat, Sep 30, 2017 at 03:39 Al Beano <albino AT autistici.org> wrote:
>
>> I looked at the APIs previously, and the only answer I could come up
>with
>> is "not if you want HTTPS".
>>
>> See my original mail below
>>
>> albino
>>
>> -------- Original Message --------
>> From: Al Beano <albino AT autistici.org>
>> Sent: 17 September 2017 18:57:29 BST
>> To: discuss AT lists.opennicproject.org
>> Subject: [opennic-discuss] Browser extension
>>
>> Hi all,
>>
>> I've done some digging around the WebExtension API, and I cannot find
>any
>> way to resolve OpenNIC names in-browser, including the use of HTTPS.
>>
>> There are two possible solutions:
>>
>> 1. create an extension which does not allow for HTTPS. Although there
>is
>> no CA currently widely in operation on OpenNIC, aditaa is working on
>one
>> and there is hope that things could change. Advertising an extension
>which
>> doesn't support HTTPS would be conceding defeat.
>>
>> 2. create an extension which does allow for HTTPS, through the use of
>a
>> proxy server which we control. This is not ideal either, but I think
>it is
>> the better of the two options: users of OpenNIC are already placing
>trust
>> in the operators of T1 and T2 servers to answer queries honestly, so
>if the
>> same people were operating the proxy server(s), the 'attack vector'
>for
>> OpenNIC would remain much the same. This would also mean that the
>proxy
>> server operators could choose which CAs to trust — as long as we only
>trust
>> genuinely trustworthy CAs this would be a good thing because users
>wouldn't
>> see a scary 'Untrusted certificate!' message and use of HTTPS would
>be a
>> seamless experience.
>>
>> The only other potential issue with option 2 is that it could result
>in
>> high resource usage, but if a few people contribute small VPSes with
>> ~50mbps network I don't think there would be any problem.
>>
>> I'm interested to hear your opinions on this. Is a proxy server
>acceptable?
>>
>> Obviously, I'd rather have the plugin support HTTPS 'properly' and if
>> anyone knows how we might be able to so please let me know!
>>
>> albino
>>
>> --------------------------
>>
>> On 30 September 2017 04:36:41 BST, Rouben <rouben AT rouben.net> wrote:
>> >I wonder if there's an API for Chrome (KHTML) and Firefox (Mozilla)
>> >engines
>> >to:
>> >
>> >- override DNS or proxy (less desirable) settings - this would
>enable
>> >lookups of non-OpenNIC domains normally, and OpenNIC domains through
>> >predetermined DNS servers, or perhaps a web API (don't know if DNS
>> >lookups
>> >are possible from within Chrome/KHTML/Firefox/Mozilla API sandbox)?
>> >
>> >- inject root CAs into the browser - again, not sure if that's
>doable
>> >at
>> >all with any API
>> >
>> >So the above two are requirements to do a "proper" or "native"
>> >implementation of OpenNIC content access. Another way to do it,
>would
>> >be to
>> >leverage a proxy like http://proxy.opennicproject.org/ - proxy in a
>> >bottle
>> >so to speak.
>> >
>> >Third option is to publish our own distribution of a web browser,
>like
>> >the
>> >Onion Browser project, but that's a bit extreme... unless perhaps we
>> >can
>> >convince the Tor project to modify their browser to use OpenNIC DNS
>by
>> >default?
>> >
>> >Rouben
>> >
>> >On Fri, Sep 29, 2017 at 9:42 PM, Dustin Souers
><texnofobix AT gmail.com>
>> >wrote:
>> >
>> >> Yes they require valid ICANN.
>> >>
>> >> I was experimenting with modifying the Let's Encrypt Boulder
>server,
>> >but
>> >> OpenNIC users would have to trust a OpenNIC CA.
>> >>
>> >> On Tue, Sep 26, 2017 at 11:47 AM, Amrit Panesar <neo AT 4195tech.com>
>> >wrote:
>> >>
>> >>> A long, long, time ago, in a thread, far, far, away,
>> >>>
>> >>> I recall discussions about using CAcert
>> >>>
>> >>> http://www.cacert.org/
>> >>>
>> >>> but I can't recall if they require an ICANN FQDN.
>> >>>
>> >>> has anyone tried recently?
>> >>>
>> >>>
>> >>> On Tue, Sep 26, 2017 at 5:08 AM, Al Beano <albino AT autistici.org>
>> >wrote:
>> >>>
>> >>>> It's definitely a step forward, but there are a couple of issues
>> >that,
>> >>>> imo, mean we shouldn't promote it as an alternative to just
>> >changing your
>> >>>> DNS settings:
>> >>>>
>> >>>> * The resolvers are run by an unknown party and we have no idea
>> >whether
>> >>>> they are trustworthy — at least with OpenNIC T2s there is some
>> >level of
>> >>>> accountability
>> >>>> * HTTPS doesn't work. Even TOFU TLS is better than nothing, and
>> >we're
>> >>>> moving towards a real CA, so this is important.
>> >>>>
>> >>>> Maybe we could solve these issues, but I think new/fixed
>> >windows/Mac
>> >>>> apps would be a better idea still.
>> >>>>
>> >>>> albino
>> >>>>
>> >>>> On 26 September 2017 11:57:49 BST, Jonah Aragon
>> ><jonah AT triplebit.net>
>> >>>> wrote:
>> >>>> >Wow nice!
>> >>>> >
>> >>>> >I’ll test that this afternoon and add it to the wiki if nobody
>> >else
>> >>>> >does.
>> >>>> >Anyone should be able to edit that site though.
>> >>>> >
>> >>>> >Jonah
>> >>>> >
>> >>>> >On Mon, Sep 25, 2017 at 11:53 PM Dmitry S. Nikolaev
>> ><dn AT mega-net.ru>
>> >>>> >wrote:
>> >>>> >
>> >>>> >> Yes, you right.
>> >>>> >>
>> >>>> >> At this note discussion of the browser exten stopped and new
>> >(about
>> >>>> >CA)
>> >>>> >> started at tlsca-wg AT lists.opennicproject.org
>> >>>> >>
>> >>>> >> If we will continue to talk about browser exten than
>> >>>> >> https://blockchain-dns.info/ added support of OpenNIC TLDs
>> >already:
>> >>>> >>
>> >>>> >> >https://github.com/B-DNS/Chrome/issues/3
>> >>>> >>
>> >>>> >> and after:
>> >>>> >>
>> >>>> >> 1.0.6 (2017-09-18)
>> >>>> >>
>> >>>> >> Add support for OpenNIC TLDs
>> ><https://wiki.opennic.org/opennic/dot>
>> >>>> >(.bbs
>> >>>> >> and others)
>> >>>> >>
>> >>>> >> But there is no info at wiki.opennic.org about it yet.
>> >>>> >>
>> >>>> >> With best regards, Dmitry S. Nikolaev
>> >>>> >> virus_net
>> >>>> >>
>> >>>> >> On 26.09.2017 05:16, rouben AT rouben.net wrote:
>> >>>> >>
>> >>>> >> 0. Browser extension is a brilliant idea, but SSL/TLS is an
>> >issue.
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --------
>> >>>> >> You are a member of the OpenNIC Discuss list.
>> >>>> >> You may unsubscribe by emailing
>> >>>> >> discuss-unsubscribe AT lists.opennicproject.org
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >-----------------------------------------------------------
>> >>>> -------------
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >--------
>> >>>> >You are a member of the OpenNIC Discuss list.
>> >>>> >You may unsubscribe by emailing
>> >>>> >discuss-unsubscribe AT lists.opennicproject.org
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --------
>> >>>> You are a member of the OpenNIC Discuss list.
>> >>>> You may unsubscribe by emailing discuss-unsubscribe AT lists.open
>> >>>> nicproject.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Amrit Panesar
>> >>> http://amrit.be
>> >>>
>> >>>
>> >>>
>> >>> --------
>> >>> You are a member of the OpenNIC Discuss list.
>> >>> You may unsubscribe by emailing discuss-unsubscribe AT lists.open
>> >>> nicproject.org
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --------
>> >> You are a member of the OpenNIC Discuss list.
>> >> You may unsubscribe by emailing discuss-unsubscribe AT lists.open
>> >> nicproject.org
>> >>
>> >>
>> >
>> >
>>
>>------------------------------------------------------------------------
>> >
>> >
>> >
>> >--------
>> >You are a member of the OpenNIC Discuss list.
>> >You may unsubscribe by emailing
>> >discuss-unsubscribe AT lists.opennicproject.org
>>
>>
>>
>> --------
>> You are a member of the OpenNIC Discuss list.
>> You may unsubscribe by emailing
>> discuss-unsubscribe AT lists.opennicproject.org
>>




Archive powered by MHonArc 2.6.19.

Top of Page