The appended random characters make that impossible. Consider if they used id + random = sum, all just plain integers, no hashing (which is approximately equivalent given large enough range for the random values, I think). You know every possible id and every resulting sum, but you still can't connect them because you don't know the random number added to the id.
Here's the that would be data published: (in "sum -- voted for" format)
18273 -- Mr. X
38475 -- Ms. Y
83744 -- Mrs. Z
23876 -- Dr. W
The voter IDs were 1, 2, 3, and 4. Please connect who voted who.
However, it's easy for voter ID 1 to check that her vote (for Dr. W) registered properly, since she remembers the random number added to her ID number was 23875.
This is pretty much what I was thinking. Writing in English gives you an advantage if you ever want other people to use/modify your code. It doesn't make much sense to write all your own functions, classes and methods in another language when practically all system/standard library APIs are in English. If you do that, you'll have to switch back and forth between languages (and yes, the effect is considerable, context switches are not cheap).
Tivoization would be if the server checked that the client isn't running a modified version.
What I said is that the client should check that the server is still offering the same code you modified. You know, because if the server was expecting you to run newer code and you substitute that with a modified version of the older code, it would probably fuck things up.
I don't care if the reason a client-side customization fails is that the server was poorly coded; if it fails, it fails.
I don't see what you're getting at with this. If it's the modification that fails, why do you care at all?
Really? Like how people that modified their iPhone software in unsupported ways accepted responsibility for the results of their changes?
Sorry, I'm not familiar with that (what modifications, what results?) and couldn't find much with a quick search.
You might think you'd react appropriately, and you might be right. If you think "anyone making modifications" will react appropriately, you aren't considering the real environment of web app development and usage.
[...]
Then if it's not a big problem, answer the question. Knowing the structure of a web page and the random ways in which code can be embedded, I think it is a big problem.
Like I said, it's an implementation detail, not all that relevant at this point. I don't know or care how exactly I'd do it.
What and how to hash wouldn't be a big problem because getting a mismatch on potentially incompatible code is preferable and easy to achieve. Warn the user that things might not work right and that the modification is likely at fault if they don't. Give them the possibility of using the new code, but still warn them it might not work either if they have modified scripts on other pages on that site.
No, I don't think that is what I said. Mostly because you inserted an incorrect motive ("for the fun of it") and an incorrect assumption (that the re-ordering of elements has no meaning).
Let's say I'm changing the look-and-feel of a page. I move a control. The control's tag has script embedded in it. The top-down ordering of script commands in the page changes, and so does your hash.
Assumptions and misunderstanding by both of us.
Any code directly embedded into an element is most likely trivial, a function call, and changes would go into the function definition. Anyway, I'd rather hash each separate slice of JS separately instead of concatenating them. And as above, getting a false mismatch is much more preferable than a false match, so it's not much of a problem unless you plan on changing the look-and-feel very often.
Well... first, writing your site so that you make changes to page A that page B relies on significantly before changing page B isn't exactly the smartest way to do it.
Second, anyone making modifications knows the risks they're running. They will most likely know or guess any problems they encounter are with their modifications and how to fix it.
Third, if you write your pages in such a way that client-side scripting can cause corruption on the server-side, that's a bug and should be fixed in any case.
Fourth, what to hash is pretty much also what to let the user substitute with his own code. That's an implementation detail and not a big problem. Also, are you seriously saying you'd move elements around in the code just for the fun of it, without actually making any other updates?
How much does a DVD and the case cost, hm? I doubt it's $25. I doubt it's even $5.
Loss is when manufacturing costs are more than what you make selling it. The funny thing about software (well, any IP product) is that most of the price does not come from manufacturing the physical product. Most of it is to cover the initial costs (ie. development). Halving the price and more than doubling the sales would in many cases give more profit to the company, especially if they're being sold over the internet (like on Steam), meaning that the cost per product sold is pretty damn low.
Slashdot Mirror
Really, nowadays you can do practically everything with just your browser. It's the new emacs.
You're taking advantage of people who don't know what things really should cost.
Different things are of different value to different people.
The appended random characters make that impossible. Consider if they used id + random = sum, all just plain integers, no hashing (which is approximately equivalent given large enough range for the random values, I think). You know every possible id and every resulting sum, but you still can't connect them because you don't know the random number added to the id.
Here's the that would be data published: (in "sum -- voted for" format)
The voter IDs were 1, 2, 3, and 4. Please connect who voted who.
However, it's easy for voter ID 1 to check that her vote (for Dr. W) registered properly, since she remembers the random number added to her ID number was 23875.
Here's an article in non-google-translated English. Also contains some other links in English.
I guess the type of pants you have and whether it stays in the pocket affect how rough a ride it gets.
Hmm... something doesn't seem quite right here...
That'd be your sense of humour.
"x times cheaper" = current-price - (x * current-price). Duh.
So, tell me; what do I have to do to make it obvious that I'm not making a serious comment? The smiley at the end doesn't seem to be doing the job...
Yeah, just like open source OSes are just begging for viruses :D.
Limited resources -> very few fat chicks. That alone significantly raises the average hotness.
Also, genes do account for something.
So, you're thinking everyone will live that 50 years in celibacy?
There's be a whole new generation of hot chicks halfway there.
I'd say the majority of people who go outside when the weather is nice also shut down their computers when they're not sitting in front of it.
You don't need a lot of people. Spamming is cheap. You only need one reply from a shitload of spams and it'll still be profitable.
This is pretty much what I was thinking. Writing in English gives you an advantage if you ever want other people to use/modify your code. It doesn't make much sense to write all your own functions, classes and methods in another language when practically all system/standard library APIs are in English. If you do that, you'll have to switch back and forth between languages (and yes, the effect is considerable, context switches are not cheap).
Everything's an "act of terrorism" these days.
They don't hit because they're leading the target, they hit because they're using scattershot. And they're hitting a shitload of other stuff too.
Four-fold rotational symmetry. You're pretty much guaranteed to find a swastika in that.
Tivoization would be if the server checked that the client isn't running a modified version.
What I said is that the client should check that the server is still offering the same code you modified. You know, because if the server was expecting you to run newer code and you substitute that with a modified version of the older code, it would probably fuck things up.
Not tivoization.
I don't care if the reason a client-side customization fails is that the server was poorly coded; if it fails, it fails.
I don't see what you're getting at with this. If it's the modification that fails, why do you care at all?
Really? Like how people that modified their iPhone software in unsupported ways accepted responsibility for the results of their changes?
Sorry, I'm not familiar with that (what modifications, what results?) and couldn't find much with a quick search.
You might think you'd react appropriately, and you might be right. If you think "anyone making modifications" will react appropriately, you aren't considering the real environment of web app development and usage.
[...]
Then if it's not a big problem, answer the question. Knowing the structure of a web page and the random ways in which code can be embedded, I think it is a big problem.
Like I said, it's an implementation detail, not all that relevant at this point. I don't know or care how exactly I'd do it.
What and how to hash wouldn't be a big problem because getting a mismatch on potentially incompatible code is preferable and easy to achieve. Warn the user that things might not work right and that the modification is likely at fault if they don't. Give them the possibility of using the new code, but still warn them it might not work either if they have modified scripts on other pages on that site.
No, I don't think that is what I said. Mostly because you inserted an incorrect motive ("for the fun of it") and an incorrect assumption (that the re-ordering of elements has no meaning).
Let's say I'm changing the look-and-feel of a page. I move a control. The control's tag has script embedded in it. The top-down ordering of script commands in the page changes, and so does your hash.
Assumptions and misunderstanding by both of us.
Any code directly embedded into an element is most likely trivial, a function call, and changes would go into the function definition. Anyway, I'd rather hash each separate slice of JS separately instead of concatenating them. And as above, getting a false mismatch is much more preferable than a false match, so it's not much of a problem unless you plan on changing the look-and-feel very often.
Well... first, writing your site so that you make changes to page A that page B relies on significantly before changing page B isn't exactly the smartest way to do it.
Second, anyone making modifications knows the risks they're running. They will most likely know or guess any problems they encounter are with their modifications and how to fix it.
Third, if you write your pages in such a way that client-side scripting can cause corruption on the server-side, that's a bug and should be fixed in any case.
Fourth, what to hash is pretty much also what to let the user substitute with his own code. That's an implementation detail and not a big problem. Also, are you seriously saying you'd move elements around in the code just for the fun of it, without actually making any other updates?
So they want to forbid nagware? I can support that.
Buying a new cert for every subdomain is wildly expensive, so these sorts of errors happen reasonably often.
I think that should be "unreasonably often".
How much does a DVD and the case cost, hm? I doubt it's $25. I doubt it's even $5.
Loss is when manufacturing costs are more than what you make selling it. The funny thing about software (well, any IP product) is that most of the price does not come from manufacturing the physical product. Most of it is to cover the initial costs (ie. development). Halving the price and more than doubling the sales would in many cases give more profit to the company, especially if they're being sold over the internet (like on Steam), meaning that the cost per product sold is pretty damn low.