Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure
Asi O es mejor + A cookie associated with a resource at http://trc.taboola.com/ was set with `SameSite=None` but without `Secure`. A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032. Add:lpcres.delve.office.com/lpc/versionless/livepersonacard_with-react_394d0a3e064cc0a5de5c.js:16 Some icons were re-registered. Applications should only call registerIcons for any given icon once. Redefining what an icon is may have unintended consequences. Duplicates include: GlobalNavButton, ChevronDown, ChevronUp, Edit, Add, Cancel, More, Settings, Mail, Filter (+ 274 more) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure
El jueves, 23 de mayo de 2019, 4:34:14 (UTC-4), Andrea Marchesini escribió: > Link to the proposal: > https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 > > Summary: > "1. Treat the lack of an explicit "SameSite" attribute as >"SameSite=Lax". That is, the "Set-Cookie" value "key=value" will >produce a cookie equivalent to "key=value; SameSite=Lax". >Cookies that require cross-site delivery can explicitly opt-into >such behavior by asserting "SameSite=None" when creating a >cookie. >2. Require the "Secure" attribute to be set for any cookie which >asserts "SameSite=None" (similar conceptually to the behavior for >the "__Secure-" prefix). That is, the "Set-Cookie" value >"key=value; SameSite=None; Secure" will be accepted, while >"key=value; SameSite=None" will be rejected." > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798 > > Platform coverage: all > > Estimated or target release: 69 - behind pref > > Preferences behind which this will be implemented: > - network.cookie.sameSite.laxByDefault > - network.cookie.sameSite.noneRequiresSecure (this requires the previous > one to be set to true) > > Is this feature enabled by default in sandboxed iframes? yes. > > Do other browser engines implement this? > - Chrome is implementing/experimenting this feature: > https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html > - Safari: no signal yet. > > web-platform-tests: There is a pull-request > https://github.com/web-platform-tests/wpt/pull/16957 > Implementing this feature, I added a mochitest to inspect cookies via > CookieManager. > > Is this feature restricted to secure contexts? no <001M >HTML. Is save Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Promise.allSettled
On 11/1/2019 2:42 PM, Jan-Ivar Bruaroey wrote: My original point was that the semantics of Promise.allSettled, which are "keep waiting for the lot even if some async operations fail", did not deserve its own standard name in the JS language, because of A) how rarely this is actually what you want, B) how easy it is to accomplish when it is, using patterns like e.g. Promise.all(promises.map(p => p.catch(e => e)) & friends, and C) (your point?) bugs from people wrongly using instead of Promise.all Yeah, my own reasoning was more strictly scoped to testing and the mozilla-central repository because that is my area of expertise, and I may miss reasons why allSettled could be more useful in JavaScript in other environments, but your general points look valid to me as well. Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to hg.mozilla.org access
Also sprach Kim Moir: > On Nov 14, 2019, we intend to change the permissions associated > with Level 3 access to revoke direct push access to hg.mozilla.org > on mozilla-inbound, Several modules have a policy that changes to documentation, e.g. for https://firefox-source-docs.mozilla.org/, can be landed with a=doc if you’re a peer. There has been discussion on this list several times in the last few years about expanding this policy to apply to the whole project. The background is that as MDN is moving away from serving Mozilla-specific developer documentation to be centred around the web platform, there is a rising need to make it easy to keep developer docs in-tree up to date. Documentation changes have historically been well served by a “wiki editing”/micro adjustments approach. I wonder if there is anything we can do with Phabricator to ease review requirements for documentation changes from peers? Lastly, I sympathise with wanting to reduce the number of routes a patch can take to reach central. This will in the long term make it easier to write automated tooling for SCM (such as wptsync) and audit changes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
