Tor Browser history leaked to syslogs via GNOME

Window titles!

added Uplift label

added Backport label

Browser windows should not be updated with the page title in private browsing mode.

@honorton are you willing/able to do the investigative work to figure out where the window-title updating code lives that we would need to patch?

The ideal fix for this is to gate the the HTML title -> Window title pathway based on whether or not we are in private browsing mode. I would guess Firefox has some platform abstraction layer to communicate with the shell/desktop manager similar to the clipboard code that we can surgically modify.

added 13.5 stable label

added Backlog label

@honorton opened an upstream bug with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1849186

If you have a Mozilla Bugzilla account I can add you to the issue.

Thanks again for the report!

Upstream liked our idea of adding a pref to keep only the browser name in the window title, so yesterday I sent a patch to implement it.

I'd like to coordinate with upstream, have them review it (ma1 already reviewed my proposal and suggested a change), and cherry-pick after they merge.

In addition to that, I think that we could expose a UI to set these preferences.

I think we should have only the browser name by default for Tor Browser, but I expect this functionality to be disruptive for some kind of users, so I wouldn't mind letting them disable it easily.

In addition to that, I think that we could expose a UI to set these preferences.

I think we should have only the browser name by default for Tor Browser, but I expect this functionality to be disruptive for some kind of users, so I wouldn't mind letting them disable it easily.

@donuts

Basically the idea is that by default we want to hide the page title from being visible in various system UIs, such as alt tab, window preview etc, and only display Tor Browser there.

The reason is to avoid disk leaks by logs created by external programs.

It feels strange to me to add a setting (i.e. entry in about:preferences) for this specifically, but not other disk-leak protections. Also potentially risky?

I think this is pretty nasty, nobody really thought of this, but it can really dump your sessions under some circumstances (I guess OP was having some bug for which they got a lot of log entries).

I think the title window is the most exposed thing to the OS in a certain sense. The browser tells it, and the list of windows is known to all programs, not necessarily evil ones (such as this case).

So, I think most of us devs are up for hiding the content title by default, or to do it at least on Linux where this problem first happened. However, the effect is particularly visible to the users (many system UI elements include the window title), and I'd expect many, many users to be annoyed by this.

Thanks for the longer explanation! I'd need to review what system UI elements include the window title on each platform before saying for sure.

Ack, thank you!

Upstream has lifted confidentiality, I think we could do the same and then cherry-pick once they merged, and in case keep false by default (or set to true only on alpha, and then see how it goes there, even though I think alpha feedback would be biased).

@pierov seems upstream is taking their time on this, do we have a patch we can apply to Tor+Mullvad Browse's in the meantime?

A person commented about that they didn't like the prefs name, and now this has been blocked for almost a month (October 12).

I wonder if they realize they're blocking the patch. I will ping them on Monday (November 13).

@richard do you want this in the next alpha?

FWIW, we're also getting tags between Monday and Tuesday, and the next Firefox ESR release is expected on November 21, so is 13.0.4.

So, if we want this in 13.5a2 we should target the (end) of the next week.

Maybe we could then backport it to 13.0.5, but I'm not very happy to without a UX response/user feedback about the fix.

Ideally I'd like some version of this in the next alpha. If there's some debate over the proper pref name we can just disable the feature unconditionally (ie: always hide the website name from the window manager) and then backport w/e patch lands upstream while setting the pref to disable by default when in private browsing mode.

@donuts does that sound ok for you from a UX perspective (default to the privater/safer option for now and allowing users to opt-out in the future once we have an upstream patch)?

I've just added a comment to the differential review.

We still have at least 10 days before the next alpha, hopefully they'll land my patch.

@richard Yep, sounds good!

Ideally I'd like some version of this in the next alpha.

To be clear, although this ticket is tagged as Linux, you'd like to make this change across all platforms – correct?

Correct.

The code is gated behind a pref (because we sent it directly to Firefox).

We flipped that pref to enable it on all platforms, but we can change it to be Linux-specific if needed.

EDIT: Firefox hasn't it on. They told us they liked the solution, as long as it was default off, whereas it's default on for us.

Thanks @pierov!

@richard To be clear (because it was left vague), my previous "Yep, sounds good!" is in relation to alpha, but I'd rather not backport anything to stable until we better understand the severity of the issue, the UX impact and have a workaround in place pls.

Followup: I'm beginning to think that the UX impact is severe enough that we shouldn't be rushing this into Alpha either – assuming you were aiming for 13.5a2?

Yes, that was our goal.

We still have time to disable it before going to alpha.

Thanks @pierov :)

removed 13.5 stable label

added 13.0 stable label

added Linux label

added Upstream label

assigned to @pierov

removed Backlog label

added Doing label

added 13.5 stable label

added Next label and removed Doing label

changed due date to November 13, 2023

@jag Do you use a GNOME based distro? If so, I'd love to hear your thoughts about the UX impact of this change once it lands.

I use KDE but I've used GNOME in the past as well I can run something on a VM and try out a build. @pierov is it available to test out a build right now?

Tangentially, I haven't used Windows in a minute I'm wondering if this affects that platform as well with https://support.microsoft.com/en-us/windows/-windows-activity-history-and-your-privacy-2b279964-44ec-8c2f-e0c2-6779b07d2cbd ?

@jag this should be in the latest nightly.

In general, the window title is easily available through APIs in all desktop platforms. Getting the actual content might be still feasible (e.g., pretend to be a screen reader).

We don't want to protect from malware or software that goes watching your browser (it'd be a difficult if not impossible task), but from software that enumerates windows for any reason, even not malicious ones (such in this case, i.e., log a problem with a program).

I think on Windows the title will disappear from the window preview you get in the taskbar (and any associated tooltip). I didn't even think to the activity history .

made the issue visible to everyone

mentioned in merge request !846 (merged)

mentioned in issue #42279 (closed)

@donuts @pierov @richard looking at this a bit more it looks like the issues will be revolving around people who use multiple TB windows:

Multitasking: people who run multiple browser windows can run into more friction. On KDE, minimized windows are indistinguishable.

On GNOME, windows are hard to distinguish as well without accompanying text especially on smaller monitors where the thumbnails are tiny.

Screen readers: I haven't tested this yet because I'm unfamiliar with screen readers on Linux, but I suspect screen readers will need to read the window titles of the window when switching applications so it might be difficult to distinguish between multiple TB windows when using screen readers. I'll make sure to verify this.

On GNOME it's a little bit better when you open the activity view (you go on the top left corner with your mouse or click on the super button) since it has big previews (well, it depends on how many windows you have in a workspace).

marked this issue as related to #42279 (closed)

added Backlog label and removed Next label

mentioned in issue #41987

mentioned in issue #41335 (moved)

mentioned in merge request !850 (merged)

/cc @ruihildt (the idea is fixing this in Base Browser, so Mullvad Browser will be changed as well).

I'd like to think about this in terms of threat model before setting it on by default in stable.

Perfectly fine to experiment with in in Alpha.

Talked to @donuts next steps for me:

Look into Windows and macOS as well
Thoroughly screenshot / take down different ways the UX can break.

Hi I wanted to give an update here I took screenshots of all the different ways a user would be switching between Tor Browser windows on different platforms.

I don't have a sense of the UX impact just yet I want to look into Mozilla's telemetry information in https://telemetry.mozilla.org/ if there's any information on people using multiple windows.

Hi all,

the patch can be tested in the lastest alpha by flipping privacy.exposeContentTitleInWindow in about:config to true.

Ok! So here's some data to help us get a sense of the UX impact of this change:

As mentioned above, issues with removing the title--as far as I can tell--will be revolving around people who use multiple browser windows so I went to look at different desktops (Windows, GNOME, KDE, macOS) to see how users switch between applications:

As you can see, most of the app switching methods include a thumbnail of the window itself:

Windows (by far the biggest platform used by TB users): all methods show thumbnails
macOS: 3 out of 4 show thumbnails
Linux/BSD: 6 out of 7 show thumbnails

So I believe switching between multiple TB windows without titles wouldn't add much friction because they're most likely accompanied with a visual aid.

Of course there are people who have visual disabilities, have small monitors, or have a lot of windows and can't depend on the thumbnails alone as a visual aid. I think a way to think about the UX impact in this case is to get data on the number of browser windows people use so that we can get a sense of how difficult it would be for the user to iterate through each one. Fortunately, Firefox has information on the number of windows people have open per session:

Here we see that for Firefox 121 users:

