Now if you want permanent classrooms, we need to work on a way where property prices just don't go up, for the communities, as people who get older acquire more wealth thus make an ageing community that is too expensive for the younger generation who is starting out.
Or else get the younger generation accustomed to the idea that they're going to have to start small and gradually build up. That's the traditional pattern, but high mobility and greater wealth has convinced us that everyone should be able to buy a nice home in their 20s or 30s. The traditional pattern also led to much smaller homes, because people generally became able to trade up about the time their kids were leaving and they no longer needed the space.
That's funny, but it's based on and reinforces a fundamental misunderstanding of Google as a company.
Most people believe that Google is an advertising company. It's not. Google is a technology company currently operating primarily in a space where advertising is the most effective funding mechanism. Google's founders weren't and I think still aren't really comfortable with advertising, but it's what works, and Google quickly found that it can apply technology to the advertising process to make it more effective and more efficient (in terms of sales leads generated per people annoyed).
Google is not fundamentally tied to advertising, however, and in fact the percentage of Google's revenues which come from advertising are declining as the company branches out. Software as a service (Google Apps, App Engine, Compute Engine, etc.) is Google's second-largest source of revenue today, and it's approaching 10% of total revenue. It seems likely the company is going to be moving into the hardware sales space as well, with Glass and driverless cars. Google Fiber is another profit-generator.
As an employee, I'll tell you that a lot of Google employees are likewise uncomfortable with advertising and are very interested in straightforward fee for service business models. Well, advertising is "fee for service", but the customer is the advertiser, not the user, and Google sees end users as its true customers, so the indirection is unpleasant.
Add to this that autonomous cars would be able to drive much closer to each other on the roads
Possibly close enough to draft off of one another and thereby increase fuel efficiency. Given the right technology we could see our long-distance highways populated primarily by massive trains of vehicles inches apart and moving at very high speeds. The front and rear vehicles would still have to fight wind resistance, but the vehicles in between would largely get a free ride.
There's a simple answer to this whole problem. Google should accept the responsibility as the driver of the vehicle, and pay just like a regular person every time the car causes an accident.
I believe this is actually Google's position on the question, that the manufacturer of the self-driving car should be liable for accidents, and that they're having a hard time convincing legislators.
My mistake. It used to be that AdBlock Plus defaulted to not blocking Google text ads. It looks like the default is to block, now, though it is still optional.
Chromium is open source so if you don't like it, fork you own copy and get whatever useless toolbars that install without permission that you want.
You let me know when Chromium gets bundled with Android cell phones or Chromebook laptops.
Nicely done... you slipped that word "bundled" in there, because obviously that's not going to happen; Google will provide the normal Chrome builds. Users that want to can install Chromium themselves, of course, and in fact Google even provides instructions on how to do it, as well as all of the source code.
And you also slyly ignored the fact that the just-announced news doesn't affect Android or Chromebook, only Windows. Maybe Chrome for Android will eventually get the same policy, but it's likely that the superior security architecture of ChromeOS will make it unnecessary on Chromebooks.
Why would kids mistaking a traitor for a hero give you hope? You didn't fixate on Snowdens revelation of domestic spying, and totally overlook his treachery regarding international spying, did you?
Nope. But given that he wisely didn't dare take the time to sort everything out before handing the data to the Guardian and fleeing, I agree with Snowden that the latter was an acceptable cost for blowing the whistle on the former. The outing of the international spying operations did little real damage; it didn't provide much information on methods, didn't expose any human assets, and despite the de rigeur howls of outrage, everyone knew it was going on anyway. At most there was a little surprise as foreign agencies discovered that the NSA was even better than previously thought.
On the other hand, the revelation that the NSA was blatantly violating the legal restrictions on its operations (albeit with some weaselly definitions attempting to work around it) and -- even more important -- that the NSA had abandoned one half of its dual mission in favor of the other half, was hugely important to get out.
Ever since I worked with the NSA a few years ago I've thought of them as the good guys, because when I worked with them they were clearly and seriously trying to strengthen the security of the corner of the US financial system I was working on. I knew they tried to break security as well, but was certain that they'd take steps to close serious holes they found which threatened important government and non-government security. The rationale was that since their job is both to spy on everyone else's signals and to secure ours, they could only safely leave holes in place if they were confident that only they could exploit them.
But thanks to Snowden we now know they not only didn't help to fix the holes they found, and didn't care if the holes were something that others might exploit, they actively tried to create new ones, to subvert new designs and implementations. They've been working to weaken our entire security infrastructure -- actively working against one half of their mission -- in order to make their jobs on the other half easier.
We really, really needed to know that. Frankly, it's information of such vital importance to REAL national security, meaning securing the freedom of Americans rather than the narrow goals of government agencies, that it would have been worth a lot more damage. Lives, even.
Yes, Snowden is a hero. Not an unblemished hero, but on balance a true American hero.
I should mention that I still don't consider the NSA wholly rotten. Actually, my colleagues work closely with an NSA employee, the guy who designed and still works on SELinux. He's smart, dedicated and very serious about improving security. There are lots more like him, probably the majority. But the organization is rotten and needs a serious housecleaning to refocus on both of its missions. Thanks to Snowden we know that.
If you're expecting a slew of new driver hackers reverse engineering chipsets, and implementing better drivers, testing all corner cases (because dev's LOVE testing) I think you're barking up a very small tree
Don't be silly.
The goal is to get a nifty new string manipulation API implemented in kernel space. Imagine how slick it would be to use (error checking omitted for brevity):
I mean, how awesome is that? Only 8 lines of code to concatenate two strings! It would even be trivial to include multiple copies of string1 and/or string2 if you wanted!
And since it's implemented in the kernel you know it'll be uber fast and secure.
Yeah, here's our HTTP replacement. We think it's pretty neat, and have been using it it when the hundreds of millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."
FTFY.
Your point is a really good one, though. It's the first thing that occurred to me when I started talking to people in Google about SPDY and QUIC. At this point making big changes in fundamental infrastructure like HTTP almost requires a single party that controls all the major moving parts to design, implement and test it.
Google, who gladly works hand in hand with the NSA
I have to call bullshit on this rather common but unsupported and unsupportable claim.
There is no evidence that Google had cooperated with the NSA in any way other than actually required by law, and there they claim to be sticklers in demanding that the government dot the i's and cross the t's, including refusing any requests that are overly broad. We can't see what they actually do, of course, because the law makes it illegal for them to say... however Google was the company that first started publishing transparency reports and took the initiative to negotiate permission to publish aggregate statistics about the requests they're legally prevented from publishing. Those published numbers make it clear that Google is not providing information about large numbers of users.
There is evidence that the NSA had an extensive operation in place tapping Google's internal network. When this was revealed, Google immediately accelerated plans to encrypt all of those links to foil the snooping.
Beyond that, look at Google's Internet security track record. Google was the first major webmail provider to switch to HTTPS. Google is still the only major web search engine that requires HTTPS. For logged-in uses, all Google services are all-encrypted, all the time, and for most services even users that aren't logged in get HTTPS by default. Yes, Google designed SPDY, and designed it without an unencrypted mode. The HTTP/2 committee may have added support for unencrypted operation, but Google didn't design it in. Google's next-gen protocol, QUIC, not only doesn't have an unencrypted mode, security is baked so deeply into it that it's basically impossible to remove or disable.
FWIW, I'm a Google engineer, and until recently my job was to work on part of the internal communications security infrastructure. It's vanishingly unlikely that Google could have had any kind of sanctioned NSA tap in place without it being visible to me, and I saw no hint of any such thing.
I happen to personally know several of the people involved with SPDY and there's no way any of them would be party to any attempt to deliberately weaken the protocol.
Beyond that, I can tell you that the internal response to the Snowden revelations about NSA access into Google was one of fury, and a deep and abiding commitment to make sure it can't happen again. Google wants to ensure that the only way the government can get data about Google's users is to come in through the front door, with appropriate court documentation.
[Google] is a Corporation whose core focus to track and monitor every single person and thing online?
This is also simply untrue. Google's core focus is in its mission statement, which you can search for. 90% of its revenue comes from targeted advertising, and Google does collect information to do that ad targeting... but only with user approval. If you don't want Google to track you, Google provides tools you can use to ensure you're not tracked. In the process you'll have to give up some (not all, but some) use of Google's services, because the targeted advertising is the fee you pay for those services. Google hopes you'll like that deal and be happy with it. But if you're not, Google wants to ensure you can opt out. See http://google.com/privacy/tool...
(Disclaimer: The above is not an official company statement. In fact, company policy encourages me not to make it (though policy doesn't prohibit me). It is, however, my firm personal view.)
The committee member is simply pointing out that new standards that do not provide any new functionality do not get used
But HTTP/2 does provide valuable new functionality, mostly around performance, with some security benefits as well. It just doesn't provide what he wants. Also, if you read the thread and notice who's involved you'll see there's not much question about it getting used. Mozilla, Opera, Apple and Microsoft are all involved and actively implementing on the browser side, and Apache and Microsoft are implementing on the server side. Google, of course, has had both sides in production for years.
He also points out useful things that the new standard could/should address but isn't.
Could address if the work in progress were thrown away and the committee went back to the drawing board.
You make it sound like this guy is just throwing a hissy fit which is just bad form.
I quite agree that "hissy fit" is a reasonable, if a bit overstated, characterization of his comments, and that said fit is bad form.
Interesting suggestion. I don't think it's workable, though, because it would require web app developers to properly indicate which of their headers are sensitive. More of them would get it wrong than right.
In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.
SPDY's security component is TLS. SPDY is essentially just some minor restrictions (not changes) in the TLS negotiation protocol, plus a sophisticated HTTP acceleration protocol tunneled inside. So this really isn't a "first attempt", by any means. Not to mention the fact that Google has been using SPDY extensively for years now and has a great deal of real-world experience with it. Your argument might hold water when applied to QUIC, but not so much to SPDY.
It really helps to read the thread and get a sense of what the actual dispute is about. In a nutshell, Kamp is bothered less that HTTP/2 is complex than that it doesn't achieve enough. In particular, it doesn't address problems that HTTP/1.1 has with being used as a large file (multi-GB) transfer protocol, and it doesn't eliminate cookies. Not many committee members seem to agree that these are important problems for HTTP/2, though most do agree that it would be nice some day to address those issues, in some standard.
What many do agree on is that there is some dangerous complexity in one part of the proposal, a header compression algorithm called HPACK. The reason for using HPACK is the CRIME attack, which exploits Gzip compression of headers to deduce cookies and other sensitive header values. It does this even though the compressed data is encrypted. HPACK is designed to be resistant to this sort of attack, but it's complex. Several committee members are arguing that it would be reasonable to proceed without header compression at all, thus greatly simplifying the proposal. Others are arguing that they can specify HPACK, but make header compression negotiable and allow clients and servers to choose to use nothing rather than HPACK, if they prefer (or something better when it comes along).
Bottom line: What we have here is one committee member who has been annoyed that his wishes to deeply rethink HTTP have been ignored. He is therefore latching onto a real issue that the rest of the committee is grappling with and using it to argue that they should just throw the whole thing out and get to work on what he wanted to do. And he made his arguments with enough flair and eloquence to get attention beyond the committee. All in all, just normal standards committee politics which has (abnormally) escaped the committee mailing list and made it to the front page of/.
I'm not asking for a citation because I don't believe it, I'm asking for a citation because I'm biased towards believing it, and I always try to counter confirmation bias.
Otherwise, the result is not surprising and in line with several legal initiatives in USA, targeting the "ex-GF revenge" sites.
In the USA, so far I've only seen articles about "thou shalt not distribute". This sounds more like "thou must giveth up".
Only because the summary is badly-written. What the ruling said was that consent could be withdrawn, which means the holder of the photos can't do the things allowed by copyright... namely make copies, display them publicly, etc.
All command lines include multiple components, including directives as well as key values. The only other option is to have a mixed UI, where some elements are entered on the command line and others are added via some other interface.
That's how command lines work, and it's both effective and usable.
Slashdot Mirror
Now if you want permanent classrooms, we need to work on a way where property prices just don't go up, for the communities, as people who get older acquire more wealth thus make an ageing community that is too expensive for the younger generation who is starting out.
Or else get the younger generation accustomed to the idea that they're going to have to start small and gradually build up. That's the traditional pattern, but high mobility and greater wealth has convinced us that everyone should be able to buy a nice home in their 20s or 30s. The traditional pattern also led to much smaller homes, because people generally became able to trade up about the time their kids were leaving and they no longer needed the space.
Posting to undo accidental negative mod. Was going for "insightful", hit "redundant".
That's funny, but it's based on and reinforces a fundamental misunderstanding of Google as a company.
Most people believe that Google is an advertising company. It's not. Google is a technology company currently operating primarily in a space where advertising is the most effective funding mechanism. Google's founders weren't and I think still aren't really comfortable with advertising, but it's what works, and Google quickly found that it can apply technology to the advertising process to make it more effective and more efficient (in terms of sales leads generated per people annoyed).
Google is not fundamentally tied to advertising, however, and in fact the percentage of Google's revenues which come from advertising are declining as the company branches out. Software as a service (Google Apps, App Engine, Compute Engine, etc.) is Google's second-largest source of revenue today, and it's approaching 10% of total revenue. It seems likely the company is going to be moving into the hardware sales space as well, with Glass and driverless cars. Google Fiber is another profit-generator.
As an employee, I'll tell you that a lot of Google employees are likewise uncomfortable with advertising and are very interested in straightforward fee for service business models. Well, advertising is "fee for service", but the customer is the advertiser, not the user, and Google sees end users as its true customers, so the indirection is unpleasant.
(#include <std_disclaimer>)
A human can see a train approaching a level crossing far sooner than a self-driving car.
Why do you say that? LIDAR is quite good at detecting large moving objects.
Add to this that autonomous cars would be able to drive much closer to each other on the roads
Possibly close enough to draft off of one another and thereby increase fuel efficiency. Given the right technology we could see our long-distance highways populated primarily by massive trains of vehicles inches apart and moving at very high speeds. The front and rear vehicles would still have to fight wind resistance, but the vehicles in between would largely get a free ride.
There's a simple answer to this whole problem. Google should accept the responsibility as the driver of the vehicle, and pay just like a regular person every time the car causes an accident.
I believe this is actually Google's position on the question, that the manufacturer of the self-driving car should be liable for accidents, and that they're having a hard time convincing legislators.
Chrome for Android doesn't have an app store, or even extensions for that matter.
Yeah, that's why I said maybe it will get the same policy, when it gets extensions and an App Store.
My mistake. It used to be that AdBlock Plus defaulted to not blocking Google text ads. It looks like the default is to block, now, though it is still optional.
Haven't got any actual counterarguments, I see.
Also to get rid of troublesome extensions like Adblock Plus.
Oh, really? It's also worth pointing out that AdBlock Plus by default doesn't block Google ads.
Chromium is open source so if you don't like it, fork you own copy and get whatever useless toolbars that install without permission that you want.
You let me know when Chromium gets bundled with Android cell phones or Chromebook laptops.
Nicely done... you slipped that word "bundled" in there, because obviously that's not going to happen; Google will provide the normal Chrome builds. Users that want to can install Chromium themselves, of course, and in fact Google even provides instructions on how to do it, as well as all of the source code.
And you also slyly ignored the fact that the just-announced news doesn't affect Android or Chromebook, only Windows. Maybe Chrome for Android will eventually get the same policy, but it's likely that the superior security architecture of ChromeOS will make it unnecessary on Chromebooks.
Why would kids mistaking a traitor for a hero give you hope? You didn't fixate on Snowdens revelation of domestic spying, and totally overlook his treachery regarding international spying, did you?
Nope. But given that he wisely didn't dare take the time to sort everything out before handing the data to the Guardian and fleeing, I agree with Snowden that the latter was an acceptable cost for blowing the whistle on the former. The outing of the international spying operations did little real damage; it didn't provide much information on methods, didn't expose any human assets, and despite the de rigeur howls of outrage, everyone knew it was going on anyway. At most there was a little surprise as foreign agencies discovered that the NSA was even better than previously thought.
On the other hand, the revelation that the NSA was blatantly violating the legal restrictions on its operations (albeit with some weaselly definitions attempting to work around it) and -- even more important -- that the NSA had abandoned one half of its dual mission in favor of the other half, was hugely important to get out.
Ever since I worked with the NSA a few years ago I've thought of them as the good guys, because when I worked with them they were clearly and seriously trying to strengthen the security of the corner of the US financial system I was working on. I knew they tried to break security as well, but was certain that they'd take steps to close serious holes they found which threatened important government and non-government security. The rationale was that since their job is both to spy on everyone else's signals and to secure ours, they could only safely leave holes in place if they were confident that only they could exploit them.
But thanks to Snowden we now know they not only didn't help to fix the holes they found, and didn't care if the holes were something that others might exploit, they actively tried to create new ones, to subvert new designs and implementations. They've been working to weaken our entire security infrastructure -- actively working against one half of their mission -- in order to make their jobs on the other half easier.
We really, really needed to know that. Frankly, it's information of such vital importance to REAL national security, meaning securing the freedom of Americans rather than the narrow goals of government agencies, that it would have been worth a lot more damage. Lives, even.
Yes, Snowden is a hero. Not an unblemished hero, but on balance a true American hero.
I should mention that I still don't consider the NSA wholly rotten. Actually, my colleagues work closely with an NSA employee, the guy who designed and still works on SELinux. He's smart, dedicated and very serious about improving security. There are lots more like him, probably the majority. But the organization is rotten and needs a serious housecleaning to refocus on both of its missions. Thanks to Snowden we know that.
If you're expecting a slew of new driver hackers reverse engineering chipsets, and implementing better drivers, testing all corner cases (because dev's LOVE testing) I think you're barking up a very small tree
Don't be silly.
The goal is to get a nifty new string manipulation API implemented in kernel space. Imagine how slick it would be to use (error checking omitted for brevity):
char* buf; FILE* fp = fopen("/dev/strcat", "r+");
fwrite(string1, string1_length, 1, fp);
fwrite(string2, string2_length, 1, fp);
fflush(fp);
buf = malloc(string1_length + string2_length);
fread(buf, string1_length + string2_length, fp);
fclose(fp);
I mean, how awesome is that? Only 8 lines of code to concatenate two strings! It would even be trivial to include multiple copies of string1 and/or string2 if you wanted!
And since it's implemented in the kernel you know it'll be uber fast and secure.
Can't argue with that. It is an issue. OTOH, I think social media is a much more serious issue in that respect than targeted advertising.
Yeah, here's our HTTP replacement. We think it's pretty neat, and have been using it it when the hundreds of millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."
FTFY.
Your point is a really good one, though. It's the first thing that occurred to me when I started talking to people in Google about SPDY and QUIC. At this point making big changes in fundamental infrastructure like HTTP almost requires a single party that controls all the major moving parts to design, implement and test it.
Google, who gladly works hand in hand with the NSA
I have to call bullshit on this rather common but unsupported and unsupportable claim.
There is no evidence that Google had cooperated with the NSA in any way other than actually required by law, and there they claim to be sticklers in demanding that the government dot the i's and cross the t's, including refusing any requests that are overly broad. We can't see what they actually do, of course, because the law makes it illegal for them to say... however Google was the company that first started publishing transparency reports and took the initiative to negotiate permission to publish aggregate statistics about the requests they're legally prevented from publishing. Those published numbers make it clear that Google is not providing information about large numbers of users.
There is evidence that the NSA had an extensive operation in place tapping Google's internal network. When this was revealed, Google immediately accelerated plans to encrypt all of those links to foil the snooping.
Beyond that, look at Google's Internet security track record. Google was the first major webmail provider to switch to HTTPS. Google is still the only major web search engine that requires HTTPS. For logged-in uses, all Google services are all-encrypted, all the time, and for most services even users that aren't logged in get HTTPS by default. Yes, Google designed SPDY, and designed it without an unencrypted mode. The HTTP/2 committee may have added support for unencrypted operation, but Google didn't design it in. Google's next-gen protocol, QUIC, not only doesn't have an unencrypted mode, security is baked so deeply into it that it's basically impossible to remove or disable.
FWIW, I'm a Google engineer, and until recently my job was to work on part of the internal communications security infrastructure. It's vanishingly unlikely that Google could have had any kind of sanctioned NSA tap in place without it being visible to me, and I saw no hint of any such thing.
I happen to personally know several of the people involved with SPDY and there's no way any of them would be party to any attempt to deliberately weaken the protocol.
Beyond that, I can tell you that the internal response to the Snowden revelations about NSA access into Google was one of fury, and a deep and abiding commitment to make sure it can't happen again. Google wants to ensure that the only way the government can get data about Google's users is to come in through the front door, with appropriate court documentation.
[Google] is a Corporation whose core focus to track and monitor every single person and thing online?
This is also simply untrue. Google's core focus is in its mission statement, which you can search for. 90% of its revenue comes from targeted advertising, and Google does collect information to do that ad targeting... but only with user approval. If you don't want Google to track you, Google provides tools you can use to ensure you're not tracked. In the process you'll have to give up some (not all, but some) use of Google's services, because the targeted advertising is the fee you pay for those services. Google hopes you'll like that deal and be happy with it. But if you're not, Google wants to ensure you can opt out. See http://google.com/privacy/tool...
(Disclaimer: The above is not an official company statement. In fact, company policy encourages me not to make it (though policy doesn't prohibit me). It is, however, my firm personal view.)
most IT folks are starry eyed suckers for the new and flashy.
New and flashy... like TLS?
The committee member is simply pointing out that new standards that do not provide any new functionality do not get used
But HTTP/2 does provide valuable new functionality, mostly around performance, with some security benefits as well. It just doesn't provide what he wants. Also, if you read the thread and notice who's involved you'll see there's not much question about it getting used. Mozilla, Opera, Apple and Microsoft are all involved and actively implementing on the browser side, and Apache and Microsoft are implementing on the server side. Google, of course, has had both sides in production for years.
He also points out useful things that the new standard could/should address but isn't.
Could address if the work in progress were thrown away and the committee went back to the drawing board.
You make it sound like this guy is just throwing a hissy fit which is just bad form.
I quite agree that "hissy fit" is a reasonable, if a bit overstated, characterization of his comments, and that said fit is bad form.
Interesting suggestion. I don't think it's workable, though, because it would require web app developers to properly indicate which of their headers are sensitive. More of them would get it wrong than right.
DRM-free ebooks for nearly 20 years.
In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.
SPDY's security component is TLS. SPDY is essentially just some minor restrictions (not changes) in the TLS negotiation protocol, plus a sophisticated HTTP acceleration protocol tunneled inside. So this really isn't a "first attempt", by any means. Not to mention the fact that Google has been using SPDY extensively for years now and has a great deal of real-world experience with it. Your argument might hold water when applied to QUIC, but not so much to SPDY.
It really helps to read the thread and get a sense of what the actual dispute is about. In a nutshell, Kamp is bothered less that HTTP/2 is complex than that it doesn't achieve enough. In particular, it doesn't address problems that HTTP/1.1 has with being used as a large file (multi-GB) transfer protocol, and it doesn't eliminate cookies. Not many committee members seem to agree that these are important problems for HTTP/2, though most do agree that it would be nice some day to address those issues, in some standard.
What many do agree on is that there is some dangerous complexity in one part of the proposal, a header compression algorithm called HPACK. The reason for using HPACK is the CRIME attack, which exploits Gzip compression of headers to deduce cookies and other sensitive header values. It does this even though the compressed data is encrypted. HPACK is designed to be resistant to this sort of attack, but it's complex. Several committee members are arguing that it would be reasonable to proceed without header compression at all, thus greatly simplifying the proposal. Others are arguing that they can specify HPACK, but make header compression negotiable and allow clients and servers to choose to use nothing rather than HPACK, if they prefer (or something better when it comes along).
Bottom line: What we have here is one committee member who has been annoyed that his wishes to deeply rethink HTTP have been ignored. He is therefore latching onto a real issue that the rest of the committee is grappling with and using it to argue that they should just throw the whole thing out and get to work on what he wanted to do. And he made his arguments with enough flair and eloquence to get attention beyond the committee. All in all, just normal standards committee politics which has (abnormally) escaped the committee mailing list and made it to the front page of /.
makes good bongs, though.
How do they compare with carbon fiber bongs?
I'm not asking for a citation because I don't believe it, I'm asking for a citation because I'm biased towards believing it, and I always try to counter confirmation bias.
Otherwise, the result is not surprising and in line with several legal initiatives in USA, targeting the "ex-GF revenge" sites.
In the USA, so far I've only seen articles about "thou shalt not distribute". This sounds more like "thou must giveth up".
Only because the summary is badly-written. What the ruling said was that consent could be withdrawn, which means the holder of the photos can't do the things allowed by copyright... namely make copies, display them publicly, etc.
All command lines include multiple components, including directives as well as key values. The only other option is to have a mixed UI, where some elements are entered on the command line and others are added via some other interface.
That's how command lines work, and it's both effective and usable.