On Thu, May 23, 2019 at 10:53 AM Frederik Braun wrote:
> Having read the proposal, I think it's a good mechanism for us to know
> about websites that want third-party cookies and it seems less costly to
> deploy for websites than Storage Access API.
>
> However, it seems this is Google's counter
Yay! This is exciting, thank you!
On Tue, Apr 10, 2018 at 4:30 AM Francois Marier
wrote:
> We intend to ship same-site cookies in Firefox 61. This new cookie
> attribute allows sites to prevent cross-site requests from using those
> cookies which provides a mechanism for web sites to protect the
We do have `worker-src` tests, FWIW:
https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/.
We'll likely need to adjust things based on the fallback mechanism y'all
are running with (and Chrome will need to drop the weird contortions we
implemented for back-compa
Hey folks! Glad to see that there's interest in this API from Mozilla. :)
On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson wrote:
> On 12 Mar 2016 7:28 PM, "Anne van Kesteren" wrote:
> > It should be identical to password manager integration.
>
> But it is not, though I suppose that a password
s space.
>
> Fixing cross-site cookies would remove one of the big security
> advantages that other platforms have over the web.
>
Talk to Mozilla's own Mark Goodwin (CC'd. Hi, Mark!) who had similar ideas
(see http://people.mozilla.org/~mgoodwin/SameDomain/samedomain-latest.
ther spec die, as I think they're
potentially important, but I haven't prioritized building a prototype to
play with.
Coincidentally, I talked to a colleague just this morning who might have
some spare cycles coming up, so who knows. Maybe he'll build a prototype
for us. :)
-mike
ght way of managing it. Off the top
of my head, we could set an `opener` flag on fetch, distinct from `client`.
If the context is "top-level" or "main frame" or whatever we call it, and
there's a `client`/`opener` mismatch, we could deal with it appropriately.
--
Mike West
7 matches
Mail list logo
