Closed Bug 471627 Opened 16 years ago Closed 16 years ago

Update text of about:private browsing before string freeze

Categories

(Firefox :: Private Browsing, defect)

Product:
Firefox
Component:
Private Browsing
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1b3

People

(Reporter: faaborg, Assigned: ehsan.akhgari)

References

Details

(Keywords: late-l10n, verified1.9.1)

Attachments

(1 file, 1 obsolete file)

Patch (v2)
11.73 KB, patch
Gavin
: review+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review 
We should decide on the final text we want for about:privatebrowsing prior to the string freeze.
From an email by beltzner:

Suggested new text - please comment:

title = You are now browsing privately

subtitle =  %shortName won't record any history until you exit Private Browsing Mode.

content =

The browser history, search history, download history, web form history, cookies, and temporary internet files from this browsing session will be destroyed once you are finished. However, any files you save to disk, or bookmarks you create will be kept.

To exit this mode, select the Private Browsing item from the Tools menu, or quit %shortName.

You can also clear your recent history that was collected before you started Private Browsing.

( Clear Recent History ... )

// other comments:

- Do we want to make the menuItem say "Start Private Browsing" and "Stop Private Browsing"? That would allow us to refer to the "Stop Private Browsing" item in the menu. I think I might have fallen on the other side of this issue before, but as I was writing this dialog, I think we might want to go the other way.

- we should put the focus in the location bar when the about private browsing tab loads, imo
>title = You are now browsing privately

yep, this sounds good

>subtitle =  %shortName won't record any history until you exit Private >Browsing Mode.

>The browser history, search history, download history, web form history, >cookies, and temporary internet files from this browsing session will be >destroyed once you are finished.

The distinction between "destroyed when you are finished" and the more generic "No history will be recorded" seems mostly implementation centric, and may cause users to feel that our implementation isn't good enough (they would want us to just not record the stuff in the first place).  I think we should obfuscate this underlying detail with the simpler phrase: "will not be recorded" or "won't remember."  Also destroyed seems to have a little bit of connotation to it, kind of like "shredded" but not as strong.  I personally like the connotation of "Firefox will not pay attention" instead of "Firefox will help you destroy evidence."

>To exit this mode, select the Private Browsing item from the Tools menu, or >quit %shortName.

Perhaps "uncheck" instead of select?

>You can also clear your recent history that was collected before you started >Private Browsing.

>( Clear Recent History ... )

Aza points out that this button has so much visual weight, that users will probably not read anything, and then hit it thinking that they need to in order to get into private browsing mode.  I agree with him, and think that we should switch to having "clear recent history" in the sentence be a hyperlink to the dialog box.  I know that this breaks conventions of having a hyperlink that accesses chrome, but I can't think of any other way around the problem of users blinding clicking the button and then OK in order to enter private browsing mode (which they are already in).

>- Do we want to make the menuItem say "Start Private Browsing" and "Stop >Private Browsing"? That would allow us to refer to the "Stop Private Browsing" >item in the menu. I think I might have fallen on the other side of this issue >before, but as I was writing this dialog, I think we might want to go the >other way.

I think we should follow common OS conventions here, although I'm a bit confused on which platforms use checked menus and which use changing command text.

>- we should put the focus in the location bar when the about private browsing >tab loads, imo

yep, good catch.
Suggested text:

title = Private Browsing

subtitle = %shortname won't remember any history for this session

content =

When private browsing, %shortname doesn't record browser history, search history, download history, web form history, cookies, and temporary internet files.  However, files you download and bookmarks you make are preserved.

You may want to start by also _clearing your recent history_ (<- hyperlink)

To stop private browsing, uncheck Tools > Private browsing, or close %shortname.

[16x16 information icon] While this computer won't have a record of your browsing history, your internet service provider or employer can still track the pages you visit.  _Learn More_.

-------------------------------------------------

The learn more hyperlink needs to go to a page similar to the help page we were planning for larry, with additional information (and maybe a diagram) about the various entities that can collect information about you.

