Not necessarily. Suppose that the database lookup gives erroneous results with probability (let's say) 10^-6 (for whatever reasons). Then if you are entering 1000 cars manually, you will have on average less than 1 false positive per year. If you harvest 10M license plates per day, you will be getting an average of 10 false positives *daily*. People are not going to be pleased by false accusations...
Not at all. Robot is derived from "robota", which is an old Czech word meaning just "work" (derived from "robit" meaning "to work"). In the middle ages, its meaning shifted to mean "mandatory work for the feudal lord", regardless of whether the subject was a free man or a serf (there were no slaves in Czech kingdom at that time). Contemporary meaning is just "any hard work".
Not exactly. Nobody but you can verify that the vote whose ID you present was really cast by you. When asked for a signed vote, you can just pick one randomly from the public log.
This assumes that the certificates on the devices are configurable. Alas, on many real devices they aren't - just a self signed cert generated by the device's firmware.
Fine, so we finally have good motivation for the manufacturers to stop trying to trick the customers by selling different products under the same name;-)
I still prefer having my e-mail dropped by sites with silly administrators to having random legitimate e-mail dropped by my GMail account just because GMail uses an over-paranoid spam filter which cannot be tuned to my needs.
In 2007, Wikipedia's english site had 1.5 million articles; in 2015 it had 4.6 million. That's three times as many individual articles, with every edit to every article stored forever. The number of pieces and sheer amount of data stored and indexed is a complex, temporal function. For the number of articles, it's (time x rate[article creation]); for the number of pieces of data created, it's (time x rate[edits per article] x articles). Because the number of articles is increasing over time, you're looking at an exponential growth function. Note that it's exponential and not geometric because the rate of edits is related to a polynomial exponent of t, since the number of edits per time increases with time thus (t*(t*r)).
Wrong. Even if I don't dispute your assumptions (constant rate of new article creations, constant rate of edits per article), the resulting function is quadratic, not exponential.
Also, the majority of historic versions is probably seldom viewed, so they do not contribute to site load much.
This does not seem to be likely, though. As far as I know, there is no polynomial-time quantum algorithm for solving the Traveling Salesman Problem, or any other NP-complete problem.
I accept that some security bugs can be hard to fix. Still, it gives a clear message about the values held by the organization if copying Chrome's UI has higher priority than fixing security bugs.
The single fact that there was a high-security bug unfixed for at least 335 days (as admitted by Mozilla's FAQ) tells that there was something very seriously wrong in Mozilla's handling of security vulnerabilities. That is the reality and it should be passed around.
Unfortunately, DMARC breaks even mailing-lists which do not tamper with the contents of the messages at all. The reason is simple: SPF. Rewriting envelope senders is the proper way of forwarding mail since ages.
If you want to have proper integrity checks of e-mail messages, use PGP, not DMARC.
What they mention is not a list of solutions, but a list of silly work-arounds, which break well-established semantics of e-mail headers. Falsifying information about the author of the message (that is, the From header) for the sole sake of making the message compatible with DKIM is broken.
A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell.
I am not a huge fan of systemd, but init scripts written in shell are a nightmare.
PDF::API2 is nice, but unfortunately it doesn't handle newer PDFs with compressed xrefs and/or object streams yet. Also, support for writing text in anything different from ASCII and maybe Latin-1 is close to missing.
I think part of the rationale is that a self-signed certificate very well might be a sign that you're the victim of a man-in-the-middle attack, and it needs to be treated as a serious potential threat.
This sounds good in theory, but the reality is that self-signed certificates (or those signed by an authority your browser does not recognize) are several orders of magnitude more common than MiTM attacks.
Otherwise, I agree that a big part of the problem is unusable UI for managing certificates in almost all existing browsers.
I expect the browser to clearly inform the user whether the connection is safe (HTTPS with a verified certificate) or unsafe (either plain HTTP, or HTTPS with an unknown certificate). I also expect the user to check that a connection to his bank is reported as safe.
If you are interested in preventing attacks against careless users, the browser might also notify the user that a site previously known to have a safe connection, no longer has one. However, I do not think this is of much help: many users just enter the domain name of their bank and rely on the bank to redirect the HTTP version to the HTTPS one, which is where a MiTM attacker can always succeed.
(An interesting special case is invalid certificates: expired ones, or certificates issued for a different domain. Here, a big fat warning could be appropriate.)
Is "as bad as no encryption" a reason for yelling on the user and presenting it like the worst security problem ever? Even if I accept the premise that it is as bad as no encryption, the obvious conclusion is that the browser should present it the same as no encryption.
Actually, it is not as bad. It still keeps you safe from passive attacks (like your ISP collecting all data for a three-letter agency, which analyses them later).
Actually, people with exceptionally good problem-solving abilities seldom have exceptionally high scores in IQ tests, since they often find multiple solutions to a task, totally unexpected by the test's author.
Using threads with locks and other traditional synchronization primitives is a walk across a minefield. More than 90% of multi-threaded programs I've ever seen are full of race conditions and other subtle bugs, which are not easily visible, but which make the program unstable on the long term (it is not unusual that a program suddenly deadlocks after running for several months). If you really want to write something parallel, use a language which provides a better abstraction, one of the possibilities is transactional memory.
The core of the problem is that GNOME developers have the habit of releasing as 2.0 or 3.0 something, which is of beta quality at best. It's quite possible that GNOME 3 contains some great ideas, but trying to attract users to software, which will need a year or two more to reach usability of the previous version, is not going to win anybody's sympathies. Exactly this has already happened with the release of GNOME 2.0: its usability was nowhere near that of GNOME 1.x, but still, it was presented as a replacement of 1.x. The users were rightfully complaining. One would have hoped that GNOME developers have learned something from that fiasco...
As of culture resistant to changes: For most people, the computer is a tool. And as with many complex tools, it takes time (sometimes years) to learn how to use them in the most efficient way. The learned experience is very valuable, but a part of it is necessarily lost when the tool suddenly starts behaving differently (people are not used to their screwdrivers changing shape overnight). Sure, changes are necessary for progress, but you should not ignore that changes come with a high cost to the users and radical changes of basic concepts even more so. Changing details is usually fine, removing functionality is worse, and radical changes of established products should be done only in cases, where the benefit is an order of magnitude larger than the loss. GNOME developers seem to ignore this fact of life for years.
UEFI Secure Boot solves a security problem which, while being real, is completely marginal in real world. The extra complexity with key management is simply not worth the gain. There is a zillion of places where you can improve real security of systems at much smaller cost.
Slashdot Mirror
Not necessarily. Suppose that the database lookup gives erroneous results with probability (let's say) 10^-6 (for whatever reasons). Then if you are entering 1000 cars manually, you will have on average less than 1 false positive per year. If you harvest 10M license plates per day, you will be getting an average of 10 false positives *daily*. People are not going to be pleased by false accusations...
Not at all. Robot is derived from "robota", which is an old Czech word meaning just "work" (derived from "robit" meaning "to work"). In the middle ages, its meaning shifted to mean "mandatory work for the feudal lord", regardless of whether the subject was a free man or a serf (there were no slaves in Czech kingdom at that time). Contemporary meaning is just "any hard work".
Not exactly. Nobody but you can verify that the vote whose ID you present was really cast by you. When asked for a signed vote, you can just pick one randomly from the public log.
This assumes that the certificates on the devices are configurable. Alas, on many real devices they aren't - just a self signed cert generated by the device's firmware.
Fine, so we finally have good motivation for the manufacturers to stop trying to trick the customers by selling different products under the same name ;-)
I still prefer having my e-mail dropped by sites with silly administrators to having random legitimate e-mail dropped by my GMail account just because GMail uses an over-paranoid spam filter which cannot be tuned to my needs.
In 2007, Wikipedia's english site had 1.5 million articles; in 2015 it had 4.6 million. That's three times as many individual articles, with every edit to every article stored forever. The number of pieces and sheer amount of data stored and indexed is a complex, temporal function. For the number of articles, it's (time x rate[article creation]); for the number of pieces of data created, it's (time x rate[edits per article] x articles). Because the number of articles is increasing over time, you're looking at an exponential growth function. Note that it's exponential and not geometric because the rate of edits is related to a polynomial exponent of t, since the number of edits per time increases with time thus (t*(t*r)).
Wrong. Even if I don't dispute your assumptions (constant rate of new article creations, constant rate of edits per article), the resulting function is quadratic, not exponential.
Also, the majority of historic versions is probably seldom viewed, so they do not contribute to site load much.
This does not seem to be likely, though. As far as I know, there is no polynomial-time quantum algorithm for solving the Traveling Salesman Problem, or any other NP-complete problem.
Well, yes and no... Within a year, almost anybody can learn to fix a garbage collector.
I accept that some security bugs can be hard to fix. Still, it gives a clear message about the values held by the organization if copying Chrome's UI has higher priority than fixing security bugs.
The single fact that there was a high-security bug unfixed for at least 335 days (as admitted by Mozilla's FAQ) tells that there was something very seriously wrong in Mozilla's handling of security vulnerabilities. That is the reality and it should be passed around.
Unfortunately, DMARC breaks even mailing-lists which do not tamper with the contents of the messages at all. The reason is simple: SPF. Rewriting envelope senders is the proper way of forwarding mail since ages.
If you want to have proper integrity checks of e-mail messages, use PGP, not DMARC.
What they mention is not a list of solutions, but a list of silly work-arounds, which break well-established semantics of e-mail headers. Falsifying information about the author of the message (that is, the From header) for the sole sake of making the message compatible with DKIM is broken.
That's a noble goal. Do you have any examples?
A traditional init script is just a shell script, including almost invariably a couple of nasty race conditions and other subtle bugs. Starting and stopping a daemon safely is close to impossible in shell. I am not a huge fan of systemd, but init scripts written in shell are a nightmare.
PDF::API2 is nice, but unfortunately it doesn't handle newer PDFs with compressed xrefs and/or object streams yet. Also, support for writing text in anything different from ASCII and maybe Latin-1 is close to missing.
SAT solvers usually guarantee that their result is correct. What they don't guarantee is that they finish in reasonable time for every input.
Is it more likely that:
c) One of the groups had better teachers, so they learned more.
Actually, this is a very common reason. In such cases, I don't see why should the better group get the same grades as the other one.
I think part of the rationale is that a self-signed certificate very well might be a sign that you're the victim of a man-in-the-middle attack, and it needs to be treated as a serious potential threat.
This sounds good in theory, but the reality is that self-signed certificates (or those signed by an authority your browser does not recognize) are several orders of magnitude more common than MiTM attacks.
Otherwise, I agree that a big part of the problem is unusable UI for managing certificates in almost all existing browsers.
I expect the browser to clearly inform the user whether the connection is safe (HTTPS with a verified certificate) or unsafe (either plain HTTP, or HTTPS with an unknown certificate). I also expect the user to check that a connection to his bank is reported as safe. If you are interested in preventing attacks against careless users, the browser might also notify the user that a site previously known to have a safe connection, no longer has one. However, I do not think this is of much help: many users just enter the domain name of their bank and rely on the bank to redirect the HTTP version to the HTTPS one, which is where a MiTM attacker can always succeed. (An interesting special case is invalid certificates: expired ones, or certificates issued for a different domain. Here, a big fat warning could be appropriate.)
Is "as bad as no encryption" a reason for yelling on the user and presenting it like the worst security problem ever? Even if I accept the premise that it is as bad as no encryption, the obvious conclusion is that the browser should present it the same as no encryption.
Actually, it is not as bad. It still keeps you safe from passive attacks (like your ISP collecting all data for a three-letter agency, which analyses them later).
Actually, people with exceptionally good problem-solving abilities seldom have exceptionally high scores in IQ tests, since they often find multiple solutions to a task, totally unexpected by the test's author.
Using threads with locks and other traditional synchronization primitives is a walk across a minefield. More than 90% of multi-threaded programs I've ever seen are full of race conditions and other subtle bugs, which are not easily visible, but which make the program unstable on the long term (it is not unusual that a program suddenly deadlocks after running for several months). If you really want to write something parallel, use a language which provides a better abstraction, one of the possibilities is transactional memory.
The core of the problem is that GNOME developers have the habit of releasing as 2.0 or 3.0 something, which is of beta quality at best. It's quite possible that GNOME 3 contains some great ideas, but trying to attract users to software, which will need a year or two more to reach usability of the previous version, is not going to win anybody's sympathies. Exactly this has already happened with the release of GNOME 2.0: its usability was nowhere near that of GNOME 1.x, but still, it was presented as a replacement of 1.x. The users were rightfully complaining. One would have hoped that GNOME developers have learned something from that fiasco...
As of culture resistant to changes: For most people, the computer is a tool. And as with many complex tools, it takes time (sometimes years) to learn how to use them in the most efficient way. The learned experience is very valuable, but a part of it is necessarily lost when the tool suddenly starts behaving differently (people are not used to their screwdrivers changing shape overnight). Sure, changes are necessary for progress, but you should not ignore that changes come with a high cost to the users and radical changes of basic concepts even more so. Changing details is usually fine, removing functionality is worse, and radical changes of established products should be done only in cases, where the benefit is an order of magnitude larger than the loss. GNOME developers seem to ignore this fact of life for years.
UEFI Secure Boot solves a security problem which, while being real, is completely marginal in real world. The extra complexity with key management is simply not worth the gain. There is a zillion of places where you can improve real security of systems at much smaller cost.