Closed Bug 1126188 Opened 10 years ago Closed 10 years ago

Show explanation text for a suggested tile with appropriate styling

Categories

(Firefox :: New Tab Page, defect)

defect
Not set
normal
Points:
5

Tracking

()

VERIFIED FIXED
Firefox 39
Iteration:
39.2 - 23 Mar
Tracking Status
firefox38 --- verified
firefox39 --- verified

People

(Reporter: Mardak, Assigned: emtwo)

References

Details

(Whiteboard: .002)

Attachments

(5 files, 4 obsolete files)

Bug 1126184 will get a related tile into the NewTabUtils.links.getLinks list of links, but without any special styling, it wouldn't be clear that this is a related tile. At minimum, we want some explanation text that the user can quickly grasp why they're seeing a related tile. One simple suggestion is "/Because you visited site.com/" https://bug1120311.bugzilla.mozilla.org/attachment.cgi?id=8553575 Not sure if it needs to always be shown or only after the user tries to interact/hovers the tile.
dcrobot, if the user has multiple top sites that match a given related tile, should we provide some way for the user to see all matches? Or do we just pick out the first (highest frecency) match? Because you visited popular.com... [hover: and also.your.net, top.site.org] ?
I imagined that it would be the first match... but more specifically, the one that matches a History Tile on their New Tab page (or at least directly related to such a History Tile). Thoughts?
Nod, most likely that would be the highest frecency match, but what if there's multiple? E.g., a sports user with both espn and yahoo sports in their top sites and we have a related tile looking for either espn and yahoo but get both.
I honestly don't think it matters, as long as the user immediately recognizes the interest category being represented. In other words, it's no so important whether it's ESPN or Yahoo! Sports... just that it's a sports site.
Could be most recent visit or show category. If we show the latter, we can a list of sites on category hover or click like dcrobot mocked up.
For a "TurboTax" tile.. "frequently visited with irs.gov" make sense? "irs.gov visitors also visited" ? "related to irs.gov" ? Basically, all of these don't mention "you," but does that lose impact or help?
Having "you" makes it personal. In the scale of being personal: Personal: "Recommended because you visited irs.gov" Less-personal: "Users that visited to irs.gov, also visited TurboxTax" Impersonal: "Related to irs.gov" We'll have to do some user testing on this. In the meantime, let's involve Patrick.
Flags: needinfo?(pfinch)
(In reply to Kevin Ghim from comment #7) > Having "you" makes it personal. In the scale of being personal: > > Personal: "Recommended because you visited irs.gov" > Less-personal: "Users that visited to irs.gov, also visited TurboxTax" > Impersonal: "Related to irs.gov" > > We'll have to do some user testing on this. In the meantime, let's involve > Patrick. My biggest concern at the moment is that the user understands the scope of how their information is being used to determine the relevance of the Tile. From the user's perspective: "If I see that you are showing my something related to my browsing history, what else are you doing with my data?" I would suggest that one way to start to attack this problem is to make it clear that the browser is doing this - along the lines of "Firefox is showing you this because it finds irs.gov in your history".
Flags: needinfo?(pfinch)
QA Contact: msamuel
Assignee: nobody → msamuel
QA Contact: msamuel
Iteration: --- → 39.1 - 9 Mar
Whiteboard: .? → .002
A couple recommendations from mmc: 1) transition in a way users can accept -- don't surprise users in a way that they'll question / be upset 2) don't be too detailed in ways that are creepy ("i didn't realize firefox knows all the sites i visit!") e.g., "because you visited site.com/page on tuesday 1:23pm at home in your pajamas" ;)
Trying to incorporate various recommendations: "Firefox suggests this because irs.gov visitors also go here" It tries to avoid directly stating that Firefox knows irs.gov is in the browsing history, which hopefully makes it less surprising and not too detailed. It's explicit in that it's a suggestion coming from Firefox - trying to imply Firefox made the decision as opposed to externally. It also tries to make the users feel comfortable with doing something "new" by letting the user know others have done this before, so it's "safe." emtwo, the main work here is getting the code to display some text for suggested tiles in a way that fits in the new tab layout. I'm guessing we'll want to allow for 2 maybe 3 lines of text as translations could end up twice as long.
emtwo, http://tyk8e9.axshare.com/new_tab.html has an example of the text being added below a tile. Although it happens to have the suggested tile in the bottom left where there's extra whitespace to work with. The suggested tile will actually be in the top left and only in the top left for now, so I'm not sure if we just increase the space below the tiles always? Only for the first row of tiles? Only when there's a suggested tile?
I think it would be most ideal to increase the space only when there is a suggested tile so that users without suggested tiles get the maximum visible tiles possible (since increasing space may remove a row of tiles, as you mentioned before) I was also wondering how prominent our suggestion text needs to be. Looking at the text for 'sponsored' tiles, it only shows up when you click the 'sponsored' tag. If we have a 'suggested' tag similar to the sponsored one, can we similarly show the suggested text when clicking the tag?
Are you referring to the existing design with the "sponsored" labels, or the new updated version of New Tab?
Aaron, I was referring to the existing design with 'sponsored' labels. I have looked at the New Tab mocks here: https://bug1121549.bugzilla.mozilla.org/attachment.cgi?id=8548988 I couldn't find what is the new way of showing sponsored tiles though? Is that the same as 'Featured' tiles?
Depends on: 1138817
With bug 1138817 adding the [suggested] tag next to the tile, I'm not sure how important it'll be to mention "suggested" in the explanation text.
Summary: Show explanation text for a related tile with appropriate styling → Show explanation text for a suggested tile with appropriate styling
No longer depends on: 1138817
I believe from a user acceptance perspective, we should go with showing sites initially instead of some category/grouping label because it's 1) an easier transition 2) leads to less creepiness questions 3) more accurate: 1) If we show users a category for suggested sites, we would introduce two new ideas to users in a single feature where users could dismiss the feature (turn it off or switch away) because of poor quality of either suggestions or categories. We shouldn’t surprise users too much by changing too many things at once. Once users accept suggestions, we can transition to categories as appropriate. 2) As pfinch pointed out in comment 8, users will try to understand why we’re showing the category or site, and because we currently can’t explain in depth what we’re doing. And as in mmc’s thoughts in comment 9, users would get creepy thoughts of “what else is being done with my data” when left to question. With sites, there doesn’t need to be extra explanation as the user can easily confirm it, e.g., typing in the site in the location bar and seeing history, but for categories, there’s no easy way for users to see what Firefox is doing. 3) Categories are more likely to be factually incorrect as they're extrapolations, and if the user sees something wrong, they’ll probably do the above (1) turn off the feature or (2) start to wonder what else is Firefox trying to analyze incorrectly. For example, if I visit a site for a specific section, say arts within a US news site, telling me about my “US news interest” would definitely make me question the feature as opposed to referring to the site.
Flags: needinfo?(kghim)
(In reply to Ed Lee :Mardak from comment #16) > I believe from a user acceptance perspective, we should go with showing > sites initially instead of some category/grouping label because it's 1) an > easier transition 2) leads to less creepiness questions 3) more accurate: > > 1) If we show users a category for suggested sites, we would introduce two > new ideas to users in a single feature where users could dismiss the feature > (turn it off or switch away) because of poor quality of either suggestions > or categories. We shouldn’t surprise users too much by changing too many > things at once. Once users accept suggestions, we can transition to > categories as appropriate. Starting off with sites as contextual explanation would be ok, as long as we have an opportunity to test out user sentiment for both options. > 2) As pfinch pointed out in comment 8, users will try to understand why > we’re showing the category or site, and because we currently can’t explain > in depth what we’re doing. And as in mmc’s thoughts in comment 9, users > would get creepy thoughts of “what else is being done with my data” when > left to question. With sites, there doesn’t need to be extra explanation as > the user can easily confirm it, e.g., typing in the site in the location bar > and seeing history, but for categories, there’s no easy way for users to see > what Firefox is doing. I'm not convinced that showing a site is less creepy. The number one creepy factor for display ads is site retargeting - although, no personal data is shared with 3rd party advertisers, will the specific mention of a site trigger negative sentiment? An additional decision that needs to be made is what site to show? > 3) Categories are more likely to be factually incorrect as they're > extrapolations, and if the user sees something wrong, they’ll probably do > the above (1) turn off the feature or (2) start to wonder what else is > Firefox trying to analyze incorrectly. For example, if I visit a site for a > specific section, say arts within a US news site, telling me about my “US > news interest” would definitely make me question the feature as opposed to > referring to the site. Good recommendations are derived from understanding the user's short-term intent and long-term interests. Since tiles are formulated by the user's frecency, it skews towards towards the long-term, which I believe is ok to use categories to suggest interest. For the shorter term, search terms and sites would be appropriate because of the relatable nature of immediate queries.
Flags: needinfo?(kghim)
(In reply to Kevin Ghim from comment #17) > I'm not convinced that showing a site is less creepy. The number one creepy > factor for display ads is site retargeting - although, no personal data is > shared with 3rd party advertisers, will the specific mention of a site > trigger negative sentiment? Site retargeting is usually creepy because the ads keep telling you to go back to the original site from unexpected places, e.g., a completely unrelated page. Just because we show a site as the reason for a suggested tile doesn't make it site retargeting. In fact, the concept of Notification Tiles is more like site retargeting as the main purpose there is to get the user to go back to that site, so if we want to avoid creepiness, perhaps we need to think harder about what we would want to do with Notification Tiles. I believe site targeting in the advertising context typically refers to an advertiser choosing which site to show their ad. Except for many target sites, they don't sell ad inventory. For example, some advertiser would want to show ads on bmw.com except BMW wants to focus the user on getting information about BMWs and not get distracted by external ads. However, with Suggested Tiles, advertisers can now reach those users who visited bmw.com-like sites. > An additional decision that needs to be made is what site to show? Probably the site with the highest frecency as that's the one that the user connects with more if multiple sites from history match. > Good recommendations are derived from understanding the user's short-term > intent and long-term interests. I don't see how that precludes using long-term site data from making good recommendations. A frequently visited site could be a strong indicator of a long-term interest. If I visit bmw.com every day, I might very well be a BMW enthusiast. As you point out, given that we're focusing on high frecency, we shouldn't pitch Suggested Tiles as a good way to reach intent.
Blocks: 1141617
Iteration: 39.1 - 9 Mar → 39.2 - 23 Mar
I think we've picked some pretty pretty simplistic examples here and its clear its already led to some complexity that will be hard to deal with. suggesting yahoo sports to an espn vistor (sports fan) is probably an easy case; and maybe suggesting a variety of car sites to the bmw enthusiast. the later gets a bit more off target if its buick or another hated brand that enthusatic bmw followers would see as spam. getting down to some more controversial topics like politics. are we starting to think about how we could classify visits and related sites for that. offerning foxnews to na msnbc view is likely to enflame or annoy some, so its key that we thing about what it is that we are trying to achieve with, or for the user before inviting them to use this feature at all, or getting them to stick with it. are we trying to encourage exploration? are we trying to broaden perspective? are we trying to assist fast navigation to more/better content just like the user has been looking at? are we just trying to play king makers and redirect traffic from espn to yahoo? -- maybe users and mozilla is not interested in any one or all of these, or not interested in that right now when then just opened this tab and see the feature in action, but if we try to explain what its that we think we are trying to achieve users, and our selves will probably know this feature better. just started to read these bugs so maybe that's been explained somewhere and can be applied to the decisions under discussion here. Its also not clear to me how we can set up a framework for localizing these categories for our users around the world that probably have a different set of interest categories and a much more complex set of related sites to figure out and categorize. are we thinking about how we might handle that?
> Site retargeting is usually creepy because.... re-targetting is not just creepy. Its a violation of user sovereignty of their system. That's at least part of the controversy around around Superfish. The goal of Superfish was retargeting, the MiTM tactics used to achieve that differ from the approach taken here, the the end results of the same. Its certainly going to be a difficult message for mozilla to convey that our approach is somehow ok, and that our objective is somehow ok if we don't have a good message about what we are trying to do for users.
(In reply to Ed Lee :Mardak from comment #18) > Site retargeting is usually creepy because the ads keep telling you to go > back to the original site from unexpected places, e.g., a completely > unrelated page. I think the creepy part is the implication that the advertising system knows your browsing history. I think it makes sense to link to a "Learn how this works" page that directly answers privacy questions like: * Are the ads matched to history by sending the history to a server that knows about what ad criteria there are or is the ad criteria sent to the browser and the matching done locally? * Once there is a match, does loading the assets reveal which IP addresses belong to users for whom there was a match or are all assets sent to all browser instances so that the asset downloads reveal nothing? (That is, if you are the server that serves the TurboTax ad asset, do you only get requests from IP addresses that run browsers that have irs.gov in their history?) * Once the user clicks an ad, does the navigation to the target of the ad carry information about where the navigation came from? That is, can the TurboTax site tell that the user arrived to the site by clicking an ad that was shown based on matching the history for irs.gov? (That is, is the fact that there was a history match in a browser running at the user's IP address revealed to the advertiser when the ad is clicked or does the visit look like any visit out of the blue from the advertiser perspective?) * Is there some other way how info about there being a history match for a user at a particular IP address gets exfiltrated?
We also need to answer henri's questions not only for this initial implementation, but for the long term plan on this. > That is, can the TurboTax site tell that the user arrived to the site by clicking an ad that was > shown based on matching the history for irs.gov? If this feature ever has any chance at being monetized the answer there is yes. The ad model always needs ways for attribution of traffic to occur for payments to follow. Partners will be clued in on the connection and likely will be the ones approaching us with suggestions on sources they want traffic redirected from. e.g. yahoo sports wants traffic from espn, here is the deal we can make.
(In reply to chris hofmann from comment #22) > > That is, can the TurboTax site tell that the user arrived to the site by clicking an ad that was > > shown based on matching the history for irs.gov? > If this feature ever has any chance at being monetized the answer there is yes. The answer is no. We explicitly built the system to not reveal which exact site the user has in history to the target site or even Mozilla. chofmann, please don't assume the worst and state them about the system we're building. We've spent quite a bit of time looking at various privacy aspects, e.g., bug 1132534 for making it difficult to figure out user's browsing history outside of Firefox and bug 1126184 for how we're doing client side decisioning.
We're waiting on more formal UI specs for this, but this patch is ready for a preliminary review. In general, we want to show 2 tile rows instead of 3 so there is some buffer space to show the explanation text. I'll attach a screenshot as well for context.
Attachment #8577405 - Flags: feedback?(adw)
(In reply to Ed Lee :Mardak from comment #23) > (In reply to chris hofmann from comment #22) > > > That is, can the TurboTax site tell that the user arrived to the site by clicking an ad that was > > > shown based on matching the history for irs.gov? > > If this feature ever has any chance at being monetized the answer there is yes. > The answer is no. We explicitly built the system to not reveal which exact > site the user has in history to the target site or even Mozilla. > > chofmann, please don't assume the worst and state them about the system > we're building. In no way was I assuming anything about the work done so far, it was an assessment of the work that lies ahead to meet the expectations as a viable revenue generator. > We've spent quite a bit of time looking at various privacy > aspects, e.g., bug 1132534 for making it difficult to figure out user's > browsing history outside of Firefox and bug 1126184 for how we're doing > client side decisioning. Thanks for those links. Reading more about them now. https://bugzilla.mozilla.org/show_bug.cgi?id=1132534#c7 https://bugzilla.mozilla.org/show_bug.cgi?id=1132534#c12 seem to only confirm expectations about how partners will think about and want this system to work if they are going to participate in any kind of revenue exchange, and desire to have tracking and accountability associated with that.
Attached image Screen Shot 2015-03-13 at 3.50.50 PM.png (obsolete) —
Screenshot of explanation text
(In reply to chris hofmann from comment #19) > I think we've picked some pretty pretty simplistic examples here and its > clear its already led to some complexity that will be hard to deal with. The immediate term plan for Firefox 38 is to have snippet-like functionality in the new tab page. We'll use suggested tiles to find android users to show a Firefox for Android tile. We'll try our various audiences, e.g., tech enthusiasts and non-profit volunteers, with different messaging but all to drive installs of Firefox for Android. > Its also not clear to me how we can set up a framework for localizing these > categories for our users around the world that probably have a different set > of interest categories and a much more complex set of related sites to > figure out and categorize. are we thinking about how we might handle that? The current thinking is that we only need to show the categories for content that we are trying to show. And whoever is providing input on which users should see the content will provide suggestions on labels/categories, e.g., "android users" "tech enthusiasts." This makes it so we only need the strings for the groups we're actually using, which are only shown to users of certain locales -- initially en-US.
pfinch, would be good to note these types of questions below: (In reply to Henri Sivonen (:hsivonen) from comment #21) > I think it makes sense to link to a "Learn how this works" page that directly answers privacy questions Indeed. We already have a "What is this page?" that links to a "Learn more..." -> https://www.mozilla.org/firefox/tiles/ We'll be updating that to answer those types of questions (although technically none of the Suggested Tiles content we'll show for Firefox 38 are paid ads -- but one could argue Mozilla's own tiles are ads themselves): > * Are the ads matched to history by sending the history to a server that > knows about what ad criteria there are or is the ad criteria sent to the > browser and the matching done locally? Matching for suggested tiles is done by giving enough information to Firefox for decide on the machine without revealing your history to any server. > * Once there is a match, does loading the assets reveal which IP addresses > belong to users for whom there was a match or are all assets sent to all > browser instances so that the asset downloads reveal nothing? (That is, if > you are the server that serves the TurboTax ad asset, do you only get > requests from IP addresses that run browsers that have irs.gov in their > history?) Matching is done on a group of sites, so even if an image request is made, it does not reveal which exact site is in the browsing history. Additionally, the images are served from machines that delete logs within 7 days, and often times we delete it much sooner -- immediately. > * Once the user clicks an ad, does the navigation to the target of the ad > carry information about where the navigation came from? That is, can the > TurboTax site tell that the user arrived to the site by clicking an ad that > was shown based on matching the history for irs.gov? Similar to how fetching the image doesn't reveal which site triggered it, clicking the tile also does not reveal which site triggered the tile to be shown in the first place. > * Is there some other way how info about there being a history match for a > user at a particular IP address gets exfiltrated? We are looking at ways to send this type of data to Mozilla servers to help us optimize the groups of sites in bug 1142386. Basically, there's techniques that allow all users to have reasonable deniability of whether they visited a site or not, but across many users, we should be able to measure trends, e.g., siteA triggered the tile 2x as often as siteB. hsivonen, I'm not sure what explanation text you looked at, but the questions sound like they come from a concern that someone could know exactly which site you visited. Does an explanation text that hints that multiple sites instead of one specific site help avoid this line of questioning? "Firefox suggests this because visitors to sites like hrblock.com also go here" (note the added "to sites like")
Flags: needinfo?(hsivonen)
Comment on attachment 8577405 [details] [diff] [review] v1: Show suggested tile explanation text under a suggested tile Review of attachment 8577405 [details] [diff] [review]: ----------------------------------------------------------------- Looks OK to me, except it's spelled "targeted," not "targetted." :-)
Attachment #8577405 - Flags: feedback?(adw) → feedback+
How flexible is the design? As in: what happens is the text spans on 3 lines?
Francesco, we don't yet have a design spec (although with this current patch, 3 lines doesn't look very nice). We'll probably need to set a limit on the number of lines that may show up and add an ellipsis for the rest I think. Aaron may have a better idea of what we would do here.
Flags: needinfo?(athornburgh)
(In reply to Marina Samuel [:emtwo] from comment #31) > We'll probably need to set a limit on the number of lines that may show up > and add an ellipsis for the rest I think. Please don't do that: this is a sensitive matter, you don't want to end up with funny truncations that change or mess with the sentence of the string. It's also really hard to test and spot (hint: people need a way to test these features somehow, e.g. flags to force-enable these tiles).
Probably worth getting some wider feedback on this, but "...Firefox suggests this because [hrblock.com] visitors also go there" suggests to me some notion that that the recommendation might be related and the most popular. At least I'd be hopeful of that. hrblock vistors probably go a lot of different places... The way I understand the algorithms and tile selection process there is only a 20% or less chance that the tile will represent the "most popular" site related to the one I visited, since we will be injecting sites into the category list to ensure randomization and reduce the chances of tracking. A lot of the the way that this feature will work is centered around categorization, and grouping of sites within those categorizations plus the who, how, or why sites get put into categories. For the user to understand and answer the basic question "how did *this* tile end up on my screen" we should be trying to explain that in a simple way. But thats also the challenge here. How can we simply explain the idea of categorization, and how this tile represents a pick from a collection of sites that other firefox users, and/or mozilla bd people have organized for you?
There is the "how" question users might have that we might give clues on, and there is also another idea about touching on an explanation of *why* Firefox might be doing this at all. Users will probably have questions about that as well. Historically there generally two kinds of navigation patterns people use browsers for: 1) to zero in on some information they want going from the general to the specific. 2) to explore from something they know to find new things they might be interested in. Google had the "I'm feeling lucky" branded feature to help people with fast navigation to content that supported way #1. They were able to wrap all the complexity of their keyword to site matching up in a simple concept that expressed to users that they might not quite get it right, but lets give it a shot. we will try to get you to the site you want as fast as possible with no compromises. The desire for this feature seems more oriented around way #2, and that we might be trying to expand or change the set of sites that users are going to. Interested in feedback on if people agree with that major premise. If its true we could try to explain or engage the user with this exploratory aspect of the content that Firefox is suggesting. The interesting part of the implementation is that there is also a randomization characteristic of the feature so there is also some luck involved in which tile the user actually was shown. And there is also an injection into that random selection process tiles that are sponsored by some cause or paying partner. Trying to describe something that involves exploration, luck, and possible sponsorship might be a hard task but those are concepts that if we hit on would convey the things the user needs to know to understand what they are getting. to bad "I'm feeling lucky" has already been taken. this is sort of the "I'm feeling lucky" for the exploration side of web browsing from the perspective of the user. maybe there is another similar simple phrase that we could label the tile with, and then let that branding [and a link to other docs] represent all the more complex aspects on what we seem to be trying to do with this feature.
(In reply to Ed Lee :Mardak from comment #28) > pfinch, would be good to note these types of questions below: > > (In reply to Henri Sivonen (:hsivonen) from comment #21) > > I think it makes sense to link to a "Learn how this works" page that directly answers privacy questions > Indeed. We already have a "What is this page?" that links to a "Learn > more..." -> https://www.mozilla.org/firefox/tiles/ When I read the text on that page and the linked pages, I'm left with the impression that information about matches to the user's browsing history gets exfiltrated but as a matter of *policy* Mozilla doesn't track it. That is, if we have *technical* (as opposed to *policy*) measures in place to mitigate exfiltration of information in the form of what tile assets get loaded, etc., the above-cited page does not do a good job pointing that out. > We'll be updating that to answer those types of questions (although > technically none of the Suggested Tiles content we'll show for Firefox 38 > are paid ads -- but one could argue Mozilla's own tiles are ads themselves): > > > * Are the ads matched to history by sending the history to a server that > > knows about what ad criteria there are or is the ad criteria sent to the > > browser and the matching done locally? > Matching for suggested tiles is done by giving enough information to Firefox > for decide on the machine without revealing your history to any server. Good. > > * Once there is a match, does loading the assets reveal which IP addresses > > belong to users for whom there was a match or are all assets sent to all > > browser instances so that the asset downloads reveal nothing? (That is, if > > you are the server that serves the TurboTax ad asset, do you only get > > requests from IP addresses that run browsers that have irs.gov in their > > history?) > Matching is done on a group of sites, so even if an image request is made, > it does not reveal which exact site is in the browsing history. Let's suppose the user has an interest that the user doesn't want revealed to Mozilla or advertisers, matching against a number of sites about that interest still reveals the interest if it is revealed that some site in that group matched even if the specific site isn't revealed. In that sense, not revealing particular sites isn't much of a mitigation if a match among a group of like-themed sites is revealed. > Additionally, the images are served from machines that delete logs within 7 > days, and often times we delete it much sooner -- immediately. That's a server-side policy that's not verifiable even if the user builds Firefox from source--not a client-side measure that makes sure the server has no technical ability to come in contact with that info. A client-side measure would be all clients loading all tile assets available at a given time so that the servers serving the assets couldn't infer anything about history matches based on the asset download. > > * Once the user clicks an ad, does the navigation to the target of the ad > > carry information about where the navigation came from? That is, can the > > TurboTax site tell that the user arrived to the site by clicking an ad that > > was shown based on matching the history for irs.gov? > Similar to how fetching the image doesn't reveal which site triggered it, > clicking the tile also does not reveal which site triggered the tile to be > shown in the first place. But does it reveal that it's a navigation from a given tile ad (as opposed to the navigation looking the same from the server perspective as the user typing turbotax.com or https://turbotax.intuit.com/ in the location bar and pressing enter)? > > * Is there some other way how info about there being a history match for a > > user at a particular IP address gets exfiltrated? > We are looking at ways to send this type of data to Mozilla servers to help > us optimize the groups of sites in bug 1142386. Basically, there's > techniques that allow all users to have reasonable deniability of whether > they visited a site or not, but across many users, we should be able to > measure trends, e.g., siteA triggered the tile 2x as often as siteB. > > > hsivonen, I'm not sure what explanation text you looked at, but the > questions sound like they come from a concern that someone could know > exactly which site you visited. Does an explanation text that hints that > multiple sites instead of one specific site help avoid this line of > questioning? The concern is whether the system allows (as far as is technically enforced on the client as opposed to promised policy-wise about what the servers do) someone to buy an ad to probe the users' history in such a way that information (whether info about visiting a particular site or visiting sites on a particular topic) about the history of a particular user (or browser running at a particular IP address as an approximation of a "particular user") is exfiltrated a) simply as a side effect of the ad getting displayed or b) at the point of the user clicking the ad. https://www.mozilla.org/firefox/tiles/ does not address the concern in a clear and obvious way.
Flags: needinfo?(hsivonen)
> > Matching is done on a group of sites, so even if an image request is made, > > it does not reveal which exact site is in the browsing history. > Let's suppose the user has an interest that the user doesn't want revealed to Mozilla or advertisers, > matching against a number of sites about that interest still reveals the interest if it is revealed that > some site in that group matched even if the specific site isn't revealed. In that sense, not revealing > particular sites isn't much of a mitigation if a match among a group of like-themed sites is revealed. Yes, in the oft sited example of how this will work in the first generation of this feature it is said that if a user frequents github, stack overflow, slack, etc - we'll show a MDN tile. The MDN tile in this case will revile to mozilla that this Firefox user has an interest in web development and we'll know the other the list of other web developer sites they frequent. As mentioned it could be policy that we won't look at this data, or do anything with it, but on the other side there is constant desire to understand how many Firefox users are "web developers" and understand how we might serve that set of users better. That's the tension that drives tracking and can lead us down a path of holding and using the data in ways that user might not expect. I think the paper that mmc put in https://bugzilla.mozilla.org/show_bug.cgi?id=1132534#c15 reflects the concern that it doesn't have to be exact sites, but leaking "likes" or areas of interest, and combinations of areas of interest is something we need to be concerned about, manage, and inform the user what the impressions, and clicks might be revealing.
Flags: needinfo?(athornburgh)
Blocks: 1143797
From our discussion: "Suggested for irs.gov visitors" don't link to irs.gov as the tile might already be on the new tab page and the user can type in the site dcrobot has some styling suggestions, e.g., the "irs.gov" text is darker
Updated styling to match mocks
Attachment #8577405 - Attachment is obsolete: true
Attachment #8579578 - Flags: review?(adw)
Attached image user-txt-screenshot.png
Attachment #8577407 - Attachment is obsolete: true
This looks great emtwo! I look forward to seeing the rollover states.
Updating string label to button (since the text will be clickable) and s/targetted/targeted
Attachment #8579578 - Attachment is obsolete: true
Attachment #8579578 - Flags: review?(adw)
Attachment #8579638 - Flags: review?(adw)
Comment on attachment 8579638 [details] [diff] [review] v3: Show suggested tile explanation text under a suggested tile Review of attachment 8579638 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/locales/en-US/chrome/browser/newTab.properties @@ +9,5 @@ > # and enhanced tiles on the same line as the tile's title, so prefer short > # strings to avoid overlap. This string should be uppercase. > newtab.sponsored.button=SPONSORED > +# LOCALIZATION NOTE(newtab.suggested.button): %1$S will be replaced inline by > +# one of the user's top 100 frecent site that triggered this suggested tile. "frecent" as in "frecency"? That's way too jargon, also site->sites. I think "top 100" would be enough to not confuse people. Also, I really hope the second part of the comment it's not true: the text should either wrap or be truncated, not invade other pieces of UI.
Truncate at a maximum of 3 lines & adjust localization comments
Attachment #8579638 - Attachment is obsolete: true
Attachment #8579638 - Flags: review?(adw)
Attachment #8580163 - Flags: review?(adw)
Comment on attachment 8580163 [details] [diff] [review] v4: Show suggested tile explanation text under a suggested tile Review of attachment 8580163 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/base/content/newtab/sites.js @@ +133,5 @@ > > + if (this.link.targetedSite) { > + let targetedSite = '<strong>' + this.link.targetedSite + "</strong>"; > + this._querySelector(".newtab-suggested").innerHTML = > + "<div class='newtab-suggested-bounds'>" + newTabString("suggested.button", [targetedSite]) + "</div>"; Using template strings might make this a little nicer. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings
Attachment #8580163 - Flags: review?(adw) → review+
Flags: firefox-backlog+
Status: NEW → ASSIGNED
Flags: qe-verify?
Steps to qe-verify: 1) change about:config pref "browser.newtabpage.directory.source" to.. https://people.mozilla.org/~msamuel/related.json 2) load "irs.gov" from location bar 3) open new tab and see the text
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Depends on: 1146146
Flags: qe-verify? → qe-verify+
QA Contact: cornel.ionce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Mozilla/5.0 (X11; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0 Tested on Windows 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5 using the STR from comment 48 with latest Nightly, build ID: 20150323030203.
Status: RESOLVED → VERIFIED
Blocks: 1148859
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Firefox/38.0 Confirming this change on Firefox 38 beta 2 (build ID: 20150406174117) also.
Blocks: 1155443
No longer blocks: 1155443
Depends on: 1180387
No longer depends on: 1180387
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: