Do WebExtensions have a way to check whether it's possible to go back/forward in history (and actually go back/forward)? I looked at history and webNavigation APIs, but it doesn't seem obvious from that.
Related
I'm developing a chrome extension. When the user goes to the options page, they might modify a setting which will require them to refresh any tabs they have in which they're using the extension. So if the user changes one of these settings, then goes back to a tab which requires a refresh, I'd like to notify them of this in a non-intrusive way.
Is there a part of the API specifically for doing this sort of thing, or some other recommended way of doing it? I was thinking of maybe a little message that comes down from the top of the page, but can be closed, or a popup coming out of the browser action.
You have many options.. To name a few:
Do not require it. As much as you can, make the (presumably) content script adapt to new settings. It's by far a better UX - in some cases.
Least intrusive would probably be to update a browser action / page action icon if you use one.
Both APIs allow a per-tab change of icon/badge. You could also animate it a little to bring attention.
An in-page notification injected into the DOM. Some sort of toast or <dialog>.
Watch tab changes with chrome.tabs events, and do something on activation of affected tab, such as a chrome.notifications notification.
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 am working on a website related to physically/psychologically abused person.
There is an emergency exit button available all time so the user can click on it before the "aggressive" person enter the room where the computer is located.
When the user click on the emergency button, the user is automatically redirected to Google with a query like "cooking apple pie" (this is an example).
Also, we would like to hide our website from the browser history in case the aggressive person check the history of the abused person. I think this cannot be done technically.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
I tried multiple things to simulate a "browsing" like using an iframe or an ajax query to another website but none populate the browser history.
Is this can be done?
Thank you for your input!
I think you may be focusing too much on the browser and computer that you do not control and not enough on the content and the server that you do control. How about taking a different approach? Why not generate the pages for the user on the fly? The links are only good once. If you click on the home button (your escape key) and the aggressive person looks in the history the attempt to access them a second time could be made to display the weather or lottery results or something innocuous, Focus on what you have control over.
Useful Technical Details
Removing/Preventing Back Button Click History
You can allow the user to browse throughout a webpage without building up a history trail on the back button by having them click exclusively on javascript: links. This would still not remove any of the visited websites from their full browser history, so it's not a full solution.
Here's an example HTML JavaScript link:
CLICK HERE TO ESCAPE!
If this is acceptable, you could build an inoffensive homepage from which the user could access the site that would use JavaScript to send them to the real website. Every link on that new website would have to be a javascript link. Disadvantages of this would be that they would no longer be able to use the back button to navigate and that JavaScript is 100% required for the site to function.
Sanitized History
Make sure you have inoffensive titles and icons for any pages in the site so if the user does not delete their browser history they will not grab the attention of the third party.
Preventing Access to Protected Content
One option you have is to disguise your website as something else by having the user log in before they are allowed to access any of the content. You could save their session/login data in such a way that it is cleared if they hit an escape button it is erased or reset. As part of the login page, you could give users an alternate password to type in that would redirect them to fake content if their abuser becomes suspicious enough to demand they log in.
The session/login information should never save between browser sessions and always have a short expiration period, to further reduce the chances of the abuser gaining access to the website.
Disguising the Site
Considerations
If you choose to disguise the site either on the homepage or behind a "fake" login, be very careful to choose something that makes sense and would not arouse suspicion or interest. You don't want the fake page to be some sort of game or anything that might pique the third party's interest.
You also don't want it to look so boring or mundane that the original user would be hard-pressed to explain their possibly frequent visits. It shouldn't be anything so specific that the third party would think twice about the original user visiting it though. For example, it might be suspicious if someone who does not enjoy the great outdoors were to be visiting a page on mountain biking.
It also can't do something like just redirect them to Google without explaining the fact that they had to log in to access it.
General Advice
Private Browsing
Multiple sources have suggested either educating your target audience in how to use IE's InPrivate Browsing mode, Firefox's Private Browsing mode, or Chrome's Incognito mode.
There unfortunately does not appear to be a way to prevent the browser from keeping the current page in its browsing history through JavaScript. It's possible there might be some sort of plug-in or third-party control which would enable this, but it's probably just easier to get your users to use a private browsing mode.
Clearing History
Clearing a user's web history would not be possible since browsers restrict websites from accessing or altering data on the user's computer directly. Since the user's browser history is part of this data it would be a security issue if any website could clear the history.
You should provide instructions to your users for pruning or clearing their browser history, whether on the website itself before they enter, or through whatever resource you showed them how to access your website.
Generating a Fake History
If you need to generate a fake list of visited websites, you can always create new tabs/windows for the users (or possibly iframes) at timed intervals with JavaScript, but the user would have to disable their popup blocker for this to take effect.
Further Reading
Here is a helpful article on creating a useful Quick Disguised Exit From A Website. This forum thread that I found it on also had some useful information, but it's likely you've already seen it.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
Have you cosidered turning it around?
What if technically all your pages and its content are about something else. So it is the content you want to hide that's loaded in a special way, making it easier for you to avoid having it in the browser history.
So then it becomes about knowing when to load/show the special content.
Above said, it's very important what #Frédéric Hamidi said:
Just keep in mind that if the "aggressive" person has control over that computer or the network, nothing can really prevent him/her from installing loggers on the machine or analyzing network traffic.
IE's InPrivate Browsing mode, Firefox's Private Browsing mode, and Chrome's Incognito mode
I would recommend this to prevent the abuser from finding the secret site in the browsing history.
Also, opening a social networking site and letting the browsing history collect that would be an excellent and believable excuse for the time spent on the computer.
I'm looking through the Chrome Extension API documentation about chrome.history, and I can't seem to find a way to query or modify the history of a single tab. That is to say, the back/forward menu contents of a tab. Everything in the docs seems to treat Chrome's history as if it was one large amalgam.
So, is there a way to query or modify Chrome history on a tab-by-tab basis? If so, how?
There is not. Jasper's suggestion is valid though, injecting a content script would allow access to the history of the tab.
So I have a Chrome extension which uses Google Analytics for tracking various things. One of those things is the extension version, set using a custom variable every time the background page is started. Now my question is: Which scope should I use, visitor or session level? I can't figure it out based on Google's documentation, and no one else seems to have had this issue. I'm not even sure there's any difference, or maybe it's just something like "it's bad practice to overwrite visitor level variables".
Chrome extensions are have some very specific characteristics and the answer to this question is not applicable to anything that is not a Chrome extension.
From your question I believe you do some basic tracking on your background page, but I assume you also do so on a popup or you fire an event if the user do some action with your extension.
In that case I'll strongly suggest that you use a Visitor Level Custom var.
The problem is that the background page is loaded only once, when the browser opens up, and it's like a tab that stays open and silent, possibly hosting some callback functions for events that may or may not happen.
Because of that once the visitor first loads your extension you'll see a pageview from you background page setting this custom var.
After that there may be a silent period where your extension doesn't track anything, this period can take hours, until hopefully the user interacts with your extensions and tracks additional data to analytics. When it finally happens chances are that over half an hour has passed since the backgroun page loaded. If that is true the visit (or session) that was started by the background page is already over. A visit with no activity for 30 min is closed by analytics. In that case that interaction will spawn a new visit.
If you set the Custom Var as a visit leve variable chances are that when you see interactions on the extension, these interactions won't have the custom var.
This approach has the bad side effect that if the version of your extension changes and the user doesn't reload the browser the version is not going to be updated, and it will be erroneously registered as te old version.
That's very unlikely. And the only way to fix it is to check the version of your app everytime the user does an interaction and set that custom var again. I believe that this is excessive and I don't do it in my extension. Still if you opt for it, it really doesn't matter if it's a visit level or visitor level custom var.