11 ms·

Target="_blank" – An underestimated vulnerability (2016)

_pdp_ 9y ago
This reminds of my 9year old vulnerability reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=469939 https://bugzilla.mozilla.org/show_bug.cgi?id=469939. Essentially one can trick a user into typing their credentials into a phishing site although it may appear they are using the legitimate site at first glance. The reason this is unfixed is that this is how the web works still.
deleted 9y ago
[deleted]
jenoer 9y ago
Various articles, blog posts etc. about this have already been posted to HN. One of these inspired me to make a Firefox add-on that solves this issue: https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my-tabs/ https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my... [/plug]
- grahamel 9y ago
  Still always good to keep in people's minds. Personally I use linting rules for this, e.g. for React projects https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...
deleted 9y ago
[deleted]
rdslw 9y ago
Google considers (1) it unfixable: "Unfortunately, we believe that this class of attacks is inherent to the current design of web browsers and can't be meaningfully mitigated by any single website; in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones." (1) https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-window-opener https://sites.google.com/site/bughunteruniversity/nonvuln/ph...
- fniephaus 9y ago
  Lighthouse Audit - Opens External Anchors Using rel="noopener": https://developers.google.com/web/tools/lighthouse/audits/noopener https://developers.google.com/web/tools/lighthouse/audits/no...
  - madeofpalk 9y ago
    The 'popular' eslint-plugin-react can also make this a lint error https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...
- Matheus28 9y ago
  Couldn't `window.opener` be opt-in instead of opt-out? It would break some websites, but I have no idea how many...
- jorangreef 9y ago
  What are the remaining vectors which would need to be mitigated? The Google article does not mention any details?
  - parenthephobia 9y ago
    One is that if you open a window, you can change the URL that's loaded later. In the example that Google's page links to they change it to a data: URI - which no longer works in Chrome - but they could just as easily change it from http://good.com/ http://good.com/ to http://evil.com/ http://evil.com/ - which would still work in Chrome - and hope you don't notice.
    - Ajedi32 9y ago
      But how can they do that without access to `window.opener`?
      - parenthephobia 9y ago
jopsen 9y ago
Couldn't this just follow same domain rules like CORS? But yeah it could break a lot of things... changing location is bad, but can it really execute JavaScript in the opener context? That would be very serious.
- parenthephobia 9y ago
  JavaScript is subject to CORS, but "opener" isn't generally, except in Edge. Even then, there is a risk of being surprised. If you open a page on the same site, you may expect that scripts on the opened page can't access the opening page: but because of CORS they can. Here's a fiddle with a link to another fiddle that copies the contents of a password field from the first fiddle: https://jsfiddle.net/u6rmc49c/3/ https://jsfiddle.net/u6rmc49c/3/
- bugmen0t 9y ago
  CORS is only for http requests. The same origin policy for DOM access allows setting the location.href attribute (getting any attribute is still disallowed). Setting location.href also works with frames in both ways, e.g. frame.location.href as well as parent.locaton.href and top.location.href
phkahler 9y ago
Once again we have to ask "why is this even possible?" Web designers have been given too much control over the browser is the usual answer and seem to be the case here. There should be no interaction allowed between tabs.
- styfle 9y ago
  The problem is the implementation, not the feature. The postMessage API provides a safer way for Windows/Tabs to communicate. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Window/post...
  - phkahler 9y ago
    Given that most implementation are flawed, and given the limited utility of this "feature", and given the inherent desire to sandbox thing on a browser, I would say the problem is the mindset of the developers who keep adding stuff that ends up exploited.
singularity2001 9y ago
TL;DR : read the original post, its to the point. why not make rel="noopener noreferrer" default? if sites want to get credit they can explicitly add rel="opener referrer"
- orf 9y ago
  Backwards compat
- zspitzer 9y ago
  I reckon it should be an optional attribute for the BASE tag, rather than having to add it to every single A tag
- nitely 9y ago
  They had their chance with HTML5. Actually, it was removed at some point.
konceptz 9y ago
I’ve seen one case, not saying the generic model is not an issue, where this was particularly bad. In a thick client built on web, there was absolutely no indication of redirection because the app’s window showed only content. Plus it was stored and delivered to other users. Persistent open redirect in a thick client.
z3t4 9y ago
> PS. Interestingly, Google doesn't seem to care. Doesn't Google's browser hide the address bar !? Hiding the address does make exploits like this way harder to notice. I know Google want's everyone to search instead of typing an URL. But URL's are really powerful, please Google, don't make them irrelevant!
- Ajedi32 9y ago
  > Doesn't Google's browser hide the address bar Huh? What are you talking about? All mobile browsers I'm aware of hide the address bar when you scroll down, not just Chrome.
  - bhandziuk 9y ago
    Though when you navigate to a new page the address bar does show as the page loads.
- deleted 9y ago
  [deleted]
Nagyman 9y ago
I think/hope Chromium's recent announcement about "Expanding user protections on the web", addresses the redirect issue: > When the user interacts with content, things can also go wrong. One example that causes user frustration is when clicking a link opens the desired destination in a new tab, while the main window navigates to a different, unwanted page. Starting in Chrome 65 we'll also detect this behavior, trigger an infobar, and prevent the main tab from being redirected. This allows the user to continue directly to their intended destination, while also preserving the context of the page they came from. https://blog.chromium.org/2017/11/expanding-user-protections-on-web.html https://blog.chromium.org/2017/11/expanding-user-protections...
- hdhzy 9y ago
  Excellent! Stealth redirects and vibrating ads are what drove me to Firefox for Android with uBlock. Note that developers could protect their sites for some time with noopener: https://mathiasbynens.github.io/rel-noopener/ https://mathiasbynens.github.io/rel-noopener/
  - ravenstine 9y ago
    Vibrating ads as in they move around or they cause your phone to vibrate? Never seen that, but either way that makes me all the more glad to have ad blocking installed at the root level. The level of annoyance the ad industry goes to is astounding.
    - hdhzy 9y ago
      They cause my phone to vibrate "thanks to" the Vibration API [0]. A critical component of the Web Platform ecosystem apparently. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Vibration_API https://developer.mozilla.org/en-US/docs/Web/API/Vibration_A...
      - r00fus 9y ago
        In time this annoyance API will be seen as equivalent to the blink [1] tag. [1] https://en.wikipedia.org/wiki/Blink_element https://en.wikipedia.org/wiki/Blink_element
Grom_PE 9y ago
In Opera 12, I killed "window.opener" by replacing the "opener" string with "opera" in the opera.dll. This way it gets overwritten by the normal window.opera variable and is essentially hidden. So far I haven't encountered a site legitimately relying on this variable.
- username223 9y ago
  Admirably thuggish! I remember doing something similar, replacing "__gnu_warning" with "__gnu_whining" in libc.so to eliminate whining about using "gets()" in throwaway programs.
- fivesigma 9y ago
  A legitimate usage case would be opening a login popup on another domain that can't be iframe'd. For example OAuth social network login popups. They require window.opener to send back login credentials to the original website.
- mygo 9y ago
  Window.opener isn’t your problem. Window.opener is sandboxed by CORS. And you need it for things such as oAuth. Target=“_blank” is your problem. That’s where Window.opener gets exposed. You’re better off finding the “_blank” definition and renaming it so that it’s never triggered, or assigning it to the definition of “self”, etc.
  - Grom_PE 9y ago
    Killing off "_blank" would disable force-opening links in a new window, which is useful in dynamic context, e.g. chat page, so I don't want that. Also, window.opener is still abusable if I middle-click links to open in a new tab. I was very surprised when my Google Search tab got replaced by something else after I middle-clicked on some questionable link.
Tehnix 9y ago
Quick fix is _Search and Replace_ in your whole project, via your favourite editor, from, > target="_blank" to > target="_blank" rel="noopener noreferrer" Which should not break anything unless you have some weird HTML lying around.
- JamieF1 9y ago
  Yep you're right. I wrote a post about it before on Medium and made an extension that automatically puts noreferrer in there for you. Here's the link: https://medium.com/@Jamie_Farrelly/browsers-are-broken-but-nobody-cares-all-it-took-was-1-line-of-code-to-fix-it-f8af13c18cff https://medium.com/@Jamie_Farrelly/browsers-are-broken-but-n...
- kccqzy 9y ago
  Does that also work on the <base> element? Browsing through MDN it seems like it doesn’t.
SippinLean 9y ago
Setting target=_blank is almost always a bad idea anyway. Typically marketers ask for it to prevent users from leaving your domain when clicking a link to an external domain; the thinking being they will remain on our site longer if we force a new window on them. Testing has shown that this doesn't work in practice, and instead achieves the opposite: the user in confused as to why they are in a new window, and it's harder for them to return to your domain. The user is confused by the ostensible "pop-up" (that they associate with ads) that has opened, and the Back button no longer returns them to our domain, breaking with their expected behavior. Users know how to open links in new tabs/windows if they want to. In testing at the places I've worked target=_blank only hurts conversions. Personally I run a plugin that strips it from all links.
- dazc 9y ago
  'Testing has shown that this doesn't work in practice....' Is there any research you can point me to about this? '...and the Back button no longer returns them to our domain, breaking with their expected behavior.' Yeah, except when the target site has disabled it and then you have even more confusion. (Accepted it is rare, but it does happen).
  - SippinLean 9y ago
    I was referencing internal A/B testing results for several high-volume e-commerce sites I've worked on. An oft-parroted best practice in UX is "effective user interface places users in control of the application." This study seems to agree: https://www.nngroup.com/articles/top-10-enduring/ https://www.nngroup.com/articles/top-10-enduring/ >Many of our study participants moved to a new site or subsite without realizing it and then struggled to get back to the main site because the subsite offered no option for return Using target=_blank ensures the Back button is broken. A third-party site disabling the Back button is out of your control.
    - dazc 9y ago
      Thanks for the further information.
username223 9y ago
It's crazy that, after 20 years, web standards people still haven't realized that the server is the user's enemy. Back in the 90s, this was demonstrated by popups, which eventually got mostly fixed in most browsers. Now we have this new pop-under mechanism, currently marked as WONTFIX, which will get slowly mitigated over the next few years. Window.opener and target=_blank are obvious avenues of abuse that would never have been added if web people had learned anything over the past couple of decades.
- marcosdumay 9y ago
  > the server is the user's enemy Not that much. Both have some conflicting interests, and plenty of aligned interests.
- XaspR8d 9y ago
  Didn't target="_blank" originate in that era you were talking about? I know the target attribute was part of HTML4 (1999). I'm not sure when _blank became a special value, but I imagine it was before the spec acknowledged it. I agree window.opener was a fairly dangerous addition, but it is subject to CORS restrictions. You can't access it from just anywhere.
  - username223 9y ago
    I think you're right about target=_blank. Still, it has very little potential to benefit the user, who can option-click or similar if he/she wants a new tab or window, but has to copy-and-paste to prevent one. It should never have been added. I would rather that web browsers simply not implement things with significant potential to do harm; at the least, those things should be disabled by default. Unfortunately we aren't headed that way: WebUSB is coming[1]. Anyone who could write that "[t]he composablity of the web allows a new ecosystem of hardware support to be built entirely from web technology" without feeling a chill run down their spine and imagining a years-long security nightmare is truly blind. [1] https://wicg.github.io/webusb/ https://wicg.github.io/webusb/
    - eponeponepon 9y ago
carstimon 9y ago
I'm pretty ignorant of browser stuff, but couldn't the attack be even worse than mentioned in the article? If the newly opened website has full control over the Facebook tab, can't the attacker directly modify the html in the opener to pop up a form asking for a password? This would be stronger because the address would not change. Could the attacker reach into the Facebook tab and pull any information from it?
- paulddraper 9y ago
  No. You do not have access to the contents of the window because facebook.com is on a different origin. As this article says, you can change the location of the window.
nixpulvis 9y ago
I can assure you that at least "some" people at Google care.

