If you can make it to a longer time for a human to crack it, it would increase the costs. Double the time, double the cost.
But, say, if it now takes 10 seconds to crack a captcha, it would need to take more than an hour to cost $1 per captcha:-).
I wonder how a web-of-trust system combined with more difficult captchas (more trust -> easier captchas) would work; if a branch of the web is a spammer, it's easier to cut off.. But, this must've been suggested even in this context already, so hit me with the "your spam protection idea doesn't work, because.." form;-).
Clean has in-place modification of arrays which doesn't break referential transparency, thanks to uniqueness typing. So you can still go and implement the same algorithm. You can mutate an array given you only have one instance of it.
You can also describe the computation required to perform the sort in-place, and let the runtime system do the impure evaluation of the algorithm for you, in-place. Sort of what Haskell lets you do with monads.
Actually the term "binding" is often used in functional languages. However, the term "variable" can also be understood to be entirely meaningful there. By 'varying' the variable (an identifier in the code you are looking at) simply doesn't have the same value always (say, between every time a function is being called), compared to a constant that would always stay, well, constant.
For example in the code fragment:
int foo(const int i) {.. }
the value i varies although it can never be mutated.
I'm thinking trying to write an algorithm in C++ using just constant variables gives you some idea how to write functional algorithms; but the language isn't quite suitable for it, with the lack of lambda functions (yes, those are coming!) and true garbage collection.
Well, if they also spelled out "What's great about this product is that you get something that looks like THIS!" in their advertisement, I'd get the picture someone would complain.. Had the Apple ad plainly told "iPhone is great, it can do all this" without emphasizing on the speed, few people would have problem with that.
What is username/password if not security via obscurity then? You can brute force them just as easily you can brute force an URL.
How can it be the service provider's fault that the viewer of the media openly sends information on the pages to the world?
And this MMS-hole is as old as MMS is; when MMS-messages weren't supported by all the phones (I suppose that can be the case today too), an SMS with the URL was sent instead. No username/password was associated with the service provider, you had your phone number. And the URL was something you could pass on if you wanted, without distributing your credentials. (I don't know if that's the case today, though, if some providers have added some response features to it; someone's going to pay for those, right?)
And even with Google Toolbar, a robots.txt should fix the issue.
And how do search engines find the pages? Not likely via links, or if they do, what's wrong with that? I believe the most plausible explanation is that the viewers of such pages are using Google Toolbar or a similar tool, which I believe can report (reports all the time?) viewed pages to Google, so it can index then, even if they don't have any inbound links.
The lack of robots.txt is an oversight, though.
But why should a secret URL not be a decent security feature? Especially if they don't have outbound links that could put them into another server's log in the form of the Referer-field of the header. Why is it an advantage that part of the URL is moved to web page credentials? The pages themselves can still be in plain text (or are they SSL-protected?) and any system between the client and the server can see the credentials no matter where they are put. There is the slight difference that a server more commonly logs only the URL, not the password, but that's just another configuration issue and not in my opinion any real security; an attacker could modify the web server produce any kinds of logs he wanted.
I did try, with one such URL, to find its inbound link with Google's linkto-search, but found nothing. This does suggest a tool such as Google Toolbar or manual page entry was used to get the pages in. The low number of images found this way suggests this too.
If the providers had a page that linked to all the MMS images that way, now that would have been a grave mistake. But relying on secret URLs on a plain text medium in any case, is not. The search engines have no magic fairy dust in them to help them find such pages - and they sure aren't brute forcing the web..
Re:GPLv2 and GPLv3 have the same spirit
on
A Year of GPLv3
·
· Score: 2, Interesting
I don't think providing the source to the operating system of your media player (or similar) would make DRM impossible. All you need to do is to put the decryption, authentication and video decoding to its own piece of hardware; and I do believe such hardware is available for example for BluRay devices - if it isn't yet, it will be, to drive down the costs. The HDL source used to construct the chip could be fully proprietary.
This way you can still provide the source to the drivers (and the rest), while still keeping the DRM aspect intact. Of course, having such close access to the DRM chip may allow finding bugs in it, but in theory it should be workable..
I don't know if everyone (GPL-people) would be happy with this solution. Does GPL3 have clauses to stop this from happening? Would it just be enough it is possible to play non-DRM-encumbered media with the device? (Or if it doesn't yet, it'd be possible to modify it to do so.)
I personally very much prefer Blender's interface over GIMP's: Blender's UI keeps out of my way, unlike GIMP with its numerous windows which I want to carefully align so that they don't overlap each other. And do that with all the new windows that come up. And as the number of windows approaches infinity, alt-tabbing will not do much good. (I have keyboard-numberable windows with Sawfish, though, so it's not that bad.)
If GIMP were to have Blender's UI, I'd consider that an improvement.
Of course, GIMP's UI is still more discoverable than Blender's, which makes it easy to find how stuff is done. This excluding the ctrl-shift-etc combinations while performing operations with the canvas, though.
I could envision one reason: it is possible to attain much smaller latency with DSP. With DSP you can guarantee n sample window within which the corrective action is taken; it will be very difficult to do so small windows when you have 2 kilobyte buffers you record sound into.. (Doesn't need to be that bad, though: that's already >40 ms with assumed 44100 sampling rate.) Perhaps if you use an approach similar to RT-Linux?
However, I believe many soundcards have had built-in programmable DSPs for a while (not really followed the matter, but atleast my good ol' Audigy has one; perhaps the advent of built in sound has killed that?), so maybe they can do that too.
While on a certain level splitting the available bandwidth to separate users fairly seems, well, fair, how about multi user systems? In those cases the whole system would likely put the all the users under the same bandwidth limitation. [Note: I haven't read the white paper describing the proposed system.]
Well, that might also seem fair, and there aren't that many multi user systems around, atleast compared to desktops. What if you give each user in the system a new IP? Could easily be done in an IPv6 system, or if you otherwise happen to have a few extra C-classes around.. Actually, with this method you could get the bandwidth multiplied by the share of a single host to your desktop too, provided you have enough IP addresses to use.
In practice a bittorrenter would like to have atleast two IPs: one for bittorrenting and one for surfing. This would be because the bittorrenting host would likely to be much slower for surfing the web, unless the system somehow knows that there are two different applications doing the magic. (A local gateway with bandwidth limiting would not be as efficient, although for example stopping bittorrent activity for the duration of surfing should help.) Indeed, that would be one fair approach: each separate application would have its own fair bandwidth, perhaps according to its own bandwidth desires. In some comments this approach was mentioned in a passing, apparently this is what the talk has mentioned also, and it has one undesirable side: obviously an application that attempts to get as much bw as possible would pose as n separate applications.
Hey, I think Vista and MacOSX have a solution for this, I hear they have DRM/Trusted Computing..;-)
I've personally had good experience with a flash-based root file system, but I implemented it with a ide-CF adapter. I picked a bit too slow card for the root, though, but the point of the device is to provide the contents of 4 hard drivers software-raid5'd over the network, so it isn't such a big deal. I don't have swap in the machine.
I've earlier set up a box to boot from a ide-flash device, while the actual root file system was on LVM. It worked nicely too.
It doesn't matter even then, when the user can't play some video off the web? "But it's an AVI file!" "I've played.MOV-files before! Teh computer's busted!" Right, but you still need to download some mystic object called "codec package".. If you're looking for a good high-level concept, a better one would be "a video file" or "an audio file"; they can be in many extensions, but so can the files themselves be encoded with various different codecs, which your computer may or may not understand.
However, it might even be more convenient to walk on a slightly
"softer" surface - after all, people buy shoes that have gel padding
to reduce the impact. I'm not quite sure the effect would be the same,
though, with a concrete tile that moves a bit per each step, because
the mass of the concrete tile (who said the tiles were going to be of
that material anyway?) is large.
I shall declare that the displays in question are in fact capable of displaying infinitely many colors!
I seriously doubt the color displayed by two adjacent pixels is _exactly_ the same, even if the computer thinks they are. In fact I doubt the a pixel will be able to continuously output the exact same color at all times, even if it is desired!
So maybe Apple can just revise their advertisement to "They can display billions of shades of colors, randomly"..
(Maybe the 'infinite'-statement doesn't hold true, with quantum mechanics and all..)
More realistically, maybe the advertisement should go like "Displays many, many colors".
Let's for a second assume that the chip in the DVD is secure in a way that it cannot be overridden (make it send the pulse) without conversing with it. That is: you actually need the activator to activate the disc. Defeating the actual pulse-mechanism might be easier, even if the dark layer would be inside the DVD: you would need to drill a (small) hole into it to be able to feed the required electric pulse. Large enough holes might reduce the resale value..
Chances are there is cryptography involved. The cryptographic keys could be partially, or in full, stored in the company server, and the device could require a connection to the server to successfully activate the chip. Perhaps even a smart card would also be required.
Thus, stealing the device itself would not be sufficient. To do 'legit looking' activation you would almost certainly need someone in the inside, and all chip activations could also be logged for later audition. (Suspicious if you do it outside business hours..)
Btw, I guess this technology could essentially be used as a replacement for RFID too, and it would make doing inventories a breeze: perhaps even automatic.
I think a more glaring omission is that there is not a single language that could be considered being of the functional language family - or even if you'd count Python as one (I definitely wouldn't), no statically typed functional languages. But I guess the "you need to be able to read other people's code" explains that partially.
And what happens if you call a method that might store the pointer for later perusal, but the method that made the call finishes? The calling method can no longer simply pop the stack and call the associated desctructors at finish, because there might exist pointers to them.
Doing this in C/C++ is considered a bug (dangling pointer), therefore You Don't Do It - instead, you get to decide and tell the compiler if the variable may be stored to the stack or not. In Java you might write code such as above and expect it to always work legitimately, so the optimization you mention will require very extensive analyzing (due to lack of developer hints) of the methods that are called - and it needs to be done on the bytecode level because sources to external libraries might not be around, but I imagine that might actually simplify things - that is, until someone makes a call to a C-library.
I don't think it is as easy as you make it out to be.
Well, I must admit that I can't remember when I've last hit the problem. But that's mostly because I've naturally double-checked with the interface, maybe even copy-pasted the definition, just to be sure it's right. (I suppose IDEs nowadays do that for you.)
Keywords 'new' and 'override' in the method declaration may be helpful to the guy reading the code, and assuming types are being used with wisdom, it will reduce the need to jump to the definition of the parent class (which I suppose is just a click away anyway).
During the development phase someone may modify the parent class declaration without realizing that there exists dependencies and thus render the code overriding it ineffective without the compiler blinking an eye.
I personally see that the slight advantage of less verboseness (writing one word less) given by not using such keywords is smaller than the slight advantage of better documentation and better compiler feedback.
(For the record: I haven't written a single line of C#, but many, many lines of C++.)
Maybe they aren't your files you are manipulating. Maybe some user of your system decided that it's a good idea to put newlines in filenames. Maybe your backup scripts crash and burn horribly because of this.
And why shouldn't her? The system obviously permits doing it. If they pose a difficulty in handling, the difficulties should be overcome, the user should not be forced upon some invisible rules.
Yeah, I know you can use for example zsh and gnu tools to overcome these kinds of trouble (with the support for 0-terminated strings), but it still comes down to that when manipulating information streams you still need to think about the low-level representation. It would be nice if handling binary data would be just as easy as handling anything else in the shell. But as the defacto interprocess communication protocol is line based, things can break horribly.
What I would like to know about this MSH is that how is handles multiple processes/threads.. That is, if you create a dataset of 1000000 elements and then select | where it, will the elements be first retrieved to memory and then processed, or does it behave 'right'? And if it does behave efficiently, what does { $f = 4 } | { $f } output?
I would like to see a shell with types (even if dynamic, although atleast partially static type system would be cool) on Unix too, but unfortunately it would, with the current set of tools, mean that lots of the code would be written simply for converting data back and forth between different defacto tools, such as sed, perl and awk. Or maybe some bright person could figure out how to make that border transparent..
Slashdot Mirror
If you can make it to a longer time for a human to crack it, it would increase the costs. Double the time, double the cost.
But, say, if it now takes 10 seconds to crack a captcha, it would need to take more than an hour to cost $1 per captcha :-).
I wonder how a web-of-trust system combined with more difficult captchas (more trust -> easier captchas) would work; if a branch of the web is a spammer, it's easier to cut off.. But, this must've been suggested even in this context already, so hit me with the "your spam protection idea doesn't work, because.." form ;-).
Clean has in-place modification of arrays which doesn't break referential transparency, thanks to uniqueness typing. So you can still go and implement the same algorithm. You can mutate an array given you only have one instance of it.
You can also describe the computation required to perform the sort in-place, and let the runtime system do the impure evaluation of the algorithm for you, in-place. Sort of what Haskell lets you do with monads.
Well, C++ has constant variables too, no?
Actually the term "binding" is often used in functional languages. However, the term "variable" can also be understood to be entirely meaningful there. By 'varying' the variable (an identifier in the code you are looking at) simply doesn't have the same value always (say, between every time a function is being called), compared to a constant that would always stay, well, constant.
For example in the code fragment:
int foo(const int i) { .. }
the value i varies although it can never be mutated.
I'm thinking trying to write an algorithm in C++ using just constant variables gives you some idea how to write functional algorithms; but the language isn't quite suitable for it, with the lack of lambda functions (yes, those are coming!) and true garbage collection.
Well, if they also spelled out "What's great about this product is that you get something that looks like THIS!" in their advertisement, I'd get the picture someone would complain.. Had the Apple ad plainly told "iPhone is great, it can do all this" without emphasizing on the speed, few people would have problem with that.
Yes, because usually machines get updated when they are powered off.. ?
Also it's easy to see why they can give unbeatable prices if they aren't paying others for their Internet connection :P.
What is username/password if not security via obscurity then? You can brute force them just as easily you can brute force an URL.
How can it be the service provider's fault that the viewer of the media openly sends information on the pages to the world?
And this MMS-hole is as old as MMS is; when MMS-messages weren't supported by all the phones (I suppose that can be the case today too), an SMS with the URL was sent instead. No username/password was associated with the service provider, you had your phone number. And the URL was something you could pass on if you wanted, without distributing your credentials. (I don't know if that's the case today, though, if some providers have added some response features to it; someone's going to pay for those, right?)
And even with Google Toolbar, a robots.txt should fix the issue.
And how do search engines find the pages? Not likely via links, or if they do, what's wrong with that? I believe the most plausible explanation is that the viewers of such pages are using Google Toolbar or a similar tool, which I believe can report (reports all the time?) viewed pages to Google, so it can index then, even if they don't have any inbound links.
The lack of robots.txt is an oversight, though.
But why should a secret URL not be a decent security feature? Especially if they don't have outbound links that could put them into another server's log in the form of the Referer-field of the header. Why is it an advantage that part of the URL is moved to web page credentials? The pages themselves can still be in plain text (or are they SSL-protected?) and any system between the client and the server can see the credentials no matter where they are put. There is the slight difference that a server more commonly logs only the URL, not the password, but that's just another configuration issue and not in my opinion any real security; an attacker could modify the web server produce any kinds of logs he wanted.
I did try, with one such URL, to find its inbound link with Google's linkto-search, but found nothing. This does suggest a tool such as Google Toolbar or manual page entry was used to get the pages in. The low number of images found this way suggests this too.
If the providers had a page that linked to all the MMS images that way, now that would have been a grave mistake. But relying on secret URLs on a plain text medium in any case, is not. The search engines have no magic fairy dust in them to help them find such pages - and they sure aren't brute forcing the web..
I don't think providing the source to the operating system of your media player (or similar) would make DRM impossible. All you need to do is to put the decryption, authentication and video decoding to its own piece of hardware; and I do believe such hardware is available for example for BluRay devices - if it isn't yet, it will be, to drive down the costs. The HDL source used to construct the chip could be fully proprietary.
This way you can still provide the source to the drivers (and the rest), while still keeping the DRM aspect intact. Of course, having such close access to the DRM chip may allow finding bugs in it, but in theory it should be workable..
I don't know if everyone (GPL-people) would be happy with this solution. Does GPL3 have clauses to stop this from happening? Would it just be enough it is possible to play non-DRM-encumbered media with the device? (Or if it doesn't yet, it'd be possible to modify it to do so.)
I personally very much prefer Blender's interface over GIMP's: Blender's UI keeps out of my way, unlike GIMP with its numerous windows which I want to carefully align so that they don't overlap each other. And do that with all the new windows that come up. And as the number of windows approaches infinity, alt-tabbing will not do much good. (I have keyboard-numberable windows with Sawfish, though, so it's not that bad.)
If GIMP were to have Blender's UI, I'd consider that an improvement.
Of course, GIMP's UI is still more discoverable than Blender's, which makes it easy to find how stuff is done. This excluding the ctrl-shift-etc combinations while performing operations with the canvas, though.
I could envision one reason: it is possible to attain much smaller latency with DSP. With DSP you can guarantee n sample window within which the corrective action is taken; it will be very difficult to do so small windows when you have 2 kilobyte buffers you record sound into.. (Doesn't need to be that bad, though: that's already >40 ms with assumed 44100 sampling rate.) Perhaps if you use an approach similar to RT-Linux?
However, I believe many soundcards have had built-in programmable DSPs for a while (not really followed the matter, but atleast my good ol' Audigy has one; perhaps the advent of built in sound has killed that?), so maybe they can do that too.
While on a certain level splitting the available bandwidth to separate users fairly seems, well, fair, how about multi user systems? In those cases the whole system would likely put the all the users under the same bandwidth limitation. [Note: I haven't read the white paper describing the proposed system.]
;-)
Well, that might also seem fair, and there aren't that many multi user systems around, atleast compared to desktops. What if you give each user in the system a new IP? Could easily be done in an IPv6 system, or if you otherwise happen to have a few extra C-classes around.. Actually, with this method you could get the bandwidth multiplied by the share of a single host to your desktop too, provided you have enough IP addresses to use.
In practice a bittorrenter would like to have atleast two IPs: one for bittorrenting and one for surfing. This would be because the bittorrenting host would likely to be much slower for surfing the web, unless the system somehow knows that there are two different applications doing the magic. (A local gateway with bandwidth limiting would not be as efficient, although for example stopping bittorrent activity for the duration of surfing should help.) Indeed, that would be one fair approach: each separate application would have its own fair bandwidth, perhaps according to its own bandwidth desires. In some comments this approach was mentioned in a passing, apparently this is what the talk has mentioned also, and it has one undesirable side: obviously an application that attempts to get as much bw as possible would pose as n separate applications.
Hey, I think Vista and MacOSX have a solution for this, I hear they have DRM/Trusted Computing..
Uptime 29 days, no crashes ever. The device is not much older than 1.5 months old, though..
I've personally had good experience with a flash-based root file system, but I implemented it with a ide-CF adapter. I picked a bit too slow card for the root, though, but the point of the device is to provide the contents of 4 hard drivers software-raid5'd over the network, so it isn't such a big deal. I don't have swap in the machine.
I've earlier set up a box to boot from a ide-flash device, while the actual root file system was on LVM. It worked nicely too.
It doesn't matter even then, when the user can't play some video off the web? "But it's an AVI file!" "I've played .MOV-files before! Teh computer's busted!" Right, but you still need to download some mystic object called "codec package".. If you're looking for a good high-level concept, a better one would be "a video file" or "an audio file"; they can be in many extensions, but so can the files themselves be encoded with various different codecs, which your computer may or may not understand.
However, it might even be more convenient to walk on a slightly "softer" surface - after all, people buy shoes that have gel padding to reduce the impact. I'm not quite sure the effect would be the same, though, with a concrete tile that moves a bit per each step, because the mass of the concrete tile (who said the tiles were going to be of that material anyway?) is large.
I shall declare that the displays in question are in fact capable of displaying infinitely many colors!
I seriously doubt the color displayed by two adjacent pixels is _exactly_ the same, even if the computer thinks they are. In fact I doubt the a pixel will be able to continuously output the exact same color at all times, even if it is desired!
So maybe Apple can just revise their advertisement to "They can display billions of shades of colors, randomly"..
(Maybe the 'infinite'-statement doesn't hold true, with quantum mechanics and all..)
More realistically, maybe the advertisement should go like "Displays many, many colors".
Don't you people have any imagination?
Let's for a second assume that the chip in the DVD is secure in a way that it cannot be overridden (make it send the pulse) without conversing with it. That is: you actually need the activator to activate the disc. Defeating the actual pulse-mechanism might be easier, even if the dark layer would be inside the DVD: you would need to drill a (small) hole into it to be able to feed the required electric pulse. Large enough holes might reduce the resale value..
Chances are there is cryptography involved. The cryptographic keys could be partially, or in full, stored in the company server, and the device could require a connection to the server to successfully activate the chip. Perhaps even a smart card would also be required.
Thus, stealing the device itself would not be sufficient. To do 'legit looking' activation you would almost certainly need someone in the inside, and all chip activations could also be logged for later audition. (Suspicious if you do it outside business hours..)
Btw, I guess this technology could essentially be used as a replacement for RFID too, and it would make doing inventories a breeze: perhaps even automatic.
I think a more glaring omission is that there is not a single language that could be considered being of the functional language family - or even if you'd count Python as one (I definitely wouldn't), no statically typed functional languages. But I guess the "you need to be able to read other people's code" explains that partially.
You still wouldn't want to use a Java finalize to for example release a database lock.
And what happens if you call a method that might store the pointer for later perusal, but the method that made the call finishes? The calling method can no longer simply pop the stack and call the associated desctructors at finish, because there might exist pointers to them.
Doing this in C/C++ is considered a bug (dangling pointer), therefore You Don't Do It - instead, you get to decide and tell the compiler if the variable may be stored to the stack or not. In Java you might write code such as above and expect it to always work legitimately, so the optimization you mention will require very extensive analyzing (due to lack of developer hints) of the methods that are called - and it needs to be done on the bytecode level because sources to external libraries might not be around, but I imagine that might actually simplify things - that is, until someone makes a call to a C-library.
I don't think it is as easy as you make it out to be.
Well, I must admit that I can't remember when I've last hit the problem. But that's mostly because I've naturally double-checked with the interface, maybe even copy-pasted the definition, just to be sure it's right. (I suppose IDEs nowadays do that for you.)
Keywords 'new' and 'override' in the method declaration may be helpful to the guy reading the code, and assuming types are being used with wisdom, it will reduce the need to jump to the definition of the parent class (which I suppose is just a click away anyway).
During the development phase someone may modify the parent class declaration without realizing that there exists dependencies and thus render the code overriding it ineffective without the compiler blinking an eye.
I personally see that the slight advantage of less verboseness (writing one word less) given by not using such keywords is smaller than the slight advantage of better documentation and better compiler feedback.
(For the record: I haven't written a single line of C#, but many, many lines of C++.)
I think a new keyword for overriding is actually a good idea. Have you never had this happen to you?
..
..and Bar::foo never gets called, and no warnings were issued by the compiler.
class Foo {
virtual void foo(int a, std::string b) { std::cout << "Default implementation: " << a << b << std::endl; }
};
class Bar: public Foo {
void foo(std::string a, int b) { std::cout << "Custom implementation: " << a << b << std::endl; }
};
Maybe they aren't your files you are manipulating. Maybe some user of your system decided that it's a good idea to put newlines in filenames. Maybe your backup scripts crash and burn horribly because of this.
And why shouldn't her? The system obviously permits doing it. If they pose a difficulty in handling, the difficulties should be overcome, the user should not be forced upon some invisible rules.
Yeah, I know you can use for example zsh and gnu tools to overcome these kinds of trouble (with the support for 0-terminated strings), but it still comes down to that when manipulating information streams you still need to think about the low-level representation. It would be nice if handling binary data would be just as easy as handling anything else in the shell. But as the defacto interprocess communication protocol is line based, things can break horribly.
What I would like to know about this MSH is that how is handles multiple processes/threads.. That is, if you create a dataset of 1000000 elements and then select | where it, will the elements be first retrieved to memory and then processed, or does it behave 'right'? And if it does behave efficiently, what does { $f = 4 } | { $f } output?
I would like to see a shell with types (even if dynamic, although atleast partially static type system would be cool) on Unix too, but unfortunately it would, with the current set of tools, mean that lots of the code would be written simply for converting data back and forth between different defacto tools, such as sed, perl and awk. Or maybe some bright person could figure out how to make that border transparent..
ITYM 'Automatic ATM machines', 'Personal PIN number' and 'Liquid LCD display' (hmh, the last one has a bit more unnatural sound..), HTH.