Except that in most cases, the contract is not being altered. It is being terminated, and a new contract is being added in its place, which you must agree to if you want to continue using the service. As long as the original contract did not imply that your right to use the service was permanent, there's really no difference between an Internet service changing their terms of service and a skating rink adding additional rules that people have to follow while skating. If the rules don't apply retroactively, not only is it not fraud, but it is also a perfectly reasonable thing to do.
That said, IMO, it is unethical to make material changes to the terms without warning and without giving users an opportunity to wind down their use of the service. That doesn't make it illegal, of course, just wrong.
And to the extent that the users don't know about a change, it probably isn't binding, but notification requirements are a separate issue from being able to change the terms....
Clear language? Legalese is about as far from clear as one can get.
Apart from severability and choice of law/venue clauses, there should be almost no legalese in a privacy policy, for two reasons.
First, a contract requires a meeting of the minds. If your policy is so abstruse that one party doesn't actually understand the terms, you may not actually have a contract.
Second, if you can't explain in common English what you are doing with my data, that almost always means that you're doing something nefarious, or at least dodgy. And if it requires a hundred-word compound-complex sentence, you need to hire a better writer who knows how to split things up into manageable paragraphs. Seriously, it just isn't that hard to explain your policies in plain and simple English. And it shouldn't require tens of pages of text just for your privacy policy. If it does, your policy probably has way too many exceptions and special cases for my taste.
I'm in the process of writing a terms-of-service/privacy-policy document for a website right now, for a site I'm currently in the process of developing. It combines a fair bit of snark and humor with a very simple, easy-to-understand explanation of what information the site collects and how that information is or is not disclosed. You can read the current version here.
I think it would be more precise to say that English has largely replaced Latin and Greek as the shared language of communication across cultures. Thus, in much the same way that someone native to Greece two hundred years ago did not need to know English to communicate with people in other countries, someone native to an English-speaking nation today need not learn Latin for that purpose except as an intellectual exercise.
So I ask you this- even if the system is "easy to game", why the hell would you want to risk it? Maybe you get past their security once, twice, a dozen times, etc. Maybe it is easy to game. That's nice and all.
The question you should be asking yourself is: "What are the consequences of being caught?". These people will happily label you as a terrorist and put you on a no-fly list FOR THE REST OF YOUR LIFE.
Which is probably about half an hour for most of the people who would likely be trying to game the system. And that is why it is the responsibility of security researchers and other folks to point out the flaws in the system and to make the TSA look like idiots at every possible opportunity. It is their civic duty, as they represent the only remaining hope that the TSA will either go away or become useful.
If it takes your HR department weeks or months to get a written offer, you seriously need to fire your HR department ASAP. Companies that are slow to hire people tend to lose the vast majority of the most qualified candidates that they're trying to hire, and the people they don't lose are frequently people who couldn't get jobs anywhere else. Such practices significantly hurt the quality of a company's workforce.
As you said, highly successful companies like Google, Apple, Facebook, etc. don't have those sorts of problems. More to the point, that's a big reason for their success. Companies whose hiring processes are more agile have a decided competitive advantage over companies whose hiring processes impede hiring the best and brightest. That means not only offering a competitive salary and competitive benefits, but also a competitive start date.
Yes, yes it is. It's a very big oversight. There are many ways that you could fix it—adding bypass pipes so that only a fraction of the water runs past the turbine, adding dummy loads, designing the system in such a way that pumping is unnecessary (which admittedly won't help the waste storage pools), etc. Newer reactor designs do these things. The Fukushima reactors, however, were near or beyond their original design lifespan, if memory serves. They're ancient designs that should have been retired a decade ago or more.
You might reasonably ask, then, why we're still running nuclear reactors that are over forty years old. The underlying cause is twofold. First, the cost for decommissioning a reactor is spectacular, so nobody wants to do it. Second, you can't build new reactors to replace the decommissioned reactors because of all the anti-nuclear backlash resulting from Three Mile Island and Chernobyl. This means that plant operators are forced to stretch out the life of the reactor far more than they rightfully should. So the NIMBYism has actually made nuclear reactors less safe. How's that for irony?
To be fair, this sounds exactly like working for any large corporation. =)
It's the polar opposite of my experience. From what I've seen in the corporate world, it is the employees who ask to take some time off before they start. The employers, given a chance, would rather have you start a week after the interview. If it takes more than a couple of weeks to get a call from HR to discuss salary, that usually means they didn't like you, and they're looking for other candidates.
Now to be fair, screw-ups with contractors happen, but I've never seen anything remotely that messy when a contractor transitions to a full employee. And I've never seen it take anywhere near nine months to bring in anyone, contractor or otherwise, unless perhaps some of the summer interns get provisional job offers that many months before they graduate, but that isn't really a similar situation.
At my current job, I went from interview to orientation in... I believe five days, give or take a day. This is not unusual. Nine months is unusual. It means either that the company is a bureaucratic hellhole that will make you want to run away in terror after a week or that the position is not something they urgently want to fill, in which case it will be the first job that they cut in six months when the layoffs come....
Because power plants are designed to generate a lot of power, and most are not designed to be able to generate a small amount of power. When the mains goes offline, they can't dump the power anywhere, and without that load to keep the generator speed regulated, the turbines would spin up to an unsafe speed and would damage themselves, so they have to shut down the reactor. Thus, if the plant is an older design that requires active safety systems after a SCRAM, they have to provide a backup power source to power those safety systems.
I originally tried a shared hosting plan that was down around that price point. It was a horrific experience involving a massively overloaded server that periodically stopped serving traffic for a half a minute at a time. I'd rather pay a little more for a reliable server with a reliably fast connection, shared or not.
Tell the webhost they have XYZ days to fix the problem before you publish the exploit.
Or if you have shell access and/or the ability to run scripts on the server, fix it yourself with chmod. It doesn't really matter if other users can see your home directory. What matters is whether they can see what's inside your home directory, and those permissions are under your account's control.
Unless, of course, this is Windows shared hosting, in which case the correct answer is "Don't do that.":-D
Or because shared hosting is a lot cheaper and is good enough for many purposes. I use shared hosting for a website that basically acts like a poor-man's Akamai cache of photographs for my real website. For $9 a month, it makes my home DSL connection fast enough to host my photo server, because I only have to push each photo out over the slow link exactly once.
Why would I pay more for a VPS when there's no content on the site that isn't publicly available and no databases to protect?
What difference does it make who (the graphics card or the monitor) is doing the scaling?
Three big differences come to mind:
The graphics card probably has more precise pixel values (floating-point values instead of scaled integers per color channel), so even if the hardware scaling algorithms in the monitor are better than "whatever we can do on ten cents of silicon" (which is a big assumption), they'll still be slightly lower quality than the GPU can produce.
The monitor doesn't have anything remotely as powerful as a GPU in it, so it is limited in the quality of scaling algorithm it can realistically implement.
The monitor can scale only the final, layer-blended image data. That means elements that need to be precise (e.g. text) are just as blurry as everything else. By contrast, a game doing the scaling on the GPU could scale those elements separately, rendering things like text at the panel's native resolution and using alpha blending to superimpose it over blurrier, scaled-up game elements.
Why don't games just spawn a separate X11 window server instance with a different resolution on a separate VC? Adding proper resource sharing between X11 instances seems like it would be a lot easier to do than rearchitecting all the existing apps to do the right thing during a temporary resolution change.
And there's no benefit to a full-screen app running in the same X11 instance as any other app other than making it possible to transition a window from being a normal window to a full screen window and back, and with a resolution change, that won't work very well anyway, which makes even that argument mostly moot.
The current versions of SSL/TLS are never vulnerable to man-in-the-middle attacks unless a trusted certificate authority is compromised (as long as both client and server implement RFC 5746). Whether the certificate authorities are trustworthy is another question, of course.
This particular problem is caused by folks disabling the SSL stack's built-in chain validation and then not implementing their own. As far as I know, there are exactly two correct ways to support self-signed keys in Android: provide your own trust store that includes trust for that specific self-signed key or subclass the X509 validation class to add that specific self-signed key as an additional trusted anchor into the list of trusted anchors that it returns. Unfortunately, there's a lot of very bad advice out there, particularly on sites like Stack Overflow, telling folks to disable chain validation entirely. The result is that not only does the app trust that self-signed key, it also trusts any self-signed key.
It doesn't help that there's no canonical source for that information from Google, so there are many, many questions on sites like Stack Overflow that all ask the same basic question in different ways and get different answers....
Patient: Doctor, when I drill a hole in my hand, I can't scoop up water from the bucket to drink.
Doctor: Why did you drill a hole in your hand?
Patient: So that the acid wouldn't stay in my hand.
Doctor (alarmed): Why did you put acid in your hand?
Patient: Because the bucket dealer wanted too much money for a bucket.
No. He talked about how people can vote if they don't have an official voter ID. Using Bills as ID.
It's not legal*, and wrong but it isn't stuffing the ballot box.
Given that just a few days earlier, a Republican staffer in the same state was arrested and charged with voter fraud for discarding the voter registration cards of Democrats, the fraud probably balances out....
Agreed. I'd love to see a judge declare that terms of service longer than one screenful of information or not written in plain English are automatically invalid because the reader cannot be expected to read and comprehend them. Such a decision would fix a lot of serious TOS/shrink-wrap license abuse.
Very true. The right solution is to make signing free for homebrew creators, but either:
Require server-side signing where you upload the game and get back a signature. That way, they can do various checksum-style tests to see if the signed content is likely pirated before signing it.
Require that each homebrew game be signed using a private key that is specific to each device, and design the hardware/OS so that only factory-signed code can use that private key. Add factory-signed tools that perform those various checksum tests locally and ask the servers for permission before signing the binary. The servers could reject requests from out-of-date versions of the signing tools, so you could have the same sort of forced-updating process for the signing tools that you'd have with a server-side solution, but you wouldn't have to push the whole binary across the wire.
Charge a small amount of money for the ability to sign homebrew binaries.
Either way, it's a cat-and-mouse game, but at least with those sorts of schemes, the pirates are on their own when trying to gain hardware access instead of having the homebrew folks working alongside them. Many eyes make all security holes public, and all.
Depends on what you mean by scalers. There are two places where scaling can occur:
At the final output stage for resolution conversion (GPU). This invariably results in fuzzy crap because the additional detail required for good scaling no longer exists. Retina displays don't do that. (Well, they *can*, but that's a separate scaling process.)
When converting from drawing coordinates to screen coordinates. Outside of printers, this is not typically done because A. most people historically bought higher resolution screens to fit more stuff on the screen, B. prior to EDID, displays did not indicate their DPI, and C. even after EDID, most HDMI TVs lie about their physical dimensions, so the DPI info you get isn't usable unless your display supports DisplayID or you have prior knowledge of the actual dimensions (e.g. in a laptop).
Either way, if you're talking about displaying content on monitors, this has not been done for decades. It has certainly been possible, in principle, for decades, but it has not been done. Now printers, on the other hand....
No, because it is much better to tell people what resolution they get, and what size screen, or such instead of a useless name that means absolutely nothing. The only reason to use such terms is to confuse customers and make it harder to compare your products to the competitions' (of course Apple knows that it's customers don't comparison shop, so they don't really care there)
Uh, no. The term "Retina Display" has additional meaning above and beyond the DPI number. It also indicates that drawing points are mapped 2:1 onto hardware pixels instead of 1:1. If you merely double the DPI, you would expect fixed-size content on the screen (menus, etc.) to be half as big. With a retina display, it doesn't because of that mapping difference.
That problem can be fixed with the same technique that you *should* be using if you're working with self-signed certs—either hard-code your CA cert into your app and override the method that returns the list of trusted anchors to return the system set plus your own or set up a trust store that indicates trust for that anchor.
Or if you're really paranoid, hard-code a list of CA certs that you trust, which may only partially overlap with the system-provided set.
Slashdot Mirror
Except that in most cases, the contract is not being altered. It is being terminated, and a new contract is being added in its place, which you must agree to if you want to continue using the service. As long as the original contract did not imply that your right to use the service was permanent, there's really no difference between an Internet service changing their terms of service and a skating rink adding additional rules that people have to follow while skating. If the rules don't apply retroactively, not only is it not fraud, but it is also a perfectly reasonable thing to do.
That said, IMO, it is unethical to make material changes to the terms without warning and without giving users an opportunity to wind down their use of the service. That doesn't make it illegal, of course, just wrong.
And to the extent that the users don't know about a change, it probably isn't binding, but notification requirements are a separate issue from being able to change the terms....
Apart from severability and choice of law/venue clauses, there should be almost no legalese in a privacy policy, for two reasons.
First, a contract requires a meeting of the minds. If your policy is so abstruse that one party doesn't actually understand the terms, you may not actually have a contract.
Second, if you can't explain in common English what you are doing with my data, that almost always means that you're doing something nefarious, or at least dodgy. And if it requires a hundred-word compound-complex sentence, you need to hire a better writer who knows how to split things up into manageable paragraphs. Seriously, it just isn't that hard to explain your policies in plain and simple English. And it shouldn't require tens of pages of text just for your privacy policy. If it does, your policy probably has way too many exceptions and special cases for my taste.
I'm in the process of writing a terms-of-service/privacy-policy document for a website right now, for a site I'm currently in the process of developing. It combines a fair bit of snark and humor with a very simple, easy-to-understand explanation of what information the site collects and how that information is or is not disclosed. You can read the current version here.
Comments or chuckles welcome.
I think it would be more precise to say that English has largely replaced Latin and Greek as the shared language of communication across cultures. Thus, in much the same way that someone native to Greece two hundred years ago did not need to know English to communicate with people in other countries, someone native to an English-speaking nation today need not learn Latin for that purpose except as an intellectual exercise.
Which is probably about half an hour for most of the people who would likely be trying to game the system. And that is why it is the responsibility of security researchers and other folks to point out the flaws in the system and to make the TSA look like idiots at every possible opportunity. It is their civic duty, as they represent the only remaining hope that the TSA will either go away or become useful.
I hear it stinks on ice.
Obligatory links:
http://nooooooooooooooo.com (seems to be down at the moment)
http://www.youtube.com/watch?v=WWaLxFIVX1s
If it takes your HR department weeks or months to get a written offer, you seriously need to fire your HR department ASAP. Companies that are slow to hire people tend to lose the vast majority of the most qualified candidates that they're trying to hire, and the people they don't lose are frequently people who couldn't get jobs anywhere else. Such practices significantly hurt the quality of a company's workforce.
As you said, highly successful companies like Google, Apple, Facebook, etc. don't have those sorts of problems. More to the point, that's a big reason for their success. Companies whose hiring processes are more agile have a decided competitive advantage over companies whose hiring processes impede hiring the best and brightest. That means not only offering a competitive salary and competitive benefits, but also a competitive start date.
Yes, yes it is. It's a very big oversight. There are many ways that you could fix it—adding bypass pipes so that only a fraction of the water runs past the turbine, adding dummy loads, designing the system in such a way that pumping is unnecessary (which admittedly won't help the waste storage pools), etc. Newer reactor designs do these things. The Fukushima reactors, however, were near or beyond their original design lifespan, if memory serves. They're ancient designs that should have been retired a decade ago or more.
You might reasonably ask, then, why we're still running nuclear reactors that are over forty years old. The underlying cause is twofold. First, the cost for decommissioning a reactor is spectacular, so nobody wants to do it. Second, you can't build new reactors to replace the decommissioned reactors because of all the anti-nuclear backlash resulting from Three Mile Island and Chernobyl. This means that plant operators are forced to stretch out the life of the reactor far more than they rightfully should. So the NIMBYism has actually made nuclear reactors less safe. How's that for irony?
It's the polar opposite of my experience. From what I've seen in the corporate world, it is the employees who ask to take some time off before they start. The employers, given a chance, would rather have you start a week after the interview. If it takes more than a couple of weeks to get a call from HR to discuss salary, that usually means they didn't like you, and they're looking for other candidates.
Now to be fair, screw-ups with contractors happen, but I've never seen anything remotely that messy when a contractor transitions to a full employee. And I've never seen it take anywhere near nine months to bring in anyone, contractor or otherwise, unless perhaps some of the summer interns get provisional job offers that many months before they graduate, but that isn't really a similar situation.
At my current job, I went from interview to orientation in... I believe five days, give or take a day. This is not unusual. Nine months is unusual. It means either that the company is a bureaucratic hellhole that will make you want to run away in terror after a week or that the position is not something they urgently want to fill, in which case it will be the first job that they cut in six months when the layoffs come....
Because power plants are designed to generate a lot of power, and most are not designed to be able to generate a small amount of power. When the mains goes offline, they can't dump the power anywhere, and without that load to keep the generator speed regulated, the turbines would spin up to an unsafe speed and would damage themselves, so they have to shut down the reactor. Thus, if the plant is an older design that requires active safety systems after a SCRAM, they have to provide a backup power source to power those safety systems.
I originally tried a shared hosting plan that was down around that price point. It was a horrific experience involving a massively overloaded server that periodically stopped serving traffic for a half a minute at a time. I'd rather pay a little more for a reliable server with a reliably fast connection, shared or not.
Or if you have shell access and/or the ability to run scripts on the server, fix it yourself with chmod. It doesn't really matter if other users can see your home directory. What matters is whether they can see what's inside your home directory, and those permissions are under your account's control.
Unless, of course, this is Windows shared hosting, in which case the correct answer is "Don't do that." :-D
Or because shared hosting is a lot cheaper and is good enough for many purposes. I use shared hosting for a website that basically acts like a poor-man's Akamai cache of photographs for my real website. For $9 a month, it makes my home DSL connection fast enough to host my photo server, because I only have to push each photo out over the slow link exactly once.
Why would I pay more for a VPS when there's no content on the site that isn't publicly available and no databases to protect?
Which is arguably a bug in and of itself.
Three big differences come to mind:
Why don't games just spawn a separate X11 window server instance with a different resolution on a separate VC? Adding proper resource sharing between X11 instances seems like it would be a lot easier to do than rearchitecting all the existing apps to do the right thing during a temporary resolution change.
And there's no benefit to a full-screen app running in the same X11 instance as any other app other than making it possible to transition a window from being a normal window to a full screen window and back, and with a resolution change, that won't work very well anyway, which makes even that argument mostly moot.
The current versions of SSL/TLS are never vulnerable to man-in-the-middle attacks unless a trusted certificate authority is compromised (as long as both client and server implement RFC 5746). Whether the certificate authorities are trustworthy is another question, of course.
This particular problem is caused by folks disabling the SSL stack's built-in chain validation and then not implementing their own. As far as I know, there are exactly two correct ways to support self-signed keys in Android: provide your own trust store that includes trust for that specific self-signed key or subclass the X509 validation class to add that specific self-signed key as an additional trusted anchor into the list of trusted anchors that it returns. Unfortunately, there's a lot of very bad advice out there, particularly on sites like Stack Overflow, telling folks to disable chain validation entirely. The result is that not only does the app trust that self-signed key, it also trusts any self-signed key.
It doesn't help that there's no canonical source for that information from Google, so there are many, many questions on sites like Stack Overflow that all ask the same basic question in different ways and get different answers....
Patient: Doctor, when I drill a hole in my hand, I can't scoop up water from the bucket to drink.
Doctor: Why did you drill a hole in your hand?
Patient: So that the acid wouldn't stay in my hand.
Doctor (alarmed): Why did you put acid in your hand?
Patient: Because the bucket dealer wanted too much money for a bucket.
Yeah, it's like that.
Given that just a few days earlier, a Republican staffer in the same state was arrested and charged with voter fraud for discarding the voter registration cards of Democrats, the fraud probably balances out....
Agreed. I'd love to see a judge declare that terms of service longer than one screenful of information or not written in plain English are automatically invalid because the reader cannot be expected to read and comprehend them. Such a decision would fix a lot of serious TOS/shrink-wrap license abuse.
Very true. The right solution is to make signing free for homebrew creators, but either:
Either way, it's a cat-and-mouse game, but at least with those sorts of schemes, the pirates are on their own when trying to gain hardware access instead of having the homebrew folks working alongside them. Many eyes make all security holes public, and all.
It is probably just HTTP live streaming. Try VLC.
Depends on what you mean by scalers. There are two places where scaling can occur:
Either way, if you're talking about displaying content on monitors, this has not been done for decades. It has certainly been possible, in principle, for decades, but it has not been done. Now printers, on the other hand....
Coordinate Systems and Drawing in iOS
Uh, no. The term "Retina Display" has additional meaning above and beyond the DPI number. It also indicates that drawing points are mapped 2:1 onto hardware pixels instead of 1:1. If you merely double the DPI, you would expect fixed-size content on the screen (menus, etc.) to be half as big. With a retina display, it doesn't because of that mapping difference.
That problem can be fixed with the same technique that you *should* be using if you're working with self-signed certs—either hard-code your CA cert into your app and override the method that returns the list of trusted anchors to return the system set plus your own or set up a trust store that indicates trust for that anchor.
Or if you're really paranoid, hard-code a list of CA certs that you trust, which may only partially overlap with the system-provided set.