Open Bug 1125994 Opened 9 years ago Updated 9 years ago

Investigate using cookies to indicate whether a donation was already made to avoid continuing to nag the user

Categories

(Mozilla Foundation Communications :: Website, task)

task
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Gijs, Unassigned)

References

(Blocks 1 open bug)

Details

+++ This bug was initially created as a clone of Bug #1116503 +++

(cloning in order to keep the discussions separate)

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #7)
> (In reply to Adam Lofting (:adamlofting) from comment #6)
> > I'm not technically knowledgeable enough about Firefox Development and the
> > snippets service to dig in to these questions in detail, but I *think* some
> > of the complexity is because the snippet is loaded into the product rather
> > than displaying a URL directly on snippets.m.o. I'm CC'ing :mkelly who may
> > know more.
> > 
> > These are good questions to ask though, and perhaps we can turn some of
> > these into specific tickets for development to the snippets service?
> 
> There's docs on how snippets are inserted into about:home[1] but you've got
> the gist of it; Firefox downloads HTML from snippets and embeds it on
> about:home, meaning direct use of cookies won't work.

I'm unclear on what you mean here; XHR (which we use to load the snippets, as best I can tell from the about:home code) per spec should be using cookies, so the snippet service (server-side) could check the sent cookies and not send the donation snippet, assuming appropriate cookie values were available and set on the domain, right?

> We could, in theory, have a page on snippets.m.o that is opened in an iframe
> and use postMessage to communicate with it to get at cookies stored on the
> snippets.m.o domain. Persona does something very similar, in fact. My
> biggest concern would be how to prevent any site from reading the cookies
> stored via that page, as it's unclear whether the targetOrigin protections
> around postMessage would work with about:home.

Indeed, even if the server didn't, as we're inserting HTML including script on about:home, I would expect that it could create an XHR request to snippets.m.o, or that we could create a specific API for the about:home code to ask for the snippet cookies from the cookie service?

The targetOrigin bit indeed doesn't like "about:home" or the URL to the real file, in my testing (the message doesn't arrive, whereas it does arrive with '*'...). That might be a bug, it might be deliberate. Unsure.

> [1]
> https://abouthome-snippets-service.readthedocs.org/en/latest/overview.html
Flags: needinfo?(mkelly)
(In reply to :Gijs Kruitbosch from comment #0)
> I'm unclear on what you mean here; XHR (which we use to load the snippets,
> as best I can tell from the about:home code) per spec should be using
> cookies, so the snippet service (server-side) could check the sent cookies
> and not send the donation snippet, assuming appropriate cookie values were
> available and set on the domain, right?

Due to the sheer size of the traffic levels that hit the snippets server, we avoid using anything on the server-side to determine what snippets are sent that can't be handled by the load balancer, which handles almost all of the traffic that comes in. AFAIK our load balancer can't be configured to cache based on the value of an individual cookie, and if it could, we'd then have to make an admin interface for snippet admins/developers to use to control those cookies.

In addition, snippets are fetched once every 24 hours, so if even if the cookie was set it'd take up to 24 hours for the snippet to disappear unless we do something client side. And if we're doing anything client side, we might as well do it all client side for the reasons above.

> Indeed, even if the server didn't, as we're inserting HTML including script
> on about:home, I would expect that it could create an XHR request to
> snippets.m.o, or that we could create a specific API for the about:home code
> to ask for the snippet cookies from the cookie service?

I think that just moves the concern from whether targetOrigin works with about:home to whether Access-Control-Allow-Origin works with about:home..

> The targetOrigin bit indeed doesn't like "about:home" or the URL to the real
> file, in my testing (the message doesn't arrive, whereas it does arrive with
> '*'...). That might be a bug, it might be deliberate. Unsure.

about:home's origin might be blank; the referrer is when going from about:home to another URL. It's very weird.
Flags: needinfo?(mkelly)
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)

> In addition, snippets are fetched once every 24 hours, so if even if the
> cookie was set it'd take up to 24 hours for the snippet to disappear unless
> we do something client side. And if we're doing anything client side, we
> might as well do it all client side for the reasons above.

FWIW, client-side is what's being done in bug 1115153 for Hello promotion snippets. That approach isn't using cookies, but it should work (we talked about it, but decided not to for reasons that escape me).
(In reply to Justin Dolske [:Dolske] from comment #2)
> (In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)
> 
> > In addition, snippets are fetched once every 24 hours, so if even if the
> > cookie was set it'd take up to 24 hours for the snippet to disappear unless
> > we do something client side. And if we're doing anything client side, we
> > might as well do it all client side for the reasons above.
> 
> FWIW, client-side is what's being done in bug 1115153 for Hello promotion
> snippets. That approach isn't using cookies, but it should work (we talked
> about it, but decided not to for reasons that escape me).

I dunno if that applies, as that's about reading an in-product setting, whereas here we're trying to communicate between about:home and the post-donation webpage, which presumably can't set in-product settings. Or did I misunderstand?
You need to log in before you can comment on or make changes to this bug.