can't figure out why Anonymize is breaking Street View ...

[Ararous]

So I set noscript.forbidWebGL to false and tried to pull up Google Maps Street View at an address, but only a black background was showing ...

I tracked the problem down to the following ABE rule:

Code: Select all

Site *
Accept from SELF++
Anonymize INCLUSION
Accept GET
Anonymize

If I comment-out "Anonymize INCLUSION", there is no longer a problem. But of course I'd rather make an exception for this particular instance rather than applying the exception for all sites, so I uncommented the above and implemented the following rule higher up ...

Code: Select all

Site ^https://geo[0-9]+\.ggpht\.com/.*$
Accept INCLUSION(XHR) from ^https://www\.google\.com/maps.*$

After inserting this more focused rule, again there is no longer a problem ...

But I am at a loss to explain why the "Anonymize INCLUSION" line was causing a problem in the first place. According to the Rules Specification ...

Anonymize (synonyms are Anon and Logout) – strips Authorization and Cookie headers,
turns methods different than GET, HEAD and OPTIONS into GET, remove upload data,
then sends the modified request.

But I checked the pre-Anonymize headers, and there are no "Authorization" headers. Cookie striping isn't to blame, either, as I had no problem testing with cookies deleted and disabled. Method conversion isn't applicable, as I checked the Browser Console and can see from NoScript's output that the requests it is Anonymize-ing are of type GET. Removing upload data is not applicable, either ...

So it seems that Anonymize is doing something in addition to what's documented. Can anyone clarify for me what's going on?

[barbaz]

Anonymize also can mess with some URL parameters (like, the parts after the '?').
Suggest you compare the URL of the requests without Anonymize to the URL of the requests with Anonymize, and post each URL.

[Ararous]

I am aware of an apparent bug in which Anonymize replaces "??" with "?" in a URL, as I've seen issues resulting from that before. I checked to confirm that particular issue isn't applicable in this case, and it isn't.

I did try to compare the URLs more generally, but there are many long URLs involved and it wasn't very practical to compare :-/

I guess I'll give it another shot....

Are the changes to the URL parameters by design? If so, can the particulars be described in an updated version of the specification?

[barbaz]

Yes the modifications are by design, so that, for instance, logins stored as GET parameters are not kept.
And it's up to Giorgio to update the rule specs.

[Ararous]

(Please note that I've truncated URLs in this message -- the forum wouldn't let me post with the full URLs and told me to click "back", which erased my message )

I think I've identified the problem; the "Cross-Origin Request Blocked" message doesn't appear when the Anonymize action isn't applied ...

Code: Select all

[ABE] <*> Anonymize INCLUSION on {GET https://geo0.ggpht.com/___ <<< https://www.google.com/___ - 11}
USER rule:
Site *
Accept from SELF++
Anonymize INCLUSION
Accept GET
Anonymize
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://geo0.ggpht.com/___. This can be fixed by moving the resource to the same domain or enabling CORS. cbk

The same URL goes through fine when the Anonymize action is not applied ...

Code: Select all

https://geo0.ggpht.com/___

GET /___ HTTP/1.1
Host: geo0.ggpht.com
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: https://www.google.com
Referer: https://www.google.com/___
DNT: 1
Connection: keep-alive

HTTP/2.0 200 OK
access-control-allow-origin: *
Age: 821
Alternate-Protocol: 443:quic,p=1
Cache-Control: public, max-age=3600
Content-Length: 20882
Content-Type: image/jpeg; charset=UTF-8
Date: Sun, 26 Apr 2015 00:31:57 GMT
Expires: Sun, 26 Apr 2015 01:31:57 GMT
Last-Modified: Fri, 13 Feb 2009 23:31:30 GMT
Server: Alleycat Server 1.0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
x-robots-tag: Googlebot: noindex, Googlebot-Image: noindex, Googlebot-Video: noindex, Googlebot-Mobile: noindex
X-XSS-Protection: 1; mode=block
X-Firefox-Spdy: h2-15

Is the Anonymize action stripping the "access-control-allow-origin: *" header?

[barbaz]

(Please note that I've truncated URLs in this message -- the forum wouldn't let me post with the full URLs and told me to click "back", which erased my message )

Yeah, the browser doesn't save the message due to this site using https. If you're having too much spam filter trouble you can PM the post to an active Moderator (currently me, GµårÐïåñ, therube, or Thrawn) and we'll try to post it for you - the spam filter doesn't apply to PM's to forum staff and it's more lenient on Mods.

Is the Anonymize action stripping the "access-control-allow-origin: *" header?

Don't know, haven't played with it to that extent. Grab HTTPFox and compare *all* the request headers and let us know?

[Ararous]

It is rewriting the first request URL (removing "&authuser=0"), but this does not seem to be a problem since both versions of the URL load fine when I input into location bar.

I'm still trying to figure out where the CORS issue is coming into play.

[Ararous]

Alright, so in the Browser Console, both NoScript and Firefox display the unmodified version of the URL. (Side note: it would be helpful if NoScript could also print the modified version of the URL, for troubleshooting purposes.)
NoScript says that it's Anonymize-ing it and then Firefox says that it's blocking it ("Cross-Origin Request Blocked").

But in HttpFox I can see the "access-control-allow-origin: *" header for the modified version of the URL. Presumably there's a failure to communicate from NoScript to Firefox that the URL was changed or that the header should be applied to what Firefox sees as the URL.

The problem seems to be that Firefox doesn't know the true URL and is applying security settings based upon a URL other than the one which is ultimately requested. Apart from causing issues like the one in this particular case, this error might have security implications, too?