Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 1
If they contract is truly only one way, it's not a contract at all -- Without mutual consideration, the agreement isn't even worth the paper it's printed on.
However, being considered for a job is arguably consideration.
Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 1
It helps if both sides initial the changes, but it isn't required.
All that has happened is that the company presented a contract to the employee, the employee refused, and presented a counter-offer, which the company accepted.
You weren't required to initial every paragraph, nor are they.
Maybe they just assume you wouldn't admit that in public anyway... I know I certainly wouldn't, if the quality of the Ericsson phone I owned was any measure.
Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 1
My first job was a local ISP, 18, straight out of high school, and I modified the non-compete (and discussed this with the HR rep, I didn't tuck the changes in the center of a large agreement or something) and it wasn't a problem.
My current $DAYJOB's latest NDA forbids me from disclosing my compensation.
Although I would rather enjoy explaining to my accountant (and the gov't, mortgage broker, etc) that I cannot reveal my annual income, I flat out refused to sign it. As of yet, they've decided my skills are more valuable then their updated NDA.
The company's argument is that it's only intended to prevent me from disclosing that information to the competition and other employees, to avoid competitive advantages as well as to help foster a positive working environment for all employees. My response was that they should word the NDA in such a fashion, rather then forbidding me from revealing my compensation at all.
As far as other employee's, that is reasonable fair too -- I happen to know I started at over double what some of the other guys that started around the same time as me were offered, although the gap has closed significantly over the last few years. I also know that I make almost as much as my boss -- I originally negotiated directly with the CEO and VP for salary though, but nonetheless I can see how it could make my coworkers upset, so the corporation has an interest in me not revealing that fact.
Re:This is actually my HOPE for the future
on
Censoring a Number
·
· Score: 1
Not at all -- It's simply impossible to use encryption to protect anything if the enemy has the encryption key in their hands.
It's perfectly possible to have relatively safe/secure encryption between multiple parties who are all committed to maintaining the security of the encryption, as long as you keep the keys from the enemy.
Unfortunately for DRM, the consumer and the enemy are the same person.
Re:Social hack - use "bullfight" for "speed trap".
on
Is Your GPS Naive?
·
· Score: 1
What SiteKey does is change the methodology of attacks. Previously you could phish for weeks until you have enough sets of credentials, then move to a untraceable location and see which ones are valid.
Now the authentication attempts must be done in real time, which raises the bar substantially. Among other things, this will make it more obvious to the bank when a number of bad authentication attempts are happening from one source IP (or one botnet)
It also means that when the bank discovers a phishing page, they can submit a login request and see where the login attempt comes from instantly, and then potentially work backward to find out who else has attempted to login from that IP (or other characteristics of the connection) to build a model of what the phisher is doing once they get access, and hopefully reverse the transactions before the money has gone too far.
But does it help the average user? Well, not really. We need to move beyond passwords to secure users.
A system that uses a password, RSA SecurID token, and a client certificate would be far more robust, but it would also be far more complex for grannie to configure -- Unless the support costs would come in under the cost of phishing, it's just not worth it.
Another thought would be to deploy smartcard readers and require the bank card to be physically inserted into the smartcard reader for the transaction to take place, this would allow for client and server certificates to be used, and the session to be immune to man-in-the-middle attacks.
Imagine, no URLs to trick a user into mistyping, no credentials to phish out of the user.
The biggest problem would be developing the hardware and software to be simple enough to use, lightweight, and developed using open standards (Not something most banks would grasp easily) or otherwise sufficiently cross-platform.
True -- But, I'd bet you could make a pretty good legal argument that due to the nature of P2P clients (especially torrents), uploading content to one user includes an implicit license to distribute that material.
This would be a rough analogy to uploading a file to a web hosting package, then suing the web server operator because they distributed the file.
And while true that the RIAA may not have the right to give me distribution rights, whether or not the RIAA has the power to grant that right or not wouldn't enter into it, since it's not likely RIAA's members would go after the RIAA.
Showing damages is still a problem -- It's very hard to go after someone for any sort of violation if the defendant's opening offer is to reemburse you for 100x the amount of damages you can claim.
Some people have often had the idea that there's something slightly shady about this because it means that in the process of downloading the file, the RIAA must also be uploading it to others, thereby becoming complicit in the distribution. Alas, there is no legal problem here, because one assumes the RIAA has been authorized by its members to distribute their materials in order to bust others. So you can't get them that way.
Sure, but at the same time, if the RIAA is intentionally and willfully releasing their content via the same P2P distribution channel as where they are actively suing users, it does present a bit of a legal problem. "I got it from the RIAA" would be a valid defense.
As always there is a chicken and the egg problem though, someone needs to first send the RIAA investigator a piece of the file before the RIAA can redistribute it, so potentially that first person would still be a target.
Yes -- Which means when you walk up to a PC and login as root/administrator, you don't know if the prompt asking for your credentials is the OS, or some user-mode trojan that wants to have some fun with your system.
With Windows, you know because Ctrl-Alt-Del cannot be intercepted by a user-mode program (unless it's already running with full administrator privileges, and even then, it needs a driver to intercept this sequence)
Which requires a driver to work -- The point of Ct-Alt-Del is called a secure attention sequence. This allows you to address the OS specifically, in a way that no user-level application can interfere with, prevent, or block.
This isn't strictly needed in Linux, since you have multiple consoles available and can use another console if you lose control of an app and are completely unable to terminate it (Although there may be a secure attention sequence in Linux too, I don't much know)
It does -- The user logged in with administrative credentials. The purpose of UAC isn't to see if the *user* should have an administrative token, but rather, if this specific process should have an administrative token.
Since UAC uses a secure desktop, regular apps cannot manipulate the dialog progmatically (you can't inject keystrokes or manipulate the mouse, for example)
If the logged in user doesn't have administrative privileges, they are required to enter credentials which do have the appropriate privileges.
Speaking of Mac commercials, I recently acquired a iBook from work (spare machine we had kicking around, part of my job requires supporting client software which can run on a Mac so it seemed like a reasonable thing to ask for)
While poking around I had this weird popup come up, it asked me for the administrator/root/whatever password for authentication. I was shocked, shocked I tell you, I've seen the Mac guy making fun of the Windows guy's secret service agent, but I didn't see the Mac's agent wandering around. I guess the Mac's secret service agent didn't make it in time for taping that commercial.
Now sure, it comes up a lot less on OSX then on Vista, but it's not exactly truth in advertising.
It also depends on the specific threat you're addressing. For example, so what if an exploit cannot allow your system to be root'd, if it's sufficient to allow third party code to execute, and that executable code can make outbound TCP connections, that's all a spam-zombie needs.
I wouldn't generally consider those as being severe though, since they'll only impact one user, and will be much easier to contain (simply delete the user's profile under Windows)
(Obviously this requires the user to be running as a limited user, not as root/administrator -- Luckily this is finally feasible in Windows Vista for virtually all applications)
In my opinion, any component shipped with the OS, or otherwise included in the OS install is fair game -- The idea being that out of the box this is how things stack up without involving user-added software.
I'm more up in the air about whether to take a default install or include all possible components offered by the OS' installer, but I'd be very tempted to suggest including them as well (Were there any IIS vulnerabilities in the list? Or any other Windows services/components which are not installed by default? -- This gets messy though)
I'd also consider, were any of the vulnerabilities negated by the Windows firewall in default configuration? -- In other words, if all we do is install the OS and run as a limited user, to what threats are we vulnerable? -- If we're willing to count vulnerabilities that apply only after core security features are disabled, then it's fair to assume the user has customized the setup, so it's also fair to installed all possible components which the OS shipped with -- In that case, all of the extra crud available should be counted)
I realize your average Linux distro isn't quite like the typical Windows box where you have a single base installation CD, and everything else is third party, which complicates things substantially when trying to determine what is part of the OS and what is not -- For purposes of comparison though, I'd suggest starting from an installation CD or DVD, and assuming nothing is downloaded from the internet.
Minor clarification, not at the request of MPAA/RIAA specifically, but rather, to allow consumers the ability to play so-called "secure" content.
None of the DRM in Vista prohibits you from doing anything at all that was possible in XP or 2000 or 98/ME either. Rather, a new feature was added (HD playback) which requires the DRM infrastructure.
Now, that being said, would I prefer that Microsoft focus their efforts elsewhere and tell the sellers of protected content to shove off and drop their restrictions if they want their media to play on PCs? Hell yeah.
Do I ever intend on using paying for media or using such features which required the OS to include DRM support? No. </rant>
Slashdot Mirror
If they contract is truly only one way, it's not a contract at all -- Without mutual consideration, the agreement isn't even worth the paper it's printed on.
However, being considered for a job is arguably consideration.
It helps if both sides initial the changes, but it isn't required.
All that has happened is that the company presented a contract to the employee, the employee refused, and presented a counter-offer, which the company accepted.
You weren't required to initial every paragraph, nor are they.
Maybe they just assume you wouldn't admit that in public anyway... I know I certainly wouldn't, if the quality of the Ericsson phone I owned was any measure.
My first job was a local ISP, 18, straight out of high school, and I modified the non-compete (and discussed this with the HR rep, I didn't tuck the changes in the center of a large agreement or something) and it wasn't a problem.
You win some, you lose some.
My current $DAYJOB's latest NDA forbids me from disclosing my compensation.
Although I would rather enjoy explaining to my accountant (and the gov't, mortgage broker, etc) that I cannot reveal my annual income, I flat out refused to sign it. As of yet, they've decided my skills are more valuable then their updated NDA.
The company's argument is that it's only intended to prevent me from disclosing that information to the competition and other employees, to avoid competitive advantages as well as to help foster a positive working environment for all employees. My response was that they should word the NDA in such a fashion, rather then forbidding me from revealing my compensation at all.
As far as other employee's, that is reasonable fair too -- I happen to know I started at over double what some of the other guys that started around the same time as me were offered, although the gap has closed significantly over the last few years. I also know that I make almost as much as my boss -- I originally negotiated directly with the CEO and VP for salary though, but nonetheless I can see how it could make my coworkers upset, so the corporation has an interest in me not revealing that fact.
#2 sounds about right...
Not at all -- It's simply impossible to use encryption to protect anything if the enemy has the encryption key in their hands.
It's perfectly possible to have relatively safe/secure encryption between multiple parties who are all committed to maintaining the security of the encryption, as long as you keep the keys from the enemy.
Unfortunately for DRM, the consumer and the enemy are the same person.
On my god, a SCHOOL!
What SiteKey does is change the methodology of attacks. Previously you could phish for weeks until you have enough sets of credentials, then move to a untraceable location and see which ones are valid.
Now the authentication attempts must be done in real time, which raises the bar substantially. Among other things, this will make it more obvious to the bank when a number of bad authentication attempts are happening from one source IP (or one botnet)
It also means that when the bank discovers a phishing page, they can submit a login request and see where the login attempt comes from instantly, and then potentially work backward to find out who else has attempted to login from that IP (or other characteristics of the connection) to build a model of what the phisher is doing once they get access, and hopefully reverse the transactions before the money has gone too far.
But does it help the average user? Well, not really. We need to move beyond passwords to secure users.
A system that uses a password, RSA SecurID token, and a client certificate would be far more robust, but it would also be far more complex for grannie to configure -- Unless the support costs would come in under the cost of phishing, it's just not worth it.
Another thought would be to deploy smartcard readers and require the bank card to be physically inserted into the smartcard reader for the transaction to take place, this would allow for client and server certificates to be used, and the session to be immune to man-in-the-middle attacks.
Imagine, no URLs to trick a user into mistyping, no credentials to phish out of the user.
The biggest problem would be developing the hardware and software to be simple enough to use, lightweight, and developed using open standards (Not something most banks would grasp easily) or otherwise sufficiently cross-platform.
This requires administrative privileges. If the user is planning on granting admin privileges, then obviously the malware owns the system.
Files can be restored easily -- Right click, choose "Previous versions" and go nuts. Harrah for shadow copies.
More importantly, he likely did give credit to the original author, himself. There wouldn't be much point in handling in the exercise otherwise.
The modern version of the good 'ol fashioned American Dream...
True -- But, I'd bet you could make a pretty good legal argument that due to the nature of P2P clients (especially torrents), uploading content to one user includes an implicit license to distribute that material.
This would be a rough analogy to uploading a file to a web hosting package, then suing the web server operator because they distributed the file.
And while true that the RIAA may not have the right to give me distribution rights, whether or not the RIAA has the power to grant that right or not wouldn't enter into it, since it's not likely RIAA's members would go after the RIAA.
Showing damages is still a problem -- It's very hard to go after someone for any sort of violation if the defendant's opening offer is to reemburse you for 100x the amount of damages you can claim.
Sure, but at the same time, if the RIAA is intentionally and willfully releasing their content via the same P2P distribution channel as where they are actively suing users, it does present a bit of a legal problem. "I got it from the RIAA" would be a valid defense.
As always there is a chicken and the egg problem though, someone needs to first send the RIAA investigator a piece of the file before the RIAA can redistribute it, so potentially that first person would still be a target.
Yes -- Which means when you walk up to a PC and login as root/administrator, you don't know if the prompt asking for your credentials is the OS, or some user-mode trojan that wants to have some fun with your system.
With Windows, you know because Ctrl-Alt-Del cannot be intercepted by a user-mode program (unless it's already running with full administrator privileges, and even then, it needs a driver to intercept this sequence)
Which requires a driver to work -- The point of Ct-Alt-Del is called a secure attention sequence. This allows you to address the OS specifically, in a way that no user-level application can interfere with, prevent, or block.
This isn't strictly needed in Linux, since you have multiple consoles available and can use another console if you lose control of an app and are completely unable to terminate it (Although there may be a secure attention sequence in Linux too, I don't much know)
It does -- The user logged in with administrative credentials. The purpose of UAC isn't to see if the *user* should have an administrative token, but rather, if this specific process should have an administrative token.
Since UAC uses a secure desktop, regular apps cannot manipulate the dialog progmatically (you can't inject keystrokes or manipulate the mouse, for example)
If the logged in user doesn't have administrative privileges, they are required to enter credentials which do have the appropriate privileges.
Exactly the same thing -- It *only* shows up in Vista when you are doing something that requires administrative privileges.
Have you ever tried Vista?
Sure, then if I start selling Linux boxes with VMWare and Windows installed, we'll call all of Windows' exploits Linux exploits too.
*sigh*
I should know better then to reply to an AC.
Speaking of Mac commercials, I recently acquired a iBook from work (spare machine we had kicking around, part of my job requires supporting client software which can run on a Mac so it seemed like a reasonable thing to ask for)
While poking around I had this weird popup come up, it asked me for the administrator/root/whatever password for authentication. I was shocked, shocked I tell you, I've seen the Mac guy making fun of the Windows guy's secret service agent, but I didn't see the Mac's agent wandering around. I guess the Mac's secret service agent didn't make it in time for taping that commercial.
Now sure, it comes up a lot less on OSX then on Vista, but it's not exactly truth in advertising.
It also depends on the specific threat you're addressing. For example, so what if an exploit cannot allow your system to be root'd, if it's sufficient to allow third party code to execute, and that executable code can make outbound TCP connections, that's all a spam-zombie needs.
I wouldn't generally consider those as being severe though, since they'll only impact one user, and will be much easier to contain (simply delete the user's profile under Windows)
(Obviously this requires the user to be running as a limited user, not as root/administrator -- Luckily this is finally feasible in Windows Vista for virtually all applications)
In my opinion, any component shipped with the OS, or otherwise included in the OS install is fair game -- The idea being that out of the box this is how things stack up without involving user-added software.
I'm more up in the air about whether to take a default install or include all possible components offered by the OS' installer, but I'd be very tempted to suggest including them as well (Were there any IIS vulnerabilities in the list? Or any other Windows services/components which are not installed by default? -- This gets messy though)
I'd also consider, were any of the vulnerabilities negated by the Windows firewall in default configuration? -- In other words, if all we do is install the OS and run as a limited user, to what threats are we vulnerable? -- If we're willing to count vulnerabilities that apply only after core security features are disabled, then it's fair to assume the user has customized the setup, so it's also fair to installed all possible components which the OS shipped with -- In that case, all of the extra crud available should be counted)
I realize your average Linux distro isn't quite like the typical Windows box where you have a single base installation CD, and everything else is third party, which complicates things substantially when trying to determine what is part of the OS and what is not -- For purposes of comparison though, I'd suggest starting from an installation CD or DVD, and assuming nothing is downloaded from the internet.
Minor clarification, not at the request of MPAA/RIAA specifically, but rather, to allow consumers the ability to play so-called "secure" content.
None of the DRM in Vista prohibits you from doing anything at all that was possible in XP or 2000 or 98/ME either. Rather, a new feature was added (HD playback) which requires the DRM infrastructure.
Now, that being said, would I prefer that Microsoft focus their efforts elsewhere and tell the sellers of protected content to shove off and drop their restrictions if they want their media to play on PCs? Hell yeah.
Do I ever intend on using paying for media or using such features which required the OS to include DRM support? No.
</rant>