[whatwg] `window.location.origin` in sandboxed IFrames.

-- Mike West mk...@google.com, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

[whatwg] Sandboxed IFrames and downloads.

the spec to include a sandboxed downloads flag, which, when present, would block all downloads from inside the frame (or, perhaps only require user confirmation?). This restriction could be lifted via an 'allow-downloads' keyword, if present in the sandbox attribute's token list. WDYT? -- Mike West

Re: [whatwg] Sandboxed IFrames and downloads.

Ping. Is this a terrible idea? :) -- Mike West mk...@google.com, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 On Sat, Feb 2, 2013 at 7:11 PM, Mike West mk...@google.com wrote: It's

Re: [whatwg] Various autocomplete= topics

supports): input type=password autocomplete-username=hober -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

strawman hints at that, but I haven't done the work to find all the places to monkey-patch. -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

hope that's not an overly burdensome taint to track. -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski lcam...@coredump.cx wrote: Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

on the element, and doesn't suggest a way of unsetting that flag. This is conceptually similar to iframe@sandbox's effect on the document loaded into the frame. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

that the site doesn't intend to do wacky manipulation of its credentials on the fly. We can use this to determine how and when the password manager (or credit card autofill, or whatever) ought to refuse to expose information to the renderer. -- Mike West mk...@google.com Google+: https://mkw.st

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 6:27 PM, Michal Zalewski lcam...@coredump.cx wrote: So I might have started this on the wrong foot Naah. Your criticism is a) not unexpected, and b) totally accurate. I hopefully believe that you're overstating the negatives, and underestimating the positives, but

[whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

is the result of an event handler or some other asynchronous action that no longer has a clear call stack back to it's originator. It's unlikely to be implemented. CSP locking down the sources of script is the best we can offer, I think. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

of authors. The central advantage of the writeonly proposal is that it's a trivial drop-in change. It's certainly not the real revolution in authentication that we desperately need on the web, but that's a feature, not a bug. :) -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter

Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

On Thu, Oct 16, 2014 at 11:43 AM, John Mellor joh...@google.com wrote: On 16 October 2014 08:52, Mike West mk...@google.com wrote: * Server stores credentials as `sha512(password + username)`. It might be better to require PBKDF2/bcrypt/scrypt. Yeah, that certainly makes sense. -mike

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

an attribute to a form field. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela Nava e...@google.com wrote: On Thu, Oct 16, 2014 at 11:59 AM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com wrote: OK, so it's just being locked down out of a formality, but has

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

complex for browser vendors, but that's fine and expected, as we're way down at the bottom of the priority heap. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und

Re: [whatwg] Proposal: Two changes to iframe@sandbox

in a frame. If the `allow-popups` flag is set, it can open auxiliary windows. If the `allow-forms` flag is set, it can POST to arbitrary origins. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891

Re: [whatwg] Proposal: Two changes to iframe@sandbox

-auxiliary` keyword (it wouldn't change the behavior of any existing sandboxed frame), and browsers generally throttle the creation of popups in various ways (Chrome allows only one popup per user gesture, for instance). -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12

[whatwg] Proposal: Two changes to iframe@sandbox

` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean browsing contexts, unaffected by the sandbox which spawned them. WDYT? -- Mike West mk...@google.com, @mikewest

Re: [whatwg] Proposal: Two changes to iframe@sandbox

to dropping support for that inside a sandbox. Especially a sandbox without `allow-same-origin`. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg

Re: [whatwg] Proposal: Two changes to iframe@sandbox

it working. I should have made that clear in the proposal, but I think (hope!) this naturally falls out of the way sandbox flags are propagated from frame to frame/window to window. -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany

Re: [whatwg] Proposal: Two changes to iframe@sandbox

be allowed to open new auxiliary browsing context without it) Correct. Both `allow-popups` and the new flag would need to be specified. and maybe is more consistent using 'allow-popups-unsandboxed' ? Or `allow-unsandboxed-popups`. I don't really care how we spell it. :) -- Mike West mk

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 11:59 PM, Justin Dolske dol...@mozilla.com wrote: On Mon, May 11, 2015 at 7:13 AM, Mike West mk...@google.com wrote: The worst offender: linking to things that are .htpasswd protected and it pops up that authentication modal. I wouldn't be terribly averse

Re: [whatwg] Proposal: Two changes to iframe@sandbox

://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-contexts. It's just a definitional thing. -mike -- Mike West mk...@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

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 6:11 AM, Mike West mk...@google.com wrote: 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the `sandbox` attribute, which, when present, would allow auxiliary browsing contexts created by `window.open` and `target=_blank` links to create clean

Re: [whatwg] Proposal: Two changes to iframe@sandbox

/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ. Feedback, positive or negative, would be appreciated (either here or there). :) -mike -- Mike West mk...@google.com, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der

Re: [whatwg] sandboxed iframe allow-auto-play

isn't an interaction we need to worry about. -mike -- Mike West mk...@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

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Tue, Jun 23, 2015 at 11:14 AM, Mike West mk...@google.com wrote: After some conversation with bz (CC'd), I've slightly formalized the description of the feature at https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments. This is something that I'd like to ship in Chrome in the somewhat

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/6/15 5:47 AM, Mike West wrote: Boris, I think this is consistent with your suggestions in https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ and https://groups.google.com

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz dved...@mozilla.com wrote: On Mon, Jul 6, 2015 at 2:47 AM, Mike West mk...@google.com wrote: I've dropped the opener/openee-disowning behavior from my proposal, and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in https

Re: [whatwg] `iframe[@sandbox]`: "sandblaster" JS library for analysis/modification

On Wed, Sep 30, 2015 at 4:56 PM, James M. Greene wrote: > While investigating, I ended up creating a JS library called *sandblaster* > [1] to assist me in analyzing We should probably just provide a mechanism for reading the currently active sandboxing flags. You