Origin Policy violation on google.by pages
up vote
2
down vote
favorite
Starting from today I'm constantly getting this error when trying to search something at google.by:
Well, well, well. What do we have here? An Origin Policy violation.
And what do we not have? A page!
You're trying to go to:
https://www.google.by/search?q=thymeleaf+is+0+or+zero&sourceid=chrome&ie=UTF-8
The policy applies to: https://www.google.by
I tried other domains (google.com, google.ru, google.de) and they are working fine. The issue is reproducible in incognito mode (with plugins disabled). In Chrome only (Firefox and Edge have no such problem) and it started recently, so it may be related to the recent Chrome update. Now I use Chrome Version 71 (Beta).
- What does it mean?
- I didn't change something in my connection settings. Who is in charge? Google? ISP?
UPD. I'm not the only one with this problem, there're other user reports of this issue on Google Chrome Help Forum.
google-search security-policy
asked Nov 16 at 12:36
naXa
1176
add a comment |
up vote
2
down vote
favorite
Starting from today I'm constantly getting this error when trying to search something at google.by:
Well, well, well. What do we have here? An Origin Policy violation.
And what do we not have? A page!
You're trying to go to:
https://www.google.by/search?q=thymeleaf+is+0+or+zero&sourceid=chrome&ie=UTF-8
The policy applies to: https://www.google.by
I tried other domains (google.com, google.ru, google.de) and they are working fine. The issue is reproducible in incognito mode (with plugins disabled). In Chrome only (Firefox and Edge have no such problem) and it started recently, so it may be related to the recent Chrome update. Now I use Chrome Version 71 (Beta).
- What does it mean?
- I didn't change something in my connection settings. Who is in charge? Google? ISP?
UPD. I'm not the only one with this problem, there're other user reports of this issue on Google Chrome Help Forum.
google-search security-policy
asked Nov 16 at 12:36
naXa
1176
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Starting from today I'm constantly getting this error when trying to search something at google.by:
Well, well, well. What do we have here? An Origin Policy violation.
And what do we not have? A page!
You're trying to go to:
https://www.google.by/search?q=thymeleaf+is+0+or+zero&sourceid=chrome&ie=UTF-8
The policy applies to: https://www.google.by
I tried other domains (google.com, google.ru, google.de) and they are working fine. The issue is reproducible in incognito mode (with plugins disabled). In Chrome only (Firefox and Edge have no such problem) and it started recently, so it may be related to the recent Chrome update. Now I use Chrome Version 71 (Beta).
- What does it mean?
- I didn't change something in my connection settings. Who is in charge? Google? ISP?
UPD. I'm not the only one with this problem, there're other user reports of this issue on Google Chrome Help Forum.
google-search security-policy
asked Nov 16 at 12:36
naXa
1176
Starting from today I'm constantly getting this error when trying to search something at google.by:
Well, well, well. What do we have here? An Origin Policy violation.
And what do we not have? A page!
You're trying to go to:
https://www.google.by/search?q=thymeleaf+is+0+or+zero&sourceid=chrome&ie=UTF-8
The policy applies to: https://www.google.by
I tried other domains (google.com, google.ru, google.de) and they are working fine. The issue is reproducible in incognito mode (with plugins disabled). In Chrome only (Firefox and Edge have no such problem) and it started recently, so it may be related to the recent Chrome update. Now I use Chrome Version 71 (Beta).
- What does it mean?
- I didn't change something in my connection settings. Who is in charge? Google? ISP?
UPD. I'm not the only one with this problem, there're other user reports of this issue on Google Chrome Help Forum.
google-search security-policy
google-search security-policy
asked Nov 16 at 12:36
naXa
1176
asked Nov 16 at 12:36
naXa
1176
edited Nov 19 at 14:00
asked Nov 16 at 12:36
naXa
1176
asked Nov 16 at 12:36
naXa
1176
asked Nov 16 at 12:36
naXa
1176
1176
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02
add a comment |
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
The reason for such a problem that the answer returned by google.by
tried to access data which was stored by a previous website request.
Wikipedia Same-origin policy
explains well the problem:
The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.
I have no real idea why issuing a query on google.by would cause a
reference that would trigger a same-origin policy block, but it is clear
that this has prevented an inappropriate access to your data.
Google is one of the most-used avenues for malware, so it's possible that its
ads system brought you a shady reference.
If this happens again, do the same thing: Restart Chrome.
The chances are that the same ad won't be served again.
answered Nov 16 at 18:27
harrymc
248k10257548
add a comment |
up vote
0
down vote
If you are on the Dev channel of Chrome and have the flag Experimental Web Platform features enabled [1], then it could be the cause according to this.
If the flag is enabled, try disabling it and restart Chrome.
[1] Check the flag here: chrome://flags/#enable-experimental-web-platform-features
answered Nov 19 at 11:03
Hejazi
1011
The problem does not bother me after Chrome restart. The flag#enable-experimental-web-platform-featuresis still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.
– naXa
Nov 19 at 13:31
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
The reason for such a problem that the answer returned by google.by
tried to access data which was stored by a previous website request.
Wikipedia Same-origin policy
explains well the problem:
The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.
I have no real idea why issuing a query on google.by would cause a
reference that would trigger a same-origin policy block, but it is clear
that this has prevented an inappropriate access to your data.
Google is one of the most-used avenues for malware, so it's possible that its
ads system brought you a shady reference.
If this happens again, do the same thing: Restart Chrome.
The chances are that the same ad won't be served again.
answered Nov 16 at 18:27
harrymc
248k10257548
add a comment |
up vote
0
down vote
accepted
The reason for such a problem that the answer returned by google.by
tried to access data which was stored by a previous website request.
Wikipedia Same-origin policy
explains well the problem:
The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.
I have no real idea why issuing a query on google.by would cause a
reference that would trigger a same-origin policy block, but it is clear
that this has prevented an inappropriate access to your data.
Google is one of the most-used avenues for malware, so it's possible that its
ads system brought you a shady reference.
If this happens again, do the same thing: Restart Chrome.
The chances are that the same ad won't be served again.
answered Nov 16 at 18:27
harrymc
248k10257548
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
The reason for such a problem that the answer returned by google.by
tried to access data which was stored by a previous website request.
Wikipedia Same-origin policy
explains well the problem:
The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.
I have no real idea why issuing a query on google.by would cause a
reference that would trigger a same-origin policy block, but it is clear
that this has prevented an inappropriate access to your data.
Google is one of the most-used avenues for malware, so it's possible that its
ads system brought you a shady reference.
If this happens again, do the same thing: Restart Chrome.
The chances are that the same ad won't be served again.
answered Nov 16 at 18:27
harrymc
248k10257548
The reason for such a problem that the answer returned by google.by
tried to access data which was stored by a previous website request.
Wikipedia Same-origin policy
explains well the problem:
The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.
I have no real idea why issuing a query on google.by would cause a
reference that would trigger a same-origin policy block, but it is clear
that this has prevented an inappropriate access to your data.
Google is one of the most-used avenues for malware, so it's possible that its
ads system brought you a shady reference.
If this happens again, do the same thing: Restart Chrome.
The chances are that the same ad won't be served again.
answered Nov 16 at 18:27
harrymc
248k10257548
answered Nov 16 at 18:27
harrymc
248k10257548
answered Nov 16 at 18:27
harrymc
248k10257548
answered Nov 16 at 18:27
harrymc
248k10257548
248k10257548
add a comment |
add a comment |
up vote
0
down vote
If you are on the Dev channel of Chrome and have the flag Experimental Web Platform features enabled [1], then it could be the cause according to this.
If the flag is enabled, try disabling it and restart Chrome.
[1] Check the flag here: chrome://flags/#enable-experimental-web-platform-features
answered Nov 19 at 11:03
Hejazi
1011
The problem does not bother me after Chrome restart. The flag#enable-experimental-web-platform-featuresis still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.
– naXa
Nov 19 at 13:31
add a comment |
up vote
0
down vote
If you are on the Dev channel of Chrome and have the flag Experimental Web Platform features enabled [1], then it could be the cause according to this.
If the flag is enabled, try disabling it and restart Chrome.
[1] Check the flag here: chrome://flags/#enable-experimental-web-platform-features
answered Nov 19 at 11:03
Hejazi
1011
The problem does not bother me after Chrome restart. The flag#enable-experimental-web-platform-featuresis still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.
– naXa
Nov 19 at 13:31
add a comment |
up vote
0
down vote
up vote
0
down vote
If you are on the Dev channel of Chrome and have the flag Experimental Web Platform features enabled [1], then it could be the cause according to this.
If the flag is enabled, try disabling it and restart Chrome.
[1] Check the flag here: chrome://flags/#enable-experimental-web-platform-features
answered Nov 19 at 11:03
Hejazi
1011
If you are on the Dev channel of Chrome and have the flag Experimental Web Platform features enabled [1], then it could be the cause according to this.
If the flag is enabled, try disabling it and restart Chrome.
[1] Check the flag here: chrome://flags/#enable-experimental-web-platform-features
answered Nov 19 at 11:03
Hejazi
1011
answered Nov 19 at 11:03
Hejazi
1011
answered Nov 19 at 11:03
Hejazi
1011
answered Nov 19 at 11:03
Hejazi
1011
1011
The problem does not bother me after Chrome restart. The flag#enable-experimental-web-platform-featuresis still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.
– naXa
Nov 19 at 13:31
add a comment |
The problem does not bother me after Chrome restart. The flag#enable-experimental-web-platform-featuresis still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.
– naXa
Nov 19 at 13:31
The problem does not bother me after Chrome restart. The flag
#enable-experimental-web-platform-features is still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.– naXa
Nov 19 at 13:31
The problem does not bother me after Chrome restart. The flag
#enable-experimental-web-platform-features is still on. I've read through the linked topic and it does not contain any explanation on why this flag was the cause.– naXa
Nov 19 at 13:31
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1375982%2forigin-policy-violation-on-google-by-pages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does this happen if you do it immediately at the start a new Chrome session? Just close all windows of Chrome, start it again and issue the query.
– harrymc
Nov 16 at 13:09
@harrymc No, the problem is gone after restart. I still don't know the cause of it. Chrome update and Tampermonkey plugin update are the main suspects.
– naXa
Nov 16 at 14:28
Can confirm, same happened on google.ca yesterday. Was gone after chrome restart, just happened again right now but now it's persisting across restarts.
– whizzzkid
Nov 16 at 21:29
Perhaps this Chromium patch was to blame.
– fitojb
Nov 20 at 18:02