Ya, I really wish they get rid of their multiple editions.
Like academic licenses (and discounted versions for less-developed countries), multiple editions are a tool for market segmentation to assure that they get the most money possible out of each segment of the market. Microsoft isn't giving that up. Its been increasing with each subsequent version of Windows, and I'd expect that Windows 7 will have more editions than Vista-era Windows (Vista + Server 2008).
I mean, pre-XP you had 3: Consumer windows [95/98/ME], Workstation (NT/2000), and Server (NT/2000), with XP-era windows you had 5: XP Home, XP Pro, XP Media Center, XP Tablet PC Edition and Server 2003, and with Vista-era windows you've got 6: the 5 Vista-branded editions + Server 2008.
That said, exit polls have been wildly inaccurate in the past two national elections and in some of the primaries this year.
Its interesting how exit polling is so well-developed that significant divergence in actual results from exit polling is evidence of election fraud when discovered in monitored elections, but when it happens in US elections, it is assumed that there is something wrong with the polling, not the election itself.
I haven't delved deep into the workings of either... but is the Azure/Microsoft lockin any different than lockin would be in writing apps for Google's App Engine?
Given that Google's AppEngine has an open source implementation released by Google, which is already being used to do third-party hosting of AppEngine apps on Amazon EC2, yes, I'd imagine that Microsoft Azure lock-in will be significantly different.
I don't see Microsoft releasing an open-source implementation of Azure.
You're right, the cloud APIs presented so far are a total lock-in.
Google and AppJet have both released standalone hosting code (Google's open source development SDK, which others have forked to use for hosting on EC2; AppJet's "appjet.jar", which isn't an open source project yet, though they've announced that they are looking at that.) So I think "total lock-in" is an unfair description of the current cloud APIs.
Yes, and Hadoop is a reimplementation of Big Table. That's the whole point: just because a reimplementation exists, doesn't make the original project open source.
OTOH, the fact that the App Engine SDK, which is an implementation of the App Engine system designed principally to be used by developers to build and test their apps before deploying them to Google's servers, has been released by Google under the Apache License 2.0, which is an open source license, does mean that it is open source.
And the fact that third parties are providing of hosting of App Engine apps outside of Google's servers using (derivatives of) the open source code provided by Google is a pretty big strike against the idea that App Engine features "vendor lock-in".
OTOH, until someone has a similarly scalable implementation of the storage API running a non-Google cloud system, there will be valid practical concerns about lock-in, even if in theory apps can be hosted elsewhere. But I'd be very surprised if someone didn't provide one in the next couple of years based on some other existing distributed db technology (SimpleDB, Hadoop, Mnesia, etc.)
AppDrop is that particular Ruby on Rails application you're looking at on the site, not Google App Engine itself. That whole thing is probably barely even half a meg of source code. It's just a way to upload files to App Engine and has nothing to do with the App Engine platform code itself.
Not, its not a way to upload files to App Engine. It is a service that allows you to run App Engine apps using a modified version of Google's own App Engine SDK (which, itself, is an open source implementation of App Engine from Google with a different storage engine replacing BigTable but using the same storage API used on the regular App Engine server, so that you can develop "off line" before uploading to Google) running on Amazon EC2.
What does that mean? How can something by reimplemented as open source without being released as open source?
I dunno, GGP was pretty odd there. But there is an implementation of App Engine released as open source by Google, the App Engine SDK, which is released under the Apache License 2.0. Appdrop.com is using a modified version of this running on EC2.
That kind of lock-in will leave customers in the lurch, subject to their vendors' bottom lines, as ISVs that can't afford to rework code to keep up with Microsoft's latest platform will begin dropping services, and customers will have little choice but to accept the new terms of service their vendors send along.
If, in fact, this were to occur, it would kill Azure as no one would purchase new services hosted on Azure, and ISVs would abandon the platform since they wouldn't be able to sell anything on it. That's why Microsoft's always been fairly devoted to backward compatibility: there main selling points in many key areas is compatibility with software, documents, etc., designed for earlier versions of their dominant products. Azure will, no doubt, work the same way.
Microsoft is hardly going to abandon the strategy that has enabled them to maintain and expand their dominance.
Yeah, because everyone knows that when one person in a company is handling sensitive info, it always stays with that person and that person alone.
If, as was stated to be the case here, the reason data is "sensitive data" is because it is "sensitive patient info" (i.e., HIPAA PHI), the same legal requirement that produces the obligation to safeguard the data with technical means also produces an obligation to prevent any access by anyone who doesn't have a specific need to have direct access to the patient data (and, at that, the specific bits of sensitive data they have contact with.) So, if only a certain definable subset of the organization has any business need to access sensitive patient data (which has been clearly stated to tbe the case here), the organization has a positive legal obligation to assure that only that subset of the organization ever has contact with that data.
It's not 03:00 everywhere on the planet nor is it sunday either.
Its quite likely that, even if your server is serving the public over the internet (which is certainly not the case for all servers), the userbase isn't spread uniformly across all available timezones.
That is also perfect in theory. In practice, the browser will warn the user of a self-signed or mismatching certificate - and the user will ignore the warning.
But--and here's the key point--this doesn't have the problem at issue, that is, even by doing this the malicious website can't steal the clients "universal login", because it never gets access, even with a fraudulent server certificate that the user chooses to accept, to the client certs private key.
Sure, any login is vulnerable to false flags if the user chooses to ignore the signs (which are pretty prominent with most modern browsers and bad SSL certs), but that's different than the asserted problem was that all shared authentication systems are vulnerable to having one malicious website that uses the shared login present a false flag that allows it to steal the client's shared login information and then reuse it to access other sites using the shared login. If your shared authentication method is using SSL with client certificates to authenticate client identity, this vulnerability doesn't exist, since the server, even by presenting a false flag, does not gain information which would allow it to pose as the client to other servers using the same authentication system.
Google should have proposed their idea to the OpenID developer community, and not pull this crap.
Do you propose the extension first, or demonstrate the benefits of it in an implementation first? It seems to be a perennial argument. Both approaches have their advantages.
The fact that Google is a (the?) major player in the web space makes this a very bad thing. Instead of a open specification that everybody agreed on, we now have one corporation doing their own thing and using their size to steamroll their changes onto OpenID.
There's lots of providers doing it the other way, and providers are useless without RPs. Google as an RP (Blogger) follows the standard. If you can support the standard in an RP implementation, its trivial to extend it to work with the Google mechanism, and Google's provided everything anyone would need to implement it--on either end--and doing so won't interfere with their ability to interact with standard providers. So Google doing this doesn't hurt anyone using standard OpenID--either as a provider or an RP--except insofar as Google becomes a popular provider and any successful provider, standard or otherwise, reduces the need for other providers.
I cannot overemphasis the need to actually read the articles: Google is not supporting OpenID 1.0, they are supporting OpenID 2.0.
Except that the Google method differs from OpenID 2.0: the user supplied identifier is not an XRI, HTTP, or HTTPS URL. While Google's method is mostly OpenID 2.0, but the Initiation, Normalization, and Discovery process (7.1 - 7.3 of OpenID Authentication 2.0) is modified.
Your entire argument is posited around Google making a more usable version of OpenID. While it may be easier for gmail users in that they can use their email addresses instead of url's, Google has not provided any spec for how other sites can implement the black box they've thrown in front of a completely vanilla OpenID.
That's not true.
They've provide a spec on its (fairly trivial) interaction (since developers couldn't use it otherwise), and they've provided recommendations and rationale on implementation approaches and UI design to support this approach (includign recommendations which presuppose other IDPs will also be using this design.) Other than actually providing a reference implementation of the black box (which is fairly simple: you send it an HTTP GET request and it responds with an XRDS document whose only interesting bit (and the only thing whose content isn't fixed) is the OpenID provider endpoint to URL to use -- if you can't implement a version of that for your own OpenID provider, you probably don't have any business implementing any kind of web application, OpenID provider or otherwise.
Do they really have a reason for doing this? Like making the login easier for normal nontechnical people rather than you and I?
In this regard, its worth noting that Google has posted a bit of "public documentation" regarding its usability research in this area (see their Usability Research on Federated Login, for starters.)
If your e-mail address is your screen name then everybody who knows your screen name also knows your e-mail address.
There's no reason your login name needs to be your screen name. Given that one is for identifying you to a system and the other is for identifying you to people, there are good reasons for them to be different, even if it might usually be desirable for their to be a 1:1 mapping on any given site.
That's not true at all. Torts and breaches of contract are "against the law" without being criminal. As are all kinds of action by the federal government which exceed its Constitutional authority. If it is criminal, it is against the law, but the converse is not true.
perhaps one of the greatest benefits of IT is the possibility of establishing a direct democracy on a national scale through online referendums.
The problem with direct democracy in a modern large society is not simply one of communication, it is also that the number of issues is too large for people who aren't devoted to it full-time to consider well, without being manipulated by those who are devoted to policy issues full-time. Online referenda address some of the communication issue (that is, getting people to the same, at least virtual, "place" so that communication can occur), but not all of the communications issues, and not the deliberation issue.
OTOH, virtual sessions of representative bodies could allow representatives to remain closer to their constituencies while still remaining engaged in political debates, and IT could offer a lot in terms of enhancing transparency.
gone are the days when logistical obstacles prevented the public from directly participating in the legislative process.
Really? When was the last time you were in a chat room with 100 million participants?
In what ways does the OpenID system promote user anonymity?
It promotes anonymity by allowing services to operate that require associating the initiator of one action with the initiator of a prior action, without requiring the "meatspace" identity of either. That is, it provides a reasonable means for a subscription-based service to verify "the person accessing this resource is the one that established this account" without ever identifying who the person is that established the account.
Since many services rely on providing that kind of relation between the person establishing an account a person requesting a resource, it promotes anonymity to provide a means that allows those services to fill that need while users remain anonymous.
Is it a sensible move for a venture capital firm that depends on a healthy Open Source community to lock it out?
Of course, the question presumes the answer. If, in fact, the VC firm depends on a healthy Open Source community, it shouldn't lock it out. The real question is does the VC firm (or, as I think would more accurately state the case here, the VC-funded firm) actually rely on that, or is it viable for them to operate without it?
The judge is part of the Judiciary, that slowly made litigation a very expensive option
Really, its the legislature (both by writing the laws that frame litigation, and by not funding the judiciary so as to make litigation more time consuming than it would otherwise be, further increasing the cost) that has made litigation a very expensive option.
Slashdot Mirror
Like academic licenses (and discounted versions for less-developed countries), multiple editions are a tool for market segmentation to assure that they get the most money possible out of each segment of the market. Microsoft isn't giving that up. Its been increasing with each subsequent version of Windows, and I'd expect that Windows 7 will have more editions than Vista-era Windows (Vista + Server 2008).
I mean, pre-XP you had 3: Consumer windows [95/98/ME], Workstation (NT/2000), and Server (NT/2000), with XP-era windows you had 5: XP Home, XP Pro, XP Media Center, XP Tablet PC Edition and Server 2003, and with Vista-era windows you've got 6: the 5 Vista-branded editions + Server 2008.
Its interesting how exit polling is so well-developed that significant divergence in actual results from exit polling is evidence of election fraud when discovered in monitored elections, but when it happens in US elections, it is assumed that there is something wrong with the polling, not the election itself.
Given that Google's AppEngine has an open source implementation released by Google, which is already being used to do third-party hosting of AppEngine apps on Amazon EC2, yes, I'd imagine that Microsoft Azure lock-in will be significantly different.
I don't see Microsoft releasing an open-source implementation of Azure.
Google and AppJet have both released standalone hosting code (Google's open source development SDK, which others have forked to use for hosting on EC2; AppJet's "appjet.jar", which isn't an open source project yet, though they've announced that they are looking at that.) So I think "total lock-in" is an unfair description of the current cloud APIs.
OTOH, the fact that the App Engine SDK, which is an implementation of the App Engine system designed principally to be used by developers to build and test their apps before deploying them to Google's servers, has been released by Google under the Apache License 2.0, which is an open source license, does mean that it is open source.
And the fact that third parties are providing of hosting of App Engine apps outside of Google's servers using (derivatives of) the open source code provided by Google is a pretty big strike against the idea that App Engine features "vendor lock-in".
OTOH, until someone has a similarly scalable implementation of the storage API running a non-Google cloud system, there will be valid practical concerns about lock-in, even if in theory apps can be hosted elsewhere. But I'd be very surprised if someone didn't provide one in the next couple of years based on some other existing distributed db technology (SimpleDB, Hadoop, Mnesia, etc.)
Not, its not a way to upload files to App Engine. It is a service that allows you to run App Engine apps using a modified version of Google's own App Engine SDK (which, itself, is an open source implementation of App Engine from Google with a different storage engine replacing BigTable but using the same storage API used on the regular App Engine server, so that you can develop "off line" before uploading to Google) running on Amazon EC2.
I dunno, GGP was pretty odd there. But there is an implementation of App Engine released as open source by Google, the App Engine SDK, which is released under the Apache License 2.0. Appdrop.com is using a modified version of this running on EC2.
If, in fact, this were to occur, it would kill Azure as no one would purchase new services hosted on Azure, and ISVs would abandon the platform since they wouldn't be able to sell anything on it. That's why Microsoft's always been fairly devoted to backward compatibility: there main selling points in many key areas is compatibility with software, documents, etc., designed for earlier versions of their dominant products. Azure will, no doubt, work the same way.
Microsoft is hardly going to abandon the strategy that has enabled them to maintain and expand their dominance.
If, as was stated to be the case here, the reason data is "sensitive data" is because it is "sensitive patient info" (i.e., HIPAA PHI), the same legal requirement that produces the obligation to safeguard the data with technical means also produces an obligation to prevent any access by anyone who doesn't have a specific need to have direct access to the patient data (and, at that, the specific bits of sensitive data they have contact with.) So, if only a certain definable subset of the organization has any business need to access sensitive patient data (which has been clearly stated to tbe the case here), the organization has a positive legal obligation to assure that only that subset of the organization ever has contact with that data.
Its quite likely that, even if your server is serving the public over the internet (which is certainly not the case for all servers), the userbase isn't spread uniformly across all available timezones.
But--and here's the key point--this doesn't have the problem at issue, that is, even by doing this the malicious website can't steal the clients "universal login", because it never gets access, even with a fraudulent server certificate that the user chooses to accept, to the client certs private key.
Sure, any login is vulnerable to false flags if the user chooses to ignore the signs (which are pretty prominent with most modern browsers and bad SSL certs), but that's different than the asserted problem was that all shared authentication systems are vulnerable to having one malicious website that uses the shared login present a false flag that allows it to steal the client's shared login information and then reuse it to access other sites using the shared login. If your shared authentication method is using SSL with client certificates to authenticate client identity, this vulnerability doesn't exist, since the server, even by presenting a false flag, does not gain information which would allow it to pose as the client to other servers using the same authentication system.
Do you propose the extension first, or demonstrate the benefits of it in an implementation first? It seems to be a perennial argument. Both approaches have their advantages.
There's lots of providers doing it the other way, and providers are useless without RPs. Google as an RP (Blogger) follows the standard. If you can support the standard in an RP implementation, its trivial to extend it to work with the Google mechanism, and Google's provided everything anyone would need to implement it--on either end--and doing so won't interfere with their ability to interact with standard providers. So Google doing this doesn't hurt anyone using standard OpenID--either as a provider or an RP--except insofar as Google becomes a popular provider and any successful provider, standard or otherwise, reduces the need for other providers.
Except that the Google method differs from OpenID 2.0: the user supplied identifier is not an XRI, HTTP, or HTTPS URL. While Google's method is mostly OpenID 2.0, but the Initiation, Normalization, and Discovery process (7.1 - 7.3 of OpenID Authentication 2.0) is modified.
Actually, no. Google's mechanism varies from OpenID 2.0 in one key area: the identifier provided is neither an XRI nor an HTTP or HTTPS URL.
I'm not sure I agree: how does it apply to SSL authentication using client certificates?
That's not true.
They've provide a spec on its (fairly trivial) interaction (since developers couldn't use it otherwise), and they've provided recommendations and rationale on implementation approaches and UI design to support this approach (includign recommendations which presuppose other IDPs will also be using this design.) Other than actually providing a reference implementation of the black box (which is fairly simple: you send it an HTTP GET request and it responds with an XRDS document whose only interesting bit (and the only thing whose content isn't fixed) is the OpenID provider endpoint to URL to use -- if you can't implement a version of that for your own OpenID provider, you probably don't have any business implementing any kind of web application, OpenID provider or otherwise.
See Google's documentation here.
In this regard, its worth noting that Google has posted a bit of "public documentation" regarding its usability research in this area (see their Usability Research on Federated Login, for starters.)
There's no reason your login name needs to be your screen name. Given that one is for identifying you to a system and the other is for identifying you to people, there are good reasons for them to be different, even if it might usually be desirable for their to be a 1:1 mapping on any given site.
That's not true at all. Torts and breaches of contract are "against the law" without being criminal. As are all kinds of action by the federal government which exceed its Constitutional authority. If it is criminal, it is against the law, but the converse is not true.
If McDonald's had a monopoly granted by the local government, the way cable companies often do, that might be a fair analogy.
Look, I've only been using the internet since ~1990 (usenet, mostly, then), but let me say this: "You must be new here."
Perfect world merits of the proposal aside, that would be an assessment nightmare.
The problem with direct democracy in a modern large society is not simply one of communication, it is also that the number of issues is too large for people who aren't devoted to it full-time to consider well, without being manipulated by those who are devoted to policy issues full-time. Online referenda address some of the communication issue (that is, getting people to the same, at least virtual, "place" so that communication can occur), but not all of the communications issues, and not the deliberation issue.
OTOH, virtual sessions of representative bodies could allow representatives to remain closer to their constituencies while still remaining engaged in political debates, and IT could offer a lot in terms of enhancing transparency.
Really? When was the last time you were in a chat room with 100 million participants?
It promotes anonymity by allowing services to operate that require associating the initiator of one action with the initiator of a prior action, without requiring the "meatspace" identity of either. That is, it provides a reasonable means for a subscription-based service to verify "the person accessing this resource is the one that established this account" without ever identifying who the person is that established the account.
Since many services rely on providing that kind of relation between the person establishing an account a person requesting a resource, it promotes anonymity to provide a means that allows those services to fill that need while users remain anonymous.
Of course, the question presumes the answer. If, in fact, the VC firm depends on a healthy Open Source community, it shouldn't lock it out. The real question is does the VC firm (or, as I think would more accurately state the case here, the VC-funded firm) actually rely on that, or is it viable for them to operate without it?
Really, its the legislature (both by writing the laws that frame litigation, and by not funding the judiciary so as to make litigation more time consuming than it would otherwise be, further increasing the cost) that has made litigation a very expensive option.