- From: Mike West <mkwst@google.com>
- Date: Tue, 12 May 2015 06:18:11 +0200
- To: Brad Hill <hillbrad@gmail.com>
- Cc: David Bruant <bruant.d@gmail.com>, Jim Manico <jim.manico@owasp.org>, WHAT Working Group Mailing List <whatwg@whatwg.org>, Chris Coyier <chriscoyier@gmail.com>, Alex Russell <slightlyoff@google.com>, Ian Hickson <ian@hixie.ch>, Justin Dolske <dolske@mozilla.com>
On Tue, May 12, 2015 at 6:05 AM, Brad Hill <hillbrad@gmail.com> wrote: > Chrome did to that once upon a time (blocking 401 prompts on all > subresource loads) but it opened up a brute-force hole where the lack of UI > allowed extremely rapid testing of HTTP Basic requiring resources, so it > got backed out. I'm not sure where it eventually ended up, but I know it > was an issue. I'd think that for a sandboxed iframe you could be a bit > more draconian and not just short-circuit the prompt but totally forbid > connecting to resources which require an Authentication header, blocking > the avenue of exploit as well as the phishing risk. It seems there should > be very few if any use cases for sandboxed content calling > HTTP-authenticated resources. > Yes. That was how I interpreted the suggestion as well; we'd suppress the dialog by cancelling the request. :) -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) >
Received on Tuesday, 12 May 2015 04:27:59 UTC