Objectives:

1) be intentionally vague about when the stuff is deleted, since it varies, and it isn't worthwhile for the user to stress about the implementation details

2) establish the term "History" to mean what we want it to mean, a collection of various types of history

3) (seriously) provide enough of a warning that if someone makes assumptions, and then gets fired, divorced, or goes to jail, they don't later attempt to murder me.
What about the case where about:privatebrowsing is visited outside the private browsing mode?  (bug 463400)
(In reply to comment #2)
> The distinction between "destroyed when you are finished" and the more generic
> "No history will be recorded" seems mostly implementation centric, and may

First, while I agree entirely that the goal of this text shouldn't be to explain how the feature worked, I do think we need to be clear that during the Private Browsing Mode session the browser will be collecting cookies which will only be deleted once we exit. Otherwise a user may be caught out by surprise.

Second, setting up the pairing between "destroyed" and "preserved" made the two statements stand out more starkly from each other.

> obfuscate this underlying detail with the simpler phrase: "will not be
> recorded" or "won't remember."  Also destroyed seems to have a little bit of
> connotation to it, kind of like "shredded" but not as strong.  I personally
> like the connotation of "Firefox will not pay attention" instead of "Firefox
> will help you destroy evidence."

All good points: "won't remember" seems like a good fit.

> >To exit this mode, select the Private Browsing item from the Tools menu, or >quit %shortName.
> 
> Perhaps "uncheck" instead of select?

I suppose, though I quite hate that as a verb, really.

> dialog box.  I know that this breaks conventions of having a hyperlink that
> accesses chrome, but I can't think of any other way around the problem of 

Makes sense, and I'm not one to be bound by conventions when sense is on the line.

> I think we should follow common OS conventions here, although I'm a bit
> confused on which platforms use checked menus and which use changing command
> text.

Common OS conventions are to "do what works best". OSX is really the only system that sometimes changes the name of the item depending on the action (usually for "Show" and "Hide" operations).

To me, it feels like the operation is really more than turning a mode on or off. It's entering and exiting a mode. I think we should change the name of the menuItem, personally, and if you don't have significant objections, I'd suggest we do it.

(In reply to comment #3)
> Suggested text:
> 
> title = Private Browsing
> 
> subtitle = %shortname won't remember any history for this session
> 
> content =
> 
> When private browsing, %shortname doesn't record browser history, search
> history, download history, web form history, cookies, and temporary internet
> files.  However, files you download and bookmarks you make are preserved.

nits:
 s/doesn't record/won't keep any/ 
 s/and temporary/or temporary/

those OK? Otherwise this all looks great.

> To stop private browsing, uncheck Tools > Private browsing, or close
> %shortname.

If we change the name of the menuItem, we can make this "To stop private browsing, select Tools > Stop Private Browsing, or close %shortName."

> [16x16 information icon] While this computer won't have a record of your
> browsing history, your internet service provider or employer can still track
> the pages you visit.  _Learn More_.

Good idea. Need to file a bug for the _Learn More_ stuff. Not sure we can get it done in time, but that string looks right for the UI, and we can land the string now and translate it and then enable the UI if/when we get the web page up.
(In reply to comment #5)
> (In reply to comment #2)
> > The distinction between "destroyed when you are finished" and the more generic
> > "No history will be recorded" seems mostly implementation centric, and may
> 
> First, while I agree entirely that the goal of this text shouldn't be to
> explain how the feature worked, I do think we need to be clear that during the
> Private Browsing Mode session the browser will be collecting cookies which will
> only be deleted once we exit. Otherwise a user may be caught out by surprise.

I think we are trying to differentiate between "keeping permanent tracks" and "not keeping permanent tracks" of what users do here, and what private browsing mode does is "not keeping permanent tracks".  IOW, nothing is "destroyed" when leaving the private mode.  Either we don't track something, or we track it temporarily inside the private browsing mode, so I agree with Alex that we should say "won't remember" instead of "destroyed when you're done".

My $.2...
Uh, keep reading, Ehsan, and you'll see that "won't remember" was what I agreed with as well, and "won't keep" is what I ended up counter-proposing to his edits. :)
(In reply to comment #3)
> 
> [16x16 information icon] While this computer won't have a record of your
> browsing history, your internet service provider or employer can still track
> the pages you visit.  _Learn More_.
> 
> -------------------------------------------------

Don't forget about mentioning Google here (ie. one and default provider of "safebrowsing" service). I finished a project that shows that it is possible for them to gather some data about visited pages in some cases... See http://bb.homelinux.org/firefox/sb2/ for a demo.
(In reply to comment #7)
> Uh, keep reading, Ehsan, and you'll see that "won't remember" was what I agreed
> with as well, and "won't keep" is what I ended up counter-proposing to his
> edits. :)

Oh, sorry for the misunderstanding!

So, is this version of the text considered final, so that I can make a patch out of it?
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Keywords: late-l10n
Yes, please go ahead, and thanks. I don't have a recent tree. Don't forget to change the entity IDs, and to not yet actually show the entity for the "While this computer won't have a record..." bit as we don't have a webpage there. When we do, the webpage would be at:

http://www.mozilla.com/%LOCALE%/firefox/private-browsing/
Attached patch Patch (v1) (obsolete) — — Splinter Review 
This patch updates the text as discussed, removes the "Enjoy!" text at the bottom of about:pb, and uses "Start/Stop Private Browsing" as the menu item.

Beltzner: please review string parts so that if mconnor doesn't get to review the patch in time, we can land the string changes.
Attachment #354974 - Flags: ui-review?(beltzner)
Attachment #354974 - Flags: review?(mconnor)
Blocks: 471726
Comment on attachment 354974 [details] [diff] [review]
Patch (v1)

nit:

>+<!ENTITY privatebrowsingpage.description               "When private browsing, &brandShortName; won't keep any browser history, search history, download history, web form history, cookies, or temporary internet files.  However, files you download and bookmarks you make are preserved.">

s/are preserved/will be kept.

I should have caught it before that.

uir+r+a191=beltzner for the string parts
Attachment #354974 - Flags: ui-review?(beltzner) → ui-review+
(In reply to comment #5)
> > [16x16 information icon] While this computer won't have a record of your
> > browsing history, your internet service provider or employer can still track
> > the pages you visit.  _Learn More_.
> 
> Good idea. Need to file a bug for the _Learn More_ stuff. Not sure we can get
> it done in time, but that string looks right for the UI, and we can land the
> string now and translate it and then enable the UI if/when we get the web page
> up.

Filed bug 471726.  This patch only adds the strings, and doesn't add those to the page yet.  I'll do that in bug 471726.
(In reply to comment #12)
> uir+r+a191=beltzner for the string parts

Thanks.  I still need code review though...  :/
Whiteboard: [needs review mconnor]
Comment on attachment 354974 [details] [diff] [review]
Patch (v1)

>+<!ENTITY privatebrowsingpage.moreInfo                  "While this computer won't have a record of your browsing history, your internet service provider or employer can still track the pages you visit.">

I see that you have chosen to ignore my comment #8 above :-(. Personally I think not mentioning Google here is very misleading from the point of average user.

"Firefox Privacy Policy" (which is integral part of EULA, actually) also says about it, so about:pb is a good place to remind users about this potential privacy invasion (users should read about this, but we all know that users usually don't read EULAs and related documents :-/): http://www.mozilla.com/en-US/legal/privacy/firefox-en.html : "(...)  it is possible that a third party service provider may determine the actual URL from the hashed URL sent (...)".
(In reply to comment #15)
> I see that you have chosen to ignore my comment #8 above :-(. Personally I
> think not mentioning Google here is very misleading from the point of average
> user.

We can't possibly list all the places which may store tracks of your activities here.  Here are some examples: a logging firewall software on your own computer, a phishing detection service provider, a 3rd party service provider used by an extension, your router, the website you visit, the 3rd parties which a certain website chooses to share its web logs with, and possibly everyone if a website makes its web logs public.

What this string is trying to convey is what promises we're trying to make (not storing any tracks inside Firefox profiles on this computer) and not what we're not promising (every place in which the tracks can still be stored).
(In reply to comment #16)
> We can't possibly list all the places which may store tracks of your activities
> here.  Here are some examples: a logging firewall software on your own
> computer, a phishing detection service provider, a 3rd party service provider
> used by an extension, your router, the website you visit, the 3rd parties which
> a certain website chooses to share its web logs with, and possibly everyone if
> a website makes its web logs public.

Most examples enumerated by you are either outside of Firefox or even outside of user control. OTOH Google's "safebrowsing" is integral part of Firefox and is enabled by default, even in "private browsing" mode.
Attachment #354974 - Flags: review?(mconnor) → review?(gavin.sharp)
Attachment #354974 - Flags: review?(gavin.sharp) → review-
Comment on attachment 354974 [details] [diff] [review]
Patch (v1)

>diff --git a/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml b/browser/components/privatebrowsing/content/aboutPrivateBrowsing.xhtml

The comment removals in this file seem unnecessary.

>+          <p>&privatebrowsingpage.clearRecentHistoryBefore; <a href="javascript:openSanitizeDialog();">

That space before the <a should also be omitted to allow localizers to control it (as you've done with the space after it), shouldn't it?

>diff --git a/browser/locales/en-US/chrome/browser/aboutPrivateBrowsing.dtd b/browser/locales/en-US/chrome/browser/aboutPrivateBrowsing.dtd

>+<!ENTITY privatebrowsingpage.howToStop                 "To stop private browsing, select &toolsMenu.label; &gt; &privateBrowsingCmd.stop.label;, or close &brandShortName;.">

Hmm, I thought I recalled that using entities within entities could lead to problems in certain cases, but I don't remember the details. Perhaps it was just related to ensuring the DTDs were referenced in the right order? Axel would probably know.

>+<!ENTITY privatebrowsingpage.moreInfo                  "While this computer won't have a record of your browsing history, your internet service provider or employer can still track the pages you visit.">
>+<!ENTITY privatebrowsingpage.learnMore                 "Learn More">

Looks like these are unused... is this the wrong patch or something?

>diff --git a/browser/locales/en-US/chrome/browser/browser.dtd b/browser/locales/en-US/chrome/browser/browser.dtd

>+<!ENTITY privateBrowsingCmd.start.label         "Start Private Browsing">
>+<!ENTITY privateBrowsingCmd.start.accesskey     "B">
>+<!ENTITY privateBrowsingCmd.stop.label          "Stop Private Browsing">
>+<!ENTITY privateBrowsingCmd.stop.accesskey      "B">

It might be obvious enough from the strings, but an l10n note indicating that these can share an accesskey since they won't ever appear together wouldn't hurt.

>diff --git a/browser/themes/pinstripe/browser/aboutPrivateBrowsing.css b/browser/themes/pinstripe/browser/aboutPrivateBrowsing.css
>diff --git a/browser/themes/winstripe/browser/aboutPrivateBrowsing.css b/browser/themes/winstripe/browser/aboutPrivateBrowsing.css

Looks like you forgot to make these changes to gnomestripe's aboutPrivateBrowsing.css?

r- because of the unused entities, but looks good otherwise with those addressed!
Whiteboard: [needs review mconnor]
Attached patch Patch (v2) — — Splinter Review 
(In reply to comment #18)
> Hmm, I thought I recalled that using entities within entities could lead to
> problems in certain cases, but I don't remember the details. Perhaps it was
> just related to ensuring the DTDs were referenced in the right order? Axel
> would probably know.

AFAIK, that's related to the ordering of DTD files, which is correct for this change.  I have tested the patch to make sure the entities resolve correctly.

> >+<!ENTITY privatebrowsingpage.moreInfo                  "While this computer won't have a record of your browsing history, your internet service provider or employer can still track the pages you visit.">
> >+<!ENTITY privatebrowsingpage.learnMore                 "Learn More">
> 
> Looks like these are unused... is this the wrong patch or something?

No, that's intentional.  We just want to have these two strings for now.  The UI for these strings will land in bug .

> r- because of the unused entities, but looks good otherwise with those
> addressed!

Fixed all of the comments.
Attachment #354974 - Attachment is obsolete: true
Attachment #355062 - Flags: review?(gavin.sharp)
Attachment #355062 - Flags: review?(gavin.sharp) → review+
(In reply to comment #19)
> No, that's intentional.  We just want to have these two strings for now.  The
> UI for these strings will land in bug .

argh, that is bug 471753
Landed on mozilla-central <http://hg.mozilla.org/mozilla-central/rev/9c13f028da54>
Target Milestone: --- → Firefox 3.2a1
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #355062 - Flags: approval1.9.1? → approval1.9.1+
Blocks: 471753
Marcia, does the changes need some litmus updates?
Flags: in-litmus?
Target Milestone: Firefox 3.2a1 → Firefox 3.1b3
s/When private browsing/When browsing privately/ ?
adding in-litmus+ since I updated all the relevant Private Browsing testcases in Litmus.
Flags: in-litmus? → in-litmus+
The page contains the text "Temporary Internet Files", which is an Internet Explorer term. Firefox uses the word "Cache" in the UI, so about:privatebrowsing should be using that term as well.
(In reply to comment #27)
> The page contains the text "Temporary Internet Files", which is an Internet
> Explorer term. Firefox uses the word "Cache" in the UI, so
> about:privatebrowsing should be using that term as well.

In the clear recent history dialog it's called "Web Cache". So to be consistent we should use this term?
(In reply to comment #28)
> In the clear recent history dialog it's called "Web Cache". So to be consistent
> we should use this term?

In Firefox 3.0 it's just called "Cache", but "Web Cache" sounds okay too. Anything but "Temporary Internet Files", really. ;)
IIRC Beltzner actually thinks that Temporary Internet Files is a better name.  I personally agree, since "cache" is really an implementation level jargon which should not be exposed to the users who do not necessarily know what it means.
Well, which (In reply to comment #30)
> IIRC Beltzner actually thinks that Temporary Internet Files is a better name. 
> I personally agree, since "cache" is really an implementation level jargon
> which should not be exposed to the users who do not necessarily know what it
> means.

Well, which term is "better" is not what is being discussed here. It is about fixing the about:privatebrowsing page to be consistent with the rest of Firefox, which is more important. Changing the term to Temporary Internet Files should be a different bug.
(In reply to comment #31)
> Well, which (In reply to comment #30)
> > IIRC Beltzner actually thinks that Temporary Internet Files is a better name. 
> > I personally agree, since "cache" is really an implementation level jargon
> > which should not be exposed to the users who do not necessarily know what it
> > means.
> 
> Well, which term is "better" is not what is being discussed here. It is about
> fixing the about:privatebrowsing page to be consistent with the rest of
> Firefox, which is more important. Changing the term to Temporary Internet Files
> should be a different bug.

If we're going to be technical about bug divisions and so forth, this is a closed bug, and we are post-string freeze, so it can all go into another bug.

Having said that, I don't particularly believe that "consistency" has more immediate priority than choosing better language, in general, so such a bug might indeed have us changing all instances to some better term, if one is forthcoming.
>The page contains the text "Temporary Internet Files", which is an Internet
>Explorer term. Firefox uses the word "Cache" in the UI, so
>about:privatebrowsing should be using that term as well.

We are slowly trying to update all of our terminology related to privacy and history to be consistent.  More details in bug 464204
Verified fixed on the 1.9.1 branch using  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre. Adding keyword.

Verified on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
An automated test makes no sense for this bug.
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: