On Fri, Jun 13, 2014 at 6:10 PM, Chris Palmer <palmer@google.com> wrote: > > You and I already seem to agree that BEACON and <a ping> should be > blocked > > and I haven't heard anybody suggest otherwise, so let's remove them from > the > > list. Now, I would guess that there is not much existing <track> or > > <picture>/<srcset> content either, so I think we could probably block > those > > now without any significant compatibility impact. And, I wouldn't be > > surprised if we were to find that there is very little <audio> mixed > content > > either. So, why not just start blocking all of those right away too? > > I would like that. > FYI: Blocking mixed <a ping> and beacon should land in Blink this week. I also added metrics to Chrome about two weeks ago for fonts, track, audio, and video. Not much of a sample size yet, but we should have better numbers in a few weeks. I'm looking forward to nixing them as well. (even things that have the same security considerations like > > <picture>) are blocked. > I think this is probably reasonable, but it's going to be hard to do in Blink. I don't think we have this context when we're fetching the resource and performing the mixed content check. I think active vs. passive is still meaningful, and although somewhat > confusing, the "legacy vs. new" distinction would/should/could go a > long way toward explaining the discrepancy. I also think it's a meaningful distinction, but I agree with Brian that we should restructure the doc to deemphasize _that_ distinction if what we really want to say is "Block everything except the bits and pieces that we can't block without wide-spread breakage." -mike
Received on Monday, 16 June 2014 14:10:48 UTC