Re: [whatwg] Proposal: Two changes to iframe@sandbox
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://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvmentsdiff=9958oldid=9955 It appears that this new keyword as described would still require the use of allow-popups in addition to allow-popups-to-escape-sandbox. Since it doesn't make any sense on its own can you change it so that either keyword allows popups to happen? That it, propose changing [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups keyword. to [Set] The sandboxed auxiliary navigation browsing context flag https://developers.whatwg.org/origin-0.html#sandboxed-auxiliary-navigation-browsing-context-flag, unless tokens contains the allow-popups or *allow-popups-to-escape-sandbox* keyword. (might then require changing -to-escape- to -that-escape-) You question to bz was can you live with it, and I can live with it. I wish it could be shorter, but my attempts (allow-popups-unsandboxed or allow-unsandboxed-popups) weren't much shorter. Keeping allow popups in there is good, especially if it can be used in place of regular allow-popups. using the word sandbox is better than anything about auxiliary contexts. - Dan Veditz
Re: [whatwg] Javascript: URLs as element attributes
On 12/1/10 7:29 AM, Boris Zbarsky wrote: On 12/1/10 3:49 AM, Philip Jägenstedt wrote: I dunno about solid, but the obvious things you can do with javascript: that you can't do as easily with data: are things that are dynamic. That said, in a sandbox the only things that are available as obvious sources of dynamism are |new Date| and |Math.random|. So achieving solidity might take some work. ;) What dynamism does a javascript: url give you that can't be achieved by running an in-page script to generate data: urls? (In a sandboxed context; I don't think we can kill javascript: hrefs in links, however much I'd like to.)
Re: [whatwg] Encrypted HTTP and related security concerns - make mixed content warnings accessible from JS?
On 11/11/10 12:06 PM, Ingo Chao wrote: For https mashups, users will see always a few security warnings in IE or Chrome, because a few components will be delivered via http. Thats good, but I would like to know that, too. The mashup should report that automatically. Hence my question regarding a warning which is accessible via JS. What do you want to know, and what will your page do with that? Simply that something was loaded insecurely? An event that something was loaded insecurely so you can stop it from loading? Detailed knowledge of what URL was loaded insecurely and by whom (not likely to fly)?
Re: [whatwg] Persistent storage is critically flawed.
Ian Hickson wrote: Note that the problems you raise also exist (and have long existed) with cookies; at least the storage APIs default to a safe state in the general case instead of defaulting to an unsafe state. In what way do the storage API's default to a safe state? What unsafe state is the alternative? You've lost me. Compared to cookies storage seems less safe: the default cookie access is to the setting host only, a case that does not even exist with global storage. To publish a cookie to a wider family of hosts the setting host must explicitly set a domain on the cookie. (Ditto path, but that turns out to be illusory protection due to the DOM same-origin policy). Web-app developers aren't complaining they can't read cookies they need from sub-domains, they're complaining when private cookies leak or when they're fooled by a cookie injected at a higher domain (e.g. .co.uk cookies). Let me throw out two alternatives for providing private persistent storage, neither of which complicates the API (though may complicate the implementation). The first piggy-backs on the domain vs host cookie concept as applied to entire storage objects. Each host would have a private persistent storage object that could only be accessed by that host; shared objects would need to be explicitly named. There should be a difference in how the two types are named a) using the cookie domain nomenclature to indicate the similar concepts www.foo.com could represent the host storage only accessible to that host, and a leading '.' in .www.foo.com would represent a shared storage area. You could argue that people will forget the dot as they do with cookie domains, but they only do with cookies because UA's let them get away with it. b) another choice would be to make globalStorage[''] magic and mean the private storage for the current host. No one is going to implement universally accessible storage (the spec even recommends against it), you could just take that out of the spec and reuse it for this. All other named areas would be shared as described by the spec. The second alternative would be to have private and shared storage items within a single storage area. I know you weren't keen on adding another attribute like secure, what if instead there was a convention such as keys which start with an underscore are private and can only be accessed if the current host matches the storage area domain. My personal preference is for 1b -- use globalStorage[''] as the non-shared storage area. -Dan Veditz
Re: [whatwg] a href= ping=
Thomas Much wrote: - If people don't want this feature, you'll have to provide a switch to turn it off. - If it can be switched off, websites will use the old, hidden ways to track users. Can't you say the same about cookies? Many people are up in arms about tracking and browsers do provide blocking tools, yet the vast majority of people leave them on and very few sites bother to use the old way of tracking state by passing it as URL query parameters.
