[art] Fwd: Please approve a mailing list or inform me how to Create a mailing list for discussing these projects

pradeep@explodingmoon.org Tue, 24 July 2018 12:07 UTC

Return-Path: <pradeep@explodingmoon.org>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF3B1277BB for <art@ietfa.amsl.com>; Tue, 24 Jul 2018 05:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.663
X-Spam-Level:
X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=explodingmoon.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSdhYpX3VleC for <art@ietfa.amsl.com>; Tue, 24 Jul 2018 05:07:24 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DF0130E8D for <art@ietf.org>; Tue, 24 Jul 2018 05:07:24 -0700 (PDT)
Received: from cmgw13.unifiedlayer.com (unknown [10.9.0.13]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 92E8017628D for <art@ietf.org>; Tue, 24 Jul 2018 06:07:23 -0600 (MDT)
Received: from box439.bluehost.com ([69.89.31.239]) by cmsmtp with ESMTP id hw67fSg6PYe1jhw67f4SL4; Tue, 24 Jul 2018 06:07:23 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=explodingmoon.org; s=default; h=MIME-Version:Content-Type:Subject:To:From: Message-ID:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mnAbfw60OKAkUThA2AXP7FlXvi0IUuxJJYqsthXZBDM=; b=I8b5w69RB+W7YTaVQ6WdauRnVQ qQAlmKg8+qJL3ISfW6QKl+rQQ9EDtSaFkDayaFJ/Xwukyw0rS7ZNg7Gst19Q52VdiHQeL73SzNK2N XaDZSHcLjiVdOFh+Sx6UY97ROGtUf+xA5uoQz3a7M+I/mzJsWUtiI/26S1YCnljjYuPnGVx/+OZd/ NTbDZvxfVVzGDzPvunT7LFIgqpI0e9gMI4eKDZYxT7BWH0hNj3nZ0yLgDkHRSMmYMU6lc9hlo4vDS Ww+nom1kv8q5nlu0cBbbzIii1FcUzekAbnhUfcyhhw/W8KWFeam0Gf6u9vOSp+dZburEigvyzbzdb nZkfcgkQ==;
Received: from [127.0.0.1] (port=25009 helo=box439.bluehost.com) by box439.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <pradeep@explodingmoon.org>) id 1fhw67-001w2r-5c for art@ietf.org; Tue, 24 Jul 2018 06:07:23 -0600
Received: from 112.133.229.115 ([112.133.229.115]) by box439.bluehost.com (Horde Framework) with HTTPS; Tue, 24 Jul 2018 06:07:22 -0600
Date: Tue, 24 Jul 2018 06:07:22 -0600
Message-ID: <20180724060722.Horde.gsPpnBoXjf5POrdlnxHcGYy@box439.bluehost.com>
From: pradeep@explodingmoon.org
To: art@ietf.org
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset="utf-8"; format="flowed"; DelSp="Yes"
MIME-Version: 1.0
Content-Disposition: inline
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box439.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - explodingmoon.org
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1fhw67-001w2r-5c
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (box439.bluehost.com) [127.0.0.1]:25009
X-Source-Auth: pradeep@explodingmoon.org
X-Email-Count: 19
X-Source-Cap: ZXhwbG9kaTQ7ZXhwbG9kaTQ7Ym94NDM5LmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/YN-UJ_8zkqMqnbZluxZEge3FLkg>
Subject: [art] Fwd: Please approve a mailing list or inform me how to Create a mailing list for discussing these projects
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2018 12:07:27 -0000

----- Forwarded message from valdis.kletnieks@vt.edu -----
    Date: Sat, 21 Jul 2018 05:12:17 -0400
    From: valdis.kletnieks@vt.edu
Subject: Re: Please approve a mailing list or inform me how to Create  
a mailing list for discussing these projects
      To: pradeep@explodingmoon.org
      Cc: ietf-action@ietf.org, ietf@ietf.org

On Fri, 20 Jul 2018 23:56:31 -0600, pradeep@explodingmoon.org said:
> Hello
>
> Please approve a mailing list for these drafts or inform me of
> procedure how to Create
> one.
>
> https://datatracker.ietf.org/doc/draft-pradeepkumarxplorer-httpi/
> https://datatracker.ietf.org/doc/draft-pradeepkumarxplorer-httpuserinfo/

These are both one-paragraph drafts calling for solutions to problems  
that have
been solved quite some time ago.

