Unless somebody has substantially improved factorization techniques, I'm pretty sure that this machine doesn't much change the world of what is safe vs. what is broken.
I suspect that it can churn through some nice offline hash attacks; but offline hash attacks generally imply that the break-in has already succeeded. Applications where the public keys are exposed to the world by design(TLS, digital signatures, etc.) try for a much greater margin of safety. If somebody is using a crypto setup so weak that a thousands to millionfold increase in available power seriously threatens them, they have issues(the remaining users of 56-bit DES should probably be crying).
No, I only import the blood from China, it turns out that letting Juan absorb the risks and costs of importing himself across the southern border was cheaper and legally less risky than importing a groundskeeper myself. I 3 the neoliberal ease with which capital and commodities move past borders, while labor that wishes to do so puts itself in a wonderfully powerless position... So very convenient...
Yeah, I hardly mean to defend the system(I was just a student there, not even work-studying with IT, much less in charge of it); but that was my best-effort guess about why they operated as they did.
My other university experience was more positive: The first time a new MAC showed up on the network, wired or wireless, it'd captive-portal you to an SSLed sign-in page where you could use your ID and password to authorize the device, and after that nothing more needed to be done. The only time that annoyed me was when I tried to kick off debian net-install on a new machine and needed network access before I had a browser working. To the system's credit, it worked just fine in lynx, so it wasn't a big deal. I think that there was also a page somewhere where you could sign in and manually authorize the MAC of a device without any browser.
Of course it's truly voluntary. I mean, sure, every two-bit politician buffing his image for the upcoming election will appear in endless daily mail hit pieces about how you must be a piratical paedo-terrorist with a predilection for violence, because why else would you have opted out of this common-sense approach to law and order; but, yeah, totally voluntary.
Obstruction of justice would not be the correct charge; but most public records laws(while not exactly toothily enforced, and often filled with trivially exploitable loopholes) do make failure to disclose as required an offense of some kind.
I resent your assertion that I'm doing nothing. Since I discovered that China has an excellent, and amazingly inexpensive, supply of both patriot blood and(when the public is especially upset about some corruption scandal) tyrant blood, I've had my undocumented groundskeeper, Juan, out watering the tree of liberty every single day! I am the very model of a postmodern, globalized, supply-chain-optimized, revolutionary!
It's almost as though somebody knows that they are legally obligated to release certain documents; but also knows that the law nowhere requires that they remove the gigantic stick from their ass before doing so(plus, public records laws often allow some sort of cost recovery fee, so printing them all out will allow you to stick it to those uppity 'journalists' and their 'transparency' to a much greater extent...)
I'm strongly suspecting that, unless s/he happens to be a kool-aid drinking Palinista, the relevant IT person probably yawned and had the stuff packaged up in 20 minutes(probably in an Outlook 2003.pst; but electronic and easily internet-transmissible at least). The bitter; but legally obligated, records handling person then presumably took over...
I can't speak for the lost and the damned who require "clean access agents" and such horrors(even if you are running a windows box, the demand that you run some invasive crapware with AV-level security privileges on your personal machine seems a bit much...); but the ones who do the open wifi-to-Cisco VPN fall into the annoying intermediate category: They aren't fully broken, so it is hard to muster support for the demand that $X00,000 dollars worth of gear be torn out; but, because they are based on technology that is really designed for corporate setups, things get unpleasant the further you go from XP, 32-bit.
As you say, something that was purely Windows only would be torn out reasonably quickly by popular demand. However, these setups aren't exactly Windows only, they just offer increasing levels of suck as you go further out. At the time I was on this campus, the 32-bit XP client, while it had to be installed, was otherwise pretty much solid. Vista/7 was a touch dodgier, and 64-bit Windows support was 'coming-real-soon-now-we-promise'. The OSX client, um, mostly worked; but the iDevices were also 'coming-real-soon-now, once Apple adds that'(which they eventually did). The dorms had hardwired ethernet drops, so console users didn't have much cause for whining. Ironically, given the state of Cisco's official client at the time, Linux users(while they had to google for directions, because campus IT didn't care) were actually better off than iDevice users and 64 bit Windows users. VPNC, while wholly unofficial, pretty much Just Worked, once the.conf was in order. iDevices were locked down, so they were awaiting Apple's pleasure and 64 bit Windows users discovered that the custom installer would automagically install a perfect-looking configuration that Just Didn't Work.
I assume that, given the fairly recent proliferation of wireless-but-embedded widgets, future installs will be much warier of vendor-specific VPN goo...
One reasonably common sticking point that I've run into a few times on university networks comes up because of a hole in the set of options provided by "standard" 802.11a/b/g/n security mechanisms:
You can run the network fully open; but then everybody's packets are in the clear(unless encrypted by whatever protocol/program they are using). You can run WEP/WPA-PSK; but that pretty much sucks for anything larger than a home network(half your users won't know the shared key, the other half will make it public knowledge in about two seconds). WPA-enterprise, with radius, works well enough architecturally; but configuration is kind of a pain in the ass for university-type situations where most devices aren't configured by the IT overlords.
So, you get situations where the APs are run fully open; but the only thing visible is a VPN appliance of some flavor(usually rhymes with "nabisco"). Campus IT will provide a pre-rolled custom installer for windows, and sometimes OSX, that installs the (unbelievably sucky) Cisco VPN client, pre-populated with everything but your username and password, and away you go. Linux users can go whistle as far as IT is concerned; but there is usually a campus-specific FAQ written up by some benevolent CS grad student at the institution telling you what your vpnc config file needs to look like, and IT doesn't care if you do manage to connect by those unofficial means.
Some schools, thankfully ones that I've never dealt with, demand some sort of(usually windows-specific) "client health monitoring" or "clean access" software be installed. That is a bigger issue. If you are lucky, they only demand it of windows clients and look the other way at macs, xboxes, and other miscellanious stuff, and you can get away with just connecting a linux box. If unlucky, "other" is treated as a pariah category...
The problem here is that, while Gartner is indeed utterly useless, their opinion is also unnecessary to determine that Google is oozing nonsense.
Different jurisdictions have different laws on the books about what data are considered specially protected, what data are an open book for the local feds, and what data require some sort of judicial approval(and to what degree that approval is a serious consideration or a simple rubber-stamp). Therefore, the jurisdiction in which your data are located(or where your outsourcing partner has offices large enough that the local feds can motivate them to comply) is part of rather than opposed to worrying about the privacy and security of your data.
Google certainly doesn't seem to be the worst when it comes to rolling over and wagging their tail for any jackboots who come calling; but anybody who thinks that they put up extra-legal resistance to any of the major powers in which they operate is, shall we say, under the influence of excessive optimism...
Obviously, it is Feigenbaum's job to exude nonsense where required; but the notion that worrying about where something is stored isn't part of(much less opposed to) "worry[ing] about security and privacy of data" is transparent absurdity.
Where data are, in part, determines what laws(and de-facto uses and abuses of power) they are subject to or subject to the protection of. In a number of cases(including the not-exactly-economically-insignificant case of EU businesses working with American cloud entities...) it might even turn out that storing certain sorts of data in some jurisdictions means that a given entity is in violation of data protection laws at home because the data protection laws are insufficiently strong where they are storing data.
Things like whether or not you are getting hacked by lulzsec are, of course, also important; but(until Google transforms itself into a cypherpunk utopia or sprouts a formidable nuclear deterrent), location is right up there with hackers in determining how likely your data are to be absconded with against your wishes. And(unlike hackers) you can't really code your way past the feds...
That is certainly true. There are excellent reasons why the linux-style light-binaries-that-specify-lots-of-dependencies + a good package manager to sort it all out model is desirable. And, even if you go with a gigantic static binary in the end for convenience of installation, having a source like the one you describe, where everything is neatly broken out, is highly desireable: It is comparatively simple, with the right tools, to turn a list of dependencies into a big static blob. The reverse, not so much.
My point was narrowly addressed from the user side: Unless your environment is so slow moving that X is missing major features or such, installing a new iteration of a big static blob every week isn't a big deal, even if it is architecturally ugly. Something that nicely breaks out the dependencies, on the other hand, can involve very, very, "interesting" explorations into package-management hell and upgrading half your system with questionably compatible backports from Unstable.
In an ideal world, you would really want something like Callaway's work to be the 'canonical' version, ready to be slotted into sufficiently new or fast moving distributions, with the option of programmatically emblobifying the whole mass into a simple-to-install lump for situations where you can't tamper with the system's shared libraries.
They can't. The fact that it is just basic HTML means that detect-and-strip will be downright trivial; but there is nothing(outside of the darkest fantasies of the "trusted computing" set) that could actually stop such activity.
It seems like this falls into the category of 'potentially useful incremental change'. It isn't resistant to rip-offs(but neither was the status quo) and it makes it somewhat easier for good-faith actors to make a pertinent piece of metadata easily accessible. The metadata dreams of the 'semantic web' types seem doomed to founder in a morass of epistemological horrors; but tagging a few bits of metadata that people are obviously interested in seems quite sensible.
More robust(not entirely bulletproof) solutions would certainly be possible; but they would involve much greater changes to the way web browsers work, and the workflow of common authoring mechanisms. For instance, assymetric-key crypto and document signing would, if widely used by authors and sensibly interpreted by web browsers and other document/media viewing applications allow authorship claims to be harder to falsify.(You could still falsely claim to have authored somebody else's work, just strip their signature and substitute your own; but you could no longer falsely claim that somebody else was the author of a given work, since you wouldn't be able to sign it as them). If you added cryptographically verified timestamps from one or more "trusted" sources, you could go one step further and allow people to demonstrate that they were the first to sign something(which would still be vulnerable to rip-offs by scrapermedia LLC programmatically scooping up every unsigned document that some poor noob puts on the web and automatically 'first-signing' it; but would make stripping and re-signing much easier to detect in general).
Such changes, though, would, unlike the HTML tag, involve serious overhaul of how the browser works, how much 'normal people' use crypto(and protect their private keys), and the features supported by authoring software. This doesn't mean that it would be a bad thing(in fact, it would have other interesting side-benefits); but it would Not be an easy move to make.
(The side benefits, of such a change, for browsers; would be that it would allow you to make the browser cache immensely more powerful and useful: In order to support cryptographic verification of authored elements and then integration of those elements with stylesheets and other webpage/CMS goo, browsers would have to have a generic capability to retrieve, cryptographically validate, and then integrate "packages" of material. This capability could also be applied to things like CSS stylesheets, javascript libraries, etc. Hypothetically, for instance, instead of a page simply specifying a javascript library, and a location on the server from which to retrieve it, a page could specify the library, its SHA-whatever hash, and its signer, along with at least one URL at which to obtain it. If the browser already has an object with an identical SHA hash(even if downloaded when visiting some entirely different domain, not uncommon for semi-standard stuff like jquery) it could skip retrieval. This would also allow page authors to link to 3rd party locations without fear of tampering that could compromise their pages. Given the increasing prevalence of large, resource-heavy, web applications, use of 3rd party CDNs, and similar, giving browsers the ability to securely cache 'packages' and then use them to construct pages, free from concerns about cross-domain attacks, and giving page authors the ability to securely invoke 3rd party resources, without risk of after-the-fact tampering, would be quite handy.)
Depends on how much of the release-churn is purely internal, and how much involves ever-climbing demands on the version numbers of dependencies...
For applications that are relatively self-contained, and make few, or very conservative, demands about their environment, it really isn't a big deal. Where things get ugly, for users of debian stable or other slow-moving distributions(some of the enterprise desktop stuff can get rather long in the tooth as well...), is the applications that expect their environment to be as bleeding-edge as they are.
Having apt report that Foo N+1 is available every damn time it runs is a minor nuisance. Having to maintain an entire parallel universe of libraries and stuff grabbed from testing or unstable just to update your browser is a major nuisance.
I'm assuming that the clarification lies in the bit you elided: Chrome doesn't have to report to Our Google Overlords the URLs you visit for it to work, and Chrome doesn't need to "know about" the URLs in question(ie. it doesn't have to do some AV-like "download-list-of-the-500,000-new-malicious-URLs-for-today" behavior).
I don't know if the statement is mere fluffy hyperbole about some rather rudimentary heuristic mechanism(along the lines of the existing handy-but-not-rocket-science feature of offering to disable javascript popups for any site that has opened, and had closed by the user, a certain number of the things, which does help prevent one of the classic "trap the noob" techniques used by the malicious) or whether it is something extremely clever; but it isn't immediately incoherent or logically impossible.
It's hard to think of a currency or form of property that isn't a little sordid some time back... Fiat currencies have Seignorage, metallic ones generally go back to some ghastly extraction industry's big toxic hole in the ground, land titles generally trace their way back through a series of transactions to the last time somebody sacked the place, burned down the last records office, and handed out the spoils to his minions...
Dear Sir,
The Kraft Foods Company, holder of the Kool-Aid(tm) name and distinctive marks, believes your insinuations to be tortuously harmful to the value and good public image of the Kool-Aid(tm) brand.
We would ask that you cease and desist your activity, and would like to remind the reading public that Jonestown residents were consumers of "flavor-aid" an inferior imitation product.
John Doe III
General Counsel
It would be one of the few legitimate excuses to submit a schematic drawing of your genitalia to a government office...
On the other hand, matters could get rather humiliating when the porn industry comes to trial and argues that "the 'apparatus' covered by claimant's patent is clearly of such dimensional disparity with the apparatus in common industry use that the applicable methods cannot be judged to be sufficiently similar to be infringing..."
The whole point of a patent is disclosure in exchange for a monopoly of limited term. Since it has been repeatedly emphasized that God works in mysterious ways to which mortals are not privy, clearly the apparatus and method in question have not been adequately disclosed to the copyright office.
Arguably, since God has retained these powers as a closely held Mystery, licenced only on a limited basis to his fertilitity and translation services provider subsidiary, Holy Spirit LLC, and a number of middle-eastern contractors to which he has outsourced prophetic work over the years, Godly power would be better served by Trade Secret, rather than Patent, protection...
I think that some subset of the American media market has compulsory licensing and a collecting agency(ASCAP, BMI, SESAC) as well, it covers 'public performance' or such if memory serves.
The general issue that seems to crop up with these collecting entities is that they are efficient and enthusiastic when it comes to extraction(whether it be shaking people down directly, lobbying for taxes on recording media, or whatever); but suddenly find themselves strangely helpless when it comes to paying out to those poor starving artists, especially the ones not in the pockets of local media conglomerates or RIAA-alikes. In addition, despite being 'compensated' by every poor sap who buys an external hard drive to back up some files, their enthusiasm for lobbying in favor of anti-piracy and pro-DRM measures ends up being undiminished.
In a theoretical ideal world of good governance, I'd be very fond of the idea; but its application seems frequently to degenerate into a stiff tax on what people were using for piracy 5 years ago, along with substantial amounts of money disappearing before they see the artists, and minimal diminution in the ferocity of attacks on end users...
I suspect that the problem is not that privacy is impossible; but that it is very much not in the interest of any major player in the sale of ebooks, the licensing of publishing rights for ebooks, etc.
While the mathematical work in cryptographic privacy schemes is extremely interesting, you could get 90% of the same results with little more than basic file and database record deletion commands if the actors involved were so motivated. If Amazon wanted you to have privacy, they could not gather information about your browsing of their inventory, not collect location data from whispernet kindles, purge all records of CC transactions the moment the risk of chargeback had timed out, etc, etc. Shockingly enough, they don't. Gotta monetize them consumer metrics!
That's really the trick: most of the clever technology for anonymity/privacy is designed to address the problem that the actors in conventional monetary, DRM, networking, etc. systems have a strong interest(and ever increasing capability) to monitor what people interacting with those systems do. If they didn't have that, the mathematical cleverness would hardly be necessary; because everyone would be purging logs as fast as they became unnecessary for immediate security purposes. The trouble, in the case of Ebooks, is that(since the main actors selling them are among those who have a strong interest in collecting user data) the majority of providers, especially of commercially popular material, would have no incentive to accept payment systems that compromise their ability to do what they want, or build reader or DRM systems that do so. This means that, while technologically quite feasible, privacy-preserving architectures are likely to remain content-light, somewhat-less-than-polished, backwaters.
There definitely isn't anybody tracking my reading of Project Gutenberg etexts with Weasel reader on my rockin'-it-old-school Visor Edge; but that particular solution is not, shall we say, going to lure away the kindle's customer base...
As is often the case, RMS is being sufficiently blunt, and proposing a set of possibly-unworkable solutions sufficiently far from the status quo, that he gives off that "extreme" vibe.
As is also often the case, it is pretty hard to argue with his thesis: Your traditional B&M bookstores, while hardly bastions of cypherpunk anonymity, were perfectly happy to take cash for whatever you felt like buying, and had neither the time nor the margins to use their cameras for anything other than trying to deter shoplifters.
Your online booksellers, Amazon etc, up the ante a bit by tracking your browsing of their inventory quite closely, and by virtue of the fact that(while this isn't impossible to get around, prepaid debit cards, and the like) the basic coin of the realm is credit/debit cards, generally establish an excellent correlation between buying history and buyer ID.
Ebooks up it still further, since they are tied directly to an account, and a CC, and frequently use(sometimes weak; but illegal in the US to break) DRM to control what you can and cannot do with what you 'own'.
Ebook readers up it still further, in that they can, and are known to, track not only your inspection of the inventory and eventual purchase; but your reading habits. The ones with location capabilities(such as all whispernet kindles), are known to report user location data to the mothership as well.
Obviously, most of these measures are somewhat slackly implemented, and a dedicated privacy-enthused individual with some time and technical skill can likely circumvent at least some of them; but that doesn't really change the fact that there has been an overwhelming increase(largely private sector and ebook driven) in the amount of transparency and control exercised over the population of readers. That simply cannot be usefully denied.
Given that large utility customers are, not universally; but much more frequently than residential customers, already billed according to more than straight KwH used, with on peak/off peak, power factor, etc. coming into the equation, I'm not sure that Pigovian taxation would be necessary.
In addition to the medical utility, such work likely has a fair amount of basic research value. The brain is monstrously complex and we don't understand it all that well. The demonstration that one phenomenon is actually a slightly modified version, re-using much of the same tissue, as a quite different seeming one likely has interesting implications. We know in broad strokes that the brain is a giant pile of hacks and ad-hoc extensions of prior function; but that isn't nearly the same thing as knowing the exact shape of the tangled mess.
Why would insurance companies be opposed to medical expert systems?
A computerized billing and coding system could analyze patient records, second-guess doctors, and reject claims faster than thousands of weak human employees...
Slashdot Mirror
Unless somebody has substantially improved factorization techniques, I'm pretty sure that this machine doesn't much change the world of what is safe vs. what is broken.
I suspect that it can churn through some nice offline hash attacks; but offline hash attacks generally imply that the break-in has already succeeded. Applications where the public keys are exposed to the world by design(TLS, digital signatures, etc.) try for a much greater margin of safety. If somebody is using a crypto setup so weak that a thousands to millionfold increase in available power seriously threatens them, they have issues(the remaining users of 56-bit DES should probably be crying).
No, I only import the blood from China, it turns out that letting Juan absorb the risks and costs of importing himself across the southern border was cheaper and legally less risky than importing a groundskeeper myself. I 3 the neoliberal ease with which capital and commodities move past borders, while labor that wishes to do so puts itself in a wonderfully powerless position... So very convenient...
Yeah, I hardly mean to defend the system(I was just a student there, not even work-studying with IT, much less in charge of it); but that was my best-effort guess about why they operated as they did.
My other university experience was more positive: The first time a new MAC showed up on the network, wired or wireless, it'd captive-portal you to an SSLed sign-in page where you could use your ID and password to authorize the device, and after that nothing more needed to be done. The only time that annoyed me was when I tried to kick off debian net-install on a new machine and needed network access before I had a browser working. To the system's credit, it worked just fine in lynx, so it wasn't a big deal. I think that there was also a page somewhere where you could sign in and manually authorize the MAC of a device without any browser.
Of course it's truly voluntary. I mean, sure, every two-bit politician buffing his image for the upcoming election will appear in endless daily mail hit pieces about how you must be a piratical paedo-terrorist with a predilection for violence, because why else would you have opted out of this common-sense approach to law and order; but, yeah, totally voluntary.
Obstruction of justice would not be the correct charge; but most public records laws(while not exactly toothily enforced, and often filled with trivially exploitable loopholes) do make failure to disclose as required an offense of some kind.
I resent your assertion that I'm doing nothing. Since I discovered that China has an excellent, and amazingly inexpensive, supply of both patriot blood and(when the public is especially upset about some corruption scandal) tyrant blood, I've had my undocumented groundskeeper, Juan, out watering the tree of liberty every single day! I am the very model of a postmodern, globalized, supply-chain-optimized, revolutionary!
It's almost as though somebody knows that they are legally obligated to release certain documents; but also knows that the law nowhere requires that they remove the gigantic stick from their ass before doing so(plus, public records laws often allow some sort of cost recovery fee, so printing them all out will allow you to stick it to those uppity 'journalists' and their 'transparency' to a much greater extent...)
.pst; but electronic and easily internet-transmissible at least). The bitter; but legally obligated, records handling person then presumably took over...
I'm strongly suspecting that, unless s/he happens to be a kool-aid drinking Palinista, the relevant IT person probably yawned and had the stuff packaged up in 20 minutes(probably in an Outlook 2003
I can't speak for the lost and the damned who require "clean access agents" and such horrors(even if you are running a windows box, the demand that you run some invasive crapware with AV-level security privileges on your personal machine seems a bit much...); but the ones who do the open wifi-to-Cisco VPN fall into the annoying intermediate category: They aren't fully broken, so it is hard to muster support for the demand that $X00,000 dollars worth of gear be torn out; but, because they are based on technology that is really designed for corporate setups, things get unpleasant the further you go from XP, 32-bit.
.conf was in order. iDevices were locked down, so they were awaiting Apple's pleasure and 64 bit Windows users discovered that the custom installer would automagically install a perfect-looking configuration that Just Didn't Work.
As you say, something that was purely Windows only would be torn out reasonably quickly by popular demand. However, these setups aren't exactly Windows only, they just offer increasing levels of suck as you go further out. At the time I was on this campus, the 32-bit XP client, while it had to be installed, was otherwise pretty much solid. Vista/7 was a touch dodgier, and 64-bit Windows support was 'coming-real-soon-now-we-promise'. The OSX client, um, mostly worked; but the iDevices were also 'coming-real-soon-now, once Apple adds that'(which they eventually did). The dorms had hardwired ethernet drops, so console users didn't have much cause for whining. Ironically, given the state of Cisco's official client at the time, Linux users(while they had to google for directions, because campus IT didn't care) were actually better off than iDevice users and 64 bit Windows users. VPNC, while wholly unofficial, pretty much Just Worked, once the
I assume that, given the fairly recent proliferation of wireless-but-embedded widgets, future installs will be much warier of vendor-specific VPN goo...
One reasonably common sticking point that I've run into a few times on university networks comes up because of a hole in the set of options provided by "standard" 802.11a/b/g/n security mechanisms:
You can run the network fully open; but then everybody's packets are in the clear(unless encrypted by whatever protocol/program they are using). You can run WEP/WPA-PSK; but that pretty much sucks for anything larger than a home network(half your users won't know the shared key, the other half will make it public knowledge in about two seconds). WPA-enterprise, with radius, works well enough architecturally; but configuration is kind of a pain in the ass for university-type situations where most devices aren't configured by the IT overlords.
So, you get situations where the APs are run fully open; but the only thing visible is a VPN appliance of some flavor(usually rhymes with "nabisco"). Campus IT will provide a pre-rolled custom installer for windows, and sometimes OSX, that installs the (unbelievably sucky) Cisco VPN client, pre-populated with everything but your username and password, and away you go. Linux users can go whistle as far as IT is concerned; but there is usually a campus-specific FAQ written up by some benevolent CS grad student at the institution telling you what your vpnc config file needs to look like, and IT doesn't care if you do manage to connect by those unofficial means.
Some schools, thankfully ones that I've never dealt with, demand some sort of(usually windows-specific) "client health monitoring" or "clean access" software be installed. That is a bigger issue. If you are lucky, they only demand it of windows clients and look the other way at macs, xboxes, and other miscellanious stuff, and you can get away with just connecting a linux box. If unlucky, "other" is treated as a pariah category...
The problem here is that, while Gartner is indeed utterly useless, their opinion is also unnecessary to determine that Google is oozing nonsense.
Different jurisdictions have different laws on the books about what data are considered specially protected, what data are an open book for the local feds, and what data require some sort of judicial approval(and to what degree that approval is a serious consideration or a simple rubber-stamp). Therefore, the jurisdiction in which your data are located(or where your outsourcing partner has offices large enough that the local feds can motivate them to comply) is part of rather than opposed to worrying about the privacy and security of your data.
Google certainly doesn't seem to be the worst when it comes to rolling over and wagging their tail for any jackboots who come calling; but anybody who thinks that they put up extra-legal resistance to any of the major powers in which they operate is, shall we say, under the influence of excessive optimism...
Obviously, it is Feigenbaum's job to exude nonsense where required; but the notion that worrying about where something is stored isn't part of(much less opposed to) "worry[ing] about security and privacy of data" is transparent absurdity.
Where data are, in part, determines what laws(and de-facto uses and abuses of power) they are subject to or subject to the protection of. In a number of cases(including the not-exactly-economically-insignificant case of EU businesses working with American cloud entities...) it might even turn out that storing certain sorts of data in some jurisdictions means that a given entity is in violation of data protection laws at home because the data protection laws are insufficiently strong where they are storing data.
Things like whether or not you are getting hacked by lulzsec are, of course, also important; but(until Google transforms itself into a cypherpunk utopia or sprouts a formidable nuclear deterrent), location is right up there with hackers in determining how likely your data are to be absconded with against your wishes. And(unlike hackers) you can't really code your way past the feds...
That is certainly true. There are excellent reasons why the linux-style light-binaries-that-specify-lots-of-dependencies + a good package manager to sort it all out model is desirable. And, even if you go with a gigantic static binary in the end for convenience of installation, having a source like the one you describe, where everything is neatly broken out, is highly desireable: It is comparatively simple, with the right tools, to turn a list of dependencies into a big static blob. The reverse, not so much.
My point was narrowly addressed from the user side: Unless your environment is so slow moving that X is missing major features or such, installing a new iteration of a big static blob every week isn't a big deal, even if it is architecturally ugly. Something that nicely breaks out the dependencies, on the other hand, can involve very, very, "interesting" explorations into package-management hell and upgrading half your system with questionably compatible backports from Unstable.
In an ideal world, you would really want something like Callaway's work to be the 'canonical' version, ready to be slotted into sufficiently new or fast moving distributions, with the option of programmatically emblobifying the whole mass into a simple-to-install lump for situations where you can't tamper with the system's shared libraries.
They can't. The fact that it is just basic HTML means that detect-and-strip will be downright trivial; but there is nothing(outside of the darkest fantasies of the "trusted computing" set) that could actually stop such activity.
It seems like this falls into the category of 'potentially useful incremental change'. It isn't resistant to rip-offs(but neither was the status quo) and it makes it somewhat easier for good-faith actors to make a pertinent piece of metadata easily accessible. The metadata dreams of the 'semantic web' types seem doomed to founder in a morass of epistemological horrors; but tagging a few bits of metadata that people are obviously interested in seems quite sensible.
More robust(not entirely bulletproof) solutions would certainly be possible; but they would involve much greater changes to the way web browsers work, and the workflow of common authoring mechanisms. For instance, assymetric-key crypto and document signing would, if widely used by authors and sensibly interpreted by web browsers and other document/media viewing applications allow authorship claims to be harder to falsify.(You could still falsely claim to have authored somebody else's work, just strip their signature and substitute your own; but you could no longer falsely claim that somebody else was the author of a given work, since you wouldn't be able to sign it as them). If you added cryptographically verified timestamps from one or more "trusted" sources, you could go one step further and allow people to demonstrate that they were the first to sign something(which would still be vulnerable to rip-offs by scrapermedia LLC programmatically scooping up every unsigned document that some poor noob puts on the web and automatically 'first-signing' it; but would make stripping and re-signing much easier to detect in general).
Such changes, though, would, unlike the HTML tag, involve serious overhaul of how the browser works, how much 'normal people' use crypto(and protect their private keys), and the features supported by authoring software. This doesn't mean that it would be a bad thing(in fact, it would have other interesting side-benefits); but it would Not be an easy move to make.
(The side benefits, of such a change, for browsers; would be that it would allow you to make the browser cache immensely more powerful and useful: In order to support cryptographic verification of authored elements and then integration of those elements with stylesheets and other webpage/CMS goo, browsers would have to have a generic capability to retrieve, cryptographically validate, and then integrate "packages" of material. This capability could also be applied to things like CSS stylesheets, javascript libraries, etc. Hypothetically, for instance, instead of a page simply specifying a javascript library, and a location on the server from which to retrieve it, a page could specify the library, its SHA-whatever hash, and its signer, along with at least one URL at which to obtain it. If the browser already has an object with an identical SHA hash(even if downloaded when visiting some entirely different domain, not uncommon for semi-standard stuff like jquery) it could skip retrieval. This would also allow page authors to link to 3rd party locations without fear of tampering that could compromise their pages. Given the increasing prevalence of large, resource-heavy, web applications, use of 3rd party CDNs, and similar, giving browsers the ability to securely cache 'packages' and then use them to construct pages, free from concerns about cross-domain attacks, and giving page authors the ability to securely invoke 3rd party resources, without risk of after-the-fact tampering, would be quite handy.)
Depends on how much of the release-churn is purely internal, and how much involves ever-climbing demands on the version numbers of dependencies...
For applications that are relatively self-contained, and make few, or very conservative, demands about their environment, it really isn't a big deal. Where things get ugly, for users of debian stable or other slow-moving distributions(some of the enterprise desktop stuff can get rather long in the tooth as well...), is the applications that expect their environment to be as bleeding-edge as they are.
Having apt report that Foo N+1 is available every damn time it runs is a minor nuisance. Having to maintain an entire parallel universe of libraries and stuff grabbed from testing or unstable just to update your browser is a major nuisance.
I'm assuming that the clarification lies in the bit you elided: Chrome doesn't have to report to Our Google Overlords the URLs you visit for it to work, and Chrome doesn't need to "know about" the URLs in question(ie. it doesn't have to do some AV-like "download-list-of-the-500,000-new-malicious-URLs-for-today" behavior).
I don't know if the statement is mere fluffy hyperbole about some rather rudimentary heuristic mechanism(along the lines of the existing handy-but-not-rocket-science feature of offering to disable javascript popups for any site that has opened, and had closed by the user, a certain number of the things, which does help prevent one of the classic "trap the noob" techniques used by the malicious) or whether it is something extremely clever; but it isn't immediately incoherent or logically impossible.
It's hard to think of a currency or form of property that isn't a little sordid some time back... Fiat currencies have Seignorage, metallic ones generally go back to some ghastly extraction industry's big toxic hole in the ground, land titles generally trace their way back through a series of transactions to the last time somebody sacked the place, burned down the last records office, and handed out the spoils to his minions...
Dear Sir, The Kraft Foods Company, holder of the Kool-Aid(tm) name and distinctive marks, believes your insinuations to be tortuously harmful to the value and good public image of the Kool-Aid(tm) brand.
We would ask that you cease and desist your activity, and would like to remind the reading public that Jonestown residents were consumers of "flavor-aid" an inferior imitation product. John Doe III General Counsel
It would be one of the few legitimate excuses to submit a schematic drawing of your genitalia to a government office...
On the other hand, matters could get rather humiliating when the porn industry comes to trial and argues that "the 'apparatus' covered by claimant's patent is clearly of such dimensional disparity with the apparatus in common industry use that the applicable methods cannot be judged to be sufficiently similar to be infringing..."
The whole point of a patent is disclosure in exchange for a monopoly of limited term. Since it has been repeatedly emphasized that God works in mysterious ways to which mortals are not privy, clearly the apparatus and method in question have not been adequately disclosed to the copyright office.
Arguably, since God has retained these powers as a closely held Mystery, licenced only on a limited basis to his fertilitity and translation services provider subsidiary, Holy Spirit LLC, and a number of middle-eastern contractors to which he has outsourced prophetic work over the years, Godly power would be better served by Trade Secret, rather than Patent, protection...
I think that some subset of the American media market has compulsory licensing and a collecting agency(ASCAP, BMI, SESAC) as well, it covers 'public performance' or such if memory serves.
The general issue that seems to crop up with these collecting entities is that they are efficient and enthusiastic when it comes to extraction(whether it be shaking people down directly, lobbying for taxes on recording media, or whatever); but suddenly find themselves strangely helpless when it comes to paying out to those poor starving artists, especially the ones not in the pockets of local media conglomerates or RIAA-alikes. In addition, despite being 'compensated' by every poor sap who buys an external hard drive to back up some files, their enthusiasm for lobbying in favor of anti-piracy and pro-DRM measures ends up being undiminished.
In a theoretical ideal world of good governance, I'd be very fond of the idea; but its application seems frequently to degenerate into a stiff tax on what people were using for piracy 5 years ago, along with substantial amounts of money disappearing before they see the artists, and minimal diminution in the ferocity of attacks on end users...
I suspect that the problem is not that privacy is impossible; but that it is very much not in the interest of any major player in the sale of ebooks, the licensing of publishing rights for ebooks, etc.
While the mathematical work in cryptographic privacy schemes is extremely interesting, you could get 90% of the same results with little more than basic file and database record deletion commands if the actors involved were so motivated. If Amazon wanted you to have privacy, they could not gather information about your browsing of their inventory, not collect location data from whispernet kindles, purge all records of CC transactions the moment the risk of chargeback had timed out, etc, etc. Shockingly enough, they don't. Gotta monetize them consumer metrics!
That's really the trick: most of the clever technology for anonymity/privacy is designed to address the problem that the actors in conventional monetary, DRM, networking, etc. systems have a strong interest(and ever increasing capability) to monitor what people interacting with those systems do. If they didn't have that, the mathematical cleverness would hardly be necessary; because everyone would be purging logs as fast as they became unnecessary for immediate security purposes. The trouble, in the case of Ebooks, is that(since the main actors selling them are among those who have a strong interest in collecting user data) the majority of providers, especially of commercially popular material, would have no incentive to accept payment systems that compromise their ability to do what they want, or build reader or DRM systems that do so. This means that, while technologically quite feasible, privacy-preserving architectures are likely to remain content-light, somewhat-less-than-polished, backwaters.
There definitely isn't anybody tracking my reading of Project Gutenberg etexts with Weasel reader on my rockin'-it-old-school Visor Edge; but that particular solution is not, shall we say, going to lure away the kindle's customer base...
As is often the case, RMS is being sufficiently blunt, and proposing a set of possibly-unworkable solutions sufficiently far from the status quo, that he gives off that "extreme" vibe.
As is also often the case, it is pretty hard to argue with his thesis: Your traditional B&M bookstores, while hardly bastions of cypherpunk anonymity, were perfectly happy to take cash for whatever you felt like buying, and had neither the time nor the margins to use their cameras for anything other than trying to deter shoplifters.
Your online booksellers, Amazon etc, up the ante a bit by tracking your browsing of their inventory quite closely, and by virtue of the fact that(while this isn't impossible to get around, prepaid debit cards, and the like) the basic coin of the realm is credit/debit cards, generally establish an excellent correlation between buying history and buyer ID.
Ebooks up it still further, since they are tied directly to an account, and a CC, and frequently use(sometimes weak; but illegal in the US to break) DRM to control what you can and cannot do with what you 'own'.
Ebook readers up it still further, in that they can, and are known to, track not only your inspection of the inventory and eventual purchase; but your reading habits. The ones with location capabilities(such as all whispernet kindles), are known to report user location data to the mothership as well.
Obviously, most of these measures are somewhat slackly implemented, and a dedicated privacy-enthused individual with some time and technical skill can likely circumvent at least some of them; but that doesn't really change the fact that there has been an overwhelming increase(largely private sector and ebook driven) in the amount of transparency and control exercised over the population of readers. That simply cannot be usefully denied.
Given that large utility customers are, not universally; but much more frequently than residential customers, already billed according to more than straight KwH used, with on peak/off peak, power factor, etc. coming into the equation, I'm not sure that Pigovian taxation would be necessary.
In addition to the medical utility, such work likely has a fair amount of basic research value. The brain is monstrously complex and we don't understand it all that well. The demonstration that one phenomenon is actually a slightly modified version, re-using much of the same tissue, as a quite different seeming one likely has interesting implications. We know in broad strokes that the brain is a giant pile of hacks and ad-hoc extensions of prior function; but that isn't nearly the same thing as knowing the exact shape of the tangled mess.
Why would insurance companies be opposed to medical expert systems?
A computerized billing and coding system could analyze patient records, second-guess doctors, and reject claims faster than thousands of weak human employees...