A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different).
Exactly. And I wonder if they've done that already, and simply not updated their integration docs. There's no way to pass a transaction date with the pixel, so Bountii must've first played with this back in January. It would've been nice to know how long the Jan 24 forgeries took to clear. The fact that the Oct 24th purchase hadn't become Available by Nov 4th suggests that Bing might now require batch confirmation for all transactions. Or perhaps the merchant used the Merchant Center interface to flag the transaction -- I know in the ecommerce systems I've been involved with, staff review the transaction log for anything unusual.
There is still that Denial of Service problem -- a user claiming all "future" order IDs and preventing legitimate customers from getting their credits. I thought Bing might've simply prevented any given customer from submitting two claims with the same merchant ID & order ID (classic "transaction token"/page reload stuff), but the screenshots of the Merchant Center suggest that Bing isn't dong that (yet).
My favorite part is that on page 20 of the Bing Cashback integration guide they say that the pixel hack is "recommended" for reporting purchases. Recommended!
Second favorite: that Samir at Bountii posted this on his blog without contacting Bing first. He should've followed something like the RFPolicy protocol (http://www.wiretrip.net/rfp/policy.html).
This is fantastic news. Hopefully they can make a decent competitor to Logitech's SqueezeCenter platform (also open source, multiplatform). It's fantastic for streaming across many different platforms, but is a bit clunky to use.
Dream on. SqueezeCenter is server-side Free Software (and client-side free-as-in-beer-but-not-speech software [SqueezePlay]); Roku only has client-side software, and they're only TALKING about releasing a free-as-in-beer SDK. So they're talking about releasing a subset of the sort of client-side free-as-in-beer code that Logitech has had for a while, and none of the free-as-in-speech server code that Logitech has offered for even longer.
And that's before you consider things like stability (Roku boxes crashing every 500 hours?). Kudos to Roku's press office for scoring the misleading/. headline, but ain't nothin' to see here.
That's my read, too. TFA doesn't say anything about even releasing source code, let alone using an OSI-approved open source license. All it promises is an SDK. You know, like the iPhone has.
In fact, one of the articles linked to from an article linked to by TFA suggests that Roku is considering charging for software upgrades that provide HD playback capabilities (http://techpulse360.com/2008/09/24/streaming-media-west-roku-to-open-netflix-player-with-sdk-shifting-to-new-name-soon/). I know that's a "Gratis" issue, not necessarily a "Libre" issue, but still, this doesn't look at all like Open Source.
I never bookmarked it, but there was a piece (on Groklaw, I believe) that highlighted the difference between the SCO/Unix contracts entered into by IBM and Sequent. The gist of the difference is that IBM's contract included language that seemed to clearly, explicitly give them the rights to do what they wanted to with any Unix-related code that IBM created. It does not appear that Sequent license had such language. There seemed to be an implication that Sequent had a fairly standard contract, and IBM's had been altered with regards to rights IBM retained over its "derivative works". Was IBM's language modification a clarification of the intent of the standard contract (as Novell would like to suggest), or an alteration designed to give IBM rights that other Unix licensees did not have (as SCO would suggest)?
It seems important to note that the "derivative works" section can be read as a restriction in rights of use and redistribution -- not, as SCO would actually prefer, as transfering ownership of code. This makes good sense. The GPL allows you to take my source code & modify it however you'd like, as long as it's for your own use. The GPL does not say that I will own any of your derivative code. But it does say that you cannot distribute your derivative works except under the terms of the GPL.
That's all SCO's claiming with its SysV license: that licensees can do what they want with the code, but cannot redistribute their source with some arbitrary license.
The difference between SCO claiming that the "derivative works" clause gives them ownership of derivatives and the IMO reasonable interpretation that the "derivative works" clause prohibits re-distribution (among other possibilities) as GPL'ed code is this: the "ownership" interpretation gives SCO a copyright claim (it's their code!) while the "redistribution" interpretation leaves SCO with a contract law case (they own the code, but they're not allowed to do *that* with it!).
I agree the $ echo citation is really weak, and seems to add nothing to the IBM/Novell argument. (I think your interpretation is actually pretty generous to Sequent: I don't see even $ echo giving Sequent the rights to release its derivatives to other Unix licensees.)
Section 4.16(b), as cited by Novell ("Under Section 4.16(b) of the Asset Purchase Agreement, Novell retains the right at Novell's sole discretion and direction, to require SCO to amend, supplement, modify, or waive any rights under, or...assign any rights to, any SVRX License to the extent so directed in any manner or respect by [Novell]. ") looks much more interesting.
But here's the big question: even if we do assume this section of the APA allows Novell to force SCO to accept changes to a licensee's contract, is it too late to change Sequent's license? Even if we assume that Novell's language ("Novell hereby directs SCO to waive any purported right SCO may claim to require Sequent (or IBM as its successor) to treat Sequent Code as subject to the confidentiality obligations or use restrictions of Sequent's SVRX license") suffices to allow Sequent to contribute its software to the GPL'ed Linux project, might that grant by Novell only apply to future contributions by Sequent?
This seems like a fairly simple contract law issue (as many have pointed out, the cases clearly seem to revolve around contract law) -- let's assume that SCO is correct in maintaining that Sequent's license forbade Sequent from contributing Unix-contaminated code to Linux. Let's assume that SCO is correct in asserting that it suffered damages from Sequent/IBM's contributions to Linux. Even if Sequent is allowed to freely contribute code starting on Feb 11, is SCO not entitled to some "relief" for damages it claims to have suffered before Novell granted such rights to Sequent?
see it, help the pro-DMCA, anti-freedom lobby?
on
Review: Spiderman
·
· Score: 2, Insightful
It's sci-fi/CGI/comic stuff and we're geeks, so we must see it, right? Bah.
Remember that the MPAA only gets licence fee on software, I am not aware of the drive itself being covered by anything more than the same sort of hardware patents that probably also cover...
You "are not aware"? "probably"? Translation: you're guessing. I would be very surprised if 1) even a "bare" drive lacked the DVD logo and 2) some fees were not collected for that logo, regardless of whether the drive included any DVD-CSS software.
I'm with cr0sh here... if you're not sure your money won't go to a prty you don't support, then don't spend it.
...most notably, Red Hat Linux 7.1 and 7.2 (beta) default to setting up a packet filter (albeit a somewhat lame ipchains-based filter even though they could have used iptables/netfilter) at install time. A standard/default RH 7.1 install (even a "full" install) would be in pretty good shape, at least vis-a-vis network attacks. Local/console attacks are another matter, as they are for any system.
A year ago I would have been much more inclined to agree with you... but it's kinda funny. As time goes on, Windows seems to have more network services, and more problems, while Linux distros are becoming more sane and simple, follwoing OpenBSD's lead...
One thing that sucks about my suggestion is the whole Legacy -> Dependant data xfer relies on the user doing some data signing. Wheich means having something like GPG on the user's client machine. Which makes this a bear to roll out with current infrastructures. You'd practically need a browser plugin to make it remotely user-friendly, and then you have the whole key security and "roaming" issue set that I fear many/most users are not prepared for even if the necessary plugins were available.
So here's an alternative way of 1) allowing a user to see/control/verify the facts being revealed by Legacy 2) allowing Dependant to trust that the affidavit signed by Legacy actually applies to the user who clicked "You Know Me"
Dependant gives you a one-time secret code when you tell it you want to share with it some info from Legacy. You
authenticate to Legacy, give it the secret code from
Dependant, tell it what fields Dependant needs (all that may be simply
following a hyperlink from Dependant to Legacy). Legacy then shows
you the facts it has for those fields. With your approval, it signs an
affidavit with the facts and the secret code. You then pass that (clear) signed affidavit to Dependant. Dependant then knows that the
person trying to sign up on Dependant is the one described by the facts
sworn to in the signed affidavit by Legacy. Whew. No client-side crypto
needed. Just keypairs for all the servers that take part in the data
exchange. If the user did have a keypair, then the user could have
(offline) a signed affidavit from Legacy linking the public key to salted
hashes of the various facts. And the user could use the affidavit andtheir keypair to send facts to Dependant without Legacy needing to be
available.
Look, what Dave proposes has a lot of very big problems. Nice idea, but the design needs a lot of work. I could talk about the API, SOAP, etc., and that stuff looks pretty goofy to me (I love methods with a fixed set of arguments: earth to Dave, if you're using XML, you should pass around XML objects, not individual fields).
But the basic ideas have BIG problems. How does dependant server know that legacy server is giving it info for the actual user, number one. Unless dependant server sees you authenticate to legacy server, it can't verify squat. That's where your signing makes sense. But you're too optmistic to think that the decrypted data can be protected. The legacy server needs to read the cleartext, so they can always give the data away. Anybody who can see the cleartext data can give it away. That's life. But crypto can help dependant site verify the relationship between data and you. How? Legacy site identifies one or more public keys with your info. When you click "You Know Me" on dependant, dependant shows you what data it wants. If that's OK with you, your client/browser signs a request for those fields. Your client authenticates to Legacy, presents the request. Legacy verifies that the public key used to sign the request is authorized to see the fields. Legacy signs an affidavit including the fields you requested and your public key (or some other identifier!). Legacy gives that affidavit to your client. Your client verifies that only the requested fields are present. You can check the signature, and verify the data's veracity. Your client signs the affidavit and returns it to Dependant. So Dependant knows that Legacy and you agree the info is correct.
Dependant subscribing to data from Legacy? That's a tricky one. What if Legacy decides that you've changed gender? Of course there's absolutely nothing preventing Legacy from giving *all* your data to Dependant if it wants to. But I think the whole notion of subscriptions is bothersome. Better to have Dependant site tell your client it wants to be updated when facts change. Your client (running in the background) can prompt you for your passphrase when it needs to obtain new signed fact affidavits for sites like Dependant that need/want to be kept up-to-date.
So how do you keep Dependant from stealing unauthorized fields? More crypto, plus auditing.:-( Dependant keeps an Authorization Form that you sign, showing what fields/facts Dependant can collect. A third party auditing firm can check Dependant's database and verify that every non-NULL field for every user was explicitly authorized form that user. If you can trust the third-party audit, you're in good shape. Well, better shape. (Or, if the updating is done by your client, then Dependant could simply keep all the signed affidavits you sent it.)
Simple one-way hashes can also be used to enable user-kept facts. Using hashes, a person can not only better control what facts Dependant sees, but can do so without any connection back to Legacy. So, yes, you'd have the ability to share data even when the network is down. Try doing that with Passort.
For more on user-stored, signed facts protected with one-way hashes, see http://www.tux.org/~peterw/anon.txt
TOS A recent thread on a local sysadmin mailing list has talked about not only Tems of Service, but what's actually implemented. One local DSL provider is accused of blocking outbound TCP port 25. No SMTP from your box, except to theior official mail relay. Is that in the Terms of Service? Allegedly not. Bottom line: some ISPs are committed to full/open access, while othetr have TOS or de facto policies that limit you. Good providers? In the US, Speakeasy for DSL is very highly regarded.
fearmongering 56k can be better? Pure fearmongering. Ask them for statistics, actual measured instances of this slowness. Then push them on their data gathering methodology. It's bunk.
latency Any half-decent broadband, in addition to higher (downstream) speeds, will give you much better first-hop latency, which can make a big difference for some activities/applications. POTS+modems suck.
contingency plans What does the provider do if the broadband circuit is down? My cable provider used to provide dialup PPP access for when the cable plant was screwed up (not that the cable connection has given much trouble at all). Now they apparently don't. And with the "free" ISPs kaput, even rebooting into Windows, I don't have any network access if the cable plant chokes. That sucks.
To all the folks claiming SETI@home is safe: how
many of you have thoroughly audited its source code? The rest of you can drop that claim. Adding any software to a system represents a security risk. Give TVA some credit for showing their employees some respect and not locking down the workstations so that management is a headache. Obviously TVA has a policy against installing unapproved software, and these folks broke that rule. They're at work, so they should follow the rules. [Sidenote: if TVA trusts JVMs, then seti@home might be OK as a Web applet.]
Power consumption: TVA is very sensitive to this issue, though it seems some posters do not know this (what a shock!). TVA has many, many employees, and the power they use is not free (has anyone been following the California power crisis press coverage?). Every extra watt that TVA burns because some dufus won't let his screen go to DPMS suspend/off mode is potentially just more nuclear waste to be dealt with.
the more clear it is that Darren is rationalizing any interpretation that amounts to "(Free|Net)BSD good, OpenBSD bad"
Is Theo a jerk? I don't know, and I don't care. Local BSD/ipfilter advocates like to joke about the Linux kernel-of-the-month club, in reference to how rapidly and radically the Linux kernel changes. Hell, ipfilter is now in its own license-interpretation-of-the-week club.
Here's wishing the best to folks woking on OpenIPF. The BSD folks deserve a good, Free packet filtering package.
All that discussion of Red Carpet, and nothing about using SSL or PK signatures to ensure no rogue apps are installed. Naturally, they haven't started to sign the packages they provide. And the main site still recommends the extra-dangerous 'Lynx hack' to install HelixCode.
According to Miguel, "you could say that Evolution is targeted to replace Outlook". Do you think they mean in terms of introducing new security holes, too?:-( It sure looks that way. Helix Code, like Microsoft, seems quite adept at crafting eye candy, but I'm not sure security is even an afterthought.
Seriously, though. VMWare is a combination of user level programs and kernel modules. The user level program isn't so interesting, but any bugs in the kernel modules could be devastating. It seems that Plex86 requires at least one special kernel module to be loaded in the host system. Which means stability is a real concern. Laugh when Windows 95 crashes inside the user level Plex86 GUI, but if the plex86.o module crashes your host system, you won't laugh.
I do not in any way mean to suggest that Plex86 is not stable -- I really have no idea, and Kevin has a great reputation. But stability does matter for things like VMWare and Plex86, even if they're being used to host lesser OSes.
From a security perspective, having the source for kernel modules seems a very good thing, and this is an advantage for Plex86 over VMWare.
And the timing for the recent successes (booting Linux, running the full Win95 GUI) couldn't be better, as VMWare is apparently about to discontinue its non-commercial/hobbyist license. If the rumors of VMWare leaching off Kevin to get their start are true, then I won't shed any tears for sales they lose to Plex86.
The principle of tying a license agreement to a piece of hardware. If DC can set a precedent for doing this, then it becomes easier for other hardware vendors to restrict the use of their products. If licenses can be tied to hardware you pay for, then we're really in trouble ("by using this Zip disk, you agree to be bound by...").
What is hardware? Almost all computer hardware, and many other devices like electric toasters, contain logic chips and software to make the devices work. Combine this fact with something like UCITA, and hardware licensing may become, in the US, a reality. The hardware might not be licensed, but the software required to make it work would be. And device complexity and trade secrets could make it prohibitively difficult to load free software (Free Firmware?).
The CueCat is silly. The only use I can imagine for it is to catalog my books and records for insurance purposes. But the notion of using IP law to restrict what I can legally do with a "thing" is unsettling.
Imagine this future: Microsoft refuses to give video card manufacturers the information needed to develop DirectX drivers unless the card makers agree that all their products will have licenses explicitly prohibiting their use with anything other than Windows. Card makers may like the Linux hardware geek camp, but, faced with this threat, anyone selling "open" video cards would lose their Windows market.
Where can I find information comparing the power consumption of different CPUs? Also interesting would be information about differences between consumption under full utilization and consumption when idle.
Sixty watts... sheesh, maybe we should all be enabling APM on our desktop machines!
From the installer to the login screen, everything is well designed, looks very pretty, is well organized and
just makes sense.
The installer is "well designed" and "makes sense"? The recommended install for Helix Code Gnome involves piping a web fetch to a root shell; a really, really dangerous hack. (See http://www.securityfocus.com/archive/1/79524 for information on exploiting any systems that use NAT or Web proxies: replace "echo" in ERR_GOGNOME with the commands of your choice. Helix Code doesn't sign packages. They don't respond to queries about improving their distribution and installation mechanisms unless publicly humiliated.
The apps and desktop are a nice step forward visually, but Helix Code takes a drag-and-drool approach to security and deserves some heat for that. They're deliberately making the distribution and installation less secure than what's offered by the major RPM-based Linux distributions.
I used to be an advocate of Gnome. But the Helix Code faster-dumber-riskier approach has me reassessing my aversion to KDE. If Miguel, Nat, & co. want to start taking seriously something besides eye candy and PR, that would be great.
Steamroller, cathedral, ivory tower, flytrap, loaded gun: pick your analogy. There are serious problems with Helix Code.
Anticompetitive dumping? No. Not when all their competition is free (Netscape, Real, Quicktime).
Netscape Navigator was not free until the success of the IE dumping/bundling made it impossible for them to sell their product. (Navigator could be used under some circumstances, e.g., by educational institutions, without payment. But use on business machines cost money.) I'm sure the folks at Opera could sell more browsers, too, if MSFT and NSCP weren't giving away their client software.
I've seen a presentation by some Mainsoft folks. The license fees aren't that bad. Basically you need a Mainsoft client runtime license for each desktop you want to run your "ported" applications on (I'm fairly sure that it's a per-seat, not per-app license), and, IIRC, the desktop license was in the range of $50 - $100 USD. Which is the same ballpark as a Windows 9x license, but Mainsoft's target is companies, where WinNT/2000 are the more likely desktop equivalents. So it's much cheaper than VMWare ($300 USD per commercial license + you still need an MS OS license). And, if you're having trouble with Windows, the increased overall stability and other benefits of Linux or Unix may easily justify the per seat fee.
MSFT used Mainsoft's tools to port IE to the flavors of Unix it already runs on, e.g. Solaris. So this isn't really big news. MS has already ported IE. They've talked about porting MediaPlayer. Both are yet more examples of anticompetitive "dumping" practices.
-Peter
US Voters: The GOP has criticized Clinton, Reno, and Klein for taking on Microsoft in court. The Democratic party had iMacs and PalmPilots at their convention. Who's more likely to support real competition in the software marketplace?
The biggest problem I have with your position is the issue of undiscovered security problems. Hopefully the white and grey hats will start picking apart the code after it's released. Grepping for sprintf(), etc. You can't stop that. But if outside hackers find holes while the code is still "beta", you won't get burned anywhere near as badly.
With no
foreknowledge that your software is buggy, crash prone and unready for use, your potential customer will have their first
impression be that of your software dumping the X server or corrupting the file system.
On the other hand, consider releasing a polished product as "beta". Potential customers will be impressed with the quality of your work ("Hey, even their beta code is solid!") A good rule of thumb might be this:
Don't call it beta until it's good enough for you. Don't call it finished until it's good enough for the rest of us.
There are some folks working pretty actively on adding Slackware support, and I think Bastille will have Mandrake 7.x support before too long. The biggest reason Red Hat is "the main target" is becuase that's what most of the developers seem to use, and being a volunteer project, there isn't a big ol' lab where Bastille hackers can play with all the distros (and architectures!) they might like to support. Anyone with a bit of experience and Perl knowledge who wants to help extend Bastille to support other distros would be welcomed!
Last year, my ISP, without any announcement, began using a transparent Web proxy. Most of my outbound traffic to TCP port 80 gets re-routed through machines running some Inktomi transparent HTTP proxy software.
Naturally, my ISP keeps logs for that traffic (Inktomi boasts that its Traffic Server can write many different log formats), in part to deal with abuse.
As you might also expect, the privacy policy does not directly cover these logs. It makes promises about some very specific types of information, but does not make any general statements that obviously pertain to types of information not covered in the enumerated, specific types. Result: I think most lawyers would say my ISP could sell access to DoubleClick, the FBI, or anyone else.
Checking your system
So are you using a proxy, but don't know it? You can check pretty quickly (though I should warn you, while a positive/proxy result is conclusive, a negative/no-proxy result may be a result of the proxy configuration, as the systems can be set up to bypass the proxy for certain sites, or to only use the proxy for certain sites, etc.).
Step 1: what's your address? Check your current address for whatever network adapter (ethernet card, PPP/dialup device, etc.). In Unix or Linux, something like '/sbin/ifconfig eth0' will do; in Windows 9x, run 'winipcfg'; in Windows NT, 'ipconfig'.
Step 2: what address do web sites see? Go to a URL that will show you the environment variables passed to CGI scripts, like http://www.cgihost.com/cgi-bin/env.cgi or http://www.ualberta.ca/htbin/dumpenv.pl . Look at REMOTE_ADDR. Reload several times. Does it change? You might see some other proxy-specific variables like HTTP_CLIENT_IP and HTTP_VIA, depending on the proxy server's configuration.
Step 3: interpreting the results If you ever see a REMOTE_ADDR value in Step 2 that doesn't match the local address from Step 1, yet you don't have a Manual or Automatic proxy configured in your browser, then congratulations, you're behind a transparent proxy, and should assume that all your Web traffic is being logged.
http:// vs https:// For regular HTTP, there's a lot they can conceivably record. The URL. Your cookies. Where you came from. Etc. For https:// it's a bit better. All they can do is record where you connected to, and when. Even this information might be deemed valuable, e.g., someone frequently connecting to many banking sites probably isn't eligible for low income tax credits. https:// is somewhat like encrypting your email: they can't tell what you're doing, but they can tell who you're contacting.
I've complained via email a few times, and received a couple polite emails from the technical staff. But nothing has changed in the official policy, so my ISP is still free to share my complete Web usage history with whomever they wish. Highest bidder? Most pushy government agency? I can't say.
The offsite cookies that are sneaked in via style sheets and other JavaScript nasties are not supposed to be accepted. This is a bit better in Mozilla, but not completely fixed, unfortunately.
Slashdot Mirror
Exactly. And I wonder if they've done that already, and simply not updated their integration docs. There's no way to pass a transaction date with the pixel, so Bountii must've first played with this back in January. It would've been nice to know how long the Jan 24 forgeries took to clear. The fact that the Oct 24th purchase hadn't become Available by Nov 4th suggests that Bing might now require batch confirmation for all transactions. Or perhaps the merchant used the Merchant Center interface to flag the transaction -- I know in the ecommerce systems I've been involved with, staff review the transaction log for anything unusual.
There is still that Denial of Service problem -- a user claiming all "future" order IDs and preventing legitimate customers from getting their credits. I thought Bing might've simply prevented any given customer from submitting two claims with the same merchant ID & order ID (classic "transaction token"/page reload stuff), but the screenshots of the Merchant Center suggest that Bing isn't dong that (yet).
My favorite part is that on page 20 of the Bing Cashback integration guide they say that the pixel hack is "recommended" for reporting purchases. Recommended!
Second favorite: that Samir at Bountii posted this on his blog without contacting Bing first. He should've followed something like the RFPolicy protocol (http://www.wiretrip.net/rfp/policy.html).
This is fantastic news. Hopefully they can make a decent competitor to Logitech's SqueezeCenter platform (also open source, multiplatform). It's fantastic for streaming across many different platforms, but is a bit clunky to use.
Dream on. SqueezeCenter is server-side Free Software (and client-side free-as-in-beer-but-not-speech software [SqueezePlay]); Roku only has client-side software, and they're only TALKING about releasing a free-as-in-beer SDK. So they're talking about releasing a subset of the sort of client-side free-as-in-beer code that Logitech has had for a while, and none of the free-as-in-speech server code that Logitech has offered for even longer.
And that's before you consider things like stability (Roku boxes crashing every 500 hours?). Kudos to Roku's press office for scoring the misleading /. headline, but ain't nothin' to see here.
That's my read, too. TFA doesn't say anything about even releasing source code, let alone using an OSI-approved open source license. All it promises is an SDK. You know, like the iPhone has.
In fact, one of the articles linked to from an article linked to by TFA suggests that Roku is considering charging for software upgrades that provide HD playback capabilities (http://techpulse360.com/2008/09/24/streaming-media-west-roku-to-open-netflix-player-with-sdk-shifting-to-new-name-soon/). I know that's a "Gratis" issue, not necessarily a "Libre" issue, but still, this doesn't look at all like Open Source.
It seems important to note that the "derivative works" section can be read as a restriction in rights of use and redistribution -- not, as SCO would actually prefer, as transfering ownership of code. This makes good sense. The GPL allows you to take my source code & modify it however you'd like, as long as it's for your own use. The GPL does not say that I will own any of your derivative code. But it does say that you cannot distribute your derivative works except under the terms of the GPL.
That's all SCO's claiming with its SysV license: that licensees can do what they want with the code, but cannot redistribute their source with some arbitrary license.
The difference between SCO claiming that the "derivative works" clause gives them ownership of derivatives and the IMO reasonable interpretation that the "derivative works" clause prohibits re-distribution (among other possibilities) as GPL'ed code is this: the "ownership" interpretation gives SCO a copyright claim (it's their code!) while the "redistribution" interpretation leaves SCO with a contract law case (they own the code, but they're not allowed to do *that* with it!).
Section 4.16(b), as cited by Novell ("Under Section 4.16(b) of the Asset Purchase Agreement, Novell retains the right at Novell's sole discretion and direction, to require SCO to amend, supplement, modify, or waive any rights under, or...assign any rights to, any SVRX License to the extent so directed in any manner or respect by [Novell]. ") looks much more interesting.
But here's the big question: even if we do assume this section of the APA allows Novell to force SCO to accept changes to a licensee's contract, is it too late to change Sequent's license? Even if we assume that Novell's language ("Novell hereby directs SCO to waive any purported right SCO may claim to require Sequent (or IBM as its successor) to treat Sequent Code as subject to the confidentiality obligations or use restrictions of Sequent's SVRX license") suffices to allow Sequent to contribute its software to the GPL'ed Linux project, might that grant by Novell only apply to future contributions by Sequent?
This seems like a fairly simple contract law issue (as many have pointed out, the cases clearly seem to revolve around contract law) -- let's assume that SCO is correct in maintaining that Sequent's license forbade Sequent from contributing Unix-contaminated code to Linux. Let's assume that SCO is correct in asserting that it suffered damages from Sequent/IBM's contributions to Linux. Even if Sequent is allowed to freely contribute code starting on Feb 11, is SCO not entitled to some "relief" for damages it claims to have suffered before Novell granted such rights to Sequent?
It's a Sony Pictures movie. Sony's a member of the MPAA, who love the DMCA. Sony Pictures has been cited as a supporter of Fritz Holling's Security Systems Standards and Certification Act (SSSCA) bill. We're talking about the kind of folks that hire lawyers to sue teenage hackers for writing unauthorized DVD playback software for GNU/Linux systems. Sure, it might be a great movie, but at least stop a minute to think where your money's going, what it will be used for down the road.
Anybody who says one vote doesn't matter must've missed the last US elections.
You "are not aware"? "probably"? Translation: you're guessing. I would be very surprised if 1) even a "bare" drive lacked the DVD logo and 2) some fees were not collected for that logo, regardless of whether the drive included any DVD-CSS software.
I'm with cr0sh here... if you're not sure your money won't go to a prty you don't support, then don't spend it.
A year ago I would have been much more inclined to agree with you... but it's kinda funny. As time goes on, Windows seems to have more network services, and more problems, while Linux distros are becoming more sane and simple, follwoing OpenBSD's lead...
So here's an alternative way of 1) allowing a user to see/control/verify the facts being revealed by Legacy 2) allowing Dependant to trust that the affidavit signed by Legacy actually applies to the user who clicked "You Know Me"
Dependant gives you a one-time secret code when you tell it you want to share with it some info from Legacy. You authenticate to Legacy, give it the secret code from Dependant, tell it what fields Dependant needs (all that may be simply following a hyperlink from Dependant to Legacy). Legacy then shows you the facts it has for those fields. With your approval, it signs an affidavit with the facts and the secret code. You then pass that (clear) signed affidavit to Dependant. Dependant then knows that the person trying to sign up on Dependant is the one described by the facts sworn to in the signed affidavit by Legacy. Whew. No client-side crypto needed. Just keypairs for all the servers that take part in the data exchange. If the user did have a keypair, then the user could have (offline) a signed affidavit from Legacy linking the public key to salted hashes of the various facts. And the user could use the affidavit andtheir keypair to send facts to Dependant without Legacy needing to be available.
But the basic ideas have BIG problems. How does dependant server know that legacy server is giving it info for the actual user, number one. Unless dependant server sees you authenticate to legacy server, it can't verify squat. That's where your signing makes sense. But you're too optmistic to think that the decrypted data can be protected. The legacy server needs to read the cleartext, so they can always give the data away. Anybody who can see the cleartext data can give it away. That's life. But crypto can help dependant site verify the relationship between data and you. How? Legacy site identifies one or more public keys with your info. When you click "You Know Me" on dependant, dependant shows you what data it wants. If that's OK with you, your client/browser signs a request for those fields. Your client authenticates to Legacy, presents the request. Legacy verifies that the public key used to sign the request is authorized to see the fields. Legacy signs an affidavit including the fields you requested and your public key (or some other identifier!). Legacy gives that affidavit to your client. Your client verifies that only the requested fields are present. You can check the signature, and verify the data's veracity. Your client signs the affidavit and returns it to Dependant. So Dependant knows that Legacy and you agree the info is correct.
Dependant subscribing to data from Legacy? That's a tricky one. What if Legacy decides that you've changed gender? Of course there's absolutely nothing preventing Legacy from giving *all* your data to Dependant if it wants to. But I think the whole notion of subscriptions is bothersome. Better to have Dependant site tell your client it wants to be updated when facts change. Your client (running in the background) can prompt you for your passphrase when it needs to obtain new signed fact affidavits for sites like Dependant that need/want to be kept up-to-date.
So how do you keep Dependant from stealing unauthorized fields? More crypto, plus auditing. :-( Dependant keeps an Authorization Form that you sign, showing what fields/facts Dependant can collect. A third party auditing firm can check Dependant's database and verify that every non-NULL field for every user was explicitly authorized form that user. If you can trust the third-party audit, you're in good shape. Well, better shape. (Or, if the updating is done by your client, then Dependant could simply keep all the signed affidavits you sent it.)
Simple one-way hashes can also be used to enable user-kept facts. Using hashes, a person can not only better control what facts Dependant sees, but can do so without any connection back to Legacy. So, yes, you'd have the ability to share data even when the network is down. Try doing that with Passort.
For more on user-stored, signed facts protected with one-way hashes, see http://www.tux.org/~peterw/anon.txt
A recent thread on a local sysadmin mailing list has talked about not only Tems of Service, but what's actually implemented. One local DSL provider is accused of blocking outbound TCP port 25. No SMTP from your box, except to theior official mail relay. Is that in the Terms of Service? Allegedly not. Bottom line: some ISPs are committed to full/open access, while othetr have TOS or de facto policies that limit you. Good providers? In the US, Speakeasy for DSL is very highly regarded.
56k can be better? Pure fearmongering. Ask them for statistics, actual measured instances of this slowness. Then push them on their data gathering methodology. It's bunk.
Any half-decent broadband, in addition to higher (downstream) speeds, will give you much better first-hop latency, which can make a big difference for some activities/applications. POTS+modems suck.
What does the provider do if the broadband circuit is down? My cable provider used to provide dialup PPP access for when the cable plant was screwed up (not that the cable connection has given much trouble at all). Now they apparently don't. And with the "free" ISPs kaput, even rebooting into Windows, I don't have any network access if the cable plant chokes. That sucks.
Power consumption: TVA is very sensitive to this issue, though it seems some posters do not know this (what a shock!). TVA has many, many employees, and the power they use is not free (has anyone been following the California power crisis press coverage?). Every extra watt that TVA burns because some dufus won't let his screen go to DPMS suspend/off mode is potentially just more nuclear waste to be dealt with.
- the less clear ipfilter's license is
- the more clear it is that Darren is rationalizing any interpretation that amounts to "(Free|Net)BSD good, OpenBSD bad"
Is Theo a jerk? I don't know, and I don't care. Local BSD/ipfilter advocates like to joke about the Linux kernel-of-the-month club, in reference to how rapidly and radically the Linux kernel changes. Hell, ipfilter is now in its own license-interpretation-of-the-week club.Here's wishing the best to folks woking on OpenIPF. The BSD folks deserve a good, Free packet filtering package.
According to Miguel, "you could say that Evolution is targeted to replace Outlook". Do you think they mean in terms of introducing new security holes, too? :-( It sure looks that way. Helix Code, like Microsoft, seems quite adept at crafting eye candy, but I'm not sure security is even an afterthought.
You're right, there is source for the vmmon, vmnet, and vmppuser modules. Audit, anyone?
Seriously, though. VMWare is a combination of user level programs and kernel modules. The user level program isn't so interesting, but any bugs in the kernel modules could be devastating. It seems that Plex86 requires at least one special kernel module to be loaded in the host system. Which means stability is a real concern. Laugh when Windows 95 crashes inside the user level Plex86 GUI, but if the plex86.o module crashes your host system, you won't laugh.
I do not in any way mean to suggest that Plex86 is not stable -- I really have no idea, and Kevin has a great reputation. But stability does matter for things like VMWare and Plex86, even if they're being used to host lesser OSes.
From a security perspective, having the source for kernel modules seems a very good thing, and this is an advantage for Plex86 over VMWare.
And the timing for the recent successes (booting Linux, running the full Win95 GUI) couldn't be better, as VMWare is apparently about to discontinue its non-commercial/hobbyist license. If the rumors of VMWare leaching off Kevin to get their start are true, then I won't shed any tears for sales they lose to Plex86.
Thanks, Kevin, and MandrakeSoft!
But the principle is.
The principle of tying a license agreement to a piece of hardware. If DC can set a precedent for doing this, then it becomes easier for other hardware vendors to restrict the use of their products. If licenses can be tied to hardware you pay for, then we're really in trouble ("by using this Zip disk, you agree to be bound by...").
What is hardware?
Almost all computer hardware, and many other devices like electric toasters, contain logic chips and software to make the devices work. Combine this fact with something like UCITA, and hardware licensing may become, in the US, a reality. The hardware might not be licensed, but the software required to make it work would be. And device complexity and trade secrets could make it prohibitively difficult to load free software (Free Firmware?).
The CueCat is silly. The only use I can imagine for it is to catalog my books and records for insurance purposes. But the notion of using IP law to restrict what I can legally do with a "thing" is unsettling.
Imagine this future: Microsoft refuses to give video card manufacturers the information needed to develop DirectX drivers unless the card makers agree that all their products will have licenses explicitly prohibiting their use with anything other than Windows. Card makers may like the Linux hardware geek camp, but, faced with this threat, anyone selling "open" video cards would lose their Windows market.
Sixty watts... sheesh, maybe we should all be enabling APM on our desktop machines!
The apps and desktop are a nice step forward visually, but Helix Code takes a drag-and-drool approach to security and deserves some heat for that. They're deliberately making the distribution and installation less secure than what's offered by the major RPM-based Linux distributions.
I used to be an advocate of Gnome. But the Helix Code faster-dumber-riskier approach has me reassessing my aversion to KDE. If Miguel, Nat, & co. want to start taking seriously something besides eye candy and PR, that would be great.
Steamroller, cathedral, ivory tower, flytrap, loaded gun: pick your analogy. There are serious problems with Helix Code.
-Peter
-Peter
MSFT used Mainsoft's tools to port IE to the flavors of Unix it already runs on, e.g. Solaris. So this isn't really big news. MS has already ported IE. They've talked about porting MediaPlayer. Both are yet more examples of anticompetitive "dumping" practices.
-Peter
US Voters: The GOP has criticized Clinton, Reno, and Klein for taking on Microsoft in court. The Democratic party had iMacs and PalmPilots at their convention. Who's more likely to support real competition in the software marketplace?
On the other hand, consider releasing a polished product as "beta". Potential customers will be impressed with the quality of your work ("Hey, even their beta code is solid!") A good rule of thumb might be this:
Don't call it beta until it's good enough for you. Don't call it finished until it's good enough for the rest of us.
There are some folks working pretty actively on adding Slackware support, and I think Bastille will have Mandrake 7.x support before too long. The biggest reason Red Hat is "the main target" is becuase that's what most of the developers seem to use, and being a volunteer project, there isn't a big ol' lab where Bastille hackers can play with all the distros (and architectures!) they might like to support. Anyone with a bit of experience and Perl knowledge who wants to help extend Bastille to support other distros would be welcomed!
Naturally, my ISP keeps logs for that traffic (Inktomi boasts that its Traffic Server can write many different log formats), in part to deal with abuse.
As you might also expect, the privacy policy does not directly cover these logs. It makes promises about some very specific types of information, but does not make any general statements that obviously pertain to types of information not covered in the enumerated, specific types. Result: I think most lawyers would say my ISP could sell access to DoubleClick, the FBI, or anyone else.
Checking your system
So are you using a proxy, but don't know it? You can check pretty quickly (though I should warn you, while a positive/proxy result is conclusive, a negative/no-proxy result may be a result of the proxy configuration, as the systems can be set up to bypass the proxy for certain sites, or to only use the proxy for certain sites, etc.).
Step 1: what's your address?
Check your current address for whatever network adapter (ethernet card, PPP/dialup device, etc.). In Unix or Linux, something like '/sbin/ifconfig eth0' will do; in Windows 9x, run 'winipcfg'; in Windows NT, 'ipconfig'.
Step 2: what address do web sites see?
Go to a URL that will show you the environment variables passed to CGI scripts, like http://www.cgihost.com/cgi-bin/env.cgi or http://www.ualberta.ca/htbin/dumpenv.pl . Look at REMOTE_ADDR. Reload several times. Does it change? You might see some other proxy-specific variables like HTTP_CLIENT_IP and HTTP_VIA, depending on the proxy server's configuration.
Step 3: interpreting the results
If you ever see a REMOTE_ADDR value in Step 2 that doesn't match the local address from Step 1, yet you don't have a Manual or Automatic proxy configured in your browser, then congratulations, you're behind a transparent proxy, and should assume that all your Web traffic is being logged.
http:// vs https:// For regular HTTP, there's a lot they can conceivably record. The URL. Your cookies. Where you came from. Etc. For https:// it's a bit better. All they can do is record where you connected to, and when. Even this information might be deemed valuable, e.g., someone frequently connecting to many banking sites probably isn't eligible for low income tax credits. https:// is somewhat like encrypting your email: they can't tell what you're doing, but they can tell who you're contacting.
I've complained via email a few times, and received a couple polite emails from the technical staff. But nothing has changed in the official policy, so my ISP is still free to share my complete Web usage history with whomever they wish. Highest bidder? Most pushy government agency? I can't say.
-Peter
See http://bugzilla.mozilla.org/show_b ug.cgi?id=9594
Yeah, that's right. These folks are marketing an add-on for IE to give it something Netscape has (tried to) offer for years.
-Peter