Don't be absurd. Unless you're browsing on, idunno, OpenBSD with lynx, there are _myriad_ ways to track you through the CDNs and ad networks. Think about it [if you don't know much about networking, HTTP, HTML, javascript, flash, silverlight, java, then sorry, don't think about it; just trust me:)]
Networking: I just hope my ISP doesn't collect marketing data from me. However if I really were paranoid, there are ways to hide the information from the ISP, too (e.g. TOR). HTTP: Thanks to AdBlock and RequestPolicy, the advertisers don't get the http requests from me. HTML: Well, that's only interesting in that it can trigger HTTP requests and the other technologies you mentioned. JavaScript: There's NoScript for that. Flash: NoScript and/or Flashblock take care of that. Silverlight: I'm using Linux, therefore no issue.:-) But otherwise NoScript will take care about that, too. Java: See NoScript
That's also not 100% secure. Are you 100% sure there's nobody ad fedex who might open that fedex letter, copy the key, and then close the letter again? And sending a messenger isn't secure either: How do you know the messenger wasn't bribed by Eve to give her a copy of the key? Even if you personally go there, there may still be some vulnerability. E.g. if you can't go there in one day and sleep in a hotel, someone at the hotel might copy the key while you sleep.
Yes, it's getting increasingly improbable, but the probability never goes to zero. On the other hand, costs go up, and as soon as the cost is larger than the cost of a stolen key, you'll simply not use that method.
Yes, NoScript blocks Flash. But... if you want to make an exception and allow a site privilege to run scripts, Flashblock still disallows "random" flash.
NoScript has the option to block embedded content also from trusted sites. Now what it doesn't have is a third level, so you can distinguish between "Script but no Flash" sites and "Script and Flash" sites. So assuming that Flashblock has its own whitelist, that is, as I realize now, indeed some extra functionality I could get (although it's one I don't need).
Indeed, one could even completely make up citations. Such as:
Faster than light communication has been achieved with space probes [1] and is used to communicate with the Voyager probes [2].
[1] April Fool, "Practical FTL communication", Journal of space probe physics 23 (1933), p. 666 [2] James T. Kirk, "Communication with Voyager", Federation Journal of Physics 42 (2001), p. 4711
Why stop there? Just get the court out of the loop, and replace it by a Wiki page to describe the final judgement. Of course, in agreement with the Wiki principle, everyone can edit it.:-)
Been there, done that. The problem was that there were enough annoying ads that blocking annoying ads itself got annoying. So I now just block all ads and be done with it.
Well, I don't have problems with ads which are selected based on the content of the page I'm looking at (assuming it's not annoying in any other way; unfortunately so many ads are that I've given up manual ad blocking and use AdBlock Plus to automatically block all ads). Note that the content of the page is most likely interesting for me (otherwise I probably wouldn't look at it). If advertisers would stop trying to track me and would stop making ads annoying (and sites would stop putting ads in the middle of articles), I'd happily stop using AdBlock Plus.
Why do you need Flashblock if you already have NoScript? For me, NoScript blocks Flash quite fine. Any advantages I'm missing by not additionally using Flashblock?
BTW, one thing I don't see in your list is RequestPolicy. It by default blocks every content from third-party web sites, and allows you to make exceptions based on both source and destination.
Fortunately, AdBlock and similar options do a very good job of blocking that content. Unfortunately some ad revenue based companies have become smart enough to break their usability if the code sent by the ad tracking is missing. So sometimes you will need a "GreaseMonkey" to get around that but it can be done.
If the site is not usable to me, I won't use it. Why should I go to great lengths to find out what exactly breaks, and write a GreaseMonkey script to fix it? Unless the page is of great importance to me, I don't see why I should do that (the only GreaseMonkey script I've ever written was for Slashdot, at a time where I didn't yet block all ads, to kill a specific ad placement which broke the layout; since I didn't manage to correct the layout, I ended up simply reloading the page until another ad placement was chosen).
I use my iGoogle page at work as the personal front page to get what I want, even Slashdot RSS feeds. And the Buyer Zone pages come up on Google pages. I use iGoogle on my personal machine also.
An advertising company uses data you give them for advertising? Who would have thought!:-)
You know, if a doctor labels you a paranoid schizophrenic, he's obviously part of the conspiracy, and therefore not to trust. THEY are just trying to get you into a hospital where they have you under control. And don't forget: That you are paranoid doesn't imply THEY are not after you.:-)
Let's change the scenario a bit. What if you regularly used that ferry and the retargeting ad you were shown was for a monthly pass discount or something. Would that possibly be of value then?
While I'm not the OP, I can answer that for thinking myself in that situation. Ind I have to answer clearly: No. It would be of value to me if I get told about that monthly pass discount the next time I'm about to book the ferry, or in other words, the next time I open their page.
While it's not reliable in general, it is reliable in cases where you can easily check whether the information given to you is correct.
You realize you've just defined extracting information under torture as an NP-Complete problem... and then implied that this was the "easy" case.
Nowhere did I say or imply that it's the "easy case"; the only place I used "easy" was in the condition. What I said is it's the reliable case (i.e. the one where you can generally expect to eventually get some useful result).
Oh, and you mixed up "NP" and "NP-complete"; the latter means that it's not only NP, but you can reduce all NP problems to it. I don't think you can reduce the travelling salesman problem to torture.:-)
What would be nice is having "tab sessions": Opening a tab and declaring it to be a separate session. When closing that tab, the session ends, and all session cookies set from that tab are deleted. Or maybe do it on a window level (so that several tabs can share the same session). Indeed, for my usage of Firefox, even automatically treating each window as a separate session would work great.
Well, it's the first time I hear that name (which possibly is caused by the fact that I never booked a ferry to or from UK). Now if I ever look for ferries to UK, and I come across that name, it surely will look somewhat familiar to me, although I probably won't remember from where. Which might make it more probable that I look at that site.
There's no need for the web browser to run in a VM; it suffices if the plugins do. Then all file accesses of the plugins would go through the browser interfaces, and therefore the browser would be able to centrally control permissions.
Too bad for those using the Gitmo attack that torture isn't a reliable way to extract information.
While it's not reliable in general, it is reliable in cases where you can easily check whether the information given to you is correct. Which is the case for cryptographic keys, but not for the original message. Unless, of course, he doesn't have the key himself (I couldn't give you the key used for the latest https session with my bank, even if I wanted to; torture certainly wouldn't help either).
Actually, it should be quite easy to reveal that someone continuously shines a laser on your system. It's just that no one up to now thought about that possible attack vector, therefore no one tested for it. I'm pretty sure that future versions of the cryptographic device will detect that attack.
Besides detecting the laser directly, maybe a strategy to prevent this type of attack would be to generate additional quantum signals for Bob's detector inside Bob's device and testing that the detector correctly detects them (this would not only detect this specific attack, but any attack which turns Bob's detector into a classical one).
Every cryptographic security is only up to possible bugs in the implementation (remember the Debian ssh problem?), so exactly 100% security is impossible. However, one difference betweeen the classical and quantum case is that in the quantum case any possible exploit has to be "online" (i.e. you have to actually intercept the actual sent message and manage to manipulate the receiving system), while for classical key exchange the breaking can also be after the fact (i.e. if all you want is the exchanged information, you can passively record all data and then try to break it afterwards). This means that
all communications performed before that exploit was found remains secure (unlike classical protocols where you only need the recorded data to apply any exploit), and
since the attacker has to manipulate the systems during operation, as soon the exploit is known you can take additional measures in order to detect it (e.g. in this case, I think it should be quite easy to detect a relatively strong laser which is continuously shining at the receiving device), thus detecting whether someone tries to exploit it (unlike classical systems, where you have no clue if someone tries to attack your cryptographic system). That is, instead of replacing your whole cryptographic infrastructure (which may be expensive), you can simply add detectors for the manipulation needed for the exploit, so that you only transmit confidential information in case the exploit isn't applied.
As the article mentions, the commercial systems add the quantum cryptography on top of the classical cryptography. So if the quantum cryptography is broken, you still have the security of the classical system. On the other hand, if the classical system used is broken (be it because the underlying cryptographic scheme is broken, or be it by exploiting a bug in the specific implementation) then you still have the security of the quantum cryptography.
How exactly would they check it out? Check that there are indeed bots contacting your server? It should not be hard for the criminal to add your server to some bot's list of servers to contact (the bot will not get any useful response from your server, but that's no problem, the bot will simply ignore any useless replies). How is the provider to distinguish https requests which return useful commands for the botnet from https requests which don't? Note that any user-facing web server handling confidential data will have to accept HTTPS requests.
It's damn easy. If someone needs permission from you to do something, and you don't want them to do it, then don't give them the permission to do it. You can't give them the permission and then complain that they do what you explicitly permitted them to do. And yes, a license is just that: A (conditional) permission to do something.
Slashdot Mirror
AFAIK PDFs are allowed to contain TrueType fonts.
Would using Core Text imply licensing costs?
Don't be absurd. Unless you're browsing on, idunno, OpenBSD with lynx, there are _myriad_ ways to track you through the CDNs and ad networks. Think about it [if you don't know much about networking, HTTP, HTML, javascript, flash, silverlight, java, then sorry, don't think about it; just trust me :)]
Networking: I just hope my ISP doesn't collect marketing data from me. However if I really were paranoid, there are ways to hide the information from the ISP, too (e.g. TOR). :-) But otherwise NoScript will take care about that, too.
HTTP: Thanks to AdBlock and RequestPolicy, the advertisers don't get the http requests from me.
HTML: Well, that's only interesting in that it can trigger HTTP requests and the other technologies you mentioned.
JavaScript: There's NoScript for that.
Flash: NoScript and/or Flashblock take care of that.
Silverlight: I'm using Linux, therefore no issue.
Java: See NoScript
That's also not 100% secure. Are you 100% sure there's nobody ad fedex who might open that fedex letter, copy the key, and then close the letter again? And sending a messenger isn't secure either: How do you know the messenger wasn't bribed by Eve to give her a copy of the key? Even if you personally go there, there may still be some vulnerability. E.g. if you can't go there in one day and sleep in a hotel, someone at the hotel might copy the key while you sleep.
Yes, it's getting increasingly improbable, but the probability never goes to zero. On the other hand, costs go up, and as soon as the cost is larger than the cost of a stolen key, you'll simply not use that method.
NoScript has the option to block embedded content also from trusted sites. Now what it doesn't have is a third level, so you can distinguish between "Script but no Flash" sites and "Script and Flash" sites. So assuming that Flashblock has its own whitelist, that is, as I realize now, indeed some extra functionality I could get (although it's one I don't need).
Indeed, one could even completely make up citations. Such as:
Faster than light communication has been achieved with space probes [1] and is used to communicate with the Voyager probes [2].
[1] April Fool, "Practical FTL communication", Journal of space probe physics 23 (1933), p. 666
[2] James T. Kirk, "Communication with Voyager", Federation Journal of Physics 42 (2001), p. 4711
Why stop there? Just get the court out of the loop, and replace it by a Wiki page to describe the final judgement. Of course, in agreement with the Wiki principle, everyone can edit it. :-)
Been there, done that. The problem was that there were enough annoying ads that blocking annoying ads itself got annoying. So I now just block all ads and be done with it.
Well, I don't have problems with ads which are selected based on the content of the page I'm looking at (assuming it's not annoying in any other way; unfortunately so many ads are that I've given up manual ad blocking and use AdBlock Plus to automatically block all ads). Note that the content of the page is most likely interesting for me (otherwise I probably wouldn't look at it). If advertisers would stop trying to track me and would stop making ads annoying (and sites would stop putting ads in the middle of articles), I'd happily stop using AdBlock Plus.
Why do you need Flashblock if you already have NoScript? For me, NoScript blocks Flash quite fine. Any advantages I'm missing by not additionally using Flashblock?
BTW, one thing I don't see in your list is RequestPolicy. It by default blocks every content from third-party web sites, and allows you to make exceptions based on both source and destination.
If the site is not usable to me, I won't use it. Why should I go to great lengths to find out what exactly breaks, and write a GreaseMonkey script to fix it? Unless the page is of great importance to me, I don't see why I should do that (the only GreaseMonkey script I've ever written was for Slashdot, at a time where I didn't yet block all ads, to kill a specific ad placement which broke the layout; since I didn't manage to correct the layout, I ended up simply reloading the page until another ad placement was chosen).
Just make sure that you don't look too long at any whorehouse in StreetView, even if the house's architecture happens to be interesting. :-)
An advertising company uses data you give them for advertising? Who would have thought! :-)
You know, if a doctor labels you a paranoid schizophrenic, he's obviously part of the conspiracy, and therefore not to trust. THEY are just trying to get you into a hospital where they have you under control. And don't forget: That you are paranoid doesn't imply THEY are not after you. :-)
While I'm not the OP, I can answer that for thinking myself in that situation. Ind I have to answer clearly: No. It would be of value to me if I get told about that monthly pass discount the next time I'm about to book the ferry, or in other words, the next time I open their page.
While it's not reliable in general, it is reliable in cases where you can easily check whether the information given to you is correct.
You realize you've just defined extracting information under torture as an NP-Complete problem... and then implied that this was the "easy" case.
Nowhere did I say or imply that it's the "easy case"; the only place I used "easy" was in the condition. What I said is it's the reliable case (i.e. the one where you can generally expect to eventually get some useful result).
Oh, and you mixed up "NP" and "NP-complete"; the latter means that it's not only NP, but you can reduce all NP problems to it. I don't think you can reduce the travelling salesman problem to torture. :-)
What would be nice is having "tab sessions": Opening a tab and declaring it to be a separate session. When closing that tab, the session ends, and all session cookies set from that tab are deleted. Or maybe do it on a window level (so that several tabs can share the same session). Indeed, for my usage of Firefox, even automatically treating each window as a separate session would work great.
Well, it's the first time I hear that name (which possibly is caused by the fact that I never booked a ferry to or from UK). Now if I ever look for ferries to UK, and I come across that name, it surely will look somewhat familiar to me, although I probably won't remember from where. Which might make it more probable that I look at that site.
There's no need for the web browser to run in a VM; it suffices if the plugins do. Then all file accesses of the plugins would go through the browser interfaces, and therefore the browser would be able to centrally control permissions.
Or use an ad blocker. Or do both.
While it's not reliable in general, it is reliable in cases where you can easily check whether the information given to you is correct. Which is the case for cryptographic keys, but not for the original message. Unless, of course, he doesn't have the key himself (I couldn't give you the key used for the latest https session with my bank, even if I wanted to; torture certainly wouldn't help either).
Actually, it should be quite easy to reveal that someone continuously shines a laser on your system. It's just that no one up to now thought about that possible attack vector, therefore no one tested for it. I'm pretty sure that future versions of the cryptographic device will detect that attack.
Besides detecting the laser directly, maybe a strategy to prevent this type of attack would be to generate additional quantum signals for Bob's detector inside Bob's device and testing that the detector correctly detects them (this would not only detect this specific attack, but any attack which turns Bob's detector into a classical one).
Well, there are several points here:
How exactly would they check it out? Check that there are indeed bots contacting your server? It should not be hard for the criminal to add your server to some bot's list of servers to contact (the bot will not get any useful response from your server, but that's no problem, the bot will simply ignore any useless replies). How is the provider to distinguish https requests which return useful commands for the botnet from https requests which don't? Note that any user-facing web server handling confidential data will have to accept HTTPS requests.
It's damn easy. If someone needs permission from you to do something, and you don't want them to do it, then don't give them the permission to do it. You can't give them the permission and then complain that they do what you explicitly permitted them to do. And yes, a license is just that: A (conditional) permission to do something.