This reminds of my 9year old vulnerability reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=469939 https://bugzilla.mozilla.org/show_bug.cgi?id=469939. Essentially one can trick a user into typing their credentials into a phishing site although it may appear they are using the legitimate site at first glance. The reason this is unfixed is that this is how the web works still.

deleted 9y ago

[deleted]

jenoer 9y ago

Various articles, blog posts etc. about this have already been posted to HN. One of these inspired me to make a Firefox add-on that solves this issue: https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my-tabs/ https://addons.mozilla.org/en-US/firefox/addon/dont-touch-my... [/plug]

grahamel 9y ago
Still always good to keep in people's minds. Personally I use linting rules for this, e.g. for React projects https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...

deleted 9y ago

[deleted]

rdslw 9y ago

Google considers (1) it unfixable: "Unfortunately, we believe that this class of attacks is inherent to the current design of web browsers and can't be meaningfully mitigated by any single website; in particular, clobbering the window.opener property limits one of the vectors, but still makes it easy to exploit the remaining ones." (1) https://sites.google.com/site/bughunteruniversity/nonvuln/phishing-with-window-opener https://sites.google.com/site/bughunteruniversity/nonvuln/ph...

fniephaus 9y ago
Lighthouse Audit - Opens External Anchors Using rel="noopener": https://developers.google.com/web/tools/lighthouse/audits/noopener https://developers.google.com/web/tools/lighthouse/audits/no...
- madeofpalk 9y ago
  The 'popular' eslint-plugin-react can also make this a lint error https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md https://github.com/yannickcr/eslint-plugin-react/blob/master...
Matheus28 9y ago
Couldn't `window.opener` be opt-in instead of opt-out? It would break some websites, but I have no idea how many...
jorangreef 9y ago
What are the remaining vectors which would need to be mitigated? The Google article does not mention any details?
- parenthephobia 9y ago
  One is that if you open a window, you can change the URL that's loaded later. In the example that Google's page links to they change it to a data: URI - which no longer works in Chrome - but they could just as easily change it from http://good.com/ http://good.com/ to http://evil.com/ http://evil.com/ - which would still work in Chrome - and hope you don't notice.
  - Ajedi32 9y ago
    But how can they do that without access to `window.opener`?
    - parenthephobia 9y ago

jopsen 9y ago

Couldn't this just follow same domain rules like CORS? But yeah it could break a lot of things... changing location is bad, but can it really execute JavaScript in the opener context? That would be very serious.

parenthephobia 9y ago
JavaScript is subject to CORS, but "opener" isn't generally, except in Edge. Even then, there is a risk of being surprised. If you open a page on the same site, you may expect that scripts on the opened page can't access the opening page: but because of CORS they can. Here's a fiddle with a link to another fiddle that copies the contents of a password field from the first fiddle: https://jsfiddle.net/u6rmc49c/3/ https://jsfiddle.net/u6rmc49c/3/
bugmen0t 9y ago
CORS is only for http requests. The same origin policy for DOM access allows setting the location.href attribute (getting any attribute is still disallowed). Setting location.href also works with frames in both ways, e.g. frame.location.href as well as parent.locaton.href and top.location.href

phkahler 9y ago

Once again we have to ask "why is this even possible?" Web designers have been given too much control over the browser is the usual answer and seem to be the case here. There should be no interaction allowed between tabs.

styfle 9y ago
The problem is the implementation, not the feature. The postMessage API provides a safer way for Windows/Tabs to communicate. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage https://developer.mozilla.org/en-US/docs/Web/API/Window/post...
- phkahler 9y ago
  Given that most implementation are flawed, and given the limited utility of this "feature", and given the inherent desire to sandbox thing on a browser, I would say the problem is the mindset of the developers who keep adding stuff that ends up exploited.

singularity2001 9y ago

TL;DR : read the original post, its to the point. why not make rel="noopener noreferrer" default? if sites want to get credit they can explicitly add rel="opener referrer"

orf 9y ago
Backwards compat
zspitzer 9y ago
I reckon it should be an optional attribute for the BASE tag, rather than having to add it to every single A tag
nitely 9y ago
They had their chance with HTML5. Actually, it was removed at some point.

