Vertically centered on Chrome Mac as well. Safari (and IE) still requires a vendor prefix to use flexbox, but with that added, it works in Safari as well:
The worst part about the DNT header was the requirement for the tracking companies to regulate themselves. Initially, the header was opt-in, but with the introduction of IE10, Microsoft decided that the option was going to be opt-out. Once the the DNT header was gaining traction and a not-so-small percentage of people began sending the header, the companies had no reason to comply, and the initiative sorta fell out of favor.
For blocking tracking, the most effective tools are browser extensions made to block ads. Ghostery provides comparisons on an non-biased website between the methods of blocking tracking through browser modifications [1]. According to the site, the Do Not Track header actually has an effect with a difference of 18% in cookie size when the header is set. AdBlock Edge and disabling third-party cookies results in a 59% and 40% decrease in cookie size respectively. It seems that the easiest thing you can do to lessen your internet footprint would be to disable third-party cookies and enable the DNT header, and the majority of tracking can be eliminated through the use of a browser extension. (But with the recent revelations [2], using a browser extension may actually reduce your browsing experience if you don't have the RAM to spare.)
> The worst part about the DNT header was the requirement for the tracking companies to regulate themselves. Initially, the header was opt-in, but with the introduction of IE10, Microsoft decided that the option was going to be opt-out.
Call me a conspiracy theorist, but being a former CTO of an adserving company, I feel qualified to at least voice my opinion: this was a brilliant move by Microsoft. The DNT header as it were, was a perfect middle-ground for advertising companies: people that cared enough were able to opt-out, and people that did not care would still be able to be tracked.
Google had the most to lose. I feel Microsoft made this decision in order to (accelerate the) kill of the DNT header, and thus hoping on more severe legislation.
I think you give them too much credit. I think Microsoft, having little to lose in the way of targeted advertising, simply wanted more people to use DNT to hurt or even just embarrass its competitors. I don't think they intended to torpedo the whole spec on purpose. (And, indeed, I don't see any severe legislation on the horizon)
Microsoft has torpedoes many specs in the past, intentionally. They are certainly in that business. There is no reason to doubt that an appearance of torpedoing a spec wasn't exactly that - its the simplest explanation.
There's definitely precedent for that behavior from Microsoft's side, obvious or not (a certain anti-trust case springs to mind). They have nothing to gain by being obvious about it, and everything to gain by being a whole lot more sneaky about it.
I'm not saying it's necessarily what happened with the DNT header, but they'd do well to avoid drawing too much attention to themselves in certain cases.
Well, no, because they actually want something like Do Not Track to succeed. The theory that they made it fail on purpose so that an even stronger version of the same idea will come about is definitely not the simplest explanation.
Wont you always be trackable by an heuristic approach?
I would expect that a fuzzy hash of your ip,location,language settings,resolution, browsertype, average mousespeed, your computers speed to draw a circle, calc a prime etc etc etc will always identify you.
So we ought to start considering whether those things should be permissible by default in browsers.
It used to be that sites could inspect the clipboard until we realised how bad for security that was. Perhaps mouse movement and/or timing information should be something that isn't allowed by default without granting the site additional permissions. Perhaps browsers could be set to stop sending many of the headers they currently send by default, or send approximations to reduce the uniqueness of the headers.
Two of the worst offenders are overly-specific user agents (a setting which should definitely be configurable) and list of plugins (which I see no reason for being available).
In Mozilla Firefox, you can create the setting general.useragent.override (it doesn’t exist by default) and set its value to “Firefox” to get a very generic user agent string that websites will still recognize as Firefox and not block as a bot.
Regarding plugins, the best solution I have found is to have none enabled. Firefox still sends them in the list when using click-to-play, so it is necessary to disable them completely.
As I said in my other comment, changing your user agent string affords you no privacy protection against those who care about knowing, and makes you more trackable.
Your browser (including the exact version) can be determined without looking at the user agent string (which is mostly a series of lies anyway). Changing it "for privacy" makes you easier to track.
As to the plugin list, you could make it non-enumerable, but then one could just probe for the X most common ones, like can be done for fonts.
I doubt it is possible to determine the exact version, or even the browser (though the accept headers might leak it), without JavaScript. Thus NoScript fixes that problem.
You are right that this gives more information to a determined person, but anyone who pushes fingerprinting to the point of detecting a user’s browser version and other characteristics through JavaScript will certainly be able to identify you uniquely anyway. In such a case, it doesn’t matter than this person has more or less information, since he can already identify you; and having a generic user agent makes people who only look at it know less about you.
It's possible to differentiate the major browsers and operating systems without javascript, and even the versions can be narrowed down without javascript even with user agent spoofing.
My opinion is that javascript should be opt-in. The idea that any junk website is allowed to execute code on your machine without asking or even the user being aware is a fundamental security flaw.
Opting in to javascript wouldn't make anyone any safer. You would literally have to manually inspect every line and re opt-in with every single request (since javascript can be dynamically generated per request) to even attempt to verify the safety of the code. Most people would simply be annoyed, and browser vendors would add opt-in by default as soon as possible, just to survive.
If you trust javascript that little, just turn it off entirely in your browser and let the rest of the web be. You're far, far more at risk from the browser itself, plugins and apps than from javascript.
>The idea that any junk website is allowed to execute code on your machine without asking or even the user being aware is a fundamental security flaw.
Ultimately then Javascript becomes useless, because 95% of clients will not have it enabled. This is why we have sandboxing, and very high browser bounties for any exploits that allow you to leave that sandbox. Is it perfect? Nope. But it's the best option to move forward safely in the web without going back in time 20 years.
Most of the web works fine, it does not break most sites the internet.
JS can be used to just do annoying crap, play sounds or videos, etc. I can choose to mute my entire browser or I can choose to not run JS on new sites until I approve of them. (This used to be more important before patches for js moving browser windows and the like)
While most JS wont break out of the browser in most cases, what you can do within the browser to determine where you have been, who you are, and (if you visit samy.pl) things like enumerating your local network or running a bitcoin miner with JS are possible.
> Most of the web works fine, it does not break most sites the internet.
While I agree with you in spirit, this doesn't seem to be true in practice. I also browse with JS turned off by default, and, in general, whenever I visit a new site, I often find it blank, or completely illegible. After allowing JavaScript for that site, I then often have to play a guessing game of what CDNs or other external resources I have to allow before anything will display. (For example, I was able to see weather on weather.com—hardly anyone's idea of a good Internet citizen, but the first one that springs to mind—simply by allowing JavaScript from their domain; but had to guess around quite a bit before I could get the settings icon to display.)
That is a really common idea here and a really arrogant one given how many SASS businesses wouldn't be possible without JS.
There were a time when the internet was about reading text, but that has long since passed. Without javascript you can't have a presentation overlayed with video (say of the presenter), you can't have real time anything, you can't comment without having to reload the page, etc. Look at how horrible the UX of HN is compared to reddit.
You would still be able to enable it if you think it's relevant and trust the website. But when I end up on a news website reading an article, I see no justification for having all these scripts from all these different untrusted sources executing in the background.
If plain HTML isn't good enough, it just means we need a better HTML.
> That is a really common idea here and a really arrogant one given how many SASS businesses wouldn't be possible without JS.
Why is it arrogant? Surely "my site won't work with your browser settings" is not inherently an argument that I have to change my browser settings!
I mean, you can say "by browsing with JavaScript off, you kill the rich web", but I can also say "by refusing to make available a plain-text version of your site, you kill the information web" (with whatever appropriate buzzwords substituted for my ungainly ones). Many of the same arguments here could, I think, have explained why Flash is absolutely necessary for the modern web—until Apple's weight showed that it isn't.
Actually the way DNT works is also its best attribute. I see more as an attempt that almost worked. It did sensibilize people and companies. Theres a want to not be tracked thats greater than it used to be.
Its not just a technical issue.
It seems that this also hashes the files to produce a fingerprint. Check out the fingerprinter [1] for the raw details on how it's done, but basically, if the file is below the "sparseFingerprintThreshold" of 5 MB, the whole file is hashed. Any file above is "sparsely hashed" where the first 512 KB, middle 512 KB, and end 512 KB are hashed and combined to produce the fingerprint for that file. It shouldn't produce any performance concerns on large files, so it should be safe to use for your movie collection.
Here's a working example that doesn't use tables: https://jsfiddle.net/q8zxxr3b/
Or, here's the inline example: