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
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
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
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
/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
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
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
://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
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
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
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
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
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
-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
` 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
31 matches
Mail list logo