konceptz 9y ago

I’ve seen one case, not saying the generic model is not an issue, where this was particularly bad. In a thick client built on web, there was absolutely no indication of redirection because the app’s window showed only content. Plus it was stored and delivered to other users. Persistent open redirect in a thick client.

z3t4 9y ago

> PS. Interestingly, Google doesn't seem to care. Doesn't Google's browser hide the address bar !? Hiding the address does make exploits like this way harder to notice. I know Google want's everyone to search instead of typing an URL. But URL's are really powerful, please Google, don't make them irrelevant!

Ajedi32 9y ago
> Doesn't Google's browser hide the address bar Huh? What are you talking about? All mobile browsers I'm aware of hide the address bar when you scroll down, not just Chrome.
- bhandziuk 9y ago
  Though when you navigate to a new page the address bar does show as the page loads.
deleted 9y ago
[deleted]

Nagyman 9y ago

I think/hope Chromium's recent announcement about "Expanding user protections on the web", addresses the redirect issue: > When the user interacts with content, things can also go wrong. One example that causes user frustration is when clicking a link opens the desired destination in a new tab, while the main window navigates to a different, unwanted page. Starting in Chrome 65 we'll also detect this behavior, trigger an infobar, and prevent the main tab from being redirected. This allows the user to continue directly to their intended destination, while also preserving the context of the page they came from. https://blog.chromium.org/2017/11/expanding-user-protections-on-web.html https://blog.chromium.org/2017/11/expanding-user-protections...

hdhzy 9y ago
Excellent! Stealth redirects and vibrating ads are what drove me to Firefox for Android with uBlock. Note that developers could protect their sites for some time with noopener: https://mathiasbynens.github.io/rel-noopener/ https://mathiasbynens.github.io/rel-noopener/
- ravenstine 9y ago
  Vibrating ads as in they move around or they cause your phone to vibrate? Never seen that, but either way that makes me all the more glad to have ad blocking installed at the root level. The level of annoyance the ad industry goes to is astounding.
  - hdhzy 9y ago
    They cause my phone to vibrate "thanks to" the Vibration API [0]. A critical component of the Web Platform ecosystem apparently. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Vibration_API https://developer.mozilla.org/en-US/docs/Web/API/Vibration_A...
    - r00fus 9y ago
      In time this annoyance API will be seen as equivalent to the blink [1] tag. [1] https://en.wikipedia.org/wiki/Blink_element https://en.wikipedia.org/wiki/Blink_element

Grom_PE 9y ago

In Opera 12, I killed "window.opener" by replacing the "opener" string with "opera" in the opera.dll. This way it gets overwritten by the normal window.opera variable and is essentially hidden. So far I haven't encountered a site legitimately relying on this variable.

username223 9y ago
Admirably thuggish! I remember doing something similar, replacing "__gnu_warning" with "__gnu_whining" in libc.so to eliminate whining about using "gets()" in throwaway programs.
fivesigma 9y ago
A legitimate usage case would be opening a login popup on another domain that can't be iframe'd. For example OAuth social network login popups. They require window.opener to send back login credentials to the original website.
mygo 9y ago
Window.opener isn’t your problem. Window.opener is sandboxed by CORS. And you need it for things such as oAuth. Target=“_blank” is your problem. That’s where Window.opener gets exposed. You’re better off finding the “_blank” definition and renaming it so that it’s never triggered, or assigning it to the definition of “self”, etc.
- Grom_PE 9y ago
  Killing off "_blank" would disable force-opening links in a new window, which is useful in dynamic context, e.g. chat page, so I don't want that. Also, window.opener is still abusable if I middle-click links to open in a new tab. I was very surprised when my Google Search tab got replaced by something else after I middle-clicked on some questionable link.

Tehnix 9y ago

Quick fix is _Search and Replace_ in your whole project, via your favourite editor, from, > target="_blank" to > target="_blank" rel="noopener noreferrer" Which should not break anything unless you have some weird HTML lying around.

