From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.60; 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.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 0ED7A77DC3 for ; Tue, 13 Mar 2018 18:53:14 -0700 (PDT) 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 F36F4432 for ; Tue, 13 Mar 2018 18:54:53 -0700 (PDT) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id w2E1sq35005382 for ; Tue, 13 Mar 2018 18:54:52 -0700 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w2E1sq2D005376 for ; Tue, 13 Mar 2018 18:54:52 -0700 Date: Tue, 13 Mar 2018 18:54:52 -0700 (PDT) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20180312125722.GA3901@nautica> Message-ID: References: <20180312071732.GA14308@nautica> <20180212083819.eklhad@comcast.net> <20180312125722.GA3901@nautica> 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] XHR same-domain restriction X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.25 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:53:15 -0000 I'm interested in the discussion that followed here. I don't have a problem with not simply wrapping the fetchHTTP call. It might be a good idea to address this somehow, but I take Karl's point that circumvention is only one 'make' away assuming someone knows what make is. What Dominique is saying about preventing code injection attacks is also important. I think part of the problem is that we are simultaneously a little like firefox/chrome/IE and a little like wget/curl, or for that matter, like 'rm' the C program. The author of rm doesn't write rm and then try to protect you from it, do they? I don't know. Do we have a savvy audience who can worry about their own caution, or a mass audience who we ought to protect from bricking their routers?? > I doubt there are restrictions on xhr domains in other browsers. > If there were such restrictions, one could get around them easily. I am not saying this hasn't been superceded later on by workarounds, but it's part of bedrock, early AJAX information that there is a restriction on the domain, or is supposed to be. W3schools has a lot of outdated pages and is occasionally ridiculed (there was a site called w3fools advising not to use it), but here is their basic AJAX information which I probably "grew up with", or used as a reference in 2007 or 2010: "...For security reasons, modern browsers do not allow access across domains. This means that both the web page and the XML file it tries to load, must be located on the same server. The examples on W3Schools all open XML files located on the W3Schools domain..." So when I reference it as though it's a fact of life, that's where I'm getting it from. After that it bifurcates into what kind of audience you're talking about and what is at stake.