Re: [webkit-dev] ASSERT vs. RELEASE_ASSERT
On 2024-04-01 16:18, Michael Catanzaro via webkit-dev wrote: > Hi, > > Just brainstorming, but I generally think it's worth enabling way more > assertions in production builds to the extent we can do so without > unacceptable performance impact. My ideal would be to rename ASSERT() to > SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make release > asserts the "default" type of assert. But I'm not ambitious enough to attempt > that. Notably, this would in many cases downgrade the severity of security > bugs, since hitting a RELEASE_ASSERT() is at worst a denial of service issue. > Curious what other WebKit developers think about this. > > Michael I'm not suggesting this has the same result as what you propose but I think it's worth mentioning the CMake build supports `-DENABLE_ASSERTS` on Release builds now and this was always possible on macOS. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fw: Request for assistance
On 2022-10-09 15:35, anonymousjune1935-webkit--- via webkit-dev wrote: > I believe this question belongs here. If not, please direct me > somewhere else that may be more appropriate. > I'm using an Android app, that MAY use WebKit for it's interactions. > Regardless, the app owners aren't particularly helpful, and suggested > this is an "Android", or perhaps "GBoard" issue. I found my way to > this mailing list via Edge open-source licensing acknowledgements. Hi, You can be confident it does not belong on this mailinglist. License acknowledgements can be very deceiving. Edge for example may acknowledge WebKit because its based on Chromium which many many years ago was based on WebKit. This is history and Edge has a completely different upstream than WebKit. Anyway this has nothing to do with the application or any browser engine; On Android you have an autofill service (which looks to be configured to be Edge) which stores this data. You can probably open Edge and delete it there or disable it in system settings by searching for "Autofill service". This is all very off topic but I hope it helped. Good luck. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for Position: Cross-Origin-Resource-Blocking (CORB)
On 2022-03-29 10:46, Patrick Griffis via webkit-dev wrote: > ... > > I believe directly going to ORB and skipping CORB is not a bad idea and > something I could work on if that is the preferred spec. Thinking about this a bit more and discussing it with others here's what I've found: - All browsers are moving to ORB, Chrome will support it. - No browser currently ships or implements ORB. - ORB is by design stricter than CORB. So there is a risk of being an early adopter. There aren't tests in WPT for this to test against, there aren't other implementations to compare with, and there is a chance of regressions on websites. Given that I think there is some value starting with CORB; It accomplishes some of the same things in a less strict and widely supported way and there is a transition path from CORB->ORB as it starts getting deployed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for Position: Trusted Types
Hi everybody, I'd like input on the Trusted Types API[0]. It is a set of APIs intended to protect against DOM-based XSS attacks. It changes various APIs to not accept arbitrary strings, for example `element.innerHTML` can only be assigned a `TrustedHTML` object. These are also policies controllable by Content-Security-Policy[1]. It has been implemented by Chromium 83+ (May 2020). There is a polyfill for everything else[2]. This would be a moderately large task that Igalia would consider starting in H2 if there is consensus on this. Thanks, Patrick [0] https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types#browser_compatibility [2] https://github.com/w3c/webappsec-trusted-types#polyfill ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for Position: Cross-Origin-Resource-Blocking (CORB)
On 2022-03-24 08:04, Anne van Kesteren wrote: > On Wed, Mar 23, 2022 at 6:19 PM Patrick Griffis via webkit-dev > wrote: >> I'd like a position on CORB and intend to implement it in the future. >> This is already part of the Fetch Standard[0] and should be relatively >> straightforward. >> >> It effectively blocks cross-origin requests for resources they don't >> make sense in their context. For example an `img` element should never >> get a response that contains HTML and in that case will not return the >> HTML data. This can prevent unintentional data leaks. >> >> This is implemented by Chromium for years now and I don't believe will >> be invasive. >> >> [0] https://fetch.spec.whatwg.org/#corb > > I'd recommend against this, for these reasons: > > 1. Both Chromium and Gecko are working on > https://github.com/annevk/orb as initially discussed at > https://github.com/whatwg/fetch/issues/721. When done this would > replace CORB. > 2. CORB as specified in Fetch is a subset of what Chromium implements. > Various aspects, such as sniffing, are not specified. > 3. What Chromium implements has also changed over time and Fetch > hasn't been updated. Thanks for the input. My intention was to implement the sniffing that Chromium does which, while not part of the spec, is somewhat documented[0]. I believe directly going to ORB and skipping CORB is not a bad idea and something I could work on if that is the preferred spec. [0] https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/cross_origin_read_blocking_explainer.md ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for Position: Cross-Origin-Resource-Blocking (CORB)
Hi everybody, I'd like a position on CORB and intend to implement it in the future. This is already part of the Fetch Standard[0] and should be relatively straightforward. It effectively blocks cross-origin requests for resources they don't make sense in their context. For example an `img` element should never get a response that contains HTML and in that case will not return the HTML data. This can prevent unintentional data leaks. This is implemented by Chromium for years now and I don't believe will be invasive. [0] https://fetch.spec.whatwg.org/#corb ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for Position: Fetch Metadata
On 2022-02-11 16:15, Patrick Griffis via webkit-dev wrote: > However Sec-Fetch-User I believe will require more > significant changes that will have to be exposed to each port. It > requires knowing if a request was initiated by a user, exact details are > specified here[2], which I think will require integration at the > Safari/WebKitGTK/etc layers. Looking more into this Firefox takes a more heuristic approach to figuring this out (was there a referrer and what is the request type) and if that approach works out for WebKit it wouldn't require any port-specific changes. Chromium itself does just ask the `ui` layer what type of "transition" caused the request which is more in-line with the spec. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for Position: Fetch Metadata
Hi everybody, I'd like a position on the Fetch Metadata[0] spec. It is a security feature that provides extra context to fetch requests so that servers can make informed decisions. It is currently implemented by both Firefox and Chromium. I have started a work-in-progress patch[1] on bug 204744 for this. It currently implements Sec-Fetch-Dest, Sec-Fetch-Mode, and part of Sec-Fetch-Site. However Sec-Fetch-User I believe will require more significant changes that will have to be exposed to each port. It requires knowing if a request was initiated by a user, exact details are specified here[2], which I think will require integration at the Safari/WebKitGTK/etc layers. So I'd appreciate input on if there is interest in this. Thanks, Patrick [0] https://www.w3.org/TR/fetch-metadata/ [1] https://bugs.webkit.org/show_bug.cgi?id=204744 [2] https://www.w3.org/TR/fetch-metadata/#directly-user-initiated ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to set up Intellisense-ish code completion/suggestions for editing WebKit sources on macOS?
On 2021-11-11 02:48, Michael[tm] Smith via webkit-dev wrote: > Can anyone recommend a combination of text-editor/IDE, plugins/tooling > (e.g., language server), and settings/config that’ll enable me to have > usable code-(auto)completion/suggestions (like Intellisense, etc.) when > editing WebKit sources in a macOS environment? > > Anyway, the last thing I’ve been trying is Visual Studio Code. In that I > tried with both the clangd extension and the ccls extension, but ended up > having basically the same problems I have with the vim integrations. > > So I switched back to trying the Microsoft-provided C/C++ Intellisense > extension (cpptools), and found that seems to work better than the clangd > or ccls extensions — at least so far as it seems to be able to at last > partially resolve the header include references. But then it too seems to > stumble on not being able to find some headers it needs. > > For example, I think I’ve been able to make it figure out #include "config.h" > — > but then the next problem I hit is stuff like this: > > cannot open source file "JavaScriptCore/JSExportMacros.h" > (dependency of "config.h") > > ...And then anyway, again, ultimately, no completion suggests when I put a dot > after a particular object name I want to get the function and data-member > suggestions for. (It seems to work for some objects, but not others.) > > So I’m hoping others here might have something working successfully in > their environments that gives them proper completion suggestions on member- > function names and data-member names. > > –Mike This may be of limited use to you because I am on Linux but may be useful information in general. It works here using Visual Studio Code with the Cmake Tools and ccls extensions installed. Header detection works, references work (including basic refactoring), intellisense works (not super fast but functional), debugging with GDB works (connecting to gdbserver with Microsoft's C++ extension for that). I had the exact same header issues as you with only Microsofts C++ extension. I have done no configuration to ccls. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Same-Site cookies by default
On 2020-03-06 6:51 pm, John Wilander wrote: > Hi Patrick! > > Thanks for bringing this up. I’ll share my view of where we are. > > First of all, cookies mostly live in the http layer so the various > WebKit ports would have to work this out independently to some extent. > Maybe libcurl and libsoup have readily available APIs for this? libsoup added samesite support this cycle implemented as the spec describes so I was wondering if we should add a toggle for this new behavior. > Second, we have communicated tentative support for SameSite=lax by > default, but in terms of its privacy protections, WebKit is far ahead > with its Intelligent Tracking Prevention (ITP, or Resource Load > Statistics in open source). Servers that expect to get default > third-party cookie access merely through a SameSite=none; Secure > configuration will find that such an option does not exist under ITP. > Instead, third-parties who need cookie access can make use of the > Storage Access API which gives users control and transparency. There are still ports without ITP; I understand the solution there is to implement ITP though :) > Finally, as far as I know, Chrome is still the only browser to try out > SameSite=lax plus forced TLS for SameSite=none and they seem to be at > 10% rollout at this moment. We’d like to hear some lessons learned > from them since it may be a tough rollout, at least for a browser that > has historically allowed all cookies in third-party contexts by > default. Safari is among a few browsers that has not allowed that. I > do not know what default cookie policies the other WebKit browsers > have. > >Regards, John > >> On Mar 6, 2020, at 1:07 PM, Patrick Griffis wrote: >> >> Chromium has had the idea to treat all cookies as SameSite=Lax by >> default as well as blocking SameSite=None over HTTP for a while now, >> hidden behind a flag, and seem to be rolling this out soon. >> >> The topic is discussed in detail here: >> https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite >> >> I just wondered if other developers had any thoughts on this move and >> if/when WebKit should follow. The downside is of course compatibility >> but the upside is improved privacy. >> ___ >> 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
[webkit-dev] Same-Site cookies by default
Chromium has had the idea to treat all cookies as SameSite=Lax by default as well as blocking SameSite=None over HTTP for a while now, hidden behind a flag, and seem to be rolling this out soon. The topic is discussed in detail here: https://web.dev/samesite-cookies-explained/#changes-to-the-default-behavior-without-samesite I just wondered if other developers had any thoughts on this move and if/when WebKit should follow. The downside is of course compatibility but the upside is improved privacy. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