JamieF1 9y ago
Yep you're right. I wrote a post about it before on Medium and made an extension that automatically puts noreferrer in there for you. Here's the link: https://medium.com/@Jamie_Farrelly/browsers-are-broken-but-nobody-cares-all-it-took-was-1-line-of-code-to-fix-it-f8af13c18cff https://medium.com/@Jamie_Farrelly/browsers-are-broken-but-n...
kccqzy 9y ago
Does that also work on the <base> element? Browsing through MDN it seems like it doesn’t.

SippinLean 9y ago

Setting target=_blank is almost always a bad idea anyway. Typically marketers ask for it to prevent users from leaving your domain when clicking a link to an external domain; the thinking being they will remain on our site longer if we force a new window on them. Testing has shown that this doesn't work in practice, and instead achieves the opposite: the user in confused as to why they are in a new window, and it's harder for them to return to your domain. The user is confused by the ostensible "pop-up" (that they associate with ads) that has opened, and the Back button no longer returns them to our domain, breaking with their expected behavior. Users know how to open links in new tabs/windows if they want to. In testing at the places I've worked target=_blank only hurts conversions. Personally I run a plugin that strips it from all links.

dazc 9y ago
'Testing has shown that this doesn't work in practice....' Is there any research you can point me to about this? '...and the Back button no longer returns them to our domain, breaking with their expected behavior.' Yeah, except when the target site has disabled it and then you have even more confusion. (Accepted it is rare, but it does happen).
- SippinLean 9y ago
  I was referencing internal A/B testing results for several high-volume e-commerce sites I've worked on. An oft-parroted best practice in UX is "effective user interface places users in control of the application." This study seems to agree: https://www.nngroup.com/articles/top-10-enduring/ https://www.nngroup.com/articles/top-10-enduring/ >Many of our study participants moved to a new site or subsite without realizing it and then struggled to get back to the main site because the subsite offered no option for return Using target=_blank ensures the Back button is broken. A third-party site disabling the Back button is out of your control.
  - dazc 9y ago
    Thanks for the further information.

username223 9y ago

It's crazy that, after 20 years, web standards people still haven't realized that the server is the user's enemy. Back in the 90s, this was demonstrated by popups, which eventually got mostly fixed in most browsers. Now we have this new pop-under mechanism, currently marked as WONTFIX, which will get slowly mitigated over the next few years. Window.opener and target=_blank are obvious avenues of abuse that would never have been added if web people had learned anything over the past couple of decades.

marcosdumay 9y ago
> the server is the user's enemy Not that much. Both have some conflicting interests, and plenty of aligned interests.
XaspR8d 9y ago
Didn't target="_blank" originate in that era you were talking about? I know the target attribute was part of HTML4 (1999). I'm not sure when _blank became a special value, but I imagine it was before the spec acknowledged it. I agree window.opener was a fairly dangerous addition, but it is subject to CORS restrictions. You can't access it from just anywhere.
- username223 9y ago
  I think you're right about target=_blank. Still, it has very little potential to benefit the user, who can option-click or similar if he/she wants a new tab or window, but has to copy-and-paste to prevent one. It should never have been added. I would rather that web browsers simply not implement things with significant potential to do harm; at the least, those things should be disabled by default. Unfortunately we aren't headed that way: WebUSB is coming[1]. Anyone who could write that "[t]he composablity of the web allows a new ecosystem of hardware support to be built entirely from web technology" without feeling a chill run down their spine and imagining a years-long security nightmare is truly blind. [1] https://wicg.github.io/webusb/ https://wicg.github.io/webusb/
  - eponeponepon 9y ago

carstimon 9y ago

I'm pretty ignorant of browser stuff, but couldn't the attack be even worse than mentioned in the article? If the newly opened website has full control over the Facebook tab, can't the attacker directly modify the html in the opener to pop up a form asking for a password? This would be stronger because the address would not change. Could the attacker reach into the Facebook tab and pull any information from it?

paulddraper 9y ago
No. You do not have access to the contents of the window because facebook.com is on a different origin. As this article says, you can change the location of the window.

nixpulvis 9y ago

I can assure you that at least "some" people at Google care.