Re: [webkit-dev] Best way to disable JavaScript
On Sun, Mar 17, 2013 at 8:56 PM, Geoffrey Garen gga...@apple.com wrote: Unfortunately, you can't implement CSP that way. :( OK, let's consider this a proposal for how the disable javascript setting should behave, and leave CSP out of it. Consider the case of two same-origin iframes A and B. Suppose A has a restrictive CSP policy (say that bans everything) and B doesn't. If B uses the DOM to insert a script element into A, then CSP should block that script element from executing. Stripping script tags at parse time won't. FWIW, I interpreted the phrases enforcing a directive prevents the protected resource from performing certain actions That text is non-normative. The introductory phrase to that sentence is generally speaking. The normative requirements are more specific. :) and Enforcing a CSP policy should not interfere with the operation of user-supplied scripts as indicating that CSP applied to the resource as loaded from its origin only, and not to other scripts operating on the resulting DOM. In that sentence, user-supplied scripts is intended to refer to user scripts or content scripts from the user agent's extension system. There isn't a great way to refer to those concepts in specs because they're not really part of the open web platform. What is the CSP-expected behavior if a user-supplied script inserts an attribute event handler, javascript: URL, regular event handler, timer, or script element in order to do its work? There's a SHOULD-level requirement that the user script act as normal. That requirement is somewhat aspirational in the sense that no user agent implements it perfectly. We've made some improvements in that resource loads initiated by content scripts correctly bypass the page's CSP policy, but we have more work to do in order to make inline event handlers and JavaScript URLs created by content scripts bypass the page's CSP policy. I noticed that the CSP specification was still in draft form. Is it too late to modify this constraint? Content-Security-Policy 1.0 is a W3C Candidate Recommendation. The WebAppSec working group is working on Content-Security-Policy 1.1. If you'd like to contribute your feedback on CSP, please join the WebAppSec working group. Thus far Apple has not joined the working group and therefore hasn't been able to contribute to the standard. To me, the defense against XSS seems pretty weak if the JavaScript content isn't stripped from the resource. I'm sure the working group would be interested in your point of view. However, I'm sorry that I'm unable to take technical feedback outside the context of the working group due to IPR concerns. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Currently, we have two different ways to disable JavaScript execution: (1) Paste / Drag n Drop / editing: Remove script elements and script attributes from untrusted source markup at parse time. (2) JavaScript disabled setting / Content Security Policy: Check settings and/or CSP at runtime. There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. I'm not sure I understand: We only invoke canExecuteScript for scripts in the main world, so running extensions (or anything else that's running in an isolated world) should not be affected. Also, the actual permission check is done via FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking e.g. only scripts from the web, but not from the inspector should also be possible. best -jochen As a defense against phishing attacks, mail clients and other web content readers disable JavaScript. This means that they can't implement pieces of their UI in JavaScript. (FWIW, WebKit violates the CSP specification in this regard: Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.) * It subjects users to XSS attacks. Runtime checking mode leaves inert JavaScript in the untrusted document. This is a risky proposition. Operations that clone or adopt nodes from the untrusted document unwittingly re-vivify that inert JavaScript, subjecting the user to attack. Experience shows that this is a difficult programming model to get right. * It's hard to verify. We have 18 different call sites to canExecuteScripts() in WebKit, not counting the call sites that pertain to plug-ins. Are you confident we've caught all the right places? Do you know if the feature you just added needs to call canExecuteScripts()? * It's two different ways to do the same thing. Simplicity is a goal of the WebKit project. Proposal: If -- for any reason -- JavaScript is disabled in a given document, the document parser will elide all JavaScript. This means that runtime checks can be removed. One potential downside to this proposal is that it changes the document's internal structure. Since the changes are not generally observable, since they only take place when we're already making much bigger changes by preventing whole scripts from running, and since we haven't seen any compatibility problems from our paste / drag n drop / editing behavior in this regard, I think this downside is acceptable. Another potential downside is that CSP errors will be reported at parse time instead of runtime. FWIW, some authors might see this as an upside. Any objections? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] rolling out a buggy security patch
On Ter, 2013-03-12 at 02:26 -0700, Maciej Stachowiak wrote: I am still curious who has access to the commit bot's bugzilla account. Is a small set of known people, is it a large set, is the password sitting around somewhere that others may get at it? I do not recall this being answered at the time, or perhaps I have forgotten. If the set with access is a small set of known people who are willing to be identified and be in the security group themselves (or already are), then I am personally fine with it. I'm a bit late to the party but in my case, the EWS bots I maintain (kov-gtk-ews and kov-ec2-gtk-ews) both have mail accounts to which only I have access. I used to run them using my GNOME email address, which meant they had access to security bugs and processed security patches (since I have access), but I decided to split them to a different account since filtering of bugzilla mails that mattered to me was getting quite complicated. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On 18 March 2013 13:00, Jochen Eisinger joc...@chromium.org wrote: On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Currently, we have two different ways to disable JavaScript execution: (1) Paste / Drag n Drop / editing: Remove script elements and script attributes from untrusted source markup at parse time. (2) JavaScript disabled setting / Content Security Policy: Check settings and/or CSP at runtime. There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. I'm not sure I understand: We only invoke canExecuteScript for scripts in the main world, so running extensions (or anything else that's running in an isolated world) should not be affected. Inspector injected scripts will be in main-world right? Sorry in-case I'm wrong :) Also, the actual permission check is done via FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking e.g. only scripts from the web, but not from the inspector should also be possible. best -jochen As a defense against phishing attacks, mail clients and other web content readers disable JavaScript. This means that they can't implement pieces of their UI in JavaScript. (FWIW, WebKit violates the CSP specification in this regard: Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.) * It subjects users to XSS attacks. Runtime checking mode leaves inert JavaScript in the untrusted document. This is a risky proposition. Operations that clone or adopt nodes from the untrusted document unwittingly re-vivify that inert JavaScript, subjecting the user to attack. Experience shows that this is a difficult programming model to get right. * It's hard to verify. We have 18 different call sites to canExecuteScripts() in WebKit, not counting the call sites that pertain to plug-ins. Are you confident we've caught all the right places? Do you know if the feature you just added needs to call canExecuteScripts()? * It's two different ways to do the same thing. Simplicity is a goal of the WebKit project. Proposal: If -- for any reason -- JavaScript is disabled in a given document, the document parser will elide all JavaScript. This means that runtime checks can be removed. One potential downside to this proposal is that it changes the document's internal structure. Since the changes are not generally observable, since they only take place when we're already making much bigger changes by preventing whole scripts from running, and since we haven't seen any compatibility problems from our paste / drag n drop / editing behavior in this regard, I think this downside is acceptable. Another potential downside is that CSP errors will be reported at parse time instead of runtime. FWIW, some authors might see this as an upside. Any objections? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On Mon, Mar 18, 2013 at 7:27 AM, Arunprasad Rajkumar ararunpra...@gmail.com wrote: On 18 March 2013 13:00, Jochen Eisinger joc...@chromium.org wrote: On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Currently, we have two different ways to disable JavaScript execution: (1) Paste / Drag n Drop / editing: Remove script elements and script attributes from untrusted source markup at parse time. (2) JavaScript disabled setting / Content Security Policy: Check settings and/or CSP at runtime. There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. I'm not sure I understand: We only invoke canExecuteScript for scripts in the main world, so running extensions (or anything else that's running in an isolated world) should not be affected. Inspector injected scripts will be in main-world right? Sorry in-case I'm wrong :) AFAIK they're in an isolated world (of course unless you type some javascript into the console, that would be executed in the main world and then be blocked) If the inspector scripts were injected into the main world, the page could mess with them And the inpsector frontend is also running its scripts in the main world, but that is easy to whitelist. -jochen Also, the actual permission check is done via FrameLoaderClient::allowScript and ::allowScriptFromSource, so blocking e.g. only scripts from the web, but not from the inspector should also be possible. best -jochen As a defense against phishing attacks, mail clients and other web content readers disable JavaScript. This means that they can't implement pieces of their UI in JavaScript. (FWIW, WebKit violates the CSP specification in this regard: Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.) * It subjects users to XSS attacks. Runtime checking mode leaves inert JavaScript in the untrusted document. This is a risky proposition. Operations that clone or adopt nodes from the untrusted document unwittingly re-vivify that inert JavaScript, subjecting the user to attack. Experience shows that this is a difficult programming model to get right. * It's hard to verify. We have 18 different call sites to canExecuteScripts() in WebKit, not counting the call sites that pertain to plug-ins. Are you confident we've caught all the right places? Do you know if the feature you just added needs to call canExecuteScripts()? * It's two different ways to do the same thing. Simplicity is a goal of the WebKit project. Proposal: If -- for any reason -- JavaScript is disabled in a given document, the document parser will elide all JavaScript. This means that runtime checks can be removed. One potential downside to this proposal is that it changes the document's internal structure. Since the changes are not generally observable, since they only take place when we're already making much bigger changes by preventing whole scripts from running, and since we haven't seen any compatibility problems from our paste / drag n drop / editing behavior in this regard, I think this downside is acceptable. Another potential downside is that CSP errors will be reported at parse time instead of runtime. FWIW, some authors might see this as an upside. Any objections? Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: ... There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. The web inspector works even with JS disabled in Safari (I filed the very first bug about this actually back when it crashed :)) and I just tested and Reader works fine too. Are there any examples of browser provided UI that actually breaks with JS disabled? I'm pretty sure those all run in different worlds. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best way to disable JavaScript
On Mon, Mar 18, 2013 at 9:49 AM, Elliott Sprehn espr...@chromium.orgwrote: On Sun, Mar 17, 2013 at 8:26 PM, Geoffrey Garen gga...@apple.com wrote: ... There are problems with mode (2): * It breaks features that are implemented in JavaScript. The Web Inspector, bookmarklets, extensions, Safari Reader, and Safari autofill all run JavaScript. This means that they break when users disable JavaScript. The web inspector works even with JS disabled in Safari (I filed the very first bug about this actually back when it crashed :)) and I just tested and Reader works fine too. Are there any examples of browser provided UI that actually breaks with JS disabled? I'm pretty sure those all run in different worlds. in chromium, e.g. the ftp directory listing is generating by javascript running on the page in the main world (so we whitelist directory listings for javascript blocking) -jochen - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Thu, Mar 14, 2013 at 4:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 14, 2013 at 12:55 PM, Dean Jackson d...@apple.com wrote: On 15/03/2013, at 6:50 AM, Dana Jansens dan...@chromium.org wrote: On Thu, Mar 14, 2013 at 3:46 PM, Dean Jackson d...@apple.com wrote: I'm not sure I like this proposal. Why is canvas special? Why doesn't img get an opaque attribute (or flag)? Why not every element? There is ongoing work to infer opaqueness in every other kind of element when possible. See for example https://bugs.webkit.org/show_bug.cgi?id=70634 Yes, I'd prefer to infer it rather than specify it. For example, I could infer that a canvas is opaque if it has a non-transparent CSS background-color. I like this approach. It means that developers don't have to explicitly use this feature to get the performance benefits. In fact, this is the preferred performance optimization approach on the Web. We don't provide explicit APIs to optimize performance. We make sensible APIs which allows us to implement more optimizations on common cases behind the scene. The problem is, automatically determining opacity automatically may itself incur a performance hit. For example, it would be impossible to determine if putImageData() was going to result in an opaque canvas without inspecting each pixel. By simply describing the use case and constraints up front, you allow the user agent to optimize what it could not otherwise do. The problem is compounded for subpixel antialiased text, where determining automatically when it is safe to use can require double the memory or VRAM, and potentially double the rendering time, due to canvas being an immediate mode API, rather than retained mode like most of the rest of the DOM. See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038958.html. For that reason, it would still require an opt-in in order not to impact the performance of existing pages. At any rate, I appreciate your feedback, and welcome you to contribute to the whatwg thread. Stephen - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New web-facing canvas feature: opaque attribute
On Thu, Mar 14, 2013 at 5:23 PM, Dean Jackson d...@apple.com wrote: On 15/03/2013, at 8:06 AM, Gregg Tavares g...@google.com wrote: Because it's not the same as fillRect(0, 0, width, height) on an empty canvas. The canvas itself has alpha (unless we add the option to not have it as has been proposed). The contents of the canvas has to stay as the user created it. If I draw with rgba(255,255,0, 0.5) I expect if I read data out of the canvas or draw that canvas into another canvas I'll get that color, not the color blended with the css background. Yes, this is what I said in another email. Maybe I'm misunderstanding this, but if the main concern is to guarantee nice subpixel-antialiased text in canvas (but not anywhere else, such as the 99.99% of places where people draw text) then well, I'm still not convinced opaque is a great idea :) Especially not as an HTML attribute. There are obviously ways to get around the problems you mentioned above (e.g. two buffers + two draws, or keeping a display list until someone wants to read out, etc) and, even more obviously, they have significant problems. It just seems to me that we're trying to address the issue of wanting nice looking text with a very specific solution on one element. Maybe we should consider what we could do across the platform? Canvas is somewhat different from the rest of the web platform. Since most DOM rendering is essentially retained mode, you always have the option to decide at render time whether or not to use subpixel antialiasing, or to re-render a previously-rendered buffer when necessary (and Chrome and Safari already do this). Since Canvas is immediate-mode, you don't have that option. If a canvas is drawn once, then later rotated via CSS, the is LCD text legal probe is now stale. That said, using the opaque attribute (or alpha:none) doesn't completely solve this either. It only guarantees that at least subpixel AA text within the canvas itself will not fringe. There's no guarantee that it won't when transformed via CSS (or WebGL) later. As you point out, the fully-automatic solutions to those problems (which have been discussed over on whatwg) themselves have unpleasant performance implications, or complexity of implementation, and don't entirely solve the problem either (e.g., canvas-WebGL). My preference is actually for a canvas context attribute which enables subpixel antialiased text unconditionally. It makes no promises at all about immunity from color fringing, but gives the power to the developer (a fully-loaded footgun). Native immediate-mode graphics APIs have this capability, so it seems natural to provide the same power to the web platform, IMHO. But let's continue that discussion on whatwg, since it's not specific to WebKit. Stephen Dean So, the canvas has to be blended if there's alpha. There's no magic getting around that. The only way around it is to give the user a way to say no alpha. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
