I have switched to using Content-Security-Policy for my website. I'm starting to see reports about the following not being allowed: https://www.pagespeed-mod.com/v1/taas
Does anyone know why the website is trying to load this file? I'm using Google Analytics and Tag Manager, but I don't think that I have any page speed mod installed. Maybe this is an extension in the user's browser? Or when they open developer tools? Another source I could think of is automatic optimization through Cloudflare which I'm also running on.
Extra info: The source of loading this script is https://3001.scriptcdn.net/code/static/1 which doesn't reveal much about who made that.
Had the exactly the same issue and preventing me from using Element Inspector/ debugger. It appears to be some Chrome extension you have installed gone rogue, see if you have extension called "Auto Refresh Plus" installed like i did before.
I also see reports on https://www.pagespeed-mod.com/v1/taas being blocked with the same source of loading. It seems to happen in short periods on the various resources I have reports from. This indicates that it is related to the user/browser and not related to the site itself.
The same can be seen with translators, extensions, security proxies etc. I have given up trying to attribute the source of anything that is likely not caused by legitimate site content.
Related
We recently made a number of changes to our CSP and have gotten reports from a very small number of users that the browser is not rendering because of one of these changes. We have 5 reports out of 2mil active users, so this is something very specific.
None of our QA are able to replicate this with their test browsers, so we're unable to determine what about the new CSP is causing the problem.
Is there a way to put a browser into some super strict mode so that it will stop all dynamic content with the slightest issue?
Rundown of my analysis:
I know the latest version also introduced some [tab] unicode, but I want to replicate this issue before I remove it so that I know that we've fixed it.
We do not have any of the deprecated X- headers in there.
Tried loading it into some online CSP validators but those come back with some vulnerabilities, but says the CSP is valid as written.
We're considering the report-to directive but have not implemented yet (Does anyone know if this would even help us in this?)
We were able to screenshare with one of the users with this issue and saw their browser console showing that it was stopping because of the CSP, but it had issues with the CSP that were very old. That user was running a current Chrome install
I'd post the csp but the invalid unicode wouldn't post anyway. It would also identify some of our clients.
I may be a bit of paranoid when it comes to installing chrome extension that request access to all my tabs and data. While a extension may be safe for the moment, a simple auto background update can make it a malicious virus and you won't even get notified about updates.
I would like to specifically whitelist all my extension to access the content pear webpages bases. Is there any such tool out there already (natively perhaps) before i start hacking my own extension to control it on my own.
That would leave me to my next question. Extension can be a bit secured running sandboxed environment and have no access to the "real" filesystem (not the virtual sandboxed filesystem) but could i write a NaCl plugin and have have full access and change the manifest file to change the content_scripts settings? if so, could you point me in the right direction?
I'm not sure to understand clearly your question, but let's calrify some things about extensions and how they can be dangerous:
First: If an extension updates and want to have new authorisations, Chrome will warn you and you can choose if you want it to be updated
Second: Chrome sandboxes extensions running on your computer
Third: The only authorisation that may represent a real danger for your computer are the ones requesting authorisation to "Access all data on your computer"
.
.
.
If you are really worried that some extensions may represent a danger for you (and I understand you), you can restrict them to run on specific webpages by doing the following:
1. Go to the extensions folders [C:\Users(YOUR USERNAME)\AppData\Local\Google\Chrome\User Data\Default\Extensions(APPID)] and open the manifest.json file with any text editor
2. In "content_scripts" declaration, in "matches", specify sites where the extension will ONLY work on [ex:*://google.com/* will make extension be active ONLY for google.com]
You can even be more precise and set specific URLs/HTML pages (see more: https://developer.chrome.com/extensions/match_patterns)
Hope it helps!
If it doesn't, please clarify your question again.
Chrome extensions can interfere with how a site is rendered and/or its behavior. This introduces unnecessary states and potential sources of errors.
So: Is there a way to disable all Chrome extensions for visitors of a certain website?
I dont think such API exists (we are taking about webiste scripts, right?) However you could determine if specific extension installed and update your code accordingly. Check this topic how to do this.
Even better and actual topic if you are fighting with adblock plus ;)
The best way to handle so far is to disable Extension sync in that specific browser.
Steps to follow:
https://superuser.com/questions/528014/how-to-disable-chrome-extensions-without-disabling-them-across-multiple-synced-d
.
I have a popular Chrome extension that is being targeted by a specific site and they are messing with our extensions functionality and telling visitors to uninstall our extension. They are detecting we are running in the browser by checking for our manifest file via looking for the URL chrome-extension://our-app-id/manifest.json. Is there anyway I can prevent this?
I tried using content-security-policy but that seems to only help with cross-scripting. If not seems like a security hole on google's part; I don't want sites knowing what extensions I am running in my browser.
Manifest version 2 that is tentatively scheduled for version 18 should fix this.
[...] today, all the resources inside your extension (e.g., images)
are visible to web pages. We're changing the default to "not visible"
and then adding a manifest attribute to let you whitelist the
resources that you want to be accessible to web pages.
Sometimes the style sheet disappears when naviguating on our WSS 3.0 sites (white background on the site, no colors, no formatting, etc.). This has mainly happened with IE6 (corporate browser for the majority of our computers). The fixes were :
clean up temporary internet files
if it still doesn't work, upgrade to IE 7
However, this time, the upgrade to IE 7 hasn't worked, the style sheet isn't applied. When we clean up temporary internet files, things go back to normal, but after a while the css disappears again.
Here are a few ideas on what you could try:
Fiddler should be able to tell you if there is a network problem.
Check the HTML for anything unusual. Is it malformed in any way? Can you save a copy and run it through an online validator (although this is limited in use as SharePoint's default markup isn't compliant).
If some users are having the issues but others aren't, check their permissions on the server.
You could also try using the SharePoint "Log in as another user" feature to see if the problem can be reproduced on your machine when logged in as them. You may also want to try running Internet Explorer as that user.
Check the Event Viewer on both client and server for anything unusual.
Check the IIS logs on the server for any errors.
Check the SharePoint ULS logs on the server in the "12 Hive" for errors that might be related to this problem.
Try running Process Monitor on the client and reproduce the problem. Search for keywords such as FAIL or ERROR to see if anything appears. Make a note of the time the problem occurs and see if the Process Monitor logs give any additional information.
Is there some javascript that's involved as well? Could it be a virus scanner that is set way to strict? As you pointed out in one of the comments, the CSS isn't even being requested (at IIS log level, which is as basic as you get, not even in SHarePoint yet), so it HAS to be something on the client PC.