That article gives no reason to be worried about elliptical curves. What it does give reason to be worried about is magical constants and the use of asymmetrical primitives for something that can be done with symmetrical primitives. The concern about the magical constants is why some algorithms use digits of e or pi for the constants. And since random number generators can be build using symmetrical primitives, it is suspicious when somebody choose to use asymmetrical primitives. That later decision need to be accompanied by a new formal security definition and a proof that such security definition cannot be achieved using symmetrical primities.
The combination of asymmetrical primitives where none are needed and magical constants of unknown origin is extremely suspicious. Even if you cannot prove it to be the case, it seems very likely that those magical constants are in fact a public key, and somebody knows the corresponding secret key.
Which asymmetrical primitive they chose for the construction is of no importance to the story though.
This is also true with respect to DES, as in the case of 3DES, and you could easily create 5DES or 10DES or whatever by chaining cipher units with different keys which are each a portion of the combined key.
It's not only the key, which is too small. The blocksize is also too small. DES has a blocksize of only 64 bits. Even the 128 bit blocksize of AES is a bit on the short side. My rule of thumb for how many blocks of data you can safely encrypt with with a single key is two raised to one quarter of the blocksize. If the blocksize is 64 bits, that gives you 512KB, if the blocksize is 128 bits you can go all the way to 64GB. With typical full disk encryption schemes using a single AES key for an entire harddisk, which could be a few TB in size, I think this is something to be concerned about.
It is just a rule of thumb though. It is not like something happens as you cross that boundary. Whether you encrypt 63GB or 65GB with a single AES key doesn't make much of a difference in terms of security. The more data you encrypt with the same key, the larger the risk of collisions is. A collision is when you by chance encrypt the same input block twice, and when does happen the cipher blocks will be identical and leak information about the collision having happened. When you reach 64GB, the probability of such a collision is about 1 in 2^64. Having that probability go any higher than that is unreasonable for a 128 bit cipher, which is why I use the rule of thumb, that I do use.
If somebody were to encrypt all the information in the world using just a single AES key, it is not unlikely that the probability of a collision would be more than 50%.
Oh, and 10DES is not something, which would be used by anybody, who knows what they are doing. The number of times you use DES needs to be an odd number. The actual security is equivalent to the number of usages of DES divided by two and rounded up. That means 2DES is no more secure than DES, and 10DES is no more secure than 9DES. So you'd go with either 9DES or 11DES. Moreover you can replace every other DES with a simple XOR with a constant with almost no loss of security, you might even gain a little bit of security that way due the XOR using 64 bit of key material but a DES operation using only 56 bits.
So rather than using 10DES (with an actual keysize of 560 bits and an effective keysize of 280 bits) you could alternate between XOR and DES such that you have 6 rounds of XOR and 5 rounds of DES (with an actual keysize of 664 and an effective keysize of 360 bits). This approach with 6 rounds of XOR and 5 rounds of DES is almost twice as fast as 10DES and to the best of my knowledge also more secure.
You, the user, ask the browser to load a web-page and you complain that the browser following the instructions of said page is a browser bug?
If the instructions causes anything to happen which has an effect beyond the scope of that webpage, then it is a bug. Let's for a moment consider the consequences, if your reasoning was valid. A user follows a link to a webpage on a compromised server, the webpage instructs the browser to install a keylogger on the user's computer. Since the user decided to follow the link and since the webpage contained instructions to install a keylogger, then installing that keylogger is expected behaviour, and it is not a bug that the browser allowed this to happen. In what world is a browser supposed to prioritize the interests of a random webpage above the interests of the user?
I agree with everything you said, except from the maybe in the subject. To me there is no question, this belongs in the browser.
mute all tabs but currently focused tab
That's not the only restriction I would put on tabs not currently in focus. I'd also like to see limits on the amount of CPU time they can spend on executing javascript. I'd like to set a limit saying all unfocused tabs cannot use more than 10% of one CPU in total for executing javascript. Yes, even if there is idle CPU time I don't want unfocused tabs to use more CPU time than that, such that my computer doesn't heat up unnecessarily.
But it seems to be making up for the lack of options in the browser.
Absolutely. They should add such a feature to Chrome. It is even the same company. Why have one part of the company making up for lack of options in products from another part of the company? Wasn't the point of Chrome that Google wanted to be able to make websites without having to always work around bad browsers?
It is not up to the browser to fix the broken functionality of a website
No, but it is the browser's responsibility to ensure that a broken website cannot break anything but that website. The browser should not trust websites to be doing things right. Any functionality that can be used incorrectly by websites will be used maliciously.
If I am playing a video on YouTube it should not be possible for another website, which I have open in another tab to disturb that playback. In most browsers this can currently be violated by either playing sounds overlapping the sound I intended to hear as well as running some heavy javascript causing the playback to freeze shortly.
Any such behaviour is a browser bug, and it is only made worse by lack of indication of which site is responsible. Other bugs such as javascript breaking parts of the browser UI is often easier to pinpoint to a specific site. For example it is surprisingly easy to break the "Copy Link Location" feature in Firefox and equally easy to break the equivalent feature in Chrome.
Maybe nobody is supposed to figure out. There are plenty of cryptographic schemes, which Randall could be using, if he don't want anybody to figure out. It could be an HMAC computed using a key, which only Randall knows. An HMAC preserves all the collision resistance properties of the underlying hash, but cannot be computed by anybody without knowledge of the key. It might not be a hash function at all, but instead a block cipher applied to some data. It could also be completely random. It could also be that those strings are really a covert channel containing some other information.
The reason it hasn't been figured out could be that there is nothing to be figured out or because it was made impossible, it could also be an entire story is hidden in those strings. Randall only knows.
It seemed that you were trying to argue that the input was actually different.
No, I was arguing that the input was not actually accurate enough to do the calculation in the first place. Floating point numbers can handle much higher accuracy than the measurements used as input. By the time you notice the difference between two runs you are already way past the point were the output could be useful.
So there are two sources of errors. Inaccurate input data which leads to reproducible bad output. Rounding errors during calculation which is smaller and thus only becomes significant later. The inaccuracy of the output due to inaccurate input data cannot be seen by running the calculation twice with the same input data. But by comparing to the real world, it can be observed that it diverges from the calculation. That divergence can be caused by inaccurate input data, flaws in the algorithm, or simply by the real world having much higher granularity than the discrete datapoints used in the algorithm.
Divergence between two runs of the same algorithm on the same input data can be caused by a number of other factors. Such factors include different rounding due to differences in the platform being used (different hardware and/or software), or non-determinism due to timing in a distributed system. For example if a node receives three floating point numbers and add them, the sum can depend on which order the three numbers were received.
The differences due to rounding errors are however not of much practical interest. By the time they are large enough to notice, the errors due to inaccurate input are already too large for the output to be of practical interest.
unless you want to start to argue that computer hardware is non-deterministic.
Distributed systems are inherently non-deterministic. Moreover it says right there in the tittle, that the different results were produced on different computers.
No. You are assuming if both calculations produce the same result, then that result is correct. In reality, you can run the same calculation twice and get the same error.
If the rounding was behaving the same, we would expect the same output given the same program and input.
If you take the same source and compile it for two different systems, is it the same program? What the compiled program does is probably within the specs of the language.
If a system produces different output every time its run with the same input, then we have a useless system
That depends very much on what the purpose of the program is. I have worked with cryptography, and for most usages in that field, a program which produces the same output twice is unusable. A program which does floating point operations need to be done in a way, where you can figure out how large an error you get. Knowing the accuracy is more important than getting the same result twice. If you do get two different results from the same calculation, you can check if the difference is within the accuracy you were supposed to get.
as we cannot have any way of verifying that what is produced is correct. If you can't unit test the system, then you have a religion, not a scientific simulation.
The complete program is not one unit. You unit test individual units. And unit tests can deal perfectly well with units, where the spec allows for more than one possible output. The unit test just need to verify that the output is within spec. Testing for one specific output value is usable in some cases, but not always.
I'm no programming expert, but isn't this basically Computer Science 101 stuff?
All I was taught about floating point at that level was how wrong results we could get, and that we should avoid it. Several years later on a more advanced course, I learned about how to do floating point calculations, if you really need to.
I fail to see how the same program + same inputs == "differences in inputs cause most of the error"....
Inaccuracies in the input most likely did cause most of the error. Maybe nobody noticed because that error was the same in all the calculations. Eventually a difference between the calculations starting to build up because of differences in rounding between the different runs. This variation was noticed, but it would still be small compared to the differences caused by inaccuracies in the input. In short means by the time you notice the difference between two runs, both of them are already way off compared to the real value due to both of them having been working on the same inaccurate input.
If you want to do better, then do calculations with a representation that keeps track of uncertainty. Even in those cases where you cannot do a floating point operation and get an exact result, you can still do the calculation and know the possible range of the error. So each number is represented by a minimum and a maximum (or a mean and an error margin). As you do calculations the minimum and maximum values will be going further and further apart. Once they get too far apart, you know the results are no longer useful.
When you start the simulation, you initialize the numbers with an error margin corresponding to the accuracy of the measurements. Different runs on different platforms may not build up errors at the same rate, and that is something you can actually look at. If the ranges from two different runs no longer overlaps, then you know there is a bug somewhere. If one simulation says the air temperature is going to be be between -10 and +30 and the other simulation says it is going to be between 0 and +20, then they can both be right, but neither simulation result is particular useful. If one simulation says it is going to be between -10 and 0 and the other says it is going to be between +20 and +30, then you know at least one of them has a bug.
The function takes all the reservations requested within a five minute period and picks one at random. That ends the arms reservation-bot arms race
No, that doesn't end the arms race. It just changes it into a different arms race. It will no longer be about getting there first but rather about putting in the largest number of reservations within a five minute window.
That works if you're just in it to make a profit, and don't care about who is able to come to the restaurant.
As in any other sort of business, if it turns out to be less fun than you envisioned but more profitable, then you can just keep making lots of profit until you have enough money to go and build what you really want to do. It is rare to hear about people who were unable to realize their dreams because they had too much money.
You speak as if all companies are equally bad. Somehow, I think you're either young or more sheltered than you believe you are.
When I was young and naive, I thought if I discretely told companies about security problems in their products, they would thank me and fix it. In reality that has never happened in any of the cases, where I have reported a security problem to a company.
In the real world the majority of companies will do nothing about a security bug unless they face an immediate threat of the information becoming public. As a security researcher, it is sensible to assume any company will behave like that, until proven otherwise.
This puts the few companies, which takes security seriously, in a bad position. They have to differentiate themselves from the rest of the industry to even get security researchers to take them seriously. One way to differentiate yourself is by offering bug bounties. The added benefit from offering bug bounties is that the company get to set rules about disclosure which must be followed to qualify for a bounty.
Use mdadm -C -b internal to create a bitmap. Detach and readd the mirror at will and it will only sync the difference.
I am going to test this on my next laptop, or if I decide to upgrade my current with an SSD some day.
Meanwhile, I do have a couple of questions. How automated is this going to be? Will it automatically start to sync, once the USB/eSata disk is connected?
Can I safely attach that disk to another computer for reading? I am worried such operation might corrupt data, even if I don't write anything. If I connect the external disk to a workstation, do I risk that the RAID layer will declare the SSD to be dead and record this fact on the external disk? Is reading from the external disk going to perform a journal replay and thereby perform some unintended writes? Is the raid layer going to increase the event counter on the external disk and potentially run past the SSD or end up at the same event counter due to the same number of cycles, but on different machines?
In a few man-years of smart peoples' times, spread out over a couple of seconds per person, almost nothing of worth could have been accomplished.
No, but those few seconds are being taken away from the time they could have spend on something else. If you will try to argue that it makes no difference if a smart person is going to spend say eight hours on a task or eight hours minus a couple of seconds, then you would be wrong.
I agree one smart person is unlikely to achieve anything great in a couple of seconds. But they could achieve something in eight hours. Could they have achieved the same in eight hours minurs a couple of seconds? There is a good chance they could. But if you keep subtracting a couple of seconds at a time, you will eventually cross a boundary where that something could no longer have been achieved.
It may be that for the majority of those people, the lost couple of seconds didn't make a difference. But for a small fraction of them it just happened by chance that those was the exact couple of seconds which made the difference between achieving something or not achieving it. Spreading the lost productivity over lots of people does not reduce the impact, it just makes it harder to measure.
Taking money from dumb people should never be illegal. If you're dumb enough to believe that a Nigerian prince needs $50k to transfer $100m to the US. Then by all means, this should be legal.
I think you are missing the point. The reason this should be illegal is not in order to protect the few people dumb enough to fall for it. There are other people smart enough to figure out in a couple of seconds, that it is a scam. But once they have figured out it is a scam, they have still wasted a couple of seconds. If we guestimate there are 10 million smart people in the world who each waste a couple of seconds figuring out it is a scam, then that has in total wasted a few man years of smart people's time. Imagine what those people could achieved in that time?
I now use LaTeX because I just get the job done and done well.
WISYWIG is evil, we need to go back to WRITING our documents rather than dicking about with font sizes and colours.
As an added benefit you can store your documents in a source control system such that you can actually keep track of changes. (The change tracking I have seen build into some office suites was fundamentally flawed. They could only compare with one previous version and not show in which order changes were made. And they were relying on all the software used by the various parties to accurately record what was changed. Not really useful as anything other than a toy.)
Canonical has bullshitted too much in the past to be taken seriously about this. Several times, they've announced that new products from major vendors (Asus, Dell) would run their version of Linux. Never happened.
I am writing this comment on a Dell that came with Ubuntu preinstalled.
Consider some sort of watermarking. It is not as easy to watermark text as it is with pictures. But it is still possible. Every time an article is written the writer need to find a few places throughout the text where two different versions of the text are equally good. Sometimes this will come very natural, when the writer encounters a situation where [he]/[she] can't make up [his]/[her] mind about the wording, the choice can be left to the watermarking software.
Leaving just a handful of bits for the watermarking software to chose in each article means any subscriber systematically copying articles would soon reveal [her]/[his] identity. Even copying as little as 100 bits of watermarking could produce a very clear signal about which subscriber is copying the data.
Make sure any technical means you choose don't get in the way of the user. You need to ensure what a user expects to be able to do with a website will still work. That includes searching the site using the users favourite search engine and sharing links with their friends.
As far as search engines go, try to treat the search engine as just another subscriber, which happens to get free access, as you want to drive users to your site.
Anybody who visits your site starting with a link from a search engine should be allowed to read the first article they found, but you can limit the number of articles per day a single user can access this way. When a non-subscriber follows links between articles, you can provide an interstitial page with information about signing up, and limiting the number of articles the user can read before subscribing.
Ensure that your subscribers can share links. When a subscriber want to share an article with [his]/[her] friends, there should be a link to provide a URL suitable for sharing. Each subscriber should only be allowed to share a fraction of the articles on the site this way. They are not supposed to be able to generate sharing URLs for every single article they access. But for those few they want to share, they should have access to such a URL. Once the sharing URL has been generated anybody with the URL should be able to access the page without having a subscription themselves.
Once in a while such a URL might spread widely, that is just good publicity for your site. In case archives of such URLs covering a substantial fraction of your site start spreading, you can easily track the URLs back to subscribers.
The trick is to ensure that fair usage remains possible, and is not hindered by technical means. And instead of trying to prevent users from stepping across the boundary of fair usage through technical means, just use technical means to track it. Subscriptions can be cancelled, if [users]/[customers] are abusing the freedom you give them.
For now at least 51% of the voting shares are owned by Page, Brin and Schmidt. If those three wanted to do it, I'm not sure the rest of the shareholders could do anything about it.
You are probably right about that. And those three are smart people, who will think about what they can expect to achieve with such a move. I believe they have reached the conclusion, that they are more likely to reach a desirable situation for their users by staying in the USA and influencing the political system there.
Remember that moving doesn't mean you can be completely unaffected by what happens in the USA, and certainly users who are still in the USA are not unaffected. And at the same time moving away reduces the influence you can have on the political system in the USA.
Google could move completely offshore if that is the problem. But they don't want to.
Google's largest engineering offices are in USA. It is not a given that Google would survive, if the majority of those engineers were unwilling to move offshore.
A significant percentage of Google's server capacity is in USA. Moving that offshore would be a major undertaking, and it would screw over the users in USA, who would get a much poorer service.
Major shareholders are in USA. I am not sure they would actually accept moving the company offshore.
Slashdot Mirror
That article gives no reason to be worried about elliptical curves. What it does give reason to be worried about is magical constants and the use of asymmetrical primitives for something that can be done with symmetrical primitives. The concern about the magical constants is why some algorithms use digits of e or pi for the constants. And since random number generators can be build using symmetrical primitives, it is suspicious when somebody choose to use asymmetrical primitives. That later decision need to be accompanied by a new formal security definition and a proof that such security definition cannot be achieved using symmetrical primities.
The combination of asymmetrical primitives where none are needed and magical constants of unknown origin is extremely suspicious. Even if you cannot prove it to be the case, it seems very likely that those magical constants are in fact a public key, and somebody knows the corresponding secret key.
Which asymmetrical primitive they chose for the construction is of no importance to the story though.
It's not only the key, which is too small. The blocksize is also too small. DES has a blocksize of only 64 bits. Even the 128 bit blocksize of AES is a bit on the short side. My rule of thumb for how many blocks of data you can safely encrypt with with a single key is two raised to one quarter of the blocksize. If the blocksize is 64 bits, that gives you 512KB, if the blocksize is 128 bits you can go all the way to 64GB. With typical full disk encryption schemes using a single AES key for an entire harddisk, which could be a few TB in size, I think this is something to be concerned about.
It is just a rule of thumb though. It is not like something happens as you cross that boundary. Whether you encrypt 63GB or 65GB with a single AES key doesn't make much of a difference in terms of security. The more data you encrypt with the same key, the larger the risk of collisions is. A collision is when you by chance encrypt the same input block twice, and when does happen the cipher blocks will be identical and leak information about the collision having happened. When you reach 64GB, the probability of such a collision is about 1 in 2^64. Having that probability go any higher than that is unreasonable for a 128 bit cipher, which is why I use the rule of thumb, that I do use.
If somebody were to encrypt all the information in the world using just a single AES key, it is not unlikely that the probability of a collision would be more than 50%.
Oh, and 10DES is not something, which would be used by anybody, who knows what they are doing. The number of times you use DES needs to be an odd number. The actual security is equivalent to the number of usages of DES divided by two and rounded up. That means 2DES is no more secure than DES, and 10DES is no more secure than 9DES. So you'd go with either 9DES or 11DES. Moreover you can replace every other DES with a simple XOR with a constant with almost no loss of security, you might even gain a little bit of security that way due the XOR using 64 bit of key material but a DES operation using only 56 bits.
So rather than using 10DES (with an actual keysize of 560 bits and an effective keysize of 280 bits) you could alternate between XOR and DES such that you have 6 rounds of XOR and 5 rounds of DES (with an actual keysize of 664 and an effective keysize of 360 bits). This approach with 6 rounds of XOR and 5 rounds of DES is almost twice as fast as 10DES and to the best of my knowledge also more secure.
If the instructions causes anything to happen which has an effect beyond the scope of that webpage, then it is a bug. Let's for a moment consider the consequences, if your reasoning was valid. A user follows a link to a webpage on a compromised server, the webpage instructs the browser to install a keylogger on the user's computer. Since the user decided to follow the link and since the webpage contained instructions to install a keylogger, then installing that keylogger is expected behaviour, and it is not a bug that the browser allowed this to happen. In what world is a browser supposed to prioritize the interests of a random webpage above the interests of the user?
That's not the only restriction I would put on tabs not currently in focus. I'd also like to see limits on the amount of CPU time they can spend on executing javascript. I'd like to set a limit saying all unfocused tabs cannot use more than 10% of one CPU in total for executing javascript. Yes, even if there is idle CPU time I don't want unfocused tabs to use more CPU time than that, such that my computer doesn't heat up unnecessarily.
Absolutely. They should add such a feature to Chrome. It is even the same company. Why have one part of the company making up for lack of options in products from another part of the company? Wasn't the point of Chrome that Google wanted to be able to make websites without having to always work around bad browsers?
No, but it is the browser's responsibility to ensure that a broken website cannot break anything but that website. The browser should not trust websites to be doing things right. Any functionality that can be used incorrectly by websites will be used maliciously.
If I am playing a video on YouTube it should not be possible for another website, which I have open in another tab to disturb that playback. In most browsers this can currently be violated by either playing sounds overlapping the sound I intended to hear as well as running some heavy javascript causing the playback to freeze shortly.
Any such behaviour is a browser bug, and it is only made worse by lack of indication of which site is responsible. Other bugs such as javascript breaking parts of the browser UI is often easier to pinpoint to a specific site. For example it is surprisingly easy to break the "Copy Link Location" feature in Firefox and equally easy to break the equivalent feature in Chrome.
Maybe nobody is supposed to figure out. There are plenty of cryptographic schemes, which Randall could be using, if he don't want anybody to figure out. It could be an HMAC computed using a key, which only Randall knows. An HMAC preserves all the collision resistance properties of the underlying hash, but cannot be computed by anybody without knowledge of the key. It might not be a hash function at all, but instead a block cipher applied to some data. It could also be completely random. It could also be that those strings are really a covert channel containing some other information.
The reason it hasn't been figured out could be that there is nothing to be figured out or because it was made impossible, it could also be an entire story is hidden in those strings. Randall only knows.
No, I was arguing that the input was not actually accurate enough to do the calculation in the first place. Floating point numbers can handle much higher accuracy than the measurements used as input. By the time you notice the difference between two runs you are already way past the point were the output could be useful.
So there are two sources of errors. Inaccurate input data which leads to reproducible bad output. Rounding errors during calculation which is smaller and thus only becomes significant later. The inaccuracy of the output due to inaccurate input data cannot be seen by running the calculation twice with the same input data. But by comparing to the real world, it can be observed that it diverges from the calculation. That divergence can be caused by inaccurate input data, flaws in the algorithm, or simply by the real world having much higher granularity than the discrete datapoints used in the algorithm.
Divergence between two runs of the same algorithm on the same input data can be caused by a number of other factors. Such factors include different rounding due to differences in the platform being used (different hardware and/or software), or non-determinism due to timing in a distributed system. For example if a node receives three floating point numbers and add them, the sum can depend on which order the three numbers were received.
The differences due to rounding errors are however not of much practical interest. By the time they are large enough to notice, the errors due to inaccurate input are already too large for the output to be of practical interest.
Distributed systems are inherently non-deterministic. Moreover it says right there in the tittle, that the different results were produced on different computers.
No. You are assuming if both calculations produce the same result, then that result is correct. In reality, you can run the same calculation twice and get the same error.
If you take the same source and compile it for two different systems, is it the same program? What the compiled program does is probably within the specs of the language.
That depends very much on what the purpose of the program is. I have worked with cryptography, and for most usages in that field, a program which produces the same output twice is unusable. A program which does floating point operations need to be done in a way, where you can figure out how large an error you get. Knowing the accuracy is more important than getting the same result twice. If you do get two different results from the same calculation, you can check if the difference is within the accuracy you were supposed to get.
The complete program is not one unit. You unit test individual units. And unit tests can deal perfectly well with units, where the spec allows for more than one possible output. The unit test just need to verify that the output is within spec. Testing for one specific output value is usable in some cases, but not always.
All I was taught about floating point at that level was how wrong results we could get, and that we should avoid it. Several years later on a more advanced course, I learned about how to do floating point calculations, if you really need to.
Inaccuracies in the input most likely did cause most of the error. Maybe nobody noticed because that error was the same in all the calculations. Eventually a difference between the calculations starting to build up because of differences in rounding between the different runs. This variation was noticed, but it would still be small compared to the differences caused by inaccuracies in the input. In short means by the time you notice the difference between two runs, both of them are already way off compared to the real value due to both of them having been working on the same inaccurate input.
If you want to do better, then do calculations with a representation that keeps track of uncertainty. Even in those cases where you cannot do a floating point operation and get an exact result, you can still do the calculation and know the possible range of the error. So each number is represented by a minimum and a maximum (or a mean and an error margin). As you do calculations the minimum and maximum values will be going further and further apart. Once they get too far apart, you know the results are no longer useful.
When you start the simulation, you initialize the numbers with an error margin corresponding to the accuracy of the measurements. Different runs on different platforms may not build up errors at the same rate, and that is something you can actually look at. If the ranges from two different runs no longer overlaps, then you know there is a bug somewhere. If one simulation says the air temperature is going to be be between -10 and +30 and the other simulation says it is going to be between 0 and +20, then they can both be right, but neither simulation result is particular useful. If one simulation says it is going to be between -10 and 0 and the other says it is going to be between +20 and +30, then you know at least one of them has a bug.
No, that doesn't end the arms race. It just changes it into a different arms race. It will no longer be about getting there first but rather about putting in the largest number of reservations within a five minute window.
As in any other sort of business, if it turns out to be less fun than you envisioned but more profitable, then you can just keep making lots of profit until you have enough money to go and build what you really want to do. It is rare to hear about people who were unable to realize their dreams because they had too much money.
When I was young and naive, I thought if I discretely told companies about security problems in their products, they would thank me and fix it. In reality that has never happened in any of the cases, where I have reported a security problem to a company.
In the real world the majority of companies will do nothing about a security bug unless they face an immediate threat of the information becoming public. As a security researcher, it is sensible to assume any company will behave like that, until proven otherwise.
This puts the few companies, which takes security seriously, in a bad position. They have to differentiate themselves from the rest of the industry to even get security researchers to take them seriously. One way to differentiate yourself is by offering bug bounties. The added benefit from offering bug bounties is that the company get to set rules about disclosure which must be followed to qualify for a bounty.
I am going to test this on my next laptop, or if I decide to upgrade my current with an SSD some day.
Meanwhile, I do have a couple of questions. How automated is this going to be? Will it automatically start to sync, once the USB/eSata disk is connected?
Can I safely attach that disk to another computer for reading? I am worried such operation might corrupt data, even if I don't write anything. If I connect the external disk to a workstation, do I risk that the RAID layer will declare the SSD to be dead and record this fact on the external disk? Is reading from the external disk going to perform a journal replay and thereby perform some unintended writes? Is the raid layer going to increase the event counter on the external disk and potentially run past the SSD or end up at the same event counter due to the same number of cycles, but on different machines?
So what? The certificate is worth nothing without the private key, which you should never send to the CA in the first place.
No, but those few seconds are being taken away from the time they could have spend on something else. If you will try to argue that it makes no difference if a smart person is going to spend say eight hours on a task or eight hours minus a couple of seconds, then you would be wrong.
I agree one smart person is unlikely to achieve anything great in a couple of seconds. But they could achieve something in eight hours. Could they have achieved the same in eight hours minurs a couple of seconds? There is a good chance they could. But if you keep subtracting a couple of seconds at a time, you will eventually cross a boundary where that something could no longer have been achieved.
It may be that for the majority of those people, the lost couple of seconds didn't make a difference. But for a small fraction of them it just happened by chance that those was the exact couple of seconds which made the difference between achieving something or not achieving it. Spreading the lost productivity over lots of people does not reduce the impact, it just makes it harder to measure.
I think you are missing the point. The reason this should be illegal is not in order to protect the few people dumb enough to fall for it. There are other people smart enough to figure out in a couple of seconds, that it is a scam. But once they have figured out it is a scam, they have still wasted a couple of seconds. If we guestimate there are 10 million smart people in the world who each waste a couple of seconds figuring out it is a scam, then that has in total wasted a few man years of smart people's time. Imagine what those people could achieved in that time?
As an added benefit you can store your documents in a source control system such that you can actually keep track of changes. (The change tracking I have seen build into some office suites was fundamentally flawed. They could only compare with one previous version and not show in which order changes were made. And they were relying on all the software used by the various parties to accurately record what was changed. Not really useful as anything other than a toy.)
I am writing this comment on a Dell that came with Ubuntu preinstalled.
No, if you had a dollar for every percent, you'd have 25$. But that's really not a lot of money.
Consider some sort of watermarking. It is not as easy to watermark text as it is with pictures. But it is still possible. Every time an article is written the writer need to find a few places throughout the text where two different versions of the text are equally good. Sometimes this will come very natural, when the writer encounters a situation where [he]/[she] can't make up [his]/[her] mind about the wording, the choice can be left to the watermarking software.
Leaving just a handful of bits for the watermarking software to chose in each article means any subscriber systematically copying articles would soon reveal [her]/[his] identity. Even copying as little as 100 bits of watermarking could produce a very clear signal about which subscriber is copying the data.
Make sure any technical means you choose don't get in the way of the user. You need to ensure what a user expects to be able to do with a website will still work. That includes searching the site using the users favourite search engine and sharing links with their friends.
As far as search engines go, try to treat the search engine as just another subscriber, which happens to get free access, as you want to drive users to your site.
Anybody who visits your site starting with a link from a search engine should be allowed to read the first article they found, but you can limit the number of articles per day a single user can access this way. When a non-subscriber follows links between articles, you can provide an interstitial page with information about signing up, and limiting the number of articles the user can read before subscribing.
Ensure that your subscribers can share links. When a subscriber want to share an article with [his]/[her] friends, there should be a link to provide a URL suitable for sharing. Each subscriber should only be allowed to share a fraction of the articles on the site this way. They are not supposed to be able to generate sharing URLs for every single article they access. But for those few they want to share, they should have access to such a URL. Once the sharing URL has been generated anybody with the URL should be able to access the page without having a subscription themselves.
Once in a while such a URL might spread widely, that is just good publicity for your site. In case archives of such URLs covering a substantial fraction of your site start spreading, you can easily track the URLs back to subscribers.
The trick is to ensure that fair usage remains possible, and is not hindered by technical means. And instead of trying to prevent users from stepping across the boundary of fair usage through technical means, just use technical means to track it. Subscriptions can be cancelled, if [users]/[customers] are abusing the freedom you give them.
You are probably right about that. And those three are smart people, who will think about what they can expect to achieve with such a move. I believe they have reached the conclusion, that they are more likely to reach a desirable situation for their users by staying in the USA and influencing the political system there.
Remember that moving doesn't mean you can be completely unaffected by what happens in the USA, and certainly users who are still in the USA are not unaffected. And at the same time moving away reduces the influence you can have on the political system in the USA.
Democracy is un-american?