'httpi://' isn't needed, because we already have all the pieces we need to do
this.  In fact, if anything, many websites have so many "related" and "you
might be interested in" links that we've coined the term "clickbait" for
attempts to get your attention among the mass of links.  And let's face it -
this is a service that should be under the user's control.  This has two
results:

1) It doesn't need to be sent to the destination site so they can decorate the
page they're sending you, so a new protocol isn't needed.

2) Since it's better done by the user, what you *really* want is a browser
extension that does all the markup and searching, without the user even having
to type 'httpi://'.  For example, see how Chrome or Firefox can deal with the
user typing a search string into the URL bar, and giving suggested completions
- each new set of completions was an entire new query from the browser to a
search engine.  Or see any of the many browser extensions that do real-time
markup of pages - everything from replacing all pictures of Donald Trump in
news stories with pictures of kittens, to extended search and annotation, to a
whole bunch of other things:

Annotation:  
https://www.maketecheasier.com/google-chrome-extensions-annotate-text-on-the-web/
Searching for related terms:  
https://www.pcworld.com/article/2158690/improve-your-search-chops-and-save-time-with-these-chrome-extensions.html
Word definitions:  
https://www.makeuseof.com/tag/7-chrome-extensions-lookup-words-meanings-browse/

(Think for a moment about how the web extension knows that the picture
is one of Donald Trump... that's not as easy as it looks...)

And userinfo isn't needed either - we already know how to do  
authenticated user
via any number of means - anything from per-user PKI certificates, to userid/
password schemes, to 2-factor authentication with physical tokens or biometric
information, to a whole collection of other methods.

As your userinfo draft says:

     " Right now to hide sensitive or subscription based information i  
have to implement username
     password restrictions in the website code i am publishing.I  
should be able to say that
     only a HTTP client request that has in addition to location and  
IP address some User information
     should be served information from my website."

You probably want to find out who Jeff Bezos is, and why his company was able
to work around this problem and make billions of dollars.  Also,  
you'll need to
explain *why* "you should be able to", and why it requires a new protocol, and
why other solutions aren't sufficient.

Hint 1 - how do weather.com and  Google Maps know where you are? (Google even
knows which way I'm facing with the cellphone.. think about that for a bit
while you think about how you're going to explain a new protocol is needed to
do that...)

Hint 2 - the Internet is growing increasingly mobile - so "location" isn't a
very reliable identifier any more.  I've paid utility bills from a laptop
tethered to a cellphone while at a Boy Scout camp 6 hours drive from where I
live - so it isn't safe to say that "me" is only at my apartment or my office.
In addition, if it reports "the wireless network at Virginia Tech" as my
location, that doesn't separate me from all the other users, because that
"location" is a single wireless SSID that spans 2,000+ access points in 200
buildings and over 19,000 users during weekday afternoons when classes are in
session.

In short, "Me" isn't tied to a location, and a location usually doesn't
identify "me" as opposed to everybody else using the network/cellphone at that
location.

Hint 3 - you still have an authentication issue.  You're unclear whether your
website should get the information as part of the user's http request, or from
a third party. If you're getting it from the user, you'd just re-invented the
very bad idea of user-side authentication - you're relying on the user to be
honest and not send you false authenticators (and of course, the Bad Guys(tm)
will send falsified information).  If you're calling a third party, you avoid
the user-side authentication problem, but now have a different problem - you
have only the information the user provided - an IP address and *maybe* a
userid/password, as information that you can send this third party to get your
"userinfo" data.

Hint 4 - you can work around those problems in Hint 3 if you're clever - at
which point you've re-invented "identity provider services" such as  
Shibboleth:
https://www.shibboleth.net/ which can be used for cross-organization
single-sign-on, and leveraged to provide services such as EduRoam:
https://www.eduroam.org/ - the end result is that I can be visiting Europe, go
to Riga Technical University, and authenticate to their wireless network - but
only if I know my userid/password at Virginia Tech and have either a specific
Yubikey 4 with me, or one of several other 2-factor authenticators  
supported by
Virginia Tech.  One of those involves calling my cellphone (which has a phone
number assigned to the southwest part of Virginia, in the US - and having it
ring even if I'm in eastern Europe. Think about that for a moment)

And all this stuff gets done without any new protocols being needed...

To get a mailing list for these proposals, you'll have to convince people that
these solved problems are in fact not solved, and explain what's wrong  
with the
solutions, and do so in a way that demonstrates that you do in fact  
know what's
already doable without these new protocols....

Good luck, you're going to need it....

----- End forwarded message -----