I'm trying to find out what's the worst case scenario, damage or repercussions of embedding an image from an ambiguous third party website from a security point of view. In specific, what technical access does the 3rd party gain to exploit?
For example, a user posts an image URL and then the image is directly embedded like so on a website:
<img src="http://www.site-thats-not-mine.com/image.jpg">
I understand that the image could be malicious, or even that it's not really an image, but what's the worst that they can do due to this? It's not like it's an uncommon practice either.
Generally, the worst it can do is track the end user. Any headers sent along with the request for the image can be used to keep a database on end users of the image. Another bad thing it can do is change -- it could lead to a broken image on your site if the image is removed or if the server goes down; and if the image is replaced with something else, it could lead to similar problems (even possible legal issues -- for example, if the image is maliciously replaced with the intention of deceiving end users of your site).
There are also browser exploits to consider, but those are not the general problems.
For example image file can be crafted in special way to exploit bugs in browser or image libraries to hack visitor machine.
Other possible things that could go wrong - remote site is down or image is gone. Or instead of lovely flower images your site will one day start displaying bestiality p0rn... It's better to serve own content :)
The worst thing that could happen?
I'd say: the universe could implode. (though I am not sure if that would be such a bad thing...)
No, that is mean in a serious though somewhat exaggerated way: since it is impossible to know all possible exploits that do exist or might be developed it is formally impossible to limit the worst possible outcome of a missuse. Such a question cannot be answered seriously. You might want to re-think your question instead.
Related
As title.
It is the safest if we go for searching free source and just use them, but it is not always the case that we can find the one that we want. If then, what will happen if I just use images from someone's website in my own project?
Images that you find on the web are licensed in one way or another, as a result it is important to understand the terms of that license.
This question goes over what you can do when your license is being infringed upon.
But from the phrasing of your question it sounds as though you are curious about what will happen if you just take images from other websites regardless of the licences on those images. In most cases, it is unlikely that much will happen as the content owner would have to be aware that you're using their licensed product. But that doesn't mean that you should.
If you were using licensed content and the content owner was aware, they have many options available, from requesting that you remove their content all the way to hiring a lawyer to pursue the issue.
I personally do not recommend just using content without knowing what license it is governed by. It is always better to ask permission first. That being said, Here is a link to a flow chart that may help in deciding if you should/can use an image from the web.
I'm excited about the rel="preload" property, because it looks like it can help speed up page render times.
The use case is a web page with a large image above the fold. Right now, Chrome doesn't start downloading the image until after fetching jQuery (a fairly heavy file). With preloading enabled, they download in parallel.
But I'm reading conflicting reports about whether I should use preload for things that are in visible HTML elements elsewhere (as opposed to things made visible by user interaction, like a dropdown menu).
This post seems to recommend not preloading:
When not to use preloading:
When the asset is referred to somewhere else on the same page.
When you're not sure the user will actually require that asset. Like on a page visitors only go to 3% of the time.
While this one seems to indicate it was really helpful for a similar situation on the Financial Times website:
When the Financial Times introduced a Link preload header to their site, they shaved 1 second off the time it took to display the masthead image...
So which is it? Should I provide an early "hint" to display the always-shown, above-the-fold image? Or should I just let the browser get to it in the usual order?
I think that in cases involving performance optimization, you really want to create an A/B test to determine which one you should do. There really is no cookie cutter answer for image preloading that applies to everybody as a best practice.
One of the biggest tenets of a favorite book of mine, Lean Enterprise, is use to A/B tests to prove or disprove a HIPPO (highly paid person's opinion). Certain opinions carry a lot of weight, both in your organization and on the internet. Because of their importance and reputation, their opinions veer towards the realm of fact, even though it may not be.
The practice of measuring performance empirically is also touted by another book I love which deals with performance tuning - Code Complete 2nd Ed. In that book, McConnell gives several code examples where you would expect one piece of code to be optimal, but in fact, it performed poorly (see chapters 25 and 26). One of his key points is that you should always test a performance optimization. If it isn't worth testing, it isn't worth writing the "highly performant" code in the first place. McConnell's premise doesn't just apply to his low level coding examples, but to high level decisions such as preloading images above the fold as well.
I can also attest to the importance of A/B testing at a professional level. I used to work on Amazon's SEO team and we A/B tested everything. The fact of the matter is that you never really know how customers will respond to something. Nobody can predict customer behavior - not even Jeff Bezos - and you really need to back up your hypothesis with real data to prove or disprove the validity of what you're doing.
Even though you can find multiple blog articles and online sources discussing whether preloading is better or not, you don't really know whether that will work for you until you've done it. Different people have different servers with different performance characteristics and different network topologies, etc. You just don't know which way is better for you until you have the data. If you launch your A/B test and find that find that your repel rate goes up when preloading, then you know that you have to dial back your treatment and return to your control. If however, you find that customers don't get bored waiting and click through at a higher rate than before, then you have a winner and you dial up the treatment - deleting the control code entirely after a period.
I hope that helps.
The article is wrong about those statements. Preloading is used by the developer because he already knows those assets are needed on a page. Preloading is not a "hint". Prefetching is more in line with what he states, that you are telling a browser that it's possible the asset may be needed.
If an image is above the fold, then you know it will be needed, and that is exactly what prefetching is for.
Addy Osmani of Google
preload is a declarative fetch, allowing you to force the browser to
make a request for a resource without blocking the document’s onload
event.
I would use rel="preload" for images only if they are to be found in css, javascript that will led to a bottleneck in the render of the page at a later time, if user driven events will request the image and it will have detrimental impact in user experience or if you are experiencing any flows due to this large image in the rendering of the page.
I understand your image is above the fold, and if it's to be found in the source code from the beginning I would let browser prioritize what to download first.
On the other hand you could always A/B this change and see if it works for you.
What are pros and cons of this technique (see Softfolio for an example). Two things I personally thought of are as follows:
Impossible to tell someone where an item of interest is located (like, you probably won't say "324-th row, second column")
Broken navigation when you return back to an infinitely scrolled page.
What else can you think of? And what do you personally think of this approach in general. Would you use this in you projects?
I think it is "neat" but requires more visual clues as to what is going on... and in many circumstances isn't what the user wants.
If I want to get to "page 7 of the results" I don't want to move to the end of the page 6 times to trigger the reload of additional data. (e.g. in an alphabetical list... If I want "M"'s, don't make me wade through a,b,c,d,e,f,g,h,i,j,k,l
Ensure there is a visual clue of more loading if you do use this (when I press CTRL+END I expect to be at the bottom)
I often find I'm still waiting on these types of pages because the "loading" of the next set of results waits until I'm very near the bottom... thus I often get there before the data is loaded/ready/rendered
(pro) I think this kind of thing would be good for certain scenarios... e.g. when I scroll down my Twitter list... I don't want a "more" button, just load it...
I would prefer better "search" filtering over fancy ajax-infinite scroll results. If I can filter down to 25 results that actually match what I want, then I won't need to scroll!
When results are served randomly, it's a great idea. People are asking, "How do I get back to where I was?". Well, you don't. The results are random, so when you return to page six, you won't be seeing what you did last time.
If you think about it, paging Sortfolio would be a bad idea, because it would imply to its users that the order of its listings are fixed, as many of you have made the mistake of assuming.
For those asking, "How can I return to a result I liked?", well, you click the 'Save to my favorites' link. As for, "How can I share a result with a friend?", you click on the result and grab its URL. Kinda simple really.
I'm not saying this infinity-scrolling business is the way to do it, I'm just saying that some of you guys are unfairly discrediting Sortfolio for usability problems which the site—given its random nature—really needn't concern itself with.
Personally I HATE that example. It makes the site much less usable than if the results were paged.
You're right too, when you hit back, you will have to page by scrolling down again, and while page down works it doesnt work well - I cant remember how many page downs i pressed to get to the site, secondly, what if the ordering changes the number of scrolls would differ anyway - I know paging would too, however its much easier to scan a few pages than keep scrolling.
Lastly, even though I am a developer I scrolled down, and the first few times I actually thought maybe if i leave it long enough it will download all the images/samples...then scrolled down and again the same thing happened AAAAAARG!
I would NEVER use this approach in projects.
I wouldn't use infinite scroll on search results. But it's really nice for casual browsing, or in a random output situation such as psychological test where it's important that items not show up in a constant order. Something like a market preference survey skews towards early choices, so randomizing the order of options is essential.
Where it gets frustrating is when the user leaves a page via a link and then wants to come back. For a browsing situation, I'd probably address that with overlays rather than linking away.
I personally find it gimicky and quite annoying. It diverges from standard navigation techniques that users are used to (such as pagination) and breaks navigating back, which is very annoying (you can't get back to a result without starting again). On top of that it doesn't conform to accessibility guidelines as it is totally reliant on JavaScript to work (which goes against the "progressive enhancement" theory of the modern web). This also has SEO implications as I doubt content "beyond the fold" would be indexed, unless it was linked to directly from elsewhere.
I can see a few limited circumstances where this might be OK, such as a very long text page, but personally I doubt I'd use it in the current form. Kind of reminds me of those Flash sites that are all style and no substance and end up annoying the user rather than enhancing their experience.
I agree this is a mess. If there is a finite list, there should be some kind of pagination mechanism that lets you know where you are.
Alternatively, or in addition, add a filtering mechanism so you can weed out the stuff you don't want to see.
SO provides a handy example of how to do it right.
Actually, It doesn't matter whether we (designers/developers) like it or not. The only thing that matters is the users perception of this. If the user finds it useful, well, then the solution is OK. If the user gets confused and can't accomplish the primary task, then redesign...
I think the cons are that when you hit the back button you lose your place on the page. Could be annoying especially if you are deep within a page.
Etsy discovered the hard way that infinite scroll isn't good for conversions. Recommend reading this article.
I was looking at the www.google.com in Firebug and noticed something odd: The Google logo is centered using a center tag.
So I went and checked the page with the W3C validator and it found 48 errors. Now, I know there are times when you can't make a page valid, especially when we're talking about something like www.google.com and you want it to be as small as possible, but can someone please explain why they use the center tag?
I attended a panel at SXSW a few years ago called "F*ck Standards" which was all about breaking from standards when it makes sense. There was a Google engineer on the panel who talked about the Google home page failing validation, using deprecated tags, etc. He said it was all about performance. He specifically mentioned layout rendering with tables beating divs and CSS in this case. As long as the page worked for their users, they favored performance over standards.
This is a very simple page with high traffic so it makes sense. I imagine if you're building a complex app that this approach might not scale well.
From the horse's mouth.
Because it's just the easiest, most concise way to get the job done. <center> is deprecated, for sure, but as long as it's still supported, you're likely to still see them using it.
Shorter than margin:0 auto. Quicker to parse. It is valid HTML4. No external dependencies, so less HTTP requests.
Usability is NOT validity.
Google Search's biggest achievement has been to build a site which is easy to use, and can be widely used. Now, if Google achieved this with a page which does not validate, well, there's a lesson there to learn.
I think a better question to ask would be "why would Google make it validate if it works fine?" It makes no difference to the user.
There has been speculation and discussion about whether this is intentional; the basic test carried out in the first link does result in a smaller page, and even gzipped, through millions of page views it theoretically stacks up. I doubt that's the reason though: it was created, tested on many browsers at the time, it worked, and continues to work.
Google's breaks validation in many ways on their home page. The very likely real reason - they are all about speed and bandwidth costs. Look at the size of the home page HTML particularly after Gzip is applied at the packet level. They are clearly trying to avoid packet fragmentation (which will mean more bandwidth) and willing to do whatever it takes to get it (identifier shortening, quote removal, deprecated tags, white space removal, etc.
If you look at this just as a validity question, fine but they break the rules on purpose if you don't assume this of course you may jump to a negative conclusion. BTW you can further optimize their pages both in positive and negative manners but why once inside the typical packet size it is somewhat pointless.
They also use other deprecated presentational tags like font and u. My guess is it makes the page quicker to load then using an external stylesheet and allows it to work on more platforms.
It's deprecated, sure, but I think simplicity is the answer to your question.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
For instance, customers that we're creating web sites for, request things like:
all links should open in a new window
put custom 'Back' button on every
page while there is a working
browser's equivalent
make some part of the text blinking etc.
Of course I tell them it's wrong, but is there some nice list of bad things to have from a respected source that I can point them to?
Become that respected source. Seriously: if your clients are showing reluctance to take your advice directly, compose documents that illustrate good and bad user interface design and publish it on your website. You gain three things from this:
You become more knowledgeable about the why of bad and good design. Having to think through something to compose it into a document is more helpful than many give it credit for.
If this is publicly published, you probably will get feedback about your ideas. Throw away the bad suggestions and integrate the good, and you become better at your craft.
You have the source for these discussions in a presentable format, yet you retain all your personal branding. If you include examples and demos of the good and bad, most people can see why you advocate for your ideas.
EDIT: epotter is dead on as far as the "buck stops here" aspect of interacting with a client. If your documents can show why irritating a user is a loss of revenue in the long run, it is unlikely you will have much push-back. On the other hand, if your personal preferences includes UI designs that don't help with retention... stop doing that. (I recall the days of "CSS Only, No Tables" designers before CSS had matured: they insisted on forcing their designs on clients, even though in some browsers they didn't render well. While a cause is admirable, you work for the client not a cause.)
Always try and show them how it will cost them money. For example, if they are going to do something that annoys the user, they will have less traffic which will lead to less revenue.
For better or worse, dollars always speak the loudest.
First, don't tell them it's wrong.
They may take it personally.
Instead, understand the need they are trying to fill, then suggest alternatives that don't include the bad behavior. Mock all the alternatives up and point out the good and bad of each one. Let them choose. As long as you have a good alternative, and sufficiently pointed out the faults of the bad implementation, then they generally come around to your point of view.
In other words, act like a designer. When a customer says, "I want green text on a red background," you don't immediately tell them that 10% of the world's males cannot read that, you first need to understand why. "Well, it's Christmas," then you can suggest alternate themes to give the site a festive feel without the design error. As long as the mockups you suggest are better than theirs then they will generally acquiesce.
Not because they made an error, but because you saw their real need and improved on their idea.
If they're adamant after that, though, do the work - don't spend your time trying to convince them the error of their design sense, it's a waste of resources.
Educate them over the long term, but if it takes you an hour to convince them not to make a change, that's one hour you could have spent improving your relationship with customers who treat you as designers rather than web-monkeys.
-Adam
I've had to play a semi-sales role at time with web projects and I have to stress how important it is to keep the customer happy.
Nevertheless, I completely agree with you that you are obligated to say something in the name of giving them what they want. I always found that the best approach is to start by agreeing with them (in principal at least). You could say,
"I completely agree with you that this
text is very important to your users.
Many testers that I've worked with
have strongly preferred using this
font/graphic/color to call out
critical text. Unfortunately, some
users associate flashing text with ads
and avoid it"
I find that this approach lets them know that you
Understand what they want
Appreciate their motivations and suggestions
Only want to help
One last word of advice, if after the gentle nudging, they don't get the point, consider doing two quick mock-ups. (their idea and yours). If that doesn't work, then just give them what they want. In the end, they pays the bills and if they really want an ugly site (assuming you can't afford to turn away business on aesthetic grounds) just give them the site.
Good luck and take deep breaths!
Jakob Nielsen's Alertbox has been an invaluable source of common-sense usability advice for me for many years. Here's something he wrote way back in 1996 that still applies today:
The BACK feature is an absolutely
essential safety net that gives users
the confidence to navigate freely in
the knowledge that they can always get
back to firm ground. We have known
from some of the earliest studies of
user navigation behaviorthat BACK is
the second-most used navigation
feature in Web browsers (after the
simple "click on a link to follow it"
action). Thus, breaking the BACK
button is no less than a usability
catastrophe.
And here are the first two of his Top Ten Web Design Mistakes of 1999:
Breaking or Slowing Down the Back Button
The Back button is the lifeline
of the Web user and the second-most
used navigation feature (after
following hypertext links). Users
happily know that they can try
anything on the Web and always be
saved by a click or two on Back to
return them to familiar territory.
Except, of course, for those sites
that break Back by committing one of
these design sins:
opening a new browser window (see mistake #2)
using an immediate redirect: every time the user clicks Back, the
browser returns to a page that bounces the user forward to the undesired location
prevents caching such that the Back navigation requires a fresh trip
to the server; all hypertext navigation should be sub-second and
this goes double for backtracking
Opening New Browser Windows
Opening up new browser windows is like a
vacuum cleaner sales person who starts
a visit by emptying an ash tray on the
customer's carpet. Don't pollute my
screen with any more windows, thanks
(particularly since current operating
systems have miserable window
management). If I want a new window, I
will open it myself!
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
These aren't crazy newfangled ideas, they're decade-old guidelines based on hard research. You'd need a really, really, really good excuse to repeat a decade-old mistake.
Find examples of actual pages that do this and show them. Here's a good place to find some.
If you show them the examples, and instead of being awed by the suckyness and changing their minds, the clients say, "Yeah! That's exactly what I want!", then make them sign a nondisclosure contract saying they'll never tell anyone who designed their web site. :)
You have to explain "why". It's not enough to tell them something is "wrong" (and in these cases, it's not so much "wrong" as it is a "bad idea")
Most people respond well to logic and reason. If you can make a reasoned argument for why doing something a certain way is a bad idea, they'll usually bow down to your experience and knowledge.
useit.com is an excellent resource for usability arguments
but you're probably wasting your time. Either do it their way ("the customer is always right") or walk away - arguing is unlikely to improve the situation unless you can demonstrate a significant monetary gain from not doing it their way, which you probably cannot do given the issues you listed.
if your name will be on the site, i'd politely walk away
Show them some articles on sites like http://useit.com which has some empirical studies on how adherence to web standard practices increases usability and so therefore user satisfaction and so therefore profit.
Ask them what results they're after. "Have all links open in a new window" is a statement of solution. Solutions are your job, the client's job is to state objectives.
Start with this: "Oh, you'd like links to open in a new window. Tell me more about why you want that - I'd like to explore with you whether there are alternate ways of getting the same results."
Perhaps continue with this: "Also, I might point your attention to other consequences of opening all links in a new window - consequences you might not have considered, and which perhaps you wouldn't like."
Suggested reading: Dale Emery's articles on resistance.
At the simplest, try to explain them each of it in a user understandable manner.
e.g. Blinking text is an old style thing not supported by all browsers
Not sure why "back" can be a problem. But put your viewpoint.
It's always convincing if you demonstrate to the user that his design is unconventional or wrong by showing a list of very well known websites that he would "respect" and pointing out how they don't do X. Your customer will probably want his site to be like the big players' web sites.
If he still insists that his weird design makes sense you could say: "yes, I agree that sounds like a good idea in theory, but the fact is that users are simply unaccustomed to X and would walk away from your website if it diverges too widely from the standard way of doing things".
IOW, when all else fails, use fear.
You can lead a horse to water, but you can't make it drink.
With customers (of any type), the best you can do is inform them of their choices, and why they are not the best ones and then leave it. If it's really bad, require sign-off stating that they find that design acceptable. Do you want to be 'right' or do you want to get something into the customer's hands that works?
If it completely impedes a working solution, then (and only then) should you stand on principle, but beware you have very few (if any) of these 'stands', so use them wisely. Be prepared to walk away.
Paul.
Unless there is a compelling business case NOT to do it (and I'm not sure this is the case with any of your examples) then if the customer is adamant DO IT! They are paying for it after all. They can always find someone else who will do it if you won't!