992966 - [Snippet Service] Build in better Sync targeting to snippet service

Status: RESOLVED WONTFIX

(Snippets :: Service, defect)

Description

[Laura Forrest]

We will be heavily promoting Sync through 2014. To best serve our users it would be good to be able to target these promotions to better fit the different audiences within our user base. 

Request: Build in ability for snippet service to know if a user is:

1. Old sync user
2. New sync user
3. Non sync user

MKelly - From our email string: 
"...there might be some obscure JavaScript trick that 
Firefox devs would know. File a snippets bug asking about it and I can 
see about CCing someone who may know."

Comment 1

[Osmose [:osmose, :mkelly]]

ttaubert / mhammond: Hi! As noted above, we'd like to be able to detect users using old sync vs new sync vs no sync. We'd be doing this via JavaScript run in an about:home snippet. Is there any way currently to detect this? If not, would it be reasonable to consider adding that ability, possibly to about:home only, and still get some use out of it in 2014?

Comment 3

[Mark Hammond [:markh] [:mhammond]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)
> ttaubert / mhammond: Hi! As noted above, we'd like to be able to detect
> users using old sync vs new sync vs no sync. We'd be doing this via
> JavaScript run in an about:home snippet. Is there any way currently to
> detect this? If not, would it be reasonable to consider adding that ability,
> possibly to about:home only, and still get some use out of it in 2014?

That should be possible, yeah.  It is trivial from javascript with chrome permissions, which I assume the code sent via snippets will not have.  In-fact, all we really need is the ability to read a single preference value.

Michael, can you please ping Tim or myself on IRC so we can discuss how we might go about this?  Note Tim is in Europe and I'm in Aust, so you will need to pick your times well :)  I'm generally online from about 4pm pacific time.

Comment 4

[Frederik Braun [:freddy]]

Is there a precedence for JavaScript in snippets? From as security perspective I'd would personally prefer not to have scripts in snippets :)

As far as I understand, the snippet service currently has access to "environment data" (like the locale?). Would it make sense to expose the user's Sync status into the mechanism that selects and delivers snippets instead of giving them JavaScript capabilities?

Comment 5

[Osmose [:osmose, :mkelly]]

(In reply to Frederik Braun [:freddyb] from comment #4)
> Is there a precedence for JavaScript in snippets? From as security
> perspective I'd would personally prefer not to have scripts in snippets :)

You are in for some bad news. :P

Not only is JavaScript in snippets normal, it's actually required. The chrome code goes so far as injecting the snippet code into about:home, but the actual snippet selection process, which also includes snippet geolocation and our metrics ping for snippet impressions, is implemented as JavaScript served up as part of the snippet code. Snippets have been designed this way since Firefox 4 and the very first about:home.

We use JavaScript in snippets all the time, which is how we've been able to do things like video snippets, logo animations, the SOPA snippet, and more.

If this comes as a surprise, perhaps we should sit down and discuss things in more detail?

> As far as I understand, the snippet service currently has access to
> "environment data" (like the locale?). 

Yes. The browser requests snippet code using a URL like 

https://snippets.mozilla.com/3/Firefox/22.0/default/Darwin_Universal-gcc3/en-US/release/Darwin%2010.8.0/default/default/

which, as you can see, includes the locale.

> Would it make sense to expose the
> user's Sync status into the mechanism that selects and delivers snippets
> instead of giving them JavaScript capabilities?

We could do that, but I strongly recommend against it, because it requires us to get the patch through Firefox, then update the snippets service backend code to handle the new parameter, then create the snippet using that new feature. The URL also serves as a cache key, so every attribute we add reduces our ability to effectively cache the service, which is the primary reason it doesn't melt from all the traffic.

With in-snippet JavaScript, we can just detect it and change the snippet instantly, without having to wait for the code changes and release process. Very much preferred from our end.

Comment 6

[Frederik Braun [:freddy]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #5)
> You are in for some bad news. :P
 
Something I have grown accustomed to ;)


I think we could increase the security and make the whole snippets setup a bit tighter here and there. 
But this is just me being personally nosy. You are of course free to move on as planned! :)
Feel free to ping me if you want additional help (which should probably go in another bug).

TLDR: Nothing to see here, move along.

Comment 7

[Mark Hammond [:markh] [:mhammond]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #5)
> With in-snippet JavaScript, we can just detect it and change the snippet
> instantly, without having to wait for the code changes and release process.
> Very much preferred from our end.

Best I can tell, the environment in which the javascript executes is not setup specially in any way.  Are you proposing that we start treating it in a special way and inject some data into that environment so it can filter based on the client's sync state?  If so, I expect it might take some time as it is likely to need both sec and privacy review.

Or maybe I'm still missing something and we can leverage facilities that already exist?

Comment 8

[Osmose [:osmose, :mkelly]]

(In reply to Mark Hammond [:markh] from comment #7)
> Best I can tell, the environment in which the javascript executes is not
> setup specially in any way.  Are you proposing that we start treating it in
> a special way and inject some data into that environment so it can filter
> based on the client's sync state?

Sort've! I was asking if there was an already-existing way for that JavaScript to detect it. If not, then we'll have to decide if the value of these snippets is worth the effort of making whatever change we'd need to make; "Go without special sync-detection snippets" is an option, essentially.

So the questions here are:

a) Is it currently possible to detect if the user is using new sync, old sync, or no sync via snippet JavaScript injected into about:home?

b) If not, is it possible to add that, and how much effort would it take? How long would it take to hit the release channel, and could that be sped up?

From your comments, it looks like the answer to (a) is "No" and the answer to (b) is "A small amount of effort". Is that accurate?

Comment 9

[Mark Hammond [:markh] [:mhammond]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #8)
> So the questions here are:
> 
> a) Is it currently possible to detect if the user is using new sync, old
> sync, or no sync via snippet JavaScript injected into about:home?

Best I can tell, the "injection" is really just moving a DOM node, including <script> tags, into an about:home element.  This means its just normal, regular JS executing on the web.  If this is correct, then I don't know of any way for JS running on the web to detect this.

> b) If not, is it possible to add that, and how much effort would it take?

From a technical POV, I imagine it wouldn't be too hard to have that code execute in a sandbox which we have setup, and thus that javascript code would have access to thinks that aren't available on the web-at-large.

However, this would almost certainly mean a sec and privacy review.

> How long would it take to hit the release channel, and could that be sped up?

Once it got past sec and privacy review, I imagine we could look at jumping the trains.
 
> From your comments, it looks like the answer to (a) is "No" and the answer
> to (b) is "A small amount of effort". Is that accurate?

I believe (b) is a relatively small amount of technical effort, but that's not the only consideration.  I was hoping to find we *already* had a custom JS environment where we could just add a couple of new flags - that would probably be much easier to get sec and privacy review for (as the heavy lifting there would have already been done)

Comment 10

[Osmose [:osmose, :mkelly]]

lforrest, jcollings: Given that there's some technical effort in updating the browser to support this, plus the developer effort to make snippets that use that, do you want to move forward with this idea? Or would snippets that don't detect sync and just promote it regardless be enough?

Comment 11

[Jean Collings]

Hey Mkelly,

Spoke to Laura and this is definitely something we would want in our product roadmap but does not need to be completed right now or by Australis. I'm actually having a meeting with Cmore and Justin in May about snippet service roadmap stuff so I'll include this request in there as well. Thanks for checking in.

Comment 12

[Chris Karlof [:ckarlof]]

Given the level of promotion of Sync in first-run and elsewhere, and lack of activity here, I'm closing.