- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 5 Jan 2015 18:49:11 +0100
- To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
- Cc: WebAppSec WG <public-webappsec@w3.org>
On Mon, Jan 5, 2015 at 6:24 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > On 01/05/2015 11:40 AM, Anne van Kesteren wrote: >> a) we already allow this to some extent (see "Mixed Content") so it's >> not the best carrot > > Currently only for images and other "passive" or "optionally-blockable" > content, right? As far as I know. >> c) executables are not bound by these limitations and are currently >> leapfrogging the web on phones > > those executables are not using the network in a secure way. they are > actively leaking information about their users. This is not something > to emulate. Agreed, and these kind of holes are used as attack venues (e.g. time synchronization on all major operating systems happens without authenticated encryption). However, to someone trying to develop a simple app this kind of papercut might be frustrating enough to switch platforms before even considering why there's such a limitation. >> d) we are in fact planning on allowing tainted cross-scheme responses >> due to service workers and point a) above (for images, sound, video) > > Is this any different from passive mixed content? Not in utility, but in API. I don't think enough people have scrutinized this to find out if there are actual differences. Fetch and Service Workers have seen very little public security feedback. > The right fix for passive mixed content is to gradually deprecate it > further, not to expand its scope. We restricted Service Workers to TLS, but did not want to make them so restrictive as to also not allow any form of Mixed Content that would "normally" be allowed. That was seen as to prohibitive. I would have rather tried forcing that and relaxing later, but alas. -- https://annevankesteren.nl/
Received on Monday, 5 January 2015 17:49:37 UTC