I need to know how some softwares or programs inject html,css,js into webbrowser without installing any extension. once I open chrome or firefox I find ads on google homepage, facebook, youtube ... I need to know how they inject this, how to prevent it and how to know which program did it.
Here is my google home page on chrome
and all the extensions are disabled I even deleted most of them
What worries me the most, is that in google chrome devtool (ressources) the url of the displayed image is the same url of the google logo. when I enter this url I found the real logo of google
You have a computer virus somewhere affecting you.
Edit:
Multiple things could be happening:
Something is intercepting the network request and injecting a different image.
Something has replace your version of chrome with their own version. The base code is public and their version can do whatever they want.
keep in mind, that content de-facing might happen on the Router/Proxy level, too.
some routers have content filters and domain blacklists for child protection.
maybe it's some kind of joke on the router level, where someone added
a content replace filter.
check your computer (spybot + kaspersky)
check your router
check firewall and all networking filters in the chain
Related
I am writing a mobile web page which has both a redirect and two manual backup links (for when the redirect doesn't work) to a Facebook Page.
The link takes the form:
fb://page/[PAGE ID NUMBER]
The redirect and link work in Chrome Mobile and Firefox Mobile but (surprise) they don't work in Facebook Browser which, instead, gives me the error:
Page can't be loaded.
I am perplexed that a link to the Facebook App doesn't work from within the Facebook Browser.
How can I resolve this? Are there any creative solutions or workarounds... or have I missed something obvious?
Additional Info: It looks like the redirect is working in at least one version of the Facebook Browser on the Facebook iOS App. So the issue may be isolated to the Facebook Android App.
UPDATE 1
I've made some progress. I've discovered that Facebook's in-app browser doesn't always (or doesn't ever?) acknowledge / load / execute external script files.
Added: (To find out why not, see Update 8, below...)
In this case the href attributes in the links were being re-populated with fb:// protocol links by an external script after page load.
I have moved the relevant javascript functions from the external script to the bottom of the actual page. I have tested the functions and I can see they are now activating. Although the links still don't work.
UPDATE 2
It struck me that there may be some security mechanism going on behind the scenes which doesn't allow for any javascript-driven re-population of href attributes and that instead of the fb:// protocol links not working, it was maybe the case that the initial, default http://www.facebook.com/ links were never even being replaced and it was those http:// protocol links that weren't working.
So I updated the PHP template, so that the initial default links were the fb:// instead of the http:// links (so nothing in the page delivered to the Facebook in-app browser would need to be updated by any client-side script at all at any point).
Nope. Still not working.
UPDATE 3
I added a plain vanilla link to the bottom of the page, linking to the site's homepage. The link functioned entirely normally.
Later, I pointed the original links to an external domain. They didn't work.
So... I concluded that only http:// protocol links to the same domain would work and that's why the links wouldn't work if they pointed to an external domain or to an fb:// protocol address.
Wrong conclusion.
I pointed the original links at the site's homepage and they still didn't work.
UPDATE 4
In a moment of inspiration, I removed the reference to the external script which I'd set up to customise the links to the OS + browser environment (even though this script reference was being entirely ignored by Facebook, according to the FB Debugging tool.
The links worked.
So the reason why the plain vanilla link I had added earlier had worked, was nothing to do with where it was pointing and simply to do with the fact that at no point had a script tried to access it or update it.
Added: (This isn't the reason. See Update 8, below...)
I pointed the original links at the external domain. They worked.
I pointed the original links at the fb:// protocol. They didn't work.
UPDATE 5
Now that I've got rid of the external script reference, I can point the original protocol links at any http:// protocol address and they work.
Including the http://www.facebook.com web equivalent of the page I am trying to open in the Facebook App.
Let's review that:
The Facebook website is opening in the Facebook in-app browser.
I know, right?
UPDATE 6 [.HTACCESS REDIRECT]
I changed the link destination to /fb-custom-redirect/.
Then I added a line to the mod_rewrite section of my .htaccess file:
RewriteRule ^fb-custom-redirect fb://page/[PAGE ID NUMBER]
Naturally the server didn't understand what I was asking for.
UPDATE 7 [PHP REDIRECT]
I created an index.php for /fb-custom-redirect/ and added the following:
<?php
header('Location: fb://page/[PAGE ID NUMBER]');
?>
Guess what? This works in Firefox Mobile. It also works in Chrome Mobile.
But in the Facebook in-app browser, it returns the same error:
Page can't be loaded.
UPDATE 8
I've only just discovered - and this is not insignificant - that when the Facebook Debugger Tool (https://developers.facebook.com/tools/debug/sharing/) refreshes Facebook's cache of a given page, it only refreshes the .html.
Pressing Scrape Again does not refresh any external resources like .css and .js files.
Instead Facebook continues to refer to its own cached versions of those files, regardless that the .html file cache has just been updated.
The workaround (in PHP, at least) is to append the filepath with a new, randomly generated query string every time the page is loaded:
<link rel="stylesheet" href="/styles/mystyles.css?'.uniqid().'" />
Now the Facebook in-app browser is fetching up-to-date versions of my .css and .js files.
This explains my initial observation in Update 1:
I've made some progress. I've discovered that Facebook's in-app
browser doesn't always (or doesn't ever?) acknowledge / load / execute
external script files.
I'm going to conclude that the Facebook in-app browser was parsing the external .js file reference every time, but it was repeatedly accessing an old, cached version of that file.
Nevertheless, even after all the hypotheses and experimenting above, I'm still no closer to discovering why fb: protocol deeplinks don't work in the Facebook App's in-app browser.
I give up.
Apple apps are sandboxed. This means they cannot access other apps and execute code. Facebook is running a browsing instance and when you try to call the fb:// protocol, the iPhone is blocking you from doing this to try to create an infinite app loading loop. I.e, you open a page in FB browser and it opens itself in FB browser and it opens itself in FB browser...
I'm trying to develop a Chrome extension that is supposed to completely replace a specific website's pages with a new UI. In other words, when the user visits said website, the extension should "intercept" it seamlessly and display the new "app" (preserving the URL and without opening a new tab or window). I currently use a content script to manipulate the DOM, but it's too messy.
Chrome apps such as Google Docs achieve the same goal through URL handlers, but they're not an option since they're now deprecated.
Currently, I'm aware of two options:
Intercept the URL and redirect it to an extension URL. I want the URL to be preserved.
Use a content script to stop the page from loading at document_start (using window.stop()) and then "inject" the new app. Apparently, that works, but it sounds quite hacky and prone to unexpected glitches.
What I'd like to know:
Is the second approach good enough? What limitations and other issues will I face if I use it?
Is there any other approach that is at least as good (and preferably designed for this purpose)?
You can't open a chrome app in a tab, only in a window. I don't think they have content scripts either.
Also, chrome apps are now only available on chrome os when you publish it for the first time (existing chrome apps work for any os).
To solve your question, you could use an extension with content scripts and just open up an iframe fullscreen so the url is preserved in the omnibox and it could have the page you want in the iframe as the page that would be in the app.
Content handlers are meant for opening a special protocol url to do something like send an email, etc. Examples would be like tel://, sms://, mailto:, etc.
So you would not want this. Also they aren't that noticable when approving to handle the protocol.
A while ago I created an application whereby clients connect to a server using WebRTC protocols.
The clients screen is made up of two halves. One half is linked to the server and receieves things like messages, and has the web page which has the WebRTC javascript in it. The other is an IFRAME. When the client connects to the server, the server sends the client a web address which is loaded in the IFRAME.
I know that some web pages cannot be loaded in an iframe, examples typically having password screens. Google forms does not appear to have this restriction, which is great.
So now imagine I launch a server and ask 20 people to connect to it. All 20 students connect to the server properly, I know because it comes up with all their details on my computer. Typically, from my testing, 15/20 will be fine. The other 5 will get a white screen. When I investigate in the console it is an XFRAMES ORIGIN problem, its saying the webpage being loaded will not allow itself to be loaded in an iframe. However everybody else (who are using the same browser [chrome], and some the same browser version) are fine.
Now I have one solution which works for some students, there is a setting in chrome which is called:
block third party cookies and site data
If this is enabled it doesn't work, if its not enabled it does work.
Now I have 4 students left who still just see a white screen whom I have no solution for. Chrome and Firefox both support the software but both produce the same issue.
The building setup is that students connect to the internet through a server. They must connect via this server as my nameserver is not local and indeed my website is not local either.
I dont think it is a coding issue as it only happens on a few select computers and everything else works just hunky dory. Thus I think it might be an issue with something else: firewall, security settings, config button etc. If anybody has any suggestions for what i can do to remedy this then I would be very grateful for your help.
I have tried to supply all info I believe to be relevant (hense the length) but anything I have missed please ask.
Thank you.
Alex
If the main site's URL is different than the iframe's URL, you'll get an xframes origin problem. This includes the protocol (http vs. https) and full domain (example.com vs www.example.com). In other words, if a user goes to example.com and the iframe uses www.example.com it could cause an xframes origin error. Or if they go to http://www.example.com and the iframe uses https://www.example.com you might get this error.
OK so for people who encounter this issue in the future I am going to create an update this post here. Basically it is for people who want an answer to the issue of iframes just displaying a whitepage.
With these three solutions I have eliminated all my issues, but as I come up with new ones I will post them here. Hopefully its useful to somebody :)
SOLUTION 1
If your iframe is aiming somewhere that requires the user to log in, it is unlikely to work. Password pages are rarely cross origin for obvious and good reasons. The solution is to ensure before they use your iframe page they log in fully to what they are doing, or provide an error message that gives them this information if it happens. See this post for details: Catch error if iframe src fails to load . Error :-"Refused to display 'http://www.google.co.in/' in a frame.."
Where I am we had dual login, so they sign into google and then into the organisation. Both these login areas will cause your page load to fail.
SOLUTION 2 (Chrome ONLY)
Some services react badly to QUIC mode, and some of my users have had issues due to this.
To fix:
1. chrome://flags
2. change QUIC mode to 'Disabled'
SOLUTION 3
If you are working via a proxy server that requires cookies, users may have issues if they have the 'Block third-party cookies and site data' button enabled. Disabling this had a positive effect on how well the iframes were working.
In chrome:
Settings
Search for cookies
Click 'content settings'
My website is loading JS to links similar to this one:
https://api.mixpanel.com/engage?data=eyIkdG9rZW4iOiI2NTQwMDNjNmRkZDAzZTg4NzY0MTM4ZTYwMDQ1M2E2NyIsIiRkaXN0aW5jdF9pZCI6InBpZmdzaXVhcmhsbHFjOXRncGw1OTlqdXJmIiwiJHNCI6eyJ0eXBlIjoiZnJlZSIsImlzTW96YmFyT24iOmZhbHNlLCJpc0RvY2tlZE9uQm90dG9tIjpmYWxzZSwiYnJvd3NlciI6ImNocm9tZSIsIm9zIjoid2luZG93cyIsInBhZ2VPbmJvYXJkaW5nU3RlcCI6InBhZ2UtaG90c3BvdHMiLCJzZXJwT25ib2FyZGluZ1N0ZXAiOiJzZXJwLWhvdHNwb3RzIn19&ip=0&verbose=0
I cannot find where it is linked from. I saw the site mixpanel.com and looks like they offer a web analytics service or something similar, but I have not any with them. Have I being hacked? What can I do to find witch file is doing the request?
I am almost sure the request is not being made directly for my website; maybe is made by some plugin? How can I be sure? Should I remove it? How?
Mixpanel is a tracking and analytics provider. If your website is hosted on your very own server, controlled by only you, then things to try are:
1) Disable all your browser's extensions. Turn them all off, confirm that it's either still happening of has been resolved. If it's no longer happening, turn them on one by one.
2) Different internet connection. Some poor WiFi hotspots may inject tracking code.
3) Try a different browser like Firefox, Chrome, Safari....
If your website is hosted by someone like Wix, SquareSpace, Weebly, etc then this tracking is very likely injected at their level and you will probably not be able to turn this off, but you should be able to get access to the insights in your control panel.
My chrome packaged app contains a PDF, and I would like to let the user view it. If I open it in the current frame I get the error "Chrome PDF Viewer is not Allowed".
Frankly, the chrome PDF viewer is pretty awful, so I'd rather let the user view it in their PDF viewer of choice anyway. If I disable the chrome PDF plugin (just as an experiment) and I try to open the PDF using chrome.app.window.open, it "downloads" the PDF, and then the user could open it. But this has two issues:
I can't realistically make the user go to chrome://plugins and do that disable
There isn't any browser window, so the user has no idea the download happened
Any suggestions? Opening PDFs that are embedded in my app is kind of a must-have feature for this app.
I've looked at this extensively, and have come to the conclusion that there's no way to get a Chrome App to open a PDF that's local. I, too, have tried data URIs.
I don't think the issue is the PDF support in the window, as it's still Chrome, or the size of the PDFs. Rather, I think it's just an engineering problem, one that might get solved someday.
As for me, I build the PDF in my Chrome App. Since I can't display it, and there's no server to upload it to, I write it to a file of the user's choosing and let the user deal with it on his/her own.
I've got this working, but whether it is a solution for you depends a lot on your use case. The solution has three parts:
Use pdfjs to do the actual rendering.
To get this running in a packaged app, you'd need to do some violence to the internationalization support. And even after you do that, you'll find that some PDFs refuse to load for no apparent reason whatsoever. So don't bother trying to make pdfjs work in a packaged app. Just:
Put your entire app into a <webview> with a persist partition, and use a HTML5 cache manifest to get all your files available for offline viewing.
Yeah, yeah, I know that cache manifests are not cool anymore. But if you can list all your files for use in a packaged app, then you are doing the one case where cache manifests actually work great.
Then use a packaged app to distribute a tiny wrapper around your page with the webview in it.
You'll also get the benefit that you don't have to rewrite your app to live within the draconian packaged app rules (eval, sync xhr, 2GB limit, etc.).
You can see a working example at m.kaon.com/c/ka (visit with Chrome to get the desktop app; if you visit that with Firefox, you'll get access to a hosted app that is using the same tricks). PDFs are down in the bottom "Why Choose Kaon" section.