The current copyright law is not how things have worked for the majority of human history.
Neither is the idea of participatory government, freedom of religion, freedom of speech, security of property against arbitrary deprivation by government, etc.
"The way things have worked for the majority of human history" rarely has much relationship to the way things ought to work.
Copyright exists to get as much into the Public Domain as soon as possible.
That may be your opinion of what copyright should do, but the Constitutional purpose of copyright (and patent) protection is "To promote the Progress of Science and useful Arts". Getting the most into the public domain the fastest may or may not be the best way of doing that.
Abandonware, whether software or books, should immediately enter the Public Domain.
I'd certainly agree that something like that is generally desirable.
I have no idea how to accomplish that fairly
One idea I've always favored is to have a short "free" copyright period, and then afterward allow periodic renewals (requiring registration) which would involve a declared value and an ad valorem tax on the declared value, with a minimum declared value. If you aren't willing to pay the minimum tax, the work goes into the public domain. If you do pay the tax, anyone or any group of people can tender the declared value and buy the work -- not for themselves, but buy it into the public domain.
While this new technique may improve security, it seems to lack one important property of pseudo-random numbers that is required by many applications: reproducibility.
That's rather the point of having an RNG rather than a PRNG. For applications that want reproducibility (and which therefore do not want actual randomness) you use a PRNG. For applications that want actual randomness you use an RNG.
Good luck finding the bug in your program with a stream of randoms you'll never be able to reconstruct again.
If there isn't a security reason to keep the random stream secret, you can always capture it as its generated and play it back if you need to reproduce results.
He took the servers. The IP was on the servers. It has been removed. Not copied.
The subjects of intellectual property rights aren't physical entities, (which is why intellectual property is a subtype of intangible personal property), so you can't "remove" IP by moving a physical object.
Suppose that there is an OS which supports that model. The Britney_Spears_Naked email would just come with instructions to check "yes" for all permissions. Since most people have no idea what all those confusing permission dialogs are, and they just want to see the damn pictures, they'll do what the instructions say and click "Yes" for everything. Still nothing solved.
Running one app should produce exactly one permissions dialog, and it shouldn't be confusing. It should directly relate what the requested permissions will allow the app to do. Now, will some people click "yes" to a dialog that tells them that the "pictures" they are trying to open want permission to delete files on their harddrive, to read everything on their hardrive, and to send information out over the web? Probably, some will. But it'll be a lot fewer than would click "yes" to a generic warning of the type most current desktop operating systems give for downloaded executables.
Oh, and protection against SQL injection attacks? That shouldn't be part of a contract; that should be implied.
"Implied" in a contract means "I hope the judge will decide this is part of the contract even though we didn't write it in." (And, often more importantly, "I hope the person I contracted with will act as if this was part of the contract, even though there is a significant chance that they would not be held to it.")
If you want someone you have a contract with to both be legally accountable to an obligation and to be certain to be cognizant of that obligation so that you don't have to take them to court, you make sure it is explicit in the contract.
buzz has a userbase/ceiling/: the number of gmail users; the userbase may be large but it's closed and entry is a large hurdle for many
This is a ceiling for the Buzz application, but not so much for the underlying social network; since Buzz uses open protocols (and especially if Google rolls out the richer set of open-protocol interfaces they've said they plan to), "who Buzz users can connect to with Buzz" is a much bigger universe than "who actually uses Buzz".
I think Google likely sees Buzz and its related open protocols (PubSubHubbub et al.) as a hammer to break open social networking walled gardens (giving Google more stuff to index, search, and provide access to and ads along side through various different interfaces), rather than seeing the Buzz application itself as something they particularly care about making dominant.
The same way Chrome is a tool to push adoption of HTML5 and other related web technologies, Buzz is a tool to push adoption
And, IME, often varies considerably between the particular subject areas within a particular community college. And that's true of colleges/universities more generally, too.
So it isn't that sites containing the information aren't available, or aren't being indexed, they just aren't being given proper weighting in the search results. That would be my two biggest wishlist items for searching - do better at filtering out linkfarms, and have a switch I could select to exclude commerce sites from a specific search.
IME, using the search options and selecting "Fewer shopping sites" seems to do a fairly good job of living up to its name, eliminating most shopping sites from the results. The only real problem I see is that Google's Search Options aren't part of the Search Settings, so while they persist as long as you keep the window open and keep doing searches in it (which, if you habitually open search results in a new tab to keep the search results list available like I do is pretty good, but not perfect.) If they would keep Search Options as part of the persistent Search Settings for your account, or at least provide an option to set the current Search Options as your default for the account, that would do a lot.
This may be a very dumb question, but how will keyboard unit movement work?
If its a simple hex-based system, and the available directions are W-NW-NE-E-SE-SW then A-W-E-D-X-Z would work. For N-NE-SE-SW-NW-N, keys E-R-F-D-S-W could work. (There are, of course, a wide range of other options for either orientation.)
If it is more complex (like an icosahedral projection decomposed into a "hex" grid (which isn't quite a true grid of hexagons, because your 20 corner spaces each have 5 sides rather than 6) -- which is pretty close to ideal for "realism" in a basically gridded movement system in that it works more like movement on a sphere rather than a cylinder -- its trickier, but it would be possible to have context-sensitive movement keys with on-screen hints.
No he complaining that Google is not being an adequate interface to the rest of the web because the only things showing up in his search are Wikipedia and link farms.
Since he said it was good only as a gateway to Wikipedia, IMDB, and similar sites for popular queries, that's very different that your characterization. Sure, its a complaint that, for any given set of subject matter, there one or a small number of useful sites, and lots of parasitic ones, but that still leaves Google as useful for searching those useful sites (especially when their coverage overlaps so you don't have to search multiple sites individually for the same information.)
This is like complaining about a car that will only take you to the library and stores, and not any other building.
Its more like complaining about a car that, when you are in a mood for a particular kind of food, there usually aren't very many good places to drive with the car, and most of the other places you could drive with it suck for the purpose of getting a decent meal of the type you want at that time.
You're still abusing a page cache as a record cache.
Its not a "page cache". Its a resource cache. There is nothing in the definition or semantics of HTTP that demands, or even favors, a particular kind of resource.
I never claimed that was doable.
Oh, but it is!
Um, First you attacked a strawman position that I never made, and now you are defending the same strawman. At this point, I think you are now truly arguing with yourself.
And all Google has to do is create a unique Buzz email address to send updates to (like Facebook has recently done), and you get instant support on any platform capable of sending email.
You can post Buzz by email to buzz@gmail.com from your gmail account. So as long as your gmail account is setup in your mail client, this is in place now.
Furthermore I can search tweets even without logging it to twitter. That's much more convenient.
You can search buzz (and tweets, and some other stuff) without logging into Buzz, too; all you have to do is use Google's main search engine; the live-updating "latest results for..." section includes tweets, buzz, etc.
I doubt there's an army of dyndns typo domains just to get your password. Heck, how could you implement it? Lets say your domain is darguard.dyndns.org and the typo domain is dargard.
IF it were to be done, I would expect the typosquatter would register typo domains for the dynamic dns provider domain (e.g., register "dydns.org", etc.) and then just engage the password capturing code on any subdomain that a request came to, assuming that the subdomain was correct.
Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.
But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is, there is no reason a single database record can't be a full resource so that you would never need to use or cache range queries to do record-level cacheing.
In fact, quite a lot of web applications use a model where a collection located at http://www.example.com/foos has individual resources accessible through http://www.example.com/foos/bar, http://www.example.com/foos/baz, etc. This pretty much directly corresponds to having a DBMS with table "foos" and records with primary keys "bar" and "baz" (and, in fact, that's often exactly what the storage is on the server.) Insofar as the existing web infrastructure is cacheing these responses, record-level cache isn't something HTTP merely supports in theory, its something that it is regularly relied on to provide.
Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?.
I never claimed that was doable. The reason, though, has nothing to do with HTTP not supporting record-level cacheing -- which it does quite well -- but with the fact caching alone, record-level or otherwise, doesn't do anything to support offline client-initiated updates that are immediately visible to the client but where the corresponding requests to the server are deferred until a connection is available.
Which, AFAICT, is the one and only problem solved by local storage for web apps, whether its provided by Google Gears, Flash, or HTML5.
It would solve the problem of browsers silently assuming trust for authentication without confirmation from the user.
People open email attachments named Britney_Spears_Naked.exe all the time even if they've never seen the sender before.
Yes, and the warning on running random executables is usually a generic (and useless) "this might cause some kind of harm to your computer" message, because most OS's don't support a model of fine-grained permissions where each application must request the permissions it needs up front and either have them specifically confirmed each time it runs or have been setup in the OS as trusted for them. The solution to that problem is different than the solution to the presumed trust problem, though its fairly straightforward as well.
In my opinion, as a half-baked measure that moves a little in the right direction, browsers would do better to just download the certificate from the website, and then warn you if the certificate ever changed when you went back to a website that claimed the same identity.
Aren't certificates normally not-permanent? So wouldn't this usually occur? I suppose you could just do it within the life of the original cert...
OTOH, if you are willing to assume that your initial connection is secure and that you trust the person on the other end, one way of providing additional security after that is to provide a secret over the connection that your browser retains. Then, on subsequent connections with the same site, the site proves that it has the secret, and your browser complains if it fails to do so.
(IIRC, Yahoo! and some other sites actually does a non-automated version of this where after establishing a secure connection, you provide a visual secret that can be echoed back to you on secured sites to demonstrated that its not an imposter. This doesn't require any changes to the technical infrastructure or browser, but does require you to look for the visual secret.)
HTTP page caching doesn't have semantics for things not of 'document' granularity.
First off, that's not true: HTTP/1.1 supports both partial GET requests (using the Range header) and caching partial GET requests, so it does have semantics for things not of "document" granularity, including caching them.
Second off, even if it was true, its not meaningful, since HTTP doesn't restrict what can be a "document" (or, in HTTP terms, a resource.) So even if it did only support caching "full" rather than partial GET requests, it could still cache at any level of granularity set by the architect of the particular application, all within the regular HTTP/1.1 scheme with no proprietary extensions.
HTTP doesn't try to provide anything at all close to record level caching.
HTTP provides exactly record level caching, if your record is accessible by a GET request to a specific URL, or as a specified byte range of a specific URL.
To me, its simple. Trust is something that should be granted by the user. A browser distribution may well include certificates for various CA's as a convenience, but generally shouldn't include any of them as trusted by default. There should be an option for the user to designate bundled CA certs (or ones obtained elsewhere) as trusted, and installers could even include option to enable them in the install procedure.
Slashdot Mirror
Neither is the idea of participatory government, freedom of religion, freedom of speech, security of property against arbitrary deprivation by government, etc.
"The way things have worked for the majority of human history" rarely has much relationship to the way things ought to work.
That may be your opinion of what copyright should do, but the Constitutional purpose of copyright (and patent) protection is "To promote the Progress of Science and useful Arts". Getting the most into the public domain the fastest may or may not be the best way of doing that.
I'd certainly agree that something like that is generally desirable.
One idea I've always favored is to have a short "free" copyright period, and then afterward allow periodic renewals (requiring registration) which would involve a declared value and an ad valorem tax on the declared value, with a minimum declared value. If you aren't willing to pay the minimum tax, the work goes into the public domain. If you do pay the tax, anyone or any group of people can tender the declared value and buy the work -- not for themselves, but buy it into the public domain.
Along those lines, you know what else is like Google App Engine for Rubyists? Google App Engine (using JRuby.)
That's rather the point of having an RNG rather than a PRNG. For applications that want reproducibility (and which therefore do not want actual randomness) you use a PRNG. For applications that want actual randomness you use an RNG.
If there isn't a security reason to keep the random stream secret, you can always capture it as its generated and play it back if you need to reproduce results.
They put a different animal on the cover of each book.
The python is, IIRC, on the cover of Programming Python.
If it is, the FSF gets some attention at little cost with the appearance of having talked Google into it.
Nonprofits are concerned about PR as well as substance.
The subjects of intellectual property rights aren't physical entities, (which is why intellectual property is a subtype of intangible personal property), so you can't "remove" IP by moving a physical object.
Running one app should produce exactly one permissions dialog, and it shouldn't be confusing. It should directly relate what the requested permissions will allow the app to do. Now, will some people click "yes" to a dialog that tells them that the "pictures" they are trying to open want permission to delete files on their harddrive, to read everything on their hardrive, and to send information out over the web? Probably, some will. But it'll be a lot fewer than would click "yes" to a generic warning of the type most current desktop operating systems give for downloaded executables.
"Implied" in a contract means "I hope the judge will decide this is part of the contract even though we didn't write it in." (And, often more importantly, "I hope the person I contracted with will act as if this was part of the contract, even though there is a significant chance that they would not be held to it.")
If you want someone you have a contract with to both be legally accountable to an obligation and to be certain to be cognizant of that obligation so that you don't have to take them to court, you make sure it is explicit in the contract.
This is a ceiling for the Buzz application, but not so much for the underlying social network; since Buzz uses open protocols (and especially if Google rolls out the richer set of open-protocol interfaces they've said they plan to), "who Buzz users can connect to with Buzz" is a much bigger universe than "who actually uses Buzz".
I think Google likely sees Buzz and its related open protocols (PubSubHubbub et al.) as a hammer to break open social networking walled gardens (giving Google more stuff to index, search, and provide access to and ads along side through various different interfaces), rather than seeing the Buzz application itself as something they particularly care about making dominant.
The same way Chrome is a tool to push adoption of HTML5 and other related web technologies, Buzz is a tool to push adoption
And, IME, often varies considerably between the particular subject areas within a particular community college. And that's true of colleges/universities more generally, too.
IME, using the search options and selecting "Fewer shopping sites" seems to do a fairly good job of living up to its name, eliminating most shopping sites from the results. The only real problem I see is that Google's Search Options aren't part of the Search Settings, so while they persist as long as you keep the window open and keep doing searches in it (which, if you habitually open search results in a new tab to keep the search results list available like I do is pretty good, but not perfect.) If they would keep Search Options as part of the persistent Search Settings for your account, or at least provide an option to set the current Search Options as your default for the account, that would do a lot.
If its a simple hex-based system, and the available directions are W-NW-NE-E-SE-SW then A-W-E-D-X-Z would work. For N-NE-SE-SW-NW-N, keys E-R-F-D-S-W could work. (There are, of course, a wide range of other options for either orientation.)
If it is more complex (like an icosahedral projection decomposed into a "hex" grid (which isn't quite a true grid of hexagons, because your 20 corner spaces each have 5 sides rather than 6) -- which is pretty close to ideal for "realism" in a basically gridded movement system in that it works more like movement on a sphere rather than a cylinder -- its trickier, but it would be possible to have context-sensitive movement keys with on-screen hints.
Since he said it was good only as a gateway to Wikipedia, IMDB, and similar sites for popular queries, that's very different that your characterization. Sure, its a complaint that, for any given set of subject matter, there one or a small number of useful sites, and lots of parasitic ones, but that still leaves Google as useful for searching those useful sites (especially when their coverage overlaps so you don't have to search multiple sites individually for the same information.)
Its more like complaining about a car that, when you are in a mood for a particular kind of food, there usually aren't very many good places to drive with the car, and most of the other places you could drive with it suck for the purpose of getting a decent meal of the type you want at that time.
Its not a "page cache". Its a resource cache. There is nothing in the definition or semantics of HTTP that demands, or even favors, a particular kind of resource.
Um, First you attacked a strawman position that I never made, and now you are defending the same strawman. At this point, I think you are now truly arguing with yourself.
You can post Buzz by email to buzz@gmail.com from your gmail account. So as long as your gmail account is setup in your mail client, this is in place now.
You can search buzz (and tweets, and some other stuff) without logging into Buzz, too; all you have to do is use Google's main search engine; the live-updating "latest results for..." section includes tweets, buzz, etc.
IF it were to be done, I would expect the typosquatter would register typo domains for the dynamic dns provider domain (e.g., register "dydns.org", etc.) and then just engage the password capturing code on any subdomain that a request came to, assuming that the subdomain was correct.
On any topic, Google's search engine is designed to be an interface to the rest of the web, not a source of its own.
Your complaint is like complaining that a car is useful only as a means of transportation.
But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is, there is no reason a single database record can't be a full resource so that you would never need to use or cache range queries to do record-level cacheing.
In fact, quite a lot of web applications use a model where a collection located at http://www.example.com/foos has individual resources accessible through http://www.example.com/foos/bar, http://www.example.com/foos/baz, etc. This pretty much directly corresponds to having a DBMS with table "foos" and records with primary keys "bar" and "baz" (and, in fact, that's often exactly what the storage is on the server.) Insofar as the existing web infrastructure is cacheing these responses, record-level cache isn't something HTTP merely supports in theory, its something that it is regularly relied on to provide.
I never claimed that was doable. The reason, though, has nothing to do with HTTP not supporting record-level cacheing -- which it does quite well -- but with the fact caching alone, record-level or otherwise, doesn't do anything to support offline client-initiated updates that are immediately visible to the client but where the corresponding requests to the server are deferred until a connection is available.
Which, AFAICT, is the one and only problem solved by local storage for web apps, whether its provided by Google Gears, Flash, or HTML5.
It would solve the problem of browsers silently assuming trust for authentication without confirmation from the user.
Yes, and the warning on running random executables is usually a generic (and useless) "this might cause some kind of harm to your computer" message, because most OS's don't support a model of fine-grained permissions where each application must request the permissions it needs up front and either have them specifically confirmed each time it runs or have been setup in the OS as trusted for them. The solution to that problem is different than the solution to the presumed trust problem, though its fairly straightforward as well.
Aren't certificates normally not-permanent? So wouldn't this usually occur? I suppose you could just do it within the life of the original cert...
OTOH, if you are willing to assume that your initial connection is secure and that you trust the person on the other end, one way of providing additional security after that is to provide a secret over the connection that your browser retains. Then, on subsequent connections with the same site, the site proves that it has the secret, and your browser complains if it fails to do so.
(IIRC, Yahoo! and some other sites actually does a non-automated version of this where after establishing a secure connection, you provide a visual secret that can be echoed back to you on secured sites to demonstrated that its not an imposter. This doesn't require any changes to the technical infrastructure or browser, but does require you to look for the visual secret.)
Who chose to use Flash, again?
First off, that's not true: HTTP/1.1 supports both partial GET requests (using the Range header) and caching partial GET requests, so it does have semantics for things not of "document" granularity, including caching them.
Second off, even if it was true, its not meaningful, since HTTP doesn't restrict what can be a "document" (or, in HTTP terms, a resource.) So even if it did only support caching "full" rather than partial GET requests, it could still cache at any level of granularity set by the architect of the particular application, all within the regular HTTP/1.1 scheme with no proprietary extensions.
HTTP provides exactly record level caching, if your record is accessible by a GET request to a specific URL, or as a specified byte range of a specific URL.
To me, its simple. Trust is something that should be granted by the user. A browser distribution may well include certificates for various CA's as a convenience, but generally shouldn't include any of them as trusted by default. There should be an option for the user to designate bundled CA certs (or ones obtained elsewhere) as trusted, and installers could even include option to enable them in the install procedure.