- From: Tim Berners-Lee <timbl@w3.org>
- Date: Mon, 5 Jan 2015 07:31:22 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
- Message-Id: <DF83D436-67B2-442F-A094-56CA2D6D7F8A@w3.org>
On 2015-01 -05, at 06:45, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jan 5, 2015 at 12:26 PM, Tim Berners-Lee <timbl@w3.org> wrote: >> They are not. Data is special > > Right. I think you could make your point more clear if rather than > talking about scripts (which could themselves create <script> elements > and such) you instead focused on the use case you care about, loading > some data from another origin. Indeed . The example is loading legacy http: data from a secure web app. > > There's already a problem with that today, it requires the other > origin to use CORS. CORS does not work with a secure app and a http: data site. The wildcard CORS is blocked. Or you have to put your script on a http: page for it to work. Hence my suggestion is is broken to have something work from a http page but not from an https one. > If it does not have that you need to use a proxy This means that the actual application center of mass is moved onto the server. This makes yet another silo. This makes all the user's activity available to the person who runs the proxy. This makes the user's activity available to anyone who subpoenas or cracks the proxy. > (or indeed a native app). Yes. > If you want to authenticate your application it requires the other > origin to support TLS (in addition to CORS). Again, you can use a > proxy to circumvent this (or indeed a native app). > > Not having these restrictions in place enables all kinds of attacks > and classic bugs ;-) > > > -- > https://annevankesteren.nl/ >
Received on Monday, 5 January 2015 12:31:31 UTC