Re: YOU "non-programmer" don't grasp what an API is! It's INTRINSIC AND INSEPARABLE FROM OTHER CODE.
> It's INTRINSIC AND INSEPARABLE FROM OTHER CODE
That depends.
For example, presumably you are reading this in a Web browser. Your Web browser has an address bar, and in that address bar, you will see something like https://www.techdirt.com/articles/.... That is a URL. It is interpreted by the Web browser and used to retrieve the HTML for this Web page (which in turn contains other URLs for things like images).
The interface used for the communication between the Web browser and the Web server is the Hypertext Transfer Protocol (HTTP) and related protocols. These are defined via specifications and are independent from any particular implementation. A copyright on the specification would not extend to an implementation, any more than the copyright on the specification for a bolt would extend to an actual bolt.
Similarly, many programming languages (e.g., C, C++) have clear separation between interface and implementation.
Now, what harms Google here is that Java is not one of those languages. Interface is much more tightly intertwingled with implementation in Java.
> It's not just arbitrary inputs that anyone could come up with in a couple seconds.
That depends entirely on how fast you type. I certainly have defined APIs "in a couple seconds".
Few of these sites seem particularly concerned about the fact that shuttering comments makes it very clear they don't really value truly local community, and lack the willpower to nurture and protect on-site (or in app) participation.
Yes, but you seem to be taking this from the attitude that every Web site should have comments.
Having a participatory community needs to be a strategic decision. It requires investment, and therefore it needs to make sense to make that investment.
The problem is that too many sites added comments because "it's what all the cool kids are doing", without any strategic sense for why they have the comments. It was a checkbox on the VC funding form, for example.
So, for many of these sites, I would argue that their decision is simply a reversion to what they should have done from the outset, given their organizational priorities. And, in many cases, it will be better that they do drop the comments, as if they are not going to make the necessary investments in engagement, those comments can easily turn into a cesspool, which reflects poorly on the organization. IOW, do it right or don't do it at all.
The highfalutin' PR fodder for why they are taking down the comments is tripe, but PR fodder is generally tripe. It may be worthy of ridicule, but it is hardly newsworthy.
Reading Mark Cuban's post, and contrasting it with John Chen's post, shows that they are not describing the same thing.
Mr. Chen is focused on what I'll call "app platform neutrality", somehow requiring developers to write apps for platforms other than iOS and Android. This would be akin to requiring developers to write apps for OS X and Linux instead of just Windows, in terms of desktop operating systems.
Mr. Cuban is focused on what I'll call "app market neutrality". His concern seems less about the platform and more about the gatekeeper role that Apple plays with iOS and, to a somewhat lesser extent, Google plays with Android. He wants there to be other possible gatekeepers, in the form of having other app distribution channels be able to be peers of the App Store and Play Store. Right now, short of jailbreaking, AFAIK it is impossible to have a peer of the App Store. While peers of the Play Store exist (e.g., Amazon AppStore for Android), on Google Play-centered devices, those peers are second-class citizens. I'll be happy to go into details on the Android side, as deep as anyone wants to go.
Of course, these pale in comparison to net neutrality, for the reasons posed in this TechDirt post and beyond. Of the two, app market neutrality comes closer to net neutrality IMHO, insofar as both are focused on the prospects of oligopolies to control content distribution.
none of what Apple or Google is doing is any change to mobile data traffic
Correct. That's mostly up to app developers. Use of SSL and other encrypted communication protocols appear to be on the rise post-Snowden. I and others are working to help app developers do a better job here.
But if you guess the 4-digit numeric passcode that 90%+ of users use to "secure" their phone? Wide open, encryption irrelevant.
The encryption isn't "irrelevant", but it is easily bypassed. This is not significantly different than anything else in encryption: your security is only as good as your key. More stuff could be done here, at the device level (e.g., separate keys for the full-disk encryption from what users use to unlock their powered-on phones) and at the app level (e.g., separate encrypted containers for highly-sensitive data).
Though I'd be curious if anyone knows of a study that would back up the "90%+" claim. I suspect that a lot of users do use weak PINs, but a survey might be illuminating.
So the phone still isn't really encrypted
Yes, it is. Your statement is akin to claiming that a locked door is not really locked, given the existence of lock picks and battering rams. Just because a security mechanism is ineffective against talented, determined attackers does not mean that it does not exist.
it has a lock you can retry infinite times
That too is something that could be improved, at least at the lockscreen level, whereby delays are introduced with every failure. If, for example, you added one second per PIN failure (no delay on first try, 1 second delay on second try, 2 second delay on third try, etc.), there would be a 50% of getting a 4-digit PIN right in several months of continuous attempts, but it could take as long as a couple of years if the attacker is extremely unlucky. I haven't been trying to brute-force devices, so I don't know how much of this is in place now (though Android historically lacked it). Which is why we have $5 wrenches and more sophisticated attacks (e.g., brute-forcing the disk encryption directly rather than trying to manually guess it at the lockscreen).
I do agree with your overall assessment that this is a lot of sturm und drang over an incremental improvement in security.
It seems like a week doesn't go by that someone doesn't launch yet another feeble over-hyped attempt to "fix email".
And your proof of this is... what, exactly?
Invariably these projects fail to take into account decades of real-world experience
And your proof of this is... what, exactly?
invariably, they prove to be insecure even before they're launched
And your proof of this is... what, exactly?
a choice which nicely maximizes the attack surface available to adversaries
And your proof of this is... what, exactly? In particular, please feel free to explain how a well-designed single-page application, backed by a well-designed Web service protocol, is intrinsically less secure than a desktop email program and existing standard email protocols.
Nearly all of them fail to ban HTML markup, an error which isn't merely enormous, but catastrophic.
And your proof of the catastrophic nature is... what, exactly? Now, if they don't sanitize the HTML (e.g., strip out JavaScript, , etc.), I will agree with your assessment. But that's a reasonably well-understood problem, employed in all sorts of Web apps, beyond Web-based email clients.
A substantial number fail to comply with BCP 38.
This would be relevant only for those projects that are offering hosted services, rather than software. Ingress filtering is incumbent upon the host, not the email software itself.
I think your second paragraph is reasonable (if a bit hyperbolic), and I think your general attitude (email is hard) is spot-on, but your first paragraph suffers from a surplus of hand-waving.
One of the key arguments made with the NSA "hoovering" the metadata is that they are "third-party records" and there is no right to privacy.
However, if law enforcement tried to claim that a rented apartment was a "third-party domicile" -- arguing that since you don't own it, you have no right to privacy, and they can toss any apartment at will -- that would get thrown out without a warrant.
Similarly, if law enforcement tried to claim that a rented post office box was a "third-party communications service", and that they could rifle through those whenever they want, that too would get tossed without a warrant.
Ditto for rented storage units.
We need case law that establishes that "rented" email accounts, "rented" file manager accounts, "rented" social network accounts, "rented" phone numbers, and the like are no different than rented apartments, PO boxes, and storage units. While we are "renting" from third parties, the privacy expectation is not lost just because third parties are involved.
The code in question is SE for Android, an Android-specific derivation of SELinux. SELinux has been part of mainstream Linux distros for a decade. While the NSA did contribute code to SELinux, SELinux is a standalone open source project with many contributors, and, more importantly, reviewers. Ditto for SE for Android.
The code in question is SE for Android, an Android-specific derivation of SELinux. SELinux has been part of mainstream Linux distros for a decade. While the NSA did contribute code to SELinux, SELinux is a standalone open source project with many contributors, and, more importantly, reviewers. Ditto for SE for Android.
So, which is more likely? That SELinux (with independent review) has a "sooper-sekrit" NSA back door, or that closed-source unreviewable OSes have them?
"which would mean the author would be forced into providing quite a few modifications that would not corrupt the original sense of the title"
As noted in another reply, 128 to 256 distinct word flips would be more than sufficient.
"What you are proposing here is some sort of human input from the author to avoid the errors that could arise from such system"
Bingo.
"As far as I can understand there is no such thing other than some modifications made by the system being shown to the authors so they can evaluate if it works well."
Or the authors coming up with the 128 to 256 occurrences themselves. That's not especially hard, and I say that as self-published author.
"But to come up with thousands or hundreds of thousands of variations that can uniquely identify a leak"
128 to 256 synonym pairs would be more than sufficient. Each represents an individual bit and can be flipped in combination.
"That's a shitload of wasted time, money and effort"
Speaking as an author, coming up with 128 to 256 synonym pairs would take me a couple of hours, tops. Remember that the algorithm involves not only the word flip, but the *specific* word flip. So, you come up with a pair of synonyms ("foo" and "bar"). Do a global search on the book to confirm which occurrences of "foo" can safely be switched to "bar" or vice-versa.
"Surely that's better spent working out how to make customers more willing to buy?"
Oh, I'm not saying that authors/publishers should be ignoring this. But you make it sound like this algorithm is rocket science, and it's not.
"the risk of false positives"
With 128 to 256 bits for the identity, a false positive (of the form where somebody tinkered with a copy to change the synonyms) is vanishingly unlikely. Tinkering with the book and toggling a synonym will make the book untraceable, but the odds of such a toggle happening to identify some other buyer is really tiny.
"the ease with which it can often be removed or obfuscated"
Somebody with two copies of the book could readily create a third copy that is untraceable. Few book readers would bother. Any DRM solution is toast in the face of a determined attack, and I'm not arguing otherwise.
"That's because the fingerprinting involves tampering with the integrity of the work"
That depends on your definition of "integrity" and the type of the "work".
For example, take this paragraph:
"Any publishers adopting this technique will be betraying the very books they claim to defend, by turning them from cherished friends into potential traitors. A far better approach for everyone, including the publishing industry, would be to offer more and better books at sensible prices -- with the correct, uncorrupted text."
This is nearly the same as the concluding paragraph of this post, with two word changes. The meaning of the paragraph, IMHO, is not substantially changed by those two word changes... but, then again, I am not the author of that paragraph, and so I am unqualified to make that claim.
If the book publisher works in concert with the author -- such as, for example, a self-published author -- it is eminently possible to come up with a laundry list of such synonym pairs and locations, where swapping between those words would not materially harm the work, but would represent bits to be toggled. Only the author will know which circumstances are safe to toggle without wrecking the meaning. And, of course, this will not work with all types of "works". Non-fiction will be easier than fiction, which will be easier than poetry.
So long as, in the eyes of the author, the integrity of the work is not compromised, using synonym toggle bits as a form of "soft DRM" is not significantly different than other forms of watermarking (e.g., steganographic insertion of identifiers into images), except that it is more reliable (e.g., not going to be wrecked if somebody tinkers with the images, such as by converting a book into another book format).
The point of "soft DRM" is to allow authors/publishers to more gently handle copyright infringement. Soft DRM of this type does not stop buyers from moving the book between devices, or from printing the book, etc. Mostly, it's there so that if a copy is distributed sans license, the author/publisher has some idea of who did it, so they can take appropriate steps.
And, once again, the "appropriate steps" will vary in severity, ranging from simply preventing that person from buying more books (akin to a shopkeeper refusing entry to those who have shoplifted) to full-on legal action. If you think that a lawsuit is an over-the-top response, that's an issue with the lawsuit, not with the "soft DRM" that enabled it.
So, IMHO, a blanket statement that this "involves tampering with the integrity of the work" is unsupportable. It may involve tampering, if the changes are made without author approval and if the changes do materially change the meaning of the affected passages. IOW, changing some words does not necessarily result in "corrupted text", any more than proofreading and editing the author's original words results in "corrupted text". Corruption is possible, but not a fait accompli.
It seems to me that request were made for more transparency, and they got more transparency. It isn't complete and total transparency, but it's more than before.
To recap:
Twitter thinks it is less transparency
Facebook thinks it is less transparency
Google thinks it is less transparency
Microsoft thinks it is less transparency
An anonymous coward thinks it is more transparency
Nobody said it was. The words "codified" and "codify" are modified by "ask" and "seek", indicating future behavior.
Further, the bill also only refers to social media accounts used for business, and not personal Internet accounts.
That is not entirely accurate IMHO. The bill's synopsis includes: "an employer may request or require an employee to disclose any user name, password, or other means for accessing an electronic communications device supplied or paid for in whole or in part by the employer or accounts or services provided by the employer or by virtue of the employee's employment relationship with the employer or that the employee uses for business purposes". The key portion is the last seven words. That will be used as justification to get any passwords and account information, on the grounds that they have no idea if an account was used "for business purposes" without first examining the account.
Rentn.org, it has come to our attention that you are making illegal use of our trademark, "snarky". Our trademark application covers its use in "an arrangement of black and white pixels", and your comment is clearly such an arrangement. We demand that TechDirt immediately take down your unlicensed used of our intellectual property.
And, to those who are thinking about replying, pointing out their patents on pixels (or the colors black and white, or on the English language), please be advised that we possess significant second-strike capability.
On the post: Yes, The Appeals Court Got Basically Everything Wrong In Deciding API's Are Covered By Copyright
Re: YOU "non-programmer" don't grasp what an API is! It's INTRINSIC AND INSEPARABLE FROM OTHER CODE.
That depends.
For example, presumably you are reading this in a Web browser. Your Web browser has an address bar, and in that address bar, you will see something like https://www.techdirt.com/articles/.... That is a URL. It is interpreted by the Web browser and used to retrieve the HTML for this Web page (which in turn contains other URLs for things like images).
The interface used for the communication between the Web browser and the Web server is the Hypertext Transfer Protocol (HTTP) and related protocols. These are defined via specifications and are independent from any particular implementation. A copyright on the specification would not extend to an implementation, any more than the copyright on the specification for a bolt would extend to an actual bolt.
Similarly, many programming languages (e.g., C, C++) have clear separation between interface and implementation.
Now, what harms Google here is that Java is not one of those languages. Interface is much more tightly intertwingled with implementation in Java.
> It's not just arbitrary inputs that anyone could come up with in a couple seconds.
That depends entirely on how fast you type. I certainly have defined APIs "in a couple seconds".
On the post: Daily Dot Latest To 'Keep Conversation Moving Forward' By Not Letting Site Visitors Comment At All
A Sense of Strategy
Yes, but you seem to be taking this from the attitude that every Web site should have comments.
Having a participatory community needs to be a strategic decision. It requires investment, and therefore it needs to make sense to make that investment.
The problem is that too many sites added comments because "it's what all the cool kids are doing", without any strategic sense for why they have the comments. It was a checkbox on the VC funding form, for example.
So, for many of these sites, I would argue that their decision is simply a reversion to what they should have done from the outset, given their organizational priorities. And, in many cases, it will be better that they do drop the comments, as if they are not going to make the necessary investments in engagement, those comments can easily turn into a cesspool, which reflects poorly on the organization. IOW, do it right or don't do it at all.
The highfalutin' PR fodder for why they are taking down the comments is tripe, but PR fodder is generally tripe. It may be worthy of ridicule, but it is hardly newsworthy.
On the post: Reminder: Fair Use Is A Right -- And Not 'An Exception' Or 'A Defense'
Re:
Feel free to provide a citation to a dictionary that has that definition. Feel free to link to it, if the dictionary is online.
On the post: No, 'App Neutrality' Is Not A Thing
App Platform Neutrality vs. App Market Neutrality
Mr. Chen is focused on what I'll call "app platform neutrality", somehow requiring developers to write apps for platforms other than iOS and Android. This would be akin to requiring developers to write apps for OS X and Linux instead of just Windows, in terms of desktop operating systems.
Mr. Cuban is focused on what I'll call "app market neutrality". His concern seems less about the platform and more about the gatekeeper role that Apple plays with iOS and, to a somewhat lesser extent, Google plays with Android. He wants there to be other possible gatekeepers, in the form of having other app distribution channels be able to be peers of the App Store and Play Store. Right now, short of jailbreaking, AFAIK it is impossible to have a peer of the App Store. While peers of the Play Store exist (e.g., Amazon AppStore for Android), on Google Play-centered devices, those peers are second-class citizens. I'll be happy to go into details on the Android side, as deep as anyone wants to go.
Of course, these pale in comparison to net neutrality, for the reasons posed in this TechDirt post and beyond. Of the two, app market neutrality comes closer to net neutrality IMHO, insofar as both are focused on the prospects of oligopolies to control content distribution.
On the post: Nine Epic Failures Of Regulating Cryptography
Re: The funny part is...
Correct. That's mostly up to app developers. Use of SSL and other encrypted communication protocols appear to be on the rise post-Snowden. I and others are working to help app developers do a better job here.
The encryption isn't "irrelevant", but it is easily bypassed. This is not significantly different than anything else in encryption: your security is only as good as your key. More stuff could be done here, at the device level (e.g., separate keys for the full-disk encryption from what users use to unlock their powered-on phones) and at the app level (e.g., separate encrypted containers for highly-sensitive data).
Though I'd be curious if anyone knows of a study that would back up the "90%+" claim. I suspect that a lot of users do use weak PINs, but a survey might be illuminating.
Yes, it is. Your statement is akin to claiming that a locked door is not really locked, given the existence of lock picks and battering rams. Just because a security mechanism is ineffective against talented, determined attackers does not mean that it does not exist.
That too is something that could be improved, at least at the lockscreen level, whereby delays are introduced with every failure. If, for example, you added one second per PIN failure (no delay on first try, 1 second delay on second try, 2 second delay on third try, etc.), there would be a 50% of getting a 4-digit PIN right in several months of continuous attempts, but it could take as long as a couple of years if the attacker is extremely unlucky. I haven't been trying to brute-force devices, so I don't know how much of this is in place now (though Android historically lacked it). Which is why we have $5 wrenches and more sophisticated attacks (e.g., brute-forcing the disk encryption directly rather than trying to manually guess it at the lockscreen).
I do agree with your overall assessment that this is a lot of sturm und drang over an incremental improvement in security.
On the post: Google Glass Wearer Claims He Was Yanked Out Of Movie, Held In Office For Hours, Over Filming He Didn't Do [Updated]
Re: Re:
http://www.businessinsider.com/man-interrogated-by-fbi-for-wearing-prescription-google-glass-at -the-movies-2014-1?op=1
On the post: Awesome Stuff: More Crowdfunding Attempts At Private And Secure Communications
Re: These flailing and misguided email systems
And your proof of this is... what, exactly?
And your proof of this is... what, exactly?
And your proof of this is... what, exactly?
And your proof of this is... what, exactly? In particular, please feel free to explain how a well-designed single-page application, backed by a well-designed Web service protocol, is intrinsically less secure than a desktop email program and existing standard email protocols.
And your proof of the catastrophic nature is... what, exactly? Now, if they don't sanitize the HTML (e.g., strip out JavaScript, , etc.), I will agree with your assessment. But that's a reasonably well-understood problem, employed in all sorts of Web apps, beyond Web-based email clients.
This would be relevant only for those projects that are offering hosted services, rather than software. Ingress filtering is incumbent upon the host, not the email software itself.
I think your second paragraph is reasonable (if a bit hyperbolic), and I think your general attitude (email is hard) is spot-on, but your first paragraph suffers from a surplus of hand-waving.
On the post: Telco Astroturfing Or Elaborate Double-Reverse Sabotage Fakeout? You Decide
Re: Re:
With frickin' laser beams attached to their heads.
Pretending to be telco astroturfers.
.
.
.
Oh, sorry. My bad. I just assumed that Dr. Evil had one of those razor things everyone's talking about. Y'know, given his head, and all.
On the post: Senator Wyden: Public Has Been Actively Mislead By Government Officials Over Surveillance
Digital vs. Physical
However, if law enforcement tried to claim that a rented apartment was a "third-party domicile" -- arguing that since you don't own it, you have no right to privacy, and they can toss any apartment at will -- that would get thrown out without a warrant.
Similarly, if law enforcement tried to claim that a rented post office box was a "third-party communications service", and that they could rifle through those whenever they want, that too would get tossed without a warrant.
Ditto for rented storage units.
We need case law that establishes that "rented" email accounts, "rented" file manager accounts, "rented" social network accounts, "rented" phone numbers, and the like are no different than rented apartments, PO boxes, and storage units. While we are "renting" from third parties, the privacy expectation is not lost just because third parties are involved.
On the post: NSA Bosses Mantra: Who Cares What The Law Says, 'Collect It All'
Re: Oh, let's name "tech companies", starting with Google.
The code in question is SE for Android, an Android-specific derivation of SELinux. SELinux has been part of mainstream Linux distros for a decade. While the NSA did contribute code to SELinux, SELinux is a standalone open source project with many contributors, and, more importantly, reviewers. Ditto for SE for Android.
On the post: NSA Talking Points On Utah Data Center: We're Teaming Up With Tech Companies To 'Protect' The Internet
Re:
So, which is more likely? That SELinux (with independent review) has a "sooper-sekrit" NSA back door, or that closed-source unreviewable OSes have them?
On the post: Latest Stupid DRM Idea: Ebooks With Corrupted Texts That Vary By Customer
Re: Re: "Integrity" not necessarily compromised
As noted in another reply, 128 to 256 distinct word flips would be more than sufficient.
"What you are proposing here is some sort of human input from the author to avoid the errors that could arise from such system"
Bingo.
"As far as I can understand there is no such thing other than some modifications made by the system being shown to the authors so they can evaluate if it works well."
Or the authors coming up with the 128 to 256 occurrences themselves. That's not especially hard, and I say that as self-published author.
On the post: Latest Stupid DRM Idea: Ebooks With Corrupted Texts That Vary By Customer
Re: Re: "Integrity" not necessarily compromised
128 to 256 synonym pairs would be more than sufficient. Each represents an individual bit and can be flipped in combination.
"That's a shitload of wasted time, money and effort"
Speaking as an author, coming up with 128 to 256 synonym pairs would take me a couple of hours, tops. Remember that the algorithm involves not only the word flip, but the *specific* word flip. So, you come up with a pair of synonyms ("foo" and "bar"). Do a global search on the book to confirm which occurrences of "foo" can safely be switched to "bar" or vice-versa.
"Surely that's better spent working out how to make customers more willing to buy?"
Oh, I'm not saying that authors/publishers should be ignoring this. But you make it sound like this algorithm is rocket science, and it's not.
"the risk of false positives"
With 128 to 256 bits for the identity, a false positive (of the form where somebody tinkered with a copy to change the synonyms) is vanishingly unlikely. Tinkering with the book and toggling a synonym will make the book untraceable, but the odds of such a toggle happening to identify some other buyer is really tiny.
"the ease with which it can often be removed or obfuscated"
Somebody with two copies of the book could readily create a third copy that is untraceable. Few book readers would bother. Any DRM solution is toast in the face of a determined attack, and I'm not arguing otherwise.
On the post: Latest Stupid DRM Idea: Ebooks With Corrupted Texts That Vary By Customer
"Integrity" not necessarily compromised
That depends on your definition of "integrity" and the type of the "work".
For example, take this paragraph:
"Any publishers adopting this technique will be betraying the very books they claim to defend, by turning them from cherished friends into potential traitors. A far better approach for everyone, including the publishing industry, would be to offer more and better books at sensible prices -- with the correct, uncorrupted text."
This is nearly the same as the concluding paragraph of this post, with two word changes. The meaning of the paragraph, IMHO, is not substantially changed by those two word changes... but, then again, I am not the author of that paragraph, and so I am unqualified to make that claim.
If the book publisher works in concert with the author -- such as, for example, a self-published author -- it is eminently possible to come up with a laundry list of such synonym pairs and locations, where swapping between those words would not materially harm the work, but would represent bits to be toggled. Only the author will know which circumstances are safe to toggle without wrecking the meaning. And, of course, this will not work with all types of "works". Non-fiction will be easier than fiction, which will be easier than poetry.
So long as, in the eyes of the author, the integrity of the work is not compromised, using synonym toggle bits as a form of "soft DRM" is not significantly different than other forms of watermarking (e.g., steganographic insertion of identifiers into images), except that it is more reliable (e.g., not going to be wrecked if somebody tinkers with the images, such as by converting a book into another book format).
The point of "soft DRM" is to allow authors/publishers to more gently handle copyright infringement. Soft DRM of this type does not stop buyers from moving the book between devices, or from printing the book, etc. Mostly, it's there so that if a copy is distributed sans license, the author/publisher has some idea of who did it, so they can take appropriate steps.
And, once again, the "appropriate steps" will vary in severity, ranging from simply preventing that person from buying more books (akin to a shopkeeper refusing entry to those who have shoplifted) to full-on legal action. If you think that a lawsuit is an over-the-top response, that's an issue with the lawsuit, not with the "soft DRM" that enabled it.
So, IMHO, a blanket statement that this "involves tampering with the integrity of the work" is unsupportable. It may involve tampering, if the changes are made without author approval and if the changes do materially change the meaning of the affected passages. IOW, changing some words does not necessarily result in "corrupted text", any more than proofreading and editing the author's original words results in "corrupted text". Corruption is possible, but not a fait accompli.
On the post: DOJ Says Tech Companies Can Sort Of Release FISA Numbers, But.. In A Way That Decreases Transparency
Re:
To recap:
On the post: TIME/CNN Poll Shows Increasing Number Of Americans Won't Give Up Civil Liberties To Fight Terrorism
Species Issue
(this comment is "BYO punchline")
On the post: IL Follows Suit: Employers Right To Ask For Social Media Passwords Codified Into Law
Re: Factual errors in the article
Nobody said it was. The words "codified" and "codify" are modified by "ask" and "seek", indicating future behavior.
That is not entirely accurate IMHO. The bill's synopsis includes: "an employer may request or require an employee to disclose any user name, password, or other means for accessing an electronic communications device supplied or paid for in whole or in part by the employer or accounts or services provided by the employer or by virtue of the employee's employment relationship with the employer or that the employee uses for business purposes". The key portion is the last seven words. That will be used as justification to get any passwords and account information, on the grounds that they have no idea if an account was used "for business purposes" without first examining the account.
On the post: NYC Mayor Bloomberg Thinks Boston Bombing Renders The Constitution Obsolete
Polls Show Growing Resolve to Live With Terror Threat
A timely Nate Silver piece, illustrating that "an increasing share of the public is skeptical about sacrificing personal freedoms for security."
On the post: Google Competitors File Ridiculous EU Complaint Arguing That 'Free' Android Is Anti-Competitive
Re:
Citation, please.
On the post: Two Famous Journalism Institutions Shame Themselves By Not Standing Up For Basic Fair Use
Re:
And, to those who are thinking about replying, pointing out their patents on pixels (or the colors black and white, or on the English language), please be advised that we possess significant second-strike capability.
Next >>