Re-reading the posts I've tagged with the anonymity label, I think I finally put my finger on something that had been bothering me pretty much from the beginning. I'd argued (here, for example) that economic considerations should make it hard to successfully run an anonymizer -- a service that allows you to connect with sites on the internet without giving away who or where you are. And yet they exist.
The argument was that the whole point of an anonymizer is that whoever's connecting to a given site could be anyone using the anonymizer, that is, if you're using the anonymizer, you could be associated with anything that anyone on the anonymizer was doing. Since some things that people want to do anonymously are risky, an anonymizer is, in some sense, distributing risk. People doing risky things should be happy to participate, but people doing less risky things may not be so willing. As a result, there may not be enough people participating to provide adequate cover.
However, this assumes that anyone can be (mis)taken for anyone else. At the technical level of IP addresses, this is true, but at the level of who's actually doing what, which is what really matters if The Man comes knocking, it's less applicable.
There are lots of reasons to want anonymity -- the principle of the thing, the ability to do stuff you're not supposed to be able to do at work, wanting to hide embarrassing activity from the people around you, wanting to blow the whistle on an organization, communicating to the outside world from a repressive regime, dealing in illicit trade, planning acts of violence and many others. The fact of using an anonymizer says little about why you might be doing it.
If I'm anonymously connecting to FaceSpace at work, there's little chance that the authorities in whatever repressive regime will come after me for plotting to blow up their government buildings, and vice versa (mutatis mutandis et cetera.). In other words, there's probably not much added risk for people doing relatively innocuous things in places where using an anonymizer is not itself illegal.
On the other hand, this is little comfort to someone trying to, say, send information out of a place where use of the internet, and probably anonymizers in particular, is restricted. The local authorities will probably know exactly which hosts are connecting with the anonymizer's servers and make it their business to find out who's associated with those hosts -- a much smaller task than tracking down all users of the anonymizer.
This is much the same situation as, say, spies in WWII trying to send radio messages out before the local authorities can triangulate their position. Many of the same techniques should apply -- never setting up in the same place twice, limiting the number of people you communicate with and how much you know about them, limiting the amount of information you know, and so forth.
So I suppose I'll be filing this under not-so-disruptive technology as well as anonymity.
Sunday, October 7, 2018
Saturday, September 29, 2018
Agile vs. waterfall
Another comment reply that outgrew the comment box. Earl comments
Sort of ... "agile" is a term of art that refers to a collection of practices aimed at reducing the lag between finding out people want something and giving it to them. Arguably the core of it is "launch and iterate", meaning "put your best guess out there, find out what it still needs, fix the most important stuff and try again".
This is more process than design, but there are definitely some design rules that tend to go with agile development, particularly "YAGNI", short for "You ain't gonna need it", which discourages trying to anticipate a need you don't yet know that you have. In more technical terms, this means not trying to build a general framework for every possible use case, but being prepared to "refactor" later on if you find out that you need to do more than you thought you did. Or, better, designing in such a way that later functionality can be added with minimum disruption to what's already there, often by having less to disrupt to begin with, because ... YAGNI.
Downey refers to "agile" both generally and in the more specific context of "agile vs. waterfall". The "waterfall" design process called for exhaustively gathering all requirements up front, then producing a design to meet those requirements, then implementing the design, then independently testing the implementation against the requirements, fixing any bugs, retesting and eventually delivering a product to the customer. Each step of the process flows into the next, and you only go forward, much like water flowing over a series of cascades. Only the test/fix/retest/... cycle was meant to be iterative, and ideally with as few iterations as possible. Waterfall projects can take months at the least and more typically years to get through all the steps, at which point there's a significant chance that the customer's understanding of what they want has evolved -- but don't worry, we can always gather more requirements, produce an improved design ...
(As an aside, Downey alludes to discussion over whether "customer" is an appropriate term for someone, say, accessing a public data website. A fair point. I'm using "customer" here because in this case this is someone paying money for a the service of producing software. The concept of open source cuts against this, but that's a whole other discussion.)
The waterfall approach can be useful in situations like space missions and avionics. In the first case, when you launch, you're literally launched and there is no "iterate". In the second, the cost of an incomplete or not-fully-vetted implementation is too high to risk. However, there's a strong argument to be made that "launch and iterate" works in more cases than one might think.
In contrast to waterfall approaches, agile methodologies think more in terms of weeks. A series of two-week "sprints", each producing some number of improvements from a list, is a fairly common approach. Some web services go further and use a "push on green" process where anything that passes the tests (generally indicated by a green bar on a test console) goes live immediately. Naturally, part of adding a new feature is adding tests that it has to pass, but that should generally be the case anyway.
Superficially, a series of two-week sprints may seem like a waterfall process on a shorter time scale, but I don't think that's a useful comparison. In a classic waterfall, you talk to your customer up front and then go dark for months, or even a year or more while the magic happens, though the development managers may produce a series of progress reports with an aggregate number of requirements implemented or such. Part of the idea or short sprints, on the other hand, is to stay in contact with your customer in order to get frequent feedback on whether you're doing the right thing. Continuous feedback is one of the hallmarks of a robust control system, whether in software or steam engines.
There are also significant differences in the details of the processes. In an agile process, the list of things to do (often organized by "stories") can and does get updated at any time. The team will generally pick a set of things to implement at the the beginning of a sprint in order to coordinate their efforts, but this is more a tactical decision, and "requirements gathering" is not blocked while the developers are implementing.
Work in agile shops tends to be estimated in relative terms like "small", "medium" or "large", since people are much better at estimating relative sizes, and there's generally an effort to break "large" items into smaller pieces since people are better at estimating them. Since this is done frequently, everyone ends up doing a bunch of fairly small-scale estimates on a regular basis, and hopefully skills improve.
Waterfall estimates are generally done up front by specialists. By the end of the design phase, you should have a firm estimate of how long the rest will take (and, a cynic might add, a firm expectation of putting in serious overtime as the schedule begins to slip).
It's not clear how common a true waterfall process is in practice. I've personally only seen it once up close, and the result was a slow-motion trainwreck the likes of which I hope never to see again. Among other things, the process called for designers to reduce their designs to "pseudocode", which is basically a detailed description of an algorithm using words instead of a formal computer language.
This was to be done in such detail that the actual coder hired to produce the code would not have to make any decisions in translating the pseudocode to actual code. This was explicitly stated in the (extensive) process documentation. But if you can explain something in that much detail, you've essentially coded it and you're just using the coder as an expensive human typewriter, not a good proposition for anyone involved. You've also put a layer of scheduling and paperwork between designing an algorithm and finding out whether it works.
We did, however, produce an impressive volume of paper binders full of documentation. I may still have a couple somewhere. I'm not sure I or anyone else has ever needed to read them.
This is an extreme case, but the mindset behind it is pervasive enough to make "agile vs. waterfall" a real controversy. As with all such controversy at least some of the waterfallish practices actually out there have more merit than the extreme case. The extreme case, even though it does exist in places, functions more as a strawman. Nonetheless, I tend to favor the sort of "admirable impatience" that Downey exemplifies. Like anything else it can be taken too far, but not in the case at hand.
This speaks to my prejudice in favor of technique over technology. And the concept of agility seems to be just the attitude of any good designer that your best weapon is your critical sense, and your compulsion to discard anything that isn't going to work.To which I would reply:
Sort of ... "agile" is a term of art that refers to a collection of practices aimed at reducing the lag between finding out people want something and giving it to them. Arguably the core of it is "launch and iterate", meaning "put your best guess out there, find out what it still needs, fix the most important stuff and try again".
This is more process than design, but there are definitely some design rules that tend to go with agile development, particularly "YAGNI", short for "You ain't gonna need it", which discourages trying to anticipate a need you don't yet know that you have. In more technical terms, this means not trying to build a general framework for every possible use case, but being prepared to "refactor" later on if you find out that you need to do more than you thought you did. Or, better, designing in such a way that later functionality can be added with minimum disruption to what's already there, often by having less to disrupt to begin with, because ... YAGNI.
Downey refers to "agile" both generally and in the more specific context of "agile vs. waterfall". The "waterfall" design process called for exhaustively gathering all requirements up front, then producing a design to meet those requirements, then implementing the design, then independently testing the implementation against the requirements, fixing any bugs, retesting and eventually delivering a product to the customer. Each step of the process flows into the next, and you only go forward, much like water flowing over a series of cascades. Only the test/fix/retest/... cycle was meant to be iterative, and ideally with as few iterations as possible. Waterfall projects can take months at the least and more typically years to get through all the steps, at which point there's a significant chance that the customer's understanding of what they want has evolved -- but don't worry, we can always gather more requirements, produce an improved design ...
(As an aside, Downey alludes to discussion over whether "customer" is an appropriate term for someone, say, accessing a public data website. A fair point. I'm using "customer" here because in this case this is someone paying money for a the service of producing software. The concept of open source cuts against this, but that's a whole other discussion.)
The waterfall approach can be useful in situations like space missions and avionics. In the first case, when you launch, you're literally launched and there is no "iterate". In the second, the cost of an incomplete or not-fully-vetted implementation is too high to risk. However, there's a strong argument to be made that "launch and iterate" works in more cases than one might think.
In contrast to waterfall approaches, agile methodologies think more in terms of weeks. A series of two-week "sprints", each producing some number of improvements from a list, is a fairly common approach. Some web services go further and use a "push on green" process where anything that passes the tests (generally indicated by a green bar on a test console) goes live immediately. Naturally, part of adding a new feature is adding tests that it has to pass, but that should generally be the case anyway.
Superficially, a series of two-week sprints may seem like a waterfall process on a shorter time scale, but I don't think that's a useful comparison. In a classic waterfall, you talk to your customer up front and then go dark for months, or even a year or more while the magic happens, though the development managers may produce a series of progress reports with an aggregate number of requirements implemented or such. Part of the idea or short sprints, on the other hand, is to stay in contact with your customer in order to get frequent feedback on whether you're doing the right thing. Continuous feedback is one of the hallmarks of a robust control system, whether in software or steam engines.
There are also significant differences in the details of the processes. In an agile process, the list of things to do (often organized by "stories") can and does get updated at any time. The team will generally pick a set of things to implement at the the beginning of a sprint in order to coordinate their efforts, but this is more a tactical decision, and "requirements gathering" is not blocked while the developers are implementing.
Work in agile shops tends to be estimated in relative terms like "small", "medium" or "large", since people are much better at estimating relative sizes, and there's generally an effort to break "large" items into smaller pieces since people are better at estimating them. Since this is done frequently, everyone ends up doing a bunch of fairly small-scale estimates on a regular basis, and hopefully skills improve.
Waterfall estimates are generally done up front by specialists. By the end of the design phase, you should have a firm estimate of how long the rest will take (and, a cynic might add, a firm expectation of putting in serious overtime as the schedule begins to slip).
It's not clear how common a true waterfall process is in practice. I've personally only seen it once up close, and the result was a slow-motion trainwreck the likes of which I hope never to see again. Among other things, the process called for designers to reduce their designs to "pseudocode", which is basically a detailed description of an algorithm using words instead of a formal computer language.
This was to be done in such detail that the actual coder hired to produce the code would not have to make any decisions in translating the pseudocode to actual code. This was explicitly stated in the (extensive) process documentation. But if you can explain something in that much detail, you've essentially coded it and you're just using the coder as an expensive human typewriter, not a good proposition for anyone involved. You've also put a layer of scheduling and paperwork between designing an algorithm and finding out whether it works.
We did, however, produce an impressive volume of paper binders full of documentation. I may still have a couple somewhere. I'm not sure I or anyone else has ever needed to read them.
This is an extreme case, but the mindset behind it is pervasive enough to make "agile vs. waterfall" a real controversy. As with all such controversy at least some of the waterfallish practices actually out there have more merit than the extreme case. The extreme case, even though it does exist in places, functions more as a strawman. Nonetheless, I tend to favor the sort of "admirable impatience" that Downey exemplifies. Like anything else it can be taken too far, but not in the case at hand.
Friday, September 28, 2018
One CSV, 30 stories (for small values of 30)
While re-reading some older posts on anonymity (of which more later, probably), and updating the occasional broken link, I happened to click through on the credit link on my profile picture. Said link is still in fine fettle and, while it hasn't been updated in a while, and one of the more recent posts is Paul Downey chastising himself for just that, there's still plenty of interesting material there, including the (current) last post, now nearly three years old, with a brilliant observation on "scope creep".
What caught my attention in particular was the series One CSV, thirty stories, which took on the "do 30 Xs in 30 days" kind of challenge in an effort to kickstart the blog. Taken literally, it wasn't a great success -- there only ended up being 21 stories, and there hasn't been much on the blog since -- but purely from a blogging point of view I'd say the experiment was indeed a success.
Downey takes a single, fairly large, CSV file containing records of land sales transactions from the UK and proceeds to turn this raw data into useful and interesting information. The analysis starts with basic statistics such as how many transactions there are (about 19 million), how many years they cover (20) and how much money changed hands (about £3 trillion) and ends up with some nifty visualizations showing changes in activity from day to day within the week, over the course of the year and over decades.
This is all done with off-the-shelf tools, starting with old-school Unix commands that date back to the 70s and then pulling together various free-source from off the web. Two of Downey's recurring themes, which were very much evident to me when we worked together on standards committees, um, a few years ago, are also very much in evidence here: A deep commitment to open data and software, and an equally strong conviction that one can and should be able to do significant things with data using basic and widely available tools.
A slogan that pops up a couple of times in the stories is "Making things open makes them better". In this spirit, all the code and data used is publicly available. Even better, though, the last story, Mistakes were made, catches the system in the act of improving itself due to its openness. On a smaller scale, reader suggestions are incorporated in real time and several visualizations benefit from collaboration with colleagues.
There's even a "hack day" in the middle. If anything sums up Downey's ideal of how technical collaboration should work, it's this: "My two favourite hacks had multidisciplinary teams build something, try it with users, realise it was the wrong thing, so built something better as a result. All in a single day!" It's one thing to believe in open source, agile development and teamwork in the abstract. The stories show them in action.
As to the second theme, the whole series, from the frenetic "30 things in 30 days" pace through to the actual results, shows an admirable sort of impatience: Let's not spend a lot of time spinning up the shiniest tools on a Big Data server farm. I've got a laptop. It's got some built-in commands. I've got some data. Let's see what we can find out.
Probably my favorite example is the use of geolocation in Postcodes. It would be nice to see sales transactions plotted on a map of the UK. Unfortunately, we don't have one of those handy, and they're surprisingly hard to come by and integrate with, but never mind. Every transaction is tagged with a "northing" and "easting", basically latitude and longitude, and there are millions of them. Just plot them spatially and, voila, a map of England and Wales, incidentally showing clearly that the data set doesn't cover Scotland or Northern Ireland.
I wouldn't say that just anyone could do the same analyses in 30 days, but neither is there any deep wizardry going on. If you've taken a couple of courses in computing, or done a moderate amount of self-study, you could almost certainly figure out how the code in the stories works and do some hacking on it yourself (in which case, please contribute anything interesting back to the repository). And then go forth and hack on other interesting public data sets, or, if you're in a position to do so, make some interesting data public yourself (but please consult with your local privacy expert first).
In short, these stories are an excellent model of what the web was meant to be: open, collaborative, lightweight and fast.
Technical content aside, there are also several small treasures in the prose, from Wikipedia links on a variety of subjects to a bit on the connection between the cover of Joy Division's Unknown Pleasures and the discovery of pulsars by Jocelyn Bell Burnell et. al..
Finally, one of the pleasures of reading the stories was their sheer Englishness (and, if I understand correctly, their Northeast Englishness in particular). The name of the blog is whatfettle. I've already mentioned postcodes, eastings and northings, but the whole series is full of Anglicisms -- whilst, a spot of breakfast, cock-a-hoop, if you are minded, splodgy ... Not all of these may be unique to the British Isles, but the aggregate effect is unmistakeable.
I hesitate to even mention this for fear of seeming to make fun of someone else's way of speaking, but that's not what I'm after at all. This isn't cute or quaint, it's just someone speaking in their natural manner. The result is located or even embodied. On the internet, anyone could be anywhere, and we all tend to pick up each other's mannerisms. But one fundamental aspect of the web is bringing people together from all sorts of different backgrounds. If you buy that, then what's the point if no one's background shows through?
What caught my attention in particular was the series One CSV, thirty stories, which took on the "do 30 X
Downey takes a single, fairly large, CSV file containing records of land sales transactions from the UK and proceeds to turn this raw data into useful and interesting information. The analysis starts with basic statistics such as how many transactions there are (about 19 million), how many years they cover (20) and how much money changed hands (about £3 trillion) and ends up with some nifty visualizations showing changes in activity from day to day within the week, over the course of the year and over decades.
This is all done with off-the-shelf tools, starting with old-school Unix commands that date back to the 70s and then pulling together various free-source from off the web. Two of Downey's recurring themes, which were very much evident to me when we worked together on standards committees, um, a few years ago, are also very much in evidence here: A deep commitment to open data and software, and an equally strong conviction that one can and should be able to do significant things with data using basic and widely available tools.
A slogan that pops up a couple of times in the stories is "Making things open makes them better". In this spirit, all the code and data used is publicly available. Even better, though, the last story, Mistakes were made, catches the system in the act of improving itself due to its openness. On a smaller scale, reader suggestions are incorporated in real time and several visualizations benefit from collaboration with colleagues.
There's even a "hack day" in the middle. If anything sums up Downey's ideal of how technical collaboration should work, it's this: "My two favourite hacks had multidisciplinary teams build something, try it with users, realise it was the wrong thing, so built something better as a result. All in a single day!" It's one thing to believe in open source, agile development and teamwork in the abstract. The stories show them in action.
As to the second theme, the whole series, from the frenetic "30 things in 30 days" pace through to the actual results, shows an admirable sort of impatience: Let's not spend a lot of time spinning up the shiniest tools on a Big Data server farm. I've got a laptop. It's got some built-in commands. I've got some data. Let's see what we can find out.
Probably my favorite example is the use of geolocation in Postcodes. It would be nice to see sales transactions plotted on a map of the UK. Unfortunately, we don't have one of those handy, and they're surprisingly hard to come by and integrate with, but never mind. Every transaction is tagged with a "northing" and "easting", basically latitude and longitude, and there are millions of them. Just plot them spatially and, voila, a map of England and Wales, incidentally showing clearly that the data set doesn't cover Scotland or Northern Ireland.
I wouldn't say that just anyone could do the same analyses in 30 days, but neither is there any deep wizardry going on. If you've taken a couple of courses in computing, or done a moderate amount of self-study, you could almost certainly figure out how the code in the stories works and do some hacking on it yourself (in which case, please contribute anything interesting back to the repository). And then go forth and hack on other interesting public data sets, or, if you're in a position to do so, make some interesting data public yourself (but please consult with your local privacy expert first).
In short, these stories are an excellent model of what the web was meant to be: open, collaborative, lightweight and fast.
Technical content aside, there are also several small treasures in the prose, from Wikipedia links on a variety of subjects to a bit on the connection between the cover of Joy Division's Unknown Pleasures and the discovery of pulsars by Jocelyn Bell Burnell et. al..
Finally, one of the pleasures of reading the stories was their sheer Englishness (and, if I understand correctly, their Northeast Englishness in particular). The name of the blog is whatfettle. I've already mentioned postcodes, eastings and northings, but the whole series is full of Anglicisms -- whilst, a spot of breakfast, cock-a-hoop, if you are minded, splodgy ... Not all of these may be unique to the British Isles, but the aggregate effect is unmistakeable.
I hesitate to even mention this for fear of seeming to make fun of someone else's way of speaking, but that's not what I'm after at all. This isn't cute or quaint, it's just someone speaking in their natural manner. The result is located or even embodied. On the internet, anyone could be anywhere, and we all tend to pick up each other's mannerisms. But one fundamental aspect of the web is bringing people together from all sorts of different backgrounds. If you buy that, then what's the point if no one's background shows through?
Thursday, May 31, 2018
Cookies, https and OpenId
I finally got around to looking at the various notices that have accumulated on the admin pages for this blog. As a result:
- This blog is supposed to display a notice regarding cookies if you access it from the EU. I'm not sure that this notice is actually appearing when it should (I've sent feedback to try to clarify), but as far as I can tell blogspot is handling cookies for this blog just like any other. I have not tried to explicitly change that behavior.
- This blog has for some time used "redirect to https". This means that if you try to access this blog via http://, it will be automatically changed to https://. This shouldn't make any difference. On the one hand, https has been around for many years, all browsers I know of handle it just fine and in any case this blog has been redirecting to https for a long time without incident. On the other hand, this is a public blog, so there's no sensitive private information here. It might maybe make a difference if you have to do some sort of login to leave comments, but I doubt it.
- Blogger no longer supports OpenID. I think this would only matter if I'd set up "trust these web sites" under the OpenId settings, but I didn't.
In other words, this should all be a whole lot of nothing, but I thought I'd let people know.
Friday, May 18, 2018
Bombshell revelations about Hedy Lamarr (sorry, couldn't resist)
A while ago I posted about the role of actor/inventor Hedy Lamarr in the development of the "frequency hopping" communication technology now used in cell phones, WiFi, Bluetooth and various military applications, among others. Now (well, since last year) there's a whole movie about it: Bombshell: The Hedy Lamarr Story. In fact, there's actually something of a cottage industry in Lamarr-related productions, including books, plays, magazine articles and not a few blog posts.
The movie goes into detail on Lamarr's life, from her childhood in Vienna to her Hollywood career, her relationship with aviation magnate Howard Hughes (who provided access to his company's chemists and engineers for her personal projects), her now-famous patent with George Antheil, her reclusive later days and her eventual recognition for her technical contributions. There are fresh interviews with friends, admirers, children and grandchildren along with archival interviews of Lamarr herself, altogether providing a well-rounded view of a lively mind.
Bombshell and the Hedy Lamarr revival in general have given long-overdue appreciation to someone who until recently was most recognized for her work in an industry concerned nearly exclusively with her looks, despite her efforts to find more challenging roles and her ultimately unsuccessful attempts to break into producing. My one quibble with the film concerns the impact of her patent. Because geek.
It is clear that US Navy contractors used the patent directly in the development of a communication system among ships, planes and sonobuoys and that a related system was used during the naval blockade in the Cuban missile crisis. At least some of that work was done before the patent expired, lending support to Lamarr's claim that she was due the customary payment for the use of her and Antheil's invention.
It's also clear that Antheil contributed significantly to the patent, particularly because he had experience in synchronizing player pianos. The scheme used 88 frequencies, one for each key on a piano, and needed the ship's radio and the torpedo's to stay in sync. Three guesses how this was accomplished. Nonetheless, the initial idea of frequency hopping was Lamarr's and it was she who actively recruited Antheil for assistance with the practical design.
This was a real, significant contribution to communications, and one that was put to practical use, albeit not as originally designed, including in one of the most critical moments of the 20th century. Neither was it a fluke. Lamarr had a lifelong interest in what we now call STEM and this was not her only invention, just the most successful. From what I've seen I have no doubt at all of her geek cred.
However, we should be careful not to go too far, as least not without providing a bit of perspective. The film itself doesn't go so far as to say Lamarr invented WiFi. That would simply not be accurate, though that hasn't stopped the occasional web site from making just that claim. However, it does heavily imply that frequency hopping plays a major role in, for example, the security of military satellites, and it explicitly calls out WiFi, bluetooth and cell phones to claim that Lamarr's invention touches a huge swath of modern-day humanity.
Yes, but ... No one person invented WiFi, which includes everything from the use of the frequency spectrum to the handshaking and security protocols, an implementation of IP (internet protocol) and the specification of metadata such as the SSID. Likewise, Lamarr's is not the only patent or invention concerning frequency hopping. None other than Nikola Tesla filed an early patent describing it. Wikipedia has a summary of other developments of the concept, including use by the German military in World War I, well before Lamarr and Antheil's patent.
WiFi certainly doesn't use piano rolls to select frequencies. Technology has marched on in the decades since then. If we're going to credit the general concept of frequency hopping, we should recognize its full history, not just Lamarr's contribution. Likewise for frequency hopping in the context of Bluetooth and CDMA in cell phones.
As to security, while the patent was originally filed for a "secret communication system", frequency hopping doesn't provide meaningful security against modern attackers. Any real security is provided by encryption systems built on usual suspects like DES and RSA, which operate on completely different principles and were of course developed completely separately. To see this, look no further than WiFi, whose original security was notoriously weak, even though it included both frequency hopping and an encryption layer on top of that. Neither that layer nor the later improvements have anything to do with frequency hopping.
On the other hand, another of Lamarr's original motivations was to circumvent jamming -- flooding a frequency with enough noise to drown out any real communication. Frequency hopping with a shared key -- the gist of the patent -- is still effective for that. If you don't know which of several dozen frequencies the actual signal is on, you have jam all of them, which requires proportionately more power and might not even be practical in some situations. That's very much alive, and important in military applications, but it's not a form of secrecy and it has little to do with WiFi or bluetooth, except that switching WiFi or Bluetooth frequencies can avoid accidental interference from other devices.
By all accounts Hedy Lamarr was an impressive person: talented, highly intelligent, diligent, creative and in many respects ahead of her times. Bombshell does a fine job conveying this, and, probably more importantly, the often tragic tension between who she was and who most of the world wanted her to be. It is also forthright about her flaws and failings and it even does a decent job with the technical details, even considering the critiques above. All this is well worth recognizing and celebrating. Putting Lamarr and Antheil's patent in proper perspective does nothing to diminish this, even if it takes away the easy narrative of Lamarr the unsung hero of the mobile revolution.
The movie goes into detail on Lamarr's life, from her childhood in Vienna to her Hollywood career, her relationship with aviation magnate Howard Hughes (who provided access to his company's chemists and engineers for her personal projects), her now-famous patent with George Antheil, her reclusive later days and her eventual recognition for her technical contributions. There are fresh interviews with friends, admirers, children and grandchildren along with archival interviews of Lamarr herself, altogether providing a well-rounded view of a lively mind.
Bombshell and the Hedy Lamarr revival in general have given long-overdue appreciation to someone who until recently was most recognized for her work in an industry concerned nearly exclusively with her looks, despite her efforts to find more challenging roles and her ultimately unsuccessful attempts to break into producing. My one quibble with the film concerns the impact of her patent. Because geek.
It is clear that US Navy contractors used the patent directly in the development of a communication system among ships, planes and sonobuoys and that a related system was used during the naval blockade in the Cuban missile crisis. At least some of that work was done before the patent expired, lending support to Lamarr's claim that she was due the customary payment for the use of her and Antheil's invention.
It's also clear that Antheil contributed significantly to the patent, particularly because he had experience in synchronizing player pianos. The scheme used 88 frequencies, one for each key on a piano, and needed the ship's radio and the torpedo's to stay in sync. Three guesses how this was accomplished. Nonetheless, the initial idea of frequency hopping was Lamarr's and it was she who actively recruited Antheil for assistance with the practical design.
This was a real, significant contribution to communications, and one that was put to practical use, albeit not as originally designed, including in one of the most critical moments of the 20th century. Neither was it a fluke. Lamarr had a lifelong interest in what we now call STEM and this was not her only invention, just the most successful. From what I've seen I have no doubt at all of her geek cred.
However, we should be careful not to go too far, as least not without providing a bit of perspective. The film itself doesn't go so far as to say Lamarr invented WiFi. That would simply not be accurate, though that hasn't stopped the occasional web site from making just that claim. However, it does heavily imply that frequency hopping plays a major role in, for example, the security of military satellites, and it explicitly calls out WiFi, bluetooth and cell phones to claim that Lamarr's invention touches a huge swath of modern-day humanity.
Yes, but ... No one person invented WiFi, which includes everything from the use of the frequency spectrum to the handshaking and security protocols, an implementation of IP (internet protocol) and the specification of metadata such as the SSID. Likewise, Lamarr's is not the only patent or invention concerning frequency hopping. None other than Nikola Tesla filed an early patent describing it. Wikipedia has a summary of other developments of the concept, including use by the German military in World War I, well before Lamarr and Antheil's patent.
WiFi certainly doesn't use piano rolls to select frequencies. Technology has marched on in the decades since then. If we're going to credit the general concept of frequency hopping, we should recognize its full history, not just Lamarr's contribution. Likewise for frequency hopping in the context of Bluetooth and CDMA in cell phones.
As to security, while the patent was originally filed for a "secret communication system", frequency hopping doesn't provide meaningful security against modern attackers. Any real security is provided by encryption systems built on usual suspects like DES and RSA, which operate on completely different principles and were of course developed completely separately. To see this, look no further than WiFi, whose original security was notoriously weak, even though it included both frequency hopping and an encryption layer on top of that. Neither that layer nor the later improvements have anything to do with frequency hopping.
On the other hand, another of Lamarr's original motivations was to circumvent jamming -- flooding a frequency with enough noise to drown out any real communication. Frequency hopping with a shared key -- the gist of the patent -- is still effective for that. If you don't know which of several dozen frequencies the actual signal is on, you have jam all of them, which requires proportionately more power and might not even be practical in some situations. That's very much alive, and important in military applications, but it's not a form of secrecy and it has little to do with WiFi or bluetooth, except that switching WiFi or Bluetooth frequencies can avoid accidental interference from other devices.
By all accounts Hedy Lamarr was an impressive person: talented, highly intelligent, diligent, creative and in many respects ahead of her times. Bombshell does a fine job conveying this, and, probably more importantly, the often tragic tension between who she was and who most of the world wanted her to be. It is also forthright about her flaws and failings and it even does a decent job with the technical details, even considering the critiques above. All this is well worth recognizing and celebrating. Putting Lamarr and Antheil's patent in proper perspective does nothing to diminish this, even if it takes away the easy narrative of Lamarr the unsung hero of the mobile revolution.
Saturday, April 7, 2018
Bitcoin and the B-word
It's not hard these days to find a chart comparing the price of Bitcoin to the NASDAQ from the dotcom bubble. They line up pretty well, provided you stretch the time scale of Bitcoin out considerably on the way up and somewhat less considerably on the way down. Whether this means Bitcoin is actually in a bubble is something we don't know just yet. Bubbles are only referred to with certainty in past tense: "That was a bubble".
There are arguments on either side. One that I don't buy is "The last time Bitcoin fell by X amount, it later rose by way-more-than-X amount." That's nice, but I'd kinda like to see a mechanism, not just numbers. There aren't that many 10X jumps left before Bitcoin is literally all the money in the world (I do realize that that's the endgame if you're a hardcore cryptocurrency advocate). There are interesting questions about just exactly how that would happen, but what happens after that? What does it mean for Bitcoin to appreciate another 10X over the dollar if there are no more dollars?
Presumably at some point BTC rising against the dollar no longer means that Bitcoin is becoming more valuable in terms of the goods and services a Bitcoin can purchase, but that the dollar is becoming less valuable in real terms until it finally goes away. How we get hyperinflation in a currency whose supply is going to zero is an interesting question. I'm not sure there are any historical precedents here. When the major currencies went off the gold standard in the 20th century, gold was still there and still had value. If dollars go away entirely then at some point we're dividing zero by zero, which can come out to any number you like.
But, for the Nth time in drafting this post, I digress down a rabbit hole of speculation over Just What Does It All Mean. The question I wanted to address here is, "Is Bitcoin in a bubble?"
But I already answered that. One of the defining properties of a bubble is you don't know for sure if you're in it. It's possible, at least in principle, that the price of Bitcoin could stabilize in some fairly tight range, and if that range isn't too far off the top (somewhere north of $19K) then we had some wild fluctuations, but not a bubble. If it keeps falling toward zero, even if it eventually stabilizes around $1000, or $100, or $10 or whatever, then I think you'll have to say we had a bubble.
Does it matter?
I'd say not really. If you're trading BTC, the important part is how you came out. You might have made a lot of money, or lost it, or even both, but you can do that trading blue chips on the NYSE (How do you make a small fortune on Wall Street? Start with a large one.) If you're interested in Bitcoin as a store of value or a payment system or whatever, then what matters is whether that comes to pass, not the exact price of BTC when that may happen.
People throw around terms like "correction", "crash" or "bubble collapse" mainly, I think, to express an opinion about what's going to happen, not what has. A correction implies that things got a bit out of hand but everything will be fine in the long run. A crash means prices fell far and fast, but doesn't really say anything about the future. A bubble collapse says that not only did prices fall, but there was much less ever there than people thought at the time. If prices ever do recover, it won't be for a good long time, and for much different reasons than drove the runup to the bubble bursting. Which of those is happening now depends on who you ask (though it's hard to call a 60%+ drop off the top a correction with a straight face).
I think that, along with the previous post, is about all I want to say about Bitcoin for a while. I note that it's been a prevalent topic here for a while -- not that I've been posting that much on anything here -- and there's got to be other web.stuff to talk about.
There are arguments on either side. One that I don't buy is "The last time Bitcoin fell by X amount, it later rose by way-more-than-X amount." That's nice, but I'd kinda like to see a mechanism, not just numbers. There aren't that many 10X jumps left before Bitcoin is literally all the money in the world (I do realize that that's the endgame if you're a hardcore cryptocurrency advocate). There are interesting questions about just exactly how that would happen, but what happens after that? What does it mean for Bitcoin to appreciate another 10X over the dollar if there are no more dollars?
Presumably at some point BTC rising against the dollar no longer means that Bitcoin is becoming more valuable in terms of the goods and services a Bitcoin can purchase, but that the dollar is becoming less valuable in real terms until it finally goes away. How we get hyperinflation in a currency whose supply is going to zero is an interesting question. I'm not sure there are any historical precedents here. When the major currencies went off the gold standard in the 20th century, gold was still there and still had value. If dollars go away entirely then at some point we're dividing zero by zero, which can come out to any number you like.
But, for the Nth time in drafting this post, I digress down a rabbit hole of speculation over Just What Does It All Mean. The question I wanted to address here is, "Is Bitcoin in a bubble?"
But I already answered that. One of the defining properties of a bubble is you don't know for sure if you're in it. It's possible, at least in principle, that the price of Bitcoin could stabilize in some fairly tight range, and if that range isn't too far off the top (somewhere north of $19K) then we had some wild fluctuations, but not a bubble. If it keeps falling toward zero, even if it eventually stabilizes around $1000, or $100, or $10 or whatever, then I think you'll have to say we had a bubble.
Does it matter?
I'd say not really. If you're trading BTC, the important part is how you came out. You might have made a lot of money, or lost it, or even both, but you can do that trading blue chips on the NYSE (How do you make a small fortune on Wall Street? Start with a large one.) If you're interested in Bitcoin as a store of value or a payment system or whatever, then what matters is whether that comes to pass, not the exact price of BTC when that may happen.
People throw around terms like "correction", "crash" or "bubble collapse" mainly, I think, to express an opinion about what's going to happen, not what has. A correction implies that things got a bit out of hand but everything will be fine in the long run. A crash means prices fell far and fast, but doesn't really say anything about the future. A bubble collapse says that not only did prices fall, but there was much less ever there than people thought at the time. If prices ever do recover, it won't be for a good long time, and for much different reasons than drove the runup to the bubble bursting. Which of those is happening now depends on who you ask (though it's hard to call a 60%+ drop off the top a correction with a straight face).
I think that, along with the previous post, is about all I want to say about Bitcoin for a while. I note that it's been a prevalent topic here for a while -- not that I've been posting that much on anything here -- and there's got to be other web.stuff to talk about.
Thursday, April 5, 2018
Crypto assets
A large portion of what one might read about Bitcoin and company online falls into a few broad classes:
- Bitcoin is totally a bubble!
- It's unfolding just like the dotcom bubble around the turn of the century, but a lot faster
- Bitcoin isn't actually worth anything
- Bitcoin is totally not a bubble!
- The last time it crashed it was way, way up a year later. Do you really want to miss out?
- Cryptocurrencies will take over the world. The world's money supply is worth tens of trillions of dollars, so BTC is conservatively worth at least $1 million (or something along those lines).
- You're all missing the point. It's not Bitcoin, it's the blockchain.
- Blockchains are useful because they provide a secure, shared, decentralized ledger
- Even if a particular currency fizzles out, there's still value in the technology
While researching a separate post, which I may or may not end up actually posting [I did, more or less -- see next post], I ran across this much more nuanced take by Adam Ludwin on the blog for chain.com. If nothing else, I love the disclaimers at the top, a bullet list ending with several "Very few people <in some group> understand what's going on" and finally "It’s very possible I don’t understand what’s going on".
In that spirit, a disclaimer or two of my own: I'd never heard of Chain or Adam Ludwin before this and I have no financial interest in it or in any crypto currency. I do note that Chain's tagline is "We build cryptographic ledgers that underpin breakthrough financial products," so it's pretty clear what Ludwin/Chain's basic stance is (and, of course, that's a good thing).
The piece itself is to some extent in the third bucket above, except with a lot more thought and detail and without the usual air of certainty. The thesis, as I understand it, is that Bitcoin and things like it are properly assets, not currency, and their value lies in supporting a certain class of distributed application where various people contribute resources to the application as a whole, and/or consume such resources.
To make this work there has to be some sort of ledger that everyone trusts. One way to do that is to put someone -- say, a bank -- in charge of the ledger. Crypto assets provide an alternative, namely a secure ledger with no single, centralized authority, which can be trusted without having to trust all the other participants, or even any particular participant.
Ludwin is careful to point out that this is not always, or even often, worth the trouble. A decentralized, secure ledger incurs significant overhead, since one way or another you have to be sure that the various parties can agree on what's in the ledger. More importantly, at least in my view, a decentralized system is by definition not governed by any single authority, meaning governance has to be provided directly by the participants. There should be cases where this is worth the trouble, but it's not a given.
Bitcoin itself is probably not the best example of what Ludwin is driving at. Better examples (which Ludwin cites) would be Filecoin (a token for tracking who is providing and using storage in a decentralized cloud) and Ethereum (a generalized platform for crypto assets). Ludwin attributes special significance to Bitcoin anyway on the basis that it currently represents the biggest chunk of actual money associated with crypto assets. I'm personally skeptical of this argument, and "first mover advantage" arguments in general, but it's not totally unreasonable.
What follows are my own thoughts, which should all start with "It’s very possible I don’t understand what’s going on", but in bigger, bolder letters.
One of my fundamental concerns with "cryptocurrencies" in general and Bitcoin in particular is that it seems hard to draw a direct line from the value of secure, decentralized ledgers as a service to the value of the associated asset. The ledger technology may be valuable in general, but that doesn't mean that any particular crypto asset is valuable. Which tokens you're using is essentially a matter of what ledger you're writing things on, but what makes a ledger valuable?
Before computers, actual paper ledgers carried records of billions of dollars in assets, but the price of paper didn't rise as a result. It came down over time as paper-making and printing became more efficient. Very few people cared who printed the ledger, so long as the layout was usable.
One of the key ideas behind Bitcoin and some but not all other tokens is that they will become more valuable over time because there is a strictly limited supply. But if the price of BTC in dollars keeps going up because everyone is hodling on to them, why use it? Why not use something else, or spin up your own tokens on Ethereum?
At the end of the day people hosting the ledger will need to be paid for the computing resources they provide, but this should be a modest cost relative to the amounts recorded on the ledger. One way or another there will be a flow of money from users of the ledger to providers of the service. In some cases these will be the same people. If I buy some capacity from a cloud provider and use it to participate in a ledger that I also use to record transactions of whatever nature, then I'm paying the cost of the computing resources to the cloud provider, and that may be about it.
This is assuming that participating in a ledger is relatively cheap. This is decidedly not the case for proof-of-work based systems like Bitcoin. Adding a new block to the Bitcoin blockchain currently gets a reward of 12.5 BTC plus whatever transaction fees are included (currently nominal). At current prices that's somewhere around $80K per block, or around $60 per transaction. This reward is effectively covered by inflating BTC rather than by direct payment, but miners are most certainly getting paid and are most certainly spending reserve currency on equipment and electricity.
However, I see no structural reason for a ledger to be expensive, unless proof-of-work really is the only way to solve the double spending problem. Without proof-of-work you're computing cryptographic signatures and copying bytes over a network. This isn't free, but it's not that expensive either.
Which leaves us with this. If secure, distributed ledgers are expensive, that's one more reason not to use them. If they're cheap, then it's hard to see how people will make huge piles of money off them. The optimum is probably in the middle somewhere, with people making modest amounts of money for providing a useful but fairly mundane service. It's still possible for individuals to make serious money in such an environment, but more in "old-fashioned" ways such as providing better service or a marginally lower price to a lot of customers.
Sunday, March 4, 2018
Another beautiful web.toy
Following a link from Wikipedia, I landed at earth.nullschool.net, which shows a gorgeous visualization of the current wind patterns on earth, at your choice of altitudes and with several possible color overlays, including temperature, humidity and "misery index". You can, of course, zoom and pan where you like and, for bonus style points, the pan feature redraws the map projection in real time, giving the impression that you're warping the fabric of space itself.
I'm pretty sure I've seen visualizations like this before, and even mentioned one or two here, but I'm pretty sure I haven't run across/linked to this particular one before. A quick search suggests I haven't. In any case, enjoy!
I'm pretty sure I've seen visualizations like this before, and even mentioned one or two here, but I'm pretty sure I haven't run across/linked to this particular one before. A quick search suggests I haven't. In any case, enjoy!
Sunday, August 27, 2017
Give us your money or we'll pirate your shows a few days early
Recently HBO suffered a data breach by parties who then tried to extort money using the threat of publicly releasing, among other things, Game of Thrones episodes and internal emails. HBO, despite having initially offered a much lower sum than demanded, reportedly in a bid to buy time, ultimately did not pay the extortionists. The Grauniad* has what looks like a pretty good summary on this one.
One thing that jumps out of this is that HBO was not particularly concerned with having episodes of its flagship show leak early. There are probably several reasons for this. HBO subscribers aren't paying per view, but monthly for the service as a whole. If someone were able to repeatedly steal HBO productions and escape prosecution, that would likely be a problem. Leaks of a few select episodes probably not.
Even if you can somehow make repeatedly stealing HBO content work, you're basically competing with HBO and the cable channels at distributing HBO content. That's not a game I'd personally want to get into. Your milage may vary, but bear in mind that people are already pirating HBO content after it airs. It's not clear how taking the extra risk to steal from HBO directly is providing that much of a competitive advantage.
More broadly, this all pushes back against the idea that, to make money selling content in a world where content can easily be copied, you need to provide something "live", like breaking news, live sporting or musical events, interactive games and such.
Of course, people can and do make money this way, but clearly that's not the only way. HBO and many other content providers have done well with more traditional productions. People seem happy to pay a modest monthly fee in order to see comedy, drama, documentaries and whatever other genres.
In principle there's a free-rider problem here in that people can get the same content, albeit generally illegally, without paying. In practice, the problem appears tolerable. HBO's refusal to pay a ransom to prevent GOT episodes from leaking underscores this. People are apparently content to pay for the brand rather than the ability to access any particular bits at any particular time.
*I tend to use the Private Eye names for the major British newspapers, particularly the Grauniad and Torygraph, because, well, sorta funny, but also fairly apt. The Telegraph is well known for its Tory leanings and the Guardian, however well it's built its brand as an international news outlet, is still prone to the sort of typo that led to the nickname in the first place. But on the other hand, if your instructions as editor are to "carry on as heretofore," I suppose that has to include the tyops. Sorry, typos.
One thing that jumps out of this is that HBO was not particularly concerned with having episodes of its flagship show leak early. There are probably several reasons for this. HBO subscribers aren't paying per view, but monthly for the service as a whole. If someone were able to repeatedly steal HBO productions and escape prosecution, that would likely be a problem. Leaks of a few select episodes probably not.
Even if you can somehow make repeatedly stealing HBO content work, you're basically competing with HBO and the cable channels at distributing HBO content. That's not a game I'd personally want to get into. Your milage may vary, but bear in mind that people are already pirating HBO content after it airs. It's not clear how taking the extra risk to steal from HBO directly is providing that much of a competitive advantage.
More broadly, this all pushes back against the idea that, to make money selling content in a world where content can easily be copied, you need to provide something "live", like breaking news, live sporting or musical events, interactive games and such.
Of course, people can and do make money this way, but clearly that's not the only way. HBO and many other content providers have done well with more traditional productions. People seem happy to pay a modest monthly fee in order to see comedy, drama, documentaries and whatever other genres.
In principle there's a free-rider problem here in that people can get the same content, albeit generally illegally, without paying. In practice, the problem appears tolerable. HBO's refusal to pay a ransom to prevent GOT episodes from leaking underscores this. People are apparently content to pay for the brand rather than the ability to access any particular bits at any particular time.
*I tend to use the Private Eye names for the major British newspapers, particularly the Grauniad and Torygraph, because, well, sorta funny, but also fairly apt. The Telegraph is well known for its Tory leanings and the Guardian, however well it's built its brand as an international news outlet, is still prone to the sort of typo that led to the nickname in the first place. But on the other hand, if your instructions as editor are to "carry on as heretofore," I suppose that has to include the tyops. Sorry, typos.
Friday, August 25, 2017
On to the next milestone
It looks like I ended up adding a few more posts to the original five (four real posts plus the birthday post). Counting this one, that'll make ten in all (but only eight real posts).
That seems like enough for now. I'll probably come back later and edit for typos and stylistic blunders, and maybe add some missing links, but I make no promise as to what will appear here for the next while. As usual, I might post again tomorrow, or not for months. I probably will post again at some point, but if not, the 600+ existing posts aren't going anywhere.
It does seem like someone (or someone's web crawler, at least) has been reading, and that's cool. If you've read and enjoyed, so much the better.
Cheers!
That seems like enough for now. I'll probably come back later and edit for typos and stylistic blunders, and maybe add some missing links, but I make no promise as to what will appear here for the next while. As usual, I might post again tomorrow, or not for months. I probably will post again at some point, but if not, the 600+ existing posts aren't going anywhere.
It does seem like someone (or someone's web crawler, at least) has been reading, and that's cool. If you've read and enjoyed, so much the better.
Cheers!
Bitcoin: Yeah, dunno about Venezuela either
Not long after posting the last post on Bitcoin I saw some headlines about Venezuelans using bitcoin instead of the Bolivar fuerte (fuerte meaning "strong") since the Bolivar itself is currently in hyperinflation. This makes some sense, in that if the inflation rate for a currency is around 700-800%, Bitcoin's fluctuations against the dollar seem like less of a problem. Bitcoin wallets and exchanges also provide a way to store value independent of the nation's banking system.
On the other hand, Bitcoin is not the only solution to this problem. Besides buying and selling a reserve currency on the black market, people have historically come up with all kinds of solutions to currency shocks, including IOUs, home-grown alternative currencies, commodities and good old-fashioned barter.
I'm not saying any of these is a good solution. In a situation such as this one there may not be any good solutions. The point is that Bitcoin is not the only game in town.
There are also practical issues. If the problem with reserve currencies is that trading in them is illegal, then the only legal way to buy Bitcoin is with Bolivares at the official rate, which exposes you to the same hyperinflation you're trying to get away from. If you're willing to trade on the black market, it's not clear why you need Bitcoin. And for that matter, the Venezuelan government can always make trading Bitcoin itself illegal.
If, somehow, Venezuela switched entirely to Bitcoin, that would currently mean around 800 billion dollars worth of Bolivares chasing around 70 billion dollars worth of Bitcoin, but that seems like a big if. For that kind of money, one could build one's own cryptocurrency.
But I'm not an economist. All of the above seems plausible to me, but I've been wrong before. So, once again ... ¯\_(ツ)_/¯.
(And once again, I don't have any position in Bitcoin one way or the other)
On the other hand, Bitcoin is not the only solution to this problem. Besides buying and selling a reserve currency on the black market, people have historically come up with all kinds of solutions to currency shocks, including IOUs, home-grown alternative currencies, commodities and good old-fashioned barter.
I'm not saying any of these is a good solution. In a situation such as this one there may not be any good solutions. The point is that Bitcoin is not the only game in town.
There are also practical issues. If the problem with reserve currencies is that trading in them is illegal, then the only legal way to buy Bitcoin is with Bolivares at the official rate, which exposes you to the same hyperinflation you're trying to get away from. If you're willing to trade on the black market, it's not clear why you need Bitcoin. And for that matter, the Venezuelan government can always make trading Bitcoin itself illegal.
If, somehow, Venezuela switched entirely to Bitcoin, that would currently mean around 800 billion dollars worth of Bolivares chasing around 70 billion dollars worth of Bitcoin, but that seems like a big if. For that kind of money, one could build one's own cryptocurrency.
But I'm not an economist. All of the above seems plausible to me, but I've been wrong before. So, once again ... ¯\_(ツ)_/¯.
(And once again, I don't have any position in Bitcoin one way or the other)
Subscribe to:
Posts (Atom)