79.46% of sessions use only one browser window
13.39% of sessions use two browser windows
3.57% of sessions use three browser windows

So I think this tells us that people don't use multiple windows at all and if they do, they will have to switch to just one other browser window to find the tab that they're looking for. So taken together with window thumbnails + people having at most 2 windows at a time, in my opinion the impact is minimal if we do decide to do ship it by default or add an option for it.

Thank you very much Jag!

in my opinion the impact is minimal if we do decide to do ship it by default or add an option for it.

Please let us know if we can do it for 13.5a3 (even though 13.5a3 will be a little be painful, because the corresponding ESR update is scheduled for December 19).

Having it as a default and providing a UI toggle is still my favorite option.

Checkboxes for boolean preferences should be very easy to add and be automatically managed once you've added them on markup (there's a special attribute to specify the pref name with the checkbox, IIRC).

Also, I remembered of another way of checking window titles on GNOME: right click on the corresponding dock icon.

I guess another part of deciding whether we should do this, I think, is to see what kind of information is retrieved when the user's device ends up in the wrong hands (a partner, a family member, border patrol, etc.) especially since our biggest platform doesn't offer disk encryption by default (if I understand correctly Windows Home doesn't encrypt the drive with BitLocker but Windows Pro does).

So, I think I need help with this decision @donuts @pierov @richard because even though the UX impact is minimal, we would still be designing the UI toggle, creating copy for it, creating help pages for it, translating it, etc:

Should we wait and see until we get more evidence of disk leaks in other platforms and even distros? I don't seem to see the syslog issue on my own Debian system (KDE) and in a VM running Debian GNOME.
Should we take the paranoid route and just remove the titles in all platforms?

I'd be up for enabling it, but maybe I'm a bit biased since I sent the patch upstream .

Probably, documentation will require the biggest effort here.

I think a UI toggle in of about:preferences#privacy would be fine (e.g., like the breach alert checkbox, but in the cookie section, for example).

removed Backport label

removed 13.0 stable label

Should we do something about this for 13.5a3?

When is 13.5a3 planned for? I see a nameless alpha in the release cal for January 30th.

13.5a3 is for before the break (next week).

Jan 30th might be 13.5a4, unless we do an additional 13.5a4 for the code review deadline.

Ah okay, gotcha. The UX team are really busy with sponsor work and end of year activities at the moment, so we're not going to be able to look at this before January at the earliest.

This was assigned CVE-2023-6872!

Thanks for the heads up @pierov!

Is this still a possible for 13.5, or should we reschedule for 14.0?

I'm happy to proceed with a new pref somewhere in Settings, however it will need design input and copy.

Are you confident there's enough time remaining in the 13.5 release cycle for this? We can always backport this feature after the release too, since it's security related.

It depends on what the pref ends up being.

If it's a checkbox (for showing only "Tor Browser"), it should be trivial to do, but we need to do it asap to have it translated.

If we want to do anything else, we should target a later release.

I wonder if we could add it but disabled by default, and maybe talk about it in the release post.

@pierov Instead of "Tor Browser" getting repeated as the window title, I'm wondering if there's some useful information we can display instead – for example:

Simple numbering of the windows: "Window 1", "Window 2", "Window 3" etc.
Naming the windows by the number of open tabs, e.g.: "3 tabs", "1 tab", "4 tabs" etc.
Some kind of randomly generated, but readable identifier – like Jitsi rooms (which wouldn't be localizable, unfortunately).

Naming the windows by the number of open tabs, e.g.: "3 tabs", "1 tab", "4 tabs" etc.

I like this!

Some kind of randomly generated, but readable identifier – like Jitsi rooms (which wouldn't be localizable, unfortunately).

Randomized by us or selectable by the user? I.e., they don't want to leak exact titles, but maybe adding a name is good enough.

So for sighted folks, I imagine the name doesn't really matter given the majority of platforms show thumbnails/window previews (which is typically how i navigate all my windows). However, there are probably UX implications here for screen-reader users.

My hunch would also be some informative name w/ metrics suggested by @donuts would be good (something like Tor Browser - Window 3 (128 Tabs))

ping @henry

The question of course then becomes, suppose if you have 2 windows, close the first window, and then open a new window. Is your resulting set of windows:

Tor Browser - Window 2 (21 tabs)
Tor Browser - Window 3 (1 tab)

or

Tor Browser - Window 1 (1 tab)
Tor Browser - Window 2 (21 tabs)

If Window number only increments we're leaking more session info than is necessary to the desktop environment and syslogs, but if we re-use window ids then there's some potential for confusion.

I love the idea of doing both approaches (i.e. naming windows and numbering tabs). A combination of proposals 2 and 3 would feels more easily memorable – e.g.:

Curious alpaca (8 tabs)

But the l10n issue is still present.

I would avoid injecting the application name into window titles though, at risk of it getting duplicated, and instead leave it up to the OS to determine when to display or read-back that info.

I reckon the particulars are going to be platform specific regarding whether or not to put the application name in the title.

From a screen reader perspective, the window title is used for:

The accessible name of windows when selecting from a list (e.g. with "Alt+Tab").
Announced when the user re-focuses the window.

For 1, the order of the windows provides a little bit of information. But ideally the titles would be distinguishable.

For 2, including the web page title could help the user understand where exactly they have returned to. Using default Orca, I couldn't find a good way to get the web title to read back immediately after re-focusing. I guess the user could navigate around to re-orient themselves though (e.g. reading the url, or switching tabs back and forth will re-read it). Using default NVDA, it speaks both the window title and the web page title on re-focus, so removing the web page title from the window title actually reduced some double-speak.

Regarding what the window title content should be:

NVDA will announce when the window title changes. So we should only change it when it wouldn't be confusing for the user.
It needs to be relevant and understandable. So include "Tor Browser".

The question of course then becomes, suppose if you have 2 windows, close the first window, and then open a new window.

This is hard. I would say that if you only have one window, it should not include "Window 1" because it is redundant and implies there are several windows open.

My instinct is to keep the window numbers persistent and reset them whenever we go back to one window (including new identity).

I have two ideas for where we could house the new preference:

We rename the new Letterboxing section in General to "Windows" (or something similar), where it would then house the preferences for Window size, Window titles and Letterboxing alignment.
Alternatively, anticipating that we may want to expose additional prefs related to disk leak protections in future, we create a new subsection for these preferences in Privacy & Security. However I'm stuck on what that new section could be called – something like "System protections"? Do you have any suggestions?

I suggest Fingeprinting protections.

I see it as an opportunity to educate users about browser fingerprinting in general.

something like "System protections"?

I'd avoid this.

We want to convey the message that previous threat models were over promising when it came to protecting by your own system.

Removing the page title is a protection against "accidental" leaks (like the one from OP) and/or light threats, not from programs actively trying to access your browser data.

I suggest Fingeprinting protections.

I think it'd be good for other prefs, such as Letterboxing, but this isn't a fingerprinting vector.

But maybe if we end up adding other sections, we could have a misc/other for stuff including disk leaks.

Alternatively, anticipating that we may want to expose additional prefs related to disk leak protections in future, we create a new subsection for these preferences in Privacy & Security. However I'm stuck on what that new section could be called – something like "System protections"? Do you have any suggestions?

Maybe "Disk leak protections"? Or "Accidental disk leak protections"?

Maybe "Disk leak protections"? Or "Accidental disk leak protections"?

@boklm I was trying to avoid saying "disk leak" as it's not a meaningful term to most users, but an argument could be made that it's better to be consistent with our terminology – e.g. by matching the language used in documentation like the design doc.

Thinking more about it, I think it's ok to go with solution 1, and make change the future if/when it is needed. It seems like an ok problem to postpone for future selves.

@boklm I was trying to avoid saying "disk leak" as it's not a meaningful term to most users, but an argument could be made that it's better to be consistent with our terminology – e.g. by matching the language used in documentation like the design doc.

Yes, it's probably not a meaningful term for most users now, but it also feels like a useful term to learn for users to better think about their threat model.

something like "System protections"? Do you have any suggestions?

What about system interaction instead?

That could fit also with #42717.

removed 13.5 stable label

added 14.0 stable label

removed Backlog label

added Roadmap::Future label

removed due date November 13, 2023

Implementation

Constraints

OS/3rd Party apps may read the browser window title at any time, so we should provide a way to not set the OS window title to the website's title in private browsing mode to avoid leaking session data (PBM)
Titles used in various parts of the desktop manager chrome, so each window should be unique/identifiable in:
- taskbars
- app switchers
- other window-selecting contexts (eg selecting a window to record in OBS)
80% of users only have 1 window open at a time, 96% of users use <= 3 windows (Firefox telemetry)
Screen Readers:
- Window title used when switching apps (eg Alt+Tab)
- Window title announced when focusing a window
- Window title announced when it changes
Mullvad Browser and Tor Browser will have the same implementation, and may be running concurrently on a user's system

Requirements

Window content MUST NOT be somehow derivable from window titles
Window titles MUST be unique, differentiable from each other
Window titles MUST be stable, MUST NOT arbitrarily change
Window titles MUST indicate to the user which browser it is (Tor Browser, Mullvad Browser, Firefox)

Proposed Solutions

Application name: Tor Browser
- not differentiable between windows, fine for ~80% of users
Numbered Application name: Window 1 - Tor Browser, Window 2 - Tor Browser
Pet name: Fuzzy Squirrel - Tor Browser, Curvy Giraffe - Tor Browser
- additional localisation needs
$NAME + (n tabs): Tor Browser (1 tab), Window 1 - Tor Browser (13 tabs), Albino Platypus - Tor Browser (3 tabs)
- will change the window title frequently when using the browser, probably awful UX for screen-reader users

Configuration

Requirements

SHOULD somehow communicate the trade-offs between the options with regards to:
- desktop manager usability
- accessibilty
- privacy/disk leaks
MUST be an optional protection
- some use-cases mean disabling even in PBM are fine (eg Tails)

Proposed Solutions

Renaming current 'Letterboxing' section to 'Windows' and options there
New section under 'Privacy & Security' for disk-leak related protections
New 'Fingerprinting Protections' section in 'Privacy & Security'

Next Steps

Assuming the above summary is accurate (and please correct me if I misrepresented anything):

Let's plan on first implementing 'Numbered Application name' (Window 1 - Tor Browser, Window 2 - Mullvad Browser). We can revisit the pet names after we receive user feedback given the additional complexity + localisation requirements. It should be in the format Window N - Tor Browser even if there is only 1 Window open to avoid spamming screen reader users.

Let's not include the tab count given the hell that would be for screen reader users. We can revisit making this a (default off) toggle-able option after we receive user feedback.

In about:preferences, let's rename the 'Letterboxing' section to 'Windows' and add an option there for this feature.

So the next question is wtf do we name this option? How about:

Show website name in browser title bar // disabled by default

During the 14.0 cycle we can add an entry to the manual and a learn more link.

Anything will need some localization, except for just "Tor Browser". Temporary solutions aren't great from a l10n point of view (we want to avoid wasting translators' time).

Also, the pref for showing only the window name is already implemented and uplifted, we just need to add the checkbox.

Show website name in browser title bar

Name sounds kinda wrong to me. I know repetition is bad, but page title is the correct one in this case. E.g., we're on GitLab/Tor's GitLab/Tor Project's GitLab/Tor Project, if we're talking about the website name. Maybe page name is somehow better?

I think probably a @donuts question

I agree text isn't 'technically' correct but the about:preferences prefs are typically not the literal/correct thing. 'Don't expose contents of <title> tag to desktop manager' is correcter/ish but probably not helpful.

Though page name is more general/accurate so probably better

It should be in the format Window N - Tor Browser even if there is only 1 Window open to avoid spamming screen reader users.

Good summary. Two things to add:

I would switch the order to lead with "Tor Browser", which is the most useful information. Also it would make it less confusing in a list of application windows. E.g. Tor Browser - window N, or Tor Browser (window N).
I personally don't mind the consistent "window N" addition. But if it is desired, I think it could be possible to drop it when we only have one window without it creating screen reader noise. I'm pretty sure NVDA only announces the application window title change when it has focus, so if we change from "Tor Browser" to "Tor Browser (window 1)" when it doesn't have focus it should be ok. All the window creation methods I know of would shift focus anyway. It would need testing though to be sure. Regardless, we can start with the simple consistent approach and add these details later.

Pet name: Fuzzy Squirrel - Tor Browser, Curvy Giraffe - Tor Browser

My instinct is that we shouldn't do this. It could get very confusing for users. Application windows don't normally have a "persona", so it just adds random noise that's hard to intuit.

let's rename the 'Letterboxing' section to 'Windows' and add an option there for this feature.

I'm not sure that "Letterboxing" fits well below "Windows". The initial window size does, but I'm not sure that "Content alignment" does.

Moreover, given recent discussions, I feel like we likely want "Letterboxing" to become "Fingerprinting" to expose other fingerprinting related preferences. So maybe we should keep these separate if that is the direction we are going in.

Could we just stick it in "Browser Privacy", under "Application window name"?

Show website name in browser title bar

I'm not sure what "title bar" is meant to be. Also, regarding "website name" vs "website title", I think that "title" is not well known. We could use "tab name" since that is probably where the user actually sees the website title being used. So maybe: "Show the current tab's name in the Tor Browser window name."

We should add an explanation as well, like "Sometimes application window names are logged by operating systems. If this includes the tab name, it could leave a trace of the web pages you have visited."

I would switch the order to lead with "Tor Browser", which is the most useful information.

I suspect this is platform specific; my desktop manager displays the app-name after the title. So we should put it wherever makes the most sense on each platform (hopefully Firefox has code for this already)

My instinct is that we shouldn't do this.

Fully agree on all points

Could we just stick it in "Browser Privacy", under "Application window name"?

Hmm, between History and Address Bar may be a good place.

And finally regarding strings for about:preferences, I like those suggestions, so the proposed new UI would be something like(?):

History

...

Application Window Name

Sometimes application window names are logged by operating systems. If this includes the tab name, it could leave a trace of the web pages you have visited.

Show the current tab's name in the Tor Browser window name

Address Bar

...

@donuts do you have opinions here?

I suspect this is platform specific; my desktop manager displays the app-name after the title. So we should put it wherever makes the most sense on each platform (hopefully Firefox has code for this already)

Yeah, it is the same for me: "Tab name - Mozilla Firefox". But I don't think the desktop has any control over this, the whole string is set by the application. I interpreted it as less "application name last" and more "the most useful/distinguishing information first". Which helps when the full title is clipped (e.g. in a task bar or Alt+Tab list), and has the added benefit that screen reader users don't have to wait as long for read back to identify their Tor Browser window.

Ah looking now at another workspace I see it's a mishmatch of identifiers, I was just lucky with the set of Windows I was looking at the time when I made the previous comment.

Here's a small sample of screenshots from different platforms, for reference: Figma link

MacOS appears to be the outlier in that it doesn't display the app name in the window title at all.

@henry: Could we just stick it in "Browser Privacy", under "Application window name"?

@morgan: Hmm, between History and Address Bar may be a good place.

I think we should still group disk leak protections together. For instance, I know we may be adding #42717 in the near future too. That could either be a separate section below Browser Privacy, or a list of checkboxes under an H2 within Browser Privacy – but we'll still need to come up with a name, e.g.:

System Privacy
OS Privacy
Privacy (i.e. "Windows Privacy")

That figma link isn't public

I'm not sure I agree that things should be linked together based on protections (i.e. disk leaks, fingerprinting, etc).

For instance, I don't think users would think to look in a 'disk leaks' protection section for something that isn't obviously going to cause disk leaks. Would it be possible to organise things based on how a user would search and discover them and indicate somehow in-place the consequences of the options?

Like to a user it may makes sense that window manager/ui display stuff would be grouped together, but the fingerprinting/linkability aspects of letterboxing vs disk leak aspects of window titles would probably come as a surprise?

That figma link isn't public

Fixed!

If it can help, I think we could include the preferences for the various clipboard settings in the same category.

@donuts can we move forward with exposing this pref in Privacy & Security and handle the general question of 'how do we group/arrange everything' in the other major preference re-work issue?

Happy to do that, given everything’s going to get shaken up anyway if/when the proposed Settings redesign becomes a thing.

Incidentally, I think we should time our preferences rework for when the upstream redesign hits ESR (potentially next year, at this rate?).

added 14.5 stable label

Looping in @felicia.

Tor Browser history leaked to syslogs via GNOME

Summary

Steps to reproduce:

What is the current bug behavior?

What is the expected behavior?

Environment

Relevant logs and/or screenshots

Designs

Child items ...

Activity

Implementation

Constraints

Requirements

Proposed Solutions

Configuration

Requirements

Proposed Solutions

Next Steps

History

Application Window Name

Address Bar