Community, Firefox has a new function . Called fingerprinter (settings under privacy).
I know what fingerprinting means. What I like to ask you is: what is Firefox doing exactly when this feature is activated, what data is being changed by this setting?
Because when you do a test on panopticlick.eff.org, in both cases, active/inactive fingerprinter setting, you still get a unique html canvas hash assigned to you.
So, what is firefox exactly "preventing" or "changing" by this fingerprinter setting then?
And can you give your short opinion: is it better to activate this new fingerprint setting, or not? If you like to be "less" easier identifiable during web surfing? I have read differing opinions. There are those who say if you block fingerprinting you look more "unique", and those who say, If you allow fingerprint, you "less unique" in the masses...
Thanks all!
Browser finger printers are a subset of trackers that allow sites to gather a certain amount of information about a visitor’s browser and device, even without the use of a cookies.
Firefox new feature can help you block fingerprinting coming from many ad trackers.
Keep in mind blocking fingerprinting may cause some sites to break or make them look strange, or the layout will be different. It can also slow down your online experience.
Related
Every now and again I get asked to install something like this on a customer web server, or we're asked if we support BrowserHawk (which we don't).
I'm wondering if Modernizr is something I can point my customers at and tell them to use instead?
I've not used Browserhawk (in fact, I'd never heard of it until now), so please don't take my opinion as infallible.
However, I do know about browsecap.ini, and having taken a few moments to read the Browserhawk website, I'm fairly certain it's also a server-side browser detection tool.
If that's the case, then the answer is 'Yes'. Current best practice says to avoid using server-side browser detection, and to use client-side feature detection instead. And this is exactly what Modernizr does.
Feature detection allows you to do much finer-grained tuning of your site according to what the user's browser is capable of, rather than simply blocking users who have (or don't have) a particular browser. It also allows you to implement specific fall-back solutions for specific features, if required.
Detecting the user's browser from the server-side is a problem because of the rapid pace of change in the browser market; you would need to be constantly updating your browser detection script to cope with new versions.
In addition, users of slightly more unusual browsers or browser shells may not be detected properly by a browser detection script, so they may have trouble with sites that use it, even though their browser should be capable of displaying the site. Also, some users may not provide the user-agent string required to correctly detect their browser; it is blocked by some proxies, firewalls, etc, and some browsers also allow it to be modified, so it can be spoofed easily if a user wants to.
But having gone to lengths to promote feature detection over browser detection, I need to point out one exception to all of this, and that's IE.
Older versions of IE have a lot of bugs. This is different to simply having missing features, because you can't actively check for bugs so easily. If you're having specific issues with IE bugs, then it is legitimate to do browser detection to avoid them. (feature detection is still valid if you're only worried about what the browser supports, rather than actual bugs)
But even in this case, a tool such as browsercap.ini or Browserhawk is unnecessary. IE helpfully supports Conditional Comments which allows you to add specific code for IE without having to go out of your way to detect it.
I'm developer of Construct 2, a HTML5 game editor for Windows. It's at http://www.scirra.com.
Recently I've been trying to add a feature that will modify an image by transforming it on a canvas. It's pretty straightforward - draw an Image to the canvas and call getImageData() to get the pixels.
When the user clicks 'preview' in our application, all the files are dumped to a temp file on disk and a browser launched to show it. Uploading to a server is not an option for previewing - some games are megabytes big.
However most browsers block you using getImageData() to get the pixels of any image loaded from disk at all. I've tried putting all the necessary image files in subdirectories as MDN suggests in its description of file:// access policies. That doesn't work either!
Chrome's --allow-file-access-from-files flag fixes it. However, I need to support all major browsers. Is there a similar workaround for at least Internet Explorer and Firefox? I have no idea about Internet Explorer, and I really wish there's something which doesn't involve manually going to about:config in Firefox, otherwise we will be deluged in support requests asking "why doesn't it work in Firefox?!".
Also, why on earth is this security policy necessary?!? It seems way over the top and makes applications like ours really difficult to write.
Any help appreciated.
Your name sounds familiar from HN.
This is pretty laid out in stone in the spec by now, though this upsets an awful lot of people. http:// and file:// are different origins, and anything that tries to put one on the other will dirty the origin. As you noted file uri's themselves have their own set of rules that make things even trickier.
Drawing something to a canvas whose origin is not the same? Too bad, the origin-clean flag henceforth is false, which then disallows you from doing various things.
A complete list of those things is located in the spec here.
But I'm sure you know all this by now. You want to get around it.
I'd suggest ins instead of trying to strong-arm the browsers around it, you bundle in some kind of lightweight web service so that things are all appearing from the same origin. It will cause a lot fewer headaches in the future.
You'll probably want something like the Python SimpleHTTPServer. But that decision really depends on what you've already got included in your product already at this point.
I imagine there must be out there a website that collects information about HTML 5 feature and what browsers version started to support them.
This might be a good way to decide based on your website profile, if you can apply that HTML 5 feature without a fallback for your visitors.
Do you know such a site/resource ?
For example I want to know what browsers support the multiple upload feature for inputs and what browser version was the first.
Update
I'm not pleased with the sites suggested so I'm opening a bounty.
Suggestions so far: Html5Test, Caniuse, modernizr.com, QuirksMode
Update 2
Some people don't understand the question. I need to implement the multiple upload feature. I know from analytics what browser are they using ( I know this is not 100% correct ).
I'm willing to sacrifice some of the visitors by not offering some advance features but I need to understand how big is this procent. I'm NOT trying to DETECT in anyway the browser. It's a similar approach with other sites that dropped IE 6 support.
So please don't talk about bad practice.
Try to look at Html5Test or caniuse.
If it's server side, you can analyze user agent to find out if client's version supports HTML5. Wikipedia is your friend.
If it's client side, there's Modernizr library.
A quick search gave me this interesting result (reproduced in several blogs): http://www.findmebyip.com/litmus/
And you can may also want to take a look at this list of how to detect each feature: http://diveintohtml5.ep.io/everything.html
Here is another website, quite incomplete but verbose and "work in progress" as of March 2011, so it might be worth keeping an eye on: http://html5accessibility.com/
This one is off topic, but since I found it, I add it. CSS compatibility in IE browsers (very extensive): http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx
And here you can find info specific to the gecko engine: https://developer.mozilla.org/en/HTML/HTML5
And, of course, MDC has compatibility tables for each feature, but separated in different pages, not as a table, e.g.: https://developer.mozilla.org/en/HTML/Element/input
http://www.modernizr.com/
HTML5Test.com collects the information but they don't give detailed reports for perusal.
A good reference site for some stuff is http://www.browserscope.org/ but that doesn't go into a lot of detail with HTML5 specific support
Another source of related stuff is http://w3c-test.org/html/tests/reporting/report.htm which is creating a set of HTML testing tools that can be run.
You or someone who wanted to create this information could use these tests and then store the UA String of each browser that hit the site with the results of each test.
Then you could just find the earliest version of each browser type that a feature successfully run on.
I think this information is stored in the databases of the sites mentioned but they just don't display it which sort of sucks. Maybe try emailing them and suggesting they add these reports.
Take a look at caniuse.com, it’s exactly what you are searching for.
QuirksMode is also a great resource, and there is an entry for multiple files input.
My vote is for:
http://www.findmebyip.com/litmus
Which i found via this blog:
http://www.deepbluesky.com/blog/-/browser-support-for-css3-and-html5_72/
You should try this website. I hope this is what you were looking for.
I would like to know if it is possible to modify Chrome or Firefox display settings, so that it would only show rectangles of HTML DOM objects? What I want to do is to decrease rendering engine job amount as much as possible, so it would only build layout of the page.
People usually refer to this mode of operation as "headless" (i.e. without UI).
Usually there's an additional requirement - to be able to run it server-side without the usual for client software installed. If you're running it client-side, I wouldn't bother about optimization, it shouldn't give you a big win anyway.
Otherwise, try searching using that term. I've seen it asked for several times, but haven't seen a working out-of-box solution.
[edit] just saw http://hg.mozilla.org/incubator/offscreen, which seems to be a headless version of Mozilla.
I wouldn't go as low-level as modifying the renderer. Instead, I suggest you use Firefox's Greasemonkey to replace the elements from the page with whatever it is you need. You'll need to know a bit of JavaScript, but it's not that hard.
However, this will only work on client side. If you want to do this on server-side ( so that it will work on any page a user requests through your own ), my guess is you'll need to grab the page's content in a string, and then modify it using a HTML parser.
While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.