From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.61; helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net; receiver= Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.61]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 8195C779FB for ; Sun, 26 Nov 2017 19:18:25 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id D0D443DC for ; Sun, 26 Nov 2017 19:20:00 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id vAR3Jx3r012024 for ; Sun, 26 Nov 2017 19:19:59 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id vAR3JxHn012018 for ; Sun, 26 Nov 2017 19:19:59 -0800 Date: Sun, 26 Nov 2017 19:19:59 -0800 (PST) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20171026174341.eklhad@comcast.net> Message-ID: References: <20171016072958.eklhad@comcast.net> <20171026174341.eklhad@comcast.net> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Edbrowse-dev] data-* attributes / new work on RC X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 03:18:25 -0000 On Sun, 26 Nov 2017, Karl Dahlke wrote: > I'm still in a bit of a quandary regarding an onclick function that doesn't complete because of an edbrowse error or shortcoming. I guess it would be good to give it some kind of toggle. If I am on a site where I can accidentally buy an elephant with my credit card, then I am worried about anything being permitted if the site is in a broken state, even where "broken state" is defined very conservatively, meaning one or more runtime errors whatsoever. But the problem is that those types of web actions are mixed together with sites where the goal is to read plain text, or write plain text, or something with no danger, something low key, and in that case we can lean towards the permissive. If you remember George something, the candy store that we didn't get working in time for Christmas gifts a couple years ago, I seem to remember there was something at the top that said this: you are logged in you are not logged in Where, possibly, what's going on is that these these strings are both sitting in html, and the page JS is supposed to erase whichever one is NOT the case. But say the page JS broke earlier along and never erased one. This is bad. It's a minefield. Maybe we should be even more conservative than we are already, meaning that it might be good to fail all links or just refuse to load. But if the user KNOWS that it is experimental and wants to do it anyway, they can set a certain flag. We should just warn them, like requiring an opt-in. Because otherwise the gravity of the situation may not be clear. It seems humorous. "Logged in, not logged in. How can I be both logged in and not logged in at the same time. It must be some kind of glitch. The site seems to work though..." And if they then go on to do something successfully, I now have a quandary also because they have gotten some use out of it even though it is a problem to plop someone down in a semi-broken page where they are going to form impressions based on surface appearances.