I am about to begin work on an information and support services website for victims of domestic and sexual abuse. Naturally, the user's visit to this website is sensitive and the repercussions of their abuser finding out that they have could be devastating. Therefore, I am seeking a way to keep the user's visit as discreet as possible.
I cannot assume the technical knowledge of each user and there are likely to be users of a wide variety of languages. Also, there is the possibility they will need to exit the site quickly (I have the solution for this) and perhaps may not be able to return to the computer before being discovered. So, while the most obvious solution is to have a page educating users on how to clear their browsing history - this may not be the most foolproof method in practice. Because of all the variables in play, a blanket solution would be the best solution.
So far, I can think of two solutions to this but am hitting a wall with both:
Firstly, simply not have the website recorded in the browsers' search history. From what I have read this is going to be problematic between browsers if not impossible to implement.
The second would be to have a landing page at an innocuous domain name that wouldn't draw suspicion and then have a button that automatically loaded the website through a Private or Incognito browser (I could simply write instructions, 'Right Click on the Button and Select 'Open in an Incognito Browser' - but I am searching for a more foolproof solution if possible).
While some incarnation of the second solution seems more plausible - I need to consider that abusers searching through browser history is a possibility and therefore, the first solution is the most desirable.
Any ideas on either of these two methods or anything more ideas you have would be most welcomed.
You cannot modify the browser history using JavaScript.
You can alter the stack of recently visited pages, but it only affect the previous/next page buttons.
Best thing I can think of : advise people visiting the website to use private browsing mode and clean the history themselves.
I was looking into a script embedded in a webpage that creates an Outlook appointment and opens it. I tested a sample appointment shared by Brian White: http://www.winscripter.com/WSH/MSOffice/90.aspx
and embedded it in a sample web page, but here are two problems:
The script works only in IE and not in any other browser.
IE issues a security message about an ActiveX control and asks if to enable it.
Do you have any idea how to make it work in all browsers and not to scare users with the ActiveX warning?
Thank you in advance!
The script you've linked to works by creating an instance of the Outlook ActiveX control. As such, no, there's no way to make this work in browsers that don't support ActiveX, which is effectively all of them except Internet Explorer.
As for not scaring the users with the ActiveX dialog box, that's not in your hands. The warning message is a security feature, part of the browser itself, and can only be disabled by changing the browser's settings - which isn't something you can do through code, for obvious reasons!
If it's appropriate to your situation, rather than do this through client-side javascript your could instead use Exchange Web Services on the server-side. This comes with its own set of limitations and things to be aware of, namely (a) it's obviously impossible to open Outlook with this method, and (b) on the server-side you'd require access to the Exchange server and would need to know the username/password of an Exchange user with permission to write to the relevant calendar (which is only going to happen if we're talking about a corporate environment).
Although I realize it is an old post, I wanted to offer another approach.
I notice your question refers specifically to OUTLOOK appointments, but what about using "iCalendar"?
{http://en.wikipedia.org/wiki/ICalendar}
This could offer a wider solution. Also, a page could offer two alternative icons.
One for Outlook, another one using iCalendar, and let the user choose which one to use.
Hope this helps. Cheers.
Marcelo F.
I'm not looking for code/how to. Just knowledge.
A client has just come to us with a question: Can we access the user's history from within a banner advert to give them some targeted advertising based on their history.
Obviously, this presents a privacy issue, but I need to give a good case for why it is technically not a viable option.
So I have a few questions...
Which browsers still, if any, support accessing a user's history, using window.history.
If some do and some don't. When did those who don't allow it stop allowing it?
If all browsers allow it (I have yet to find a script that works), why is it not commonly used?
Finally,
Having been on Amazon.co.uk, I then go to Macrumors.com and the adverts give me adverts based on products I have bought/looked at. I'm guessing this is just based on cookies/a system that amazon has implemented?
Just to make things clear:
I know it is a privacy issue. I am not looking for code/a way to do it (as I mentioned above)
There are ways to "sniff" for visited links within a page.
There used to be a way using the JavaScript history object, to list all the objects within your history (from the current site). history.length still works now. I seem to remember some browsers only returning undefined for each item, some returning them as an unreadable object.
No!
There's no browser (that I know of) that legitimately give you access to a user's browsing history.
There has been incidents where it was possible to do so by exploiting certain behaviors of the browser. Recently, in Firefox 16 there's a vulnerability that, if exploited properly, allows you to peek into the user's browsing history.
In the case you're describing (Amazon), yes, cookies are used. To be more accurate, Third-Party Cookies are used.
Update:
I was very interested in your last edit (about history being completely open in the past), so I tried to go back a little.
I'm currently building a project and I would like to make use of some simple javascript - I know some people have it disabled to prevent XSS and other things. Should I...
a) Use the simple javascript, those users with it disabled are missing out
b) Don't use the simple javascript, users with it enabled have to click a little more
c) Code both javascript-enabled and javascript-disabled functionality
I'm not really sure as the web is always changing, what do you recommend?
Degrade gracefully - make sure the site works without JavaScript, then add bells and whistles for those with JavaScript enabled.
Everyone else has committed good comments, but there are a few other considerations to make.
Sometimes the javascript will be hosted on a different domain, and be prone to timeout.
Sometimes that domain may become inacessible, while your site remains accessible. Its not good to have your site completely stack itself in this scenario.
For this reason, "blocking" scripts ( ie: document write inline ) like that present in google's tracker, should be avoided, or at very least, should go as late in the page as possible so the page renders whether or not the domain is timing out requests or not.
If you happen to be serving JS from a broken/malicious server, by intent or by accident, one can halt page rendering simply by having a script that serves that javascript which just calls "sleep(forever)" once its sent all the headers.
Some People Use NoScript
Like the above problem, sometimes the clients environment may block certain script sources, be it the users choosing, or other reasons ( ie: browser security satisfactions, odd antivirus/anti-malware apps ). The most popular and controllable instance of this is NoScript, and I myself paranoidly block some of the popular tracking/advertising services with it ( some proxy servers will do this too ).
However, if a site is not well designed, the failing of one script to load still executes code that was dependant on that script being present, which yeilds errors and stops everything working.
My recommendation is :
Use Firebug
Use NoScript and block out everything --> See Site still works
Enable core site scripts that you cant' do without for anything --> See site still works and firebug doesn't whine.
Enable 3rd party stuff --> See site still works and firebug doesn't whine.
There are a lot of other complications that can crop up, but satisfying the above 2 should solve most of them. Just assume that, for whatever reason, one or more resources that comprise a page are viable to spontaneously disappear ( they do, all the time ), and you want the page to "survive" this problem as amicably as possible. For the problems that may persist for < 10 seconds, its not so bad, refresh the page and its fixed, but if its a problem that can occur, and severley hamper usability for an hour or more at a time.
In essence, instead of thinking "oh, theres the edge case users that don't have javascript", try thinking more a long the lines of "its really easy to have something go wrong, and have ALL of our users with broken javascript. Ouch! Lets try make it so we dont' really hose ourself when that does happen"
( I've seen IE updates get rolled out and hose javascript for that entire browser until the people whom wrote the scripts find a workaround. Losing all your IE customers is not a good thing )
:set sarcasm
:set ignoreSpelling
:set iq=76
Don't worry, its only a 5% Niché Market
Nobody cares about targeting Niché markets right? All those funny propeller heads running lynx in their geeky stupid linoox cpus, spending all their time on the intarwebs surfing because they have nothing better to do with their life or money? the crazy security paranoid nerds disabling javascript left and right because they don't like it?
Nobody wants them as your primary customer now do they?
Niché markets. Pfft. Who cares!
:set nosarcasm
Consider your audience
"Degrade gracefully" is generally the best answer. But lots of sites now depend on JS - especially AJAX.
Consider your audience. If your site is aimed at extremely tech-savvy people, the chances of them not having javascript are small, and you can notify them to turn it on if necessary.
If your audience may access your site with mobile devices, don't assume they have JavaScript, and don't even assume they support CSS properly. Aim to degrade gracefully all the way down to bare HTML.
I've learned a lot from my question: What's With Those Do-Not-Use Javascript People
Go with Ajax and Web 2.0. It's the way the web is going and it's wonderful. Isn't Stackoverflow great to be on? It's not quite as nice with your Javascript turned off.
Once you have your site ready, but before you let it go live, test it with Javascript off, and just add whatever you feel you need to make your site appear and function to them. You only need to add what you feel is essential.
Remember, except for visually impared people using screen readers, the others have chosen to turn javascript off. They can also choose to trust your site and turn javascript on for your site if they want to use all the functionality you have. It really is their choice.
As other have said, it should "degrade gracefully".
In other works, it must work without Javascript (period). It doesn't have to work well. The folks who've disabled Javascript know the limitations that causes and have accepted them. But if you are trying to sell them something, it's important that they can still buy it.
On the site I'm designing, there's a javascript-based fly-out menu. With Javascript off, all the flyouts are always open. It doesn't look as cool as it would with JS, but it can still be used to navigate the site.
It depends on how much time you have to develop and maintain both solutions, and how much the non-javascript users are worth to you.
My e-commerce site relies heavily on javascript, and in over a year and a half, I've not received a single complaint.
In fact, I don't think I've seen a single visitor with javascript disabled in any of logs since I started.
That doesn't mean they're not out there. It just means that either (a) they're a tiny percentage, (b) they're not interested in what I'm selling, or (c) both of the above.
Code your web site with support for the bare minimum kind of browser. Then more people can use your site without frustration even if they don't have all the bells and whistles--like Flash, Javascript, and Java--enabled. It may not be practical to continue support for ancient browsers, say Netscape Navigator 4, because a user can be reasonably expected to keep their computer up-to-date. However, features like Javascript, Flash, and Java can be security holes in old or modern browsers, as well as being an annoyance.
Neither of my parents keep Javascript or Flash enabled because they've had too many experiences with them slowing down their already slow connection, crashing their browsers, or being more of an annoyance on sites that use it stupidly (which is a lot of them...) than a useful feature. It's just bad design if, for example, your form requires an AJAX call be made and you can't actually hit a submit button to send the form when Javascript is disabled.
My mother was recently quite frustrated to discover that she is now unable to click through eBay results pages because each one requires Javascript. The only way she can see the next page of results is to turn on Javascript or to show more results per page. Now what reason would there be for page links to require Javascript while the 'results per page' links are just plain links? They should all be plain old HTML links. Maybe Javascript could be used to add some whiz-bang to the navigation, but a user should not be punished with a bad interface for having Javascript disabled. It's stupid on eBay's part, and it causes undue hassle for their users.
I am one of those that uses 'No-Script.' And I can tell you that sites that use javascript and don't work without it enabled is extremely annoying, stackOverflow... No we don't expect it to be very fancy, if I upvote load a new page that says "Thank you."
We expect to be able to use the site with reasonable limitations, don't ever display a page that says JS must be enabled, though, even if the site is crap without it. And yes if your site convinces us to stay we will enable. A function that isn't in common use on the site can also require javascript.
Please note that your site should also look good with no JS or CSS, if nothing else it is good for Bots.
As others have pointed out some phones don't have JS, this is changing but another good reason to have reasonable non-JS. I suggest code with non-JS and add JS after the former works, there are good ways where JS can work with the non-JS layout.
It helps me in my implementations to think about it as "progressive enhancement" rather than graceful degradation. Degradation often leads you to figure out how to make it work w/o js after it is implemented, instead of making a baseline and enhancing with js.
It is essential to at least test your website is functional when JavaScript is turned off.
As orip says, degrading gracefully is very important. It should be vital that your page both looks nice and functions when JavaScript is disabled.
For a standard web site that is primarily intended for conveying information, degrade gracefully always.
For web applications:
When building a web application for a standard internet audience, I would keep the three following facts in mind:
95%-97% of potential users will have JavaScript enabled.
At times established users will need to access functionality when JavaScript is not available.
3%-5% of potential users will have JavaScript intentionally disabled.
Given fact one, if you believe that building a JavaScript reliant web application will deliver a superior user experience, then by all means do it. Doing so may help you accumulate users.
However, given fact two, you should always provide a means by which your users can access core functionality without JavaScript. Do you need to offer every single feature? Probably not. But a user should be able to get his or her work done. This will keep your users happy when they find themselves temporarily without JavaScript.
Given fact three, I would also provide an in depth tour as an attempt to entice these users to enable JavaScript.
As an aside, one of my most favorite web applications, Remember The Milk follows this approach. Also, Google's Calendar application is unusable without JavaScript. So JavaScript reliant web apps are on the rise and that trend is probably unstoppable. In my opinion this is a good thing.
(Do keep in mind that JavaScript make Accessbility a bigger problem than it is already. Please do make an effort to make your apps usable by those with disabilities.)
As said before, it depends on your target audience.
If I'm part of it, you want to make sure that your site works (if not ideally) on my phone, and that it gives me reason to turn Javascript on when I surf there with it off. Nobody expects full functionality with Javascript disabled, and anybody who uses their phone to access websites expects some issues, but you need to at least provide teasers. For a web store, make sure customers can see at least some merchandise anyway, even if they can't buy without Javascript.
Is it alright to expect that the user using the back end will have Javascript enabled?
I guess the answer I'll get is 'it depends on your target users'. I am developing a system for fun that will hopefully be used by other people. I would like to hear from other people developing back end systems, and what did they decide to do and why?
SEO I'm not concerned with, and semantics aern't of as much importance.
Personally I would expect the failover, but there are circumstances (particularly low profile sites, intranets, e-learning content) where you can assume JS.
Mostly you can even go with a simple "You require JS / This works better with JS" and I would consider that good enough, but there's a couple of instances where I would demand real failover:
.gov or other public service sites (legal requirements)
sites for web-tech companies (you need to demonstrate your ability to do this)
very high traffic sites (where the 3% of non-JS users becomes a high absolute number)
sites (or pages) for mobile devices (most of these haven't got JS reliably)
In general, it's reasonably easy to provide some kind of noscript, so why not do it anyway?
if its for fun please go ahead and require javascript.
considering the 3 points :
backend means only a few people will be accessing them (and all of them probably have knowledge about web too, eg. know what javascript is and how to get it enabled)
SEO isn't important
it's for fun
I'd say that it's alright. :)
annakata provided a pretty good insight as well.
It really depends on your application and its target audiences. Do you care about user accessibility (can disabled people use the site), do you want your site to work on various mobile browsers with limited JavaScript support? I would try to build the site so that it would gracefully degrade without CSS or JavaScript. That is unless you site is very dynamic, like say a word processor which can't possible work at all without JavaScript.
Yes, It mostly depends on your target user.
Whatever the front end is, the back end must be bulletproof.
At least, it should make ensure that, nobody can hack or make a mess by disabling javascript.
server-side filtering/validations is important for security, while client-side validation and interactivity is important for usability.
I don't think it's unreasonable to require Javascript for a web based backend/CMS, where your target users are likely to be a fairly small and pretty specific group.
All the CMS systems that I've worked on so far have required it.
I refer you to this post by Jeff Atwood. The important assertion in it is that you can expect that javascript will work as expected among browsers. The security risks are also lower today. So I would say that is now safe to ignore clients that do not enable javascript. If you want to attack users javascript would give a clear advantage.
The only exception I can think of is mobile sites. Although mobile browsers have gone better and do support javascript, the extra download bandwidth and the small screen make js less suitable.
As long as the function that your application will be serving is general, I'd say it is safe to rely on Javascript. One of the sites that I manage receives ~35,000 UV's on a good day. I think it is fair to say we come in contact with quite a variety of browser and operating system combinations. According to our stats, roughly 97% of our users have Javascript enabled.
If it can fail elegantly without Javascript, I'd opt for that solution, but I wouldn't lose sleep over the fact that you might be losing a few people everyday.