[webkit-dev] Adding 'X-Content-Type-Options: nosniff' support for scripts.
Continuing my trend of digging up old threads, I'd like to implement support for 'X-Content-Type-Options: nosniff' when processing script, as discussed way back in 2011: https://lists.webkit.org/pipermail/webkit-dev/2011-November/018557.html. This should be a pretty small patch[1], but because support might require work outside WebKit, I'll implement it behind an ENABLE_NOSNIFF flag[2]. Thanks! [1]: https://bugs.webkit.org/show_bug.cgi?id=71851 [2]: https://bugs.webkit.org/show_bug.cgi?id=109029 -mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Clipboard class plans
Hi folks. I have some work planned on the DOM clipboard classes. I’m not in a big hurry to get this done fast. It’s my side project. But I thought some people might be interested in what I am thinking about doing. I have a good 20% of the project already sitting in my local git repository and I’m going to file a bug or two and start posting patches soon. The major step is to refactor so that Pasteboard is the platform abstraction and Clipboard is a pure DOM class built on top of Pasteboard. To do a good job on that I will probably need help from people willing to tackle platforms other than Mac. I’ve started by doing the refactoring on Mac and putting an #ifdef in place for scaffolding. Here are my notes so far on what I think I’d like to do, in case you’d like to comment. DOM Clipboard class and platform directory clipboard and drag abstraction class (Pasteboard) Get Clipboard.h and DragState.h includes out of commonly-included headers. - Doing this first makes the changes to Clipboard.h require a lot less recompiling. Change DragClient so it uses a Pasteboard object instead of a Clipboard object to pass the identifier of the pasteboard. Make Clipboard a non-polymorphic class with the abstractions in the Pasteboard class. - Each Clipboard will hold a Pasteboard. - Mac first, then each other platform. - Share as much code as possible between platforms in Clipboard; platform differences should be primarily in Pasteboard. - This will add more functions to the Pasteboard class. Make Pasteboard functions const, since Pasteboard identifies a pasteboard--the actual pasteboard contents are outside the class. Pass pasteboards around as const Pasteboard. For operations that are not part of the Clipboard DOM API, have callers get to the Pasteboard and use it, rather than using the Clipboard. Move all Clipboard class code into the DOM directory. - Even platform-specific functions should be there, not in the platform directory. Factor out the non-platform-abstraction parts of Pasteboard that depend on the DOM, Page, Frame, etc. and move that part into the editing directory Move the Mac-specific snapshotting functions out of Frame.h and FrameMac.mm into their own home. - Probably the editing directory. - Change interfaces to be platform independent so the callers don't need to use Objective-C++. - Consider making them cross-platform. Investigate replacing DragImageRef with a more solid abstraction rather than a typedef. - Need to be able to write platform-independent drag code. Change Clipboard functions to match DOM instead of having subtly different names. Eliminate custom bindings for Clipboard. - Move setDragImage element logic out of JSClipboardCustom.cpp bindings into the Clipboard class. - Change return type of Clipboard::types to PassRefPtrDOMStringList instead of ListHashSetString because that's what we support for DOMString[] in our IDL. Or alternatively, do more overloads for toArray so we can use VectorString or ListHashSetString. Make sure Pasteboard checks this is still the current pasteboard when doing write operations with change count on Mac. - Is there an equivalent on other platforms? - Creating a new pasteboard gets the change count each time, which may be excessive; is there a better way to fit this in? Put more of the dragging code inside #if ENABLE(DRAG_SUPPORT). - It seems kind of random what is conditional and what is not. Do something to more clearly separate the dragging and copy/paste code the Pasteboard class. Reduce some of the strange idioms in the Clipboard class - The use of the magic string initialized for dropEffect and effectAllowed is strange. Rename Clipboard to DOMClipboard. Rename Pasteboard to Clipboard. Rename DragState members to eliminate the m_ prefix since it's a struct. Or make it a class. Rename DragState::m_dragSrc to dragSource, or perhaps something even nicer. DOM Event classes Break headers back up into a file per class? - MouseEvent.h has many classes in it. Cut down on DOM event class constructors and create functions. - Should need only one constructor per class, the one that takes the initializer, or possibly the empty one. - Code inside WebCore and WebKit should use one of the two create functions used by the bindings. - Need to put all the arguments into the initializers, but the way they work we can't put RefPtrClipboard into an initializer without including Clipboard.h; might mean we should move initializers into separate headers. EventInit structures called initializers may need some naming work. - Better to have a name without the abbreviation init. - Not sure we should call them initializers since they are just initialization arguments; the name implies they do more than they do. Reduce or eliminate POINTER_LOCK conditionals in MouseEvent.h. - First, not sure it makes sense to have more state in the DOM mouse event for that feature. - Second, if we do it's excessive to do it with ifdefs in the
Re: [webkit-dev] Adding 'X-Content-Type-Options: nosniff' support for scripts.
We should check whether IE still have that behavior (i.e., in the latest version of IE). I remember them running into some compatibility problems with that aspect of nosniff, and I'm not sure if they resolved those issue via evangelism or by adopting our behavior. Adam On Wed, Feb 6, 2013 at 1:33 AM, Mike West mk...@chromium.org wrote: Continuing my trend of digging up old threads, I'd like to implement support for 'X-Content-Type-Options: nosniff' when processing script, as discussed way back in 2011: https://lists.webkit.org/pipermail/webkit-dev/2011-November/018557.html. This should be a pretty small patch[1], but because support might require work outside WebKit, I'll implement it behind an ENABLE_NOSNIFF flag[2]. Thanks! [1]: https://bugs.webkit.org/show_bug.cgi?id=71851 [2]: https://bugs.webkit.org/show_bug.cgi?id=109029 -mike ___ 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] Clipboard class plans
I can help with work required for the chromium port. On Wed, Feb 6, 2013 at 9:13 AM, Darin Adler da...@apple.com wrote: Hi folks. I have some work planned on the DOM clipboard classes. I’m not in a big hurry to get this done fast. It’s my side project. But I thought some people might be interested in what I am thinking about doing. I have a good 20% of the project already sitting in my local git repository and I’m going to file a bug or two and start posting patches soon. The major step is to refactor so that Pasteboard is the platform abstraction and Clipboard is a pure DOM class built on top of Pasteboard. To do a good job on that I will probably need help from people willing to tackle platforms other than Mac. I’ve started by doing the refactoring on Mac and putting an #ifdef in place for scaffolding. Here are my notes so far on what I think I’d like to do, in case you’d like to comment. *DOM Clipboard class and platform directory clipboard and drag abstraction class (Pasteboard)* Get Clipboard.h and DragState.h includes out of commonly-included headers. - Doing this first makes the changes to Clipboard.h require a lot less recompiling. Change DragClient so it uses a Pasteboard object instead of a Clipboard object to pass the identifier of the pasteboard. Make Clipboard a non-polymorphic class with the abstractions in the Pasteboard class. - Each Clipboard will hold a Pasteboard. - Mac first, then each other platform. - Share as much code as possible between platforms in Clipboard; platform differences should be primarily in Pasteboard. - This will add more functions to the Pasteboard class. Make Pasteboard functions const, since Pasteboard identifies a pasteboard--the actual pasteboard contents are outside the class. Pass pasteboards around as const Pasteboard. For operations that are not part of the Clipboard DOM API, have callers get to the Pasteboard and use it, rather than using the Clipboard. Move all Clipboard class code into the DOM directory. - Even platform-specific functions should be there, not in the platform directory. Factor out the non-platform-abstraction parts of Pasteboard that depend on the DOM, Page, Frame, etc. and move that part into the editing directory Move the Mac-specific snapshotting functions out of Frame.h and FrameMac.mm into their own home. - Probably the editing directory. - Change interfaces to be platform independent so the callers don't need to use Objective-C++. - Consider making them cross-platform. Investigate replacing DragImageRef with a more solid abstraction rather than a typedef. - Need to be able to write platform-independent drag code. Change Clipboard functions to match DOM instead of having subtly different names. Eliminate custom bindings for Clipboard. - Move setDragImage element logic out of JSClipboardCustom.cpp bindings into the Clipboard class. - Change return type of Clipboard::types to PassRefPtrDOMStringList instead of ListHashSetString because that's what we support for DOMString[] in our IDL. Or alternatively, do more overloads for toArray so we can use VectorString or ListHashSetString. I think Clipboard.types currently returns an Array. There's a patch in progress to change this to VectorString to remove the need for custom bindings (https://bugs.webkit.org/show_bug.cgi?id=82878 and https://bugs.webkit.org/show_bug.cgi?id=82888). The spec originally specified DOMStringList, but this ended up being changed, since DOMStringList is considered deprecated. Make sure Pasteboard checks this is still the current pasteboard when doing write operations with change count on Mac. - Is there an equivalent on other platforms? Windows has GetClipboardSequenceNumber(); however, Linux has nothing comparable built-in. There are some things like QtClipboard and XFixes that provide a pasteboard changed event that add this functionality. - Creating a new pasteboard gets the change count each time, which may be excessive; is there a better way to fit this in? Put more of the dragging code inside #if ENABLE(DRAG_SUPPORT). - It seems kind of random what is conditional and what is not. Do something to more clearly separate the dragging and copy/paste code the Pasteboard class. Reduce some of the strange idioms in the Clipboard class - The use of the magic string initialized for dropEffect and effectAllowed is strange. Rename Clipboard to DOMClipboard. Rename Pasteboard to Clipboard. Rename DragState members to eliminate the m_ prefix since it's a struct. Or make it a class. Rename DragState::m_dragSrc to dragSource, or perhaps something even nicer. *DOM Event classes* Break headers back up into a file per class? - MouseEvent.h has many classes in it. Cut down on DOM event class constructors and create functions. - Should need only one constructor per class, the one that takes the initializer, or possibly the empty one. - Code inside WebCore and
Re: [webkit-dev] Clipboard class plans
On Feb 6, 2013, at 12:06 PM, Daniel Cheng dch...@chromium.org wrote: I think Clipboard.types currently returns an Array. Clipboard::types currently returns ListHashSetString, and custom bindings translate that into a JavaScript array. There's a patch in progress to change this to VectorString to remove the need for custom bindings (https://bugs.webkit.org/show_bug.cgi?id=82878 and https://bugs.webkit.org/show_bug.cgi?id=82888). Great, that’s exactly what I had in mind. In fact, I did a similar patch locally. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin On Wed, Feb 6, 2013 at 4:06 PM, Alec Flett alecfl...@google.com wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.orgwrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.orgwrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. If there's particular libraries we want to use which have different conventions, the adaptation should be done at the level of interfacing the library. Changing WebKit's conventiones because of one optional dependency does not make sense to me. Regards, Maciej On Feb 6, 2013, at 4:35 PM, Alec Flett alecfl...@chromium.org wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin On Wed, Feb 6, 2013 at 4:06 PM, Alec Flett alecfl...@google.com wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin ___ 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] SerializedScriptValue: signed vs unsigned char
On Wed, Feb 6, 2013 at 4:59 PM, Alec Flett alecfl...@chromium.org wrote: On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. To be fair, there hasn't been a convention in WebKit at all. uint8_t was chosen for SerializedScriptValue roughly two months ago, with specific IndexedDB support in mind: https://bugs.webkit.org/show_bug.cgi?id=104354 - this usage is not widespread, and in fact the only consumer of this type is IndexedDB. If there's particular libraries we want to use which have different conventions, the adaptation should be done at the level of interfacing the library. Changing WebKit's conventiones because of one optional dependency does not make sense to me. Maybe more simply: Vectoruint8_t was chosen very recently to replace String, in support of cleaning up IndexedDB code. IndexedDB would like to use Vectorchar now for further cleanup. Would you feel the same if we were switching from String to Vectorchar? Yeah, We use char all over WebCore to represent a byte, including in SharedBuffer. We should use for SerializedScriptValue for consistency. If we think that uint8_t is better than char to represent bytes, then we should make that change globally in WebCore separately. Adam On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. If there's particular libraries we want to use which have different conventions, the adaptation should be done at the level of interfacing the library. Changing WebKit's conventiones because of one optional dependency does not make sense to me. Regards, Maciej On Feb 6, 2013, at 4:35 PM, Alec Flett alecfl...@chromium.org wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when (ironically) we were hooking up IndexedDB to JSC, just a month or so ago. So far Benjamin objected, and then seems to have rescinded. Glenn, do you depend on SerializedScriptValue's current method signatures? Alec On Mon, Feb 4, 2013 at 5:14 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 4, 2013 at 4:54 PM, Alec Flett alecfl...@chromium.org wrote: Well, nobody is explicitly using LChar with SerializedScriptValue (maybe it should, maybe that's another issue) but I guess this is why I'm asking - I'm happy to just deal with this in IDB with some ugly reinterpret_casts here and there (ok maybe not happy, but satisfied enough) if folks prefer that. I don't personally find uint8_t to be any more intuitive than char, but it sounds like some do. Nevermind... Well, since you never use character types and only raw data, just ignore my comment. As far as I know, it is already common to use signed char for raw data (in the network stack for example). Benjamin On Wed, Feb 6, 2013 at 4:06 PM, Alec Flett alecfl...@google.com wrote: ok, so something else has come up: SharedBuffer. SharedBuffer has an adoptVector method that allows you to adopt Vectorchar... some of the stuff I'm using that interacts with LevelDB is also dealing with SharedBuffer, hence I've had to do some nasty casting from Vectoruint8_t to Vectorchar to allow me to call SharedBuffer.adoptVector() And again, we could tweak SharedBuffer to accept Vectorunsigned char but now we have two subsystems (LevelDB, and SharedBuffer) that seem to prefer char as raw data. Personally outside of WebKit I tend to see more char* as the common denominator for raw bytes. Further, there are no subsystems that actually depend on SerializedScriptValue using uint8_t - it was just what we decided to use when
Re: [webkit-dev] SerializedScriptValue: signed vs unsigned char
On Feb 6, 2013, at 4:59 PM, Alec Flett alecfl...@chromium.org wrote: On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. To be fair, there hasn't been a convention in WebKit at all. uint8_t was chosen for SerializedScriptValue roughly two months ago, with specific IndexedDB support in mind: https://bugs.webkit.org/show_bug.cgi?id=104354 - this usage is not widespread, and in fact the only consumer of this type is IndexedDB. I don't know where you get this idea from -- SerializedScriptValue has always used uint8 buffers. That IndexedDB used Strings and that _it_ changed to uint8 buffers is entirely irrelevant here. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
