VHS, at least in the US, most certainly *did* use DRM. It was called Macrovision. From a technical standpoint, it was easy to defeat. So we tried to solve it legislatively.
What you describe still isn't "right." You shouldn't use.dev for anything since you don't own the TLD. Google can't actually *stop* you from doing this on their local network. But the browser will refuse to do http with anything that ends in.dev and require https. So now if you have an incorrect setup, you can either (a) stop using the.dev TLD incorrectly or (b) generate a bunch of bogus self-signed certificates and updated your browsers to accept the CA. Since both of these require effort, the hope is that people will do the right thing and stop using.dev at all since they don't own any subdomains within.dev (Google doesn't sell them) Maybe you are missing the point that there is no correct way to use.dev.
There are some really poor UI designs out there. But generally the UI is somewhat of secondary issue. Many problems require deep domain knowledge to solve and we keep trying to build electronic systems that can be used without the prerequisite skills. Those will continue to fail. Things like Facebook are useful regardless of UI as long as it is even tolerable. So the issue is not UI improvement in most cases.
I don't know whether they do these email focus groups or not, but if they do, they aren't very effective. My wife's car has a picture of a tire tread with an exclamation mark that indicates low tire pressure. Looks confusingly similar to a thermometer in water so you may think you have an overhead. The check engine light is useless if you have never seen an engine on a test stand. Honestly text would work way better than icons for these interfaces. A 16 character display with an actual text message would take up less space and convey more information. Of course it's not language-neutral which is a disadvantage but it's much more expressive.
DRM schemes aren't going away and having standards around them seems like the best path forward. Without DRM, you can't have content rental systems. It's been said many times that information wants to be free, but the content creators need to eat and the studio executives need to fuel a lavish lifestyle. Without some form of DRM you wouldn't be able to have subscription services like HBO Go or Amazon Prime. It's a fair criticism that when you "purchase" a movie or TV show using Amazon Prime or Apple TV or similar that it's really a long-term rental. There was a time when a DRM-free purchase seemed like a great idea. But that was when we wanted to do things like download an entire movie and play on various devices. Now everything is streaming and you don't even notice the DRM. New standards will make it even less intrusive. Yes part of Stallman's "Right to Read" is coming true in that you can't lend your DRM purchases very well and sharing your password isn't a great idea. But also the prices have come down so much that there's no *need* for this. Everybody can have their own access for a very affordable price so the doom and gloom predictions are not materializing. I'm glad EFF resigned because I'd like to see them focus their attention on more important issues.
If your setup is that insecure, you could do MITM-capture anyway for any 3rd party network.
This makes no sense. Most of your comments seem pretty reasonable but then parts of the comments always seem to misunderstand the problem. As an example, let's say that I configure a server on my network to respond to requests to http://www.slashdot.org./ If I'm not going to visit the real slashdot, I wouldn't see any problem with this as long as I'm on the local network. But lets say the network configuration changes (either because I physically relocate, somebody fat fingers a local DNS entry, et cetera). Now I go to load those URLs. I'm suddenly sending data to the real slashdot.org. Data that I probably don't wan to be sending to a third-party because it may be confidential. And data that the third-party doesn't want to receive since it's junk traffic to them.
This doesn't expose me to MiTM at all other than the general MiTM problem when sending http over untrusted networks. But this neither increases nor decreases my exposure to MiTM. It just means that I'm sending data where it shouldn't go. Not that MITM isn't something to worry about;it's just not the problem that occurs when misusing TLDs.
Using.example,.invalid, and.localhost complies with the RFCs. Using.dev (when it's an in-use TLD) most certainly does *not* comply with the RFC. But, even if it did, it would be foolish. If I have a bunch of URLs like myserver.dev that work on my corporate network and then I leave the office, I could accidentally load those URLs and leak data to a third-party. So even if the RFCs allowed this it would be foolish. The issue here is that people aren't using the TLDs in the RFCs. They are using the wrong ones. Google is making a change to Chrome to push them in the right direction. I have no idea why this wouldn't be universally celebrated.
That's a very fair point. The expansion of TLDs was a huge problem. But we also have *reserved* TLDs that can safely be used for testing. Any other TLD may get sold in the future. So, as has been pointed out other places, if you just use either the reserved TLD or a domain that you own for your servers, you are future proof against future TLD expansion. The fact that people are pretending that the new TLDs don't exist and haven't reconfigured their servers is quite shocking given how long ago this happened.
Seriously are people really using.dev URLs to point to local resources where there could be a name collision with a real TLD? So you have a bunch of links to [].dev that people have stored. And then they switch networks where.dev resolves correctly and they start erroneously sending data to third parties. And we don't all see why that is an awful problem?/. is starting to sound like its the new hangout for Equifax CSO candidates.
Although I think your point has some validity, in many large organizations, there is no application portfolio management whatsoever so you don't even have a list of deployed systems never mind information about their internals or patches.
She should be skewered for hiding her background, though. If her profile was incomplete, she could add her additional credentials. If she really was unqualified and got the job via dubious means she should just come out and say it. But to go into hiding after something like this, regardless of any other facts, her current behavior is worthy of a skewering.
People who think they might get rich through luck have a legitimate fear that the current system would make them poor again. If I'm going to get a one-time windfall and have to make it last, of course I don't want a large portion to go to taxes. If I can do something that adds value continuously so I always have income, then I'm not so concerned.
The sun's energy is, for practical purposes, infinite. So if we got to a point where we can harvest it efficiently, it's reasonable to think that there wont be conflict over finite resources. Of course this has never happened so there is no evidence. But it's a reasonable prediction. However, people will probably still have conflict over power and control and other more abstract things and the ability to cause more destruction.
Well you can save up to buy the more expensive laptop. Then you'll drop it again and it turns out you would have been way better off buying a much cheaper one and keeping the extra cash in the bank. Warranties don't cover accidental damage. And you could get an outlier that lasts only the warranty period. In general, other than perhaps housing and vehicles, if you have to "save up" to buy something, you are better off saving up and then not buying it.
Except that you can't figure out which equipment is durable and reliable. You might be getting better headphones for $200 or you might be getting $12 headphones that are marked up. Well if you buy the $12 version, your total risk is $12. If you buy the $200 version, your risk is $200. So given that you can't be sure that the order-of-magnitude more expensive option is actually better, you have to go with the cheaper option. Furthermore even a "durable and reliable" piece of equipment is subject to accidental damage which isn't covered by warranty. So you're still better off going with the low risk option sometimes even if the higher priced option is genuinely better.
I think you are right. I confused them with the other headphones because I actually read the link in the article to the BoM breakdown which was for the over-the-ear beats headphones!
Yes but the later post points out that the counterfeits are almost identical and that the genuine ones aren't any better. So this kind of contributes more to the original point that the "value is in the brand," (i.e. they suck but are expensive)
They have "beats" in really large letters so that everybody else in the gym can notice that you are wearing them which is the only reason you would buy such a ridiculous product as these to begin with. Unfortunately, having the beats headphones isn't going to provide the attention from the cute girls in the gym who are in better shape and not interested. You can't file a class action suit saying that the headphones didn't increase your sex appeal, though.
Well except that Google has already issued a patch going back to Android Marshmallow. But since it seems Apple never had the vulnerability this is +1 for Apple although I don't have any long-running statistics on security.
Slashdot Mirror
VHS, at least in the US, most certainly *did* use DRM. It was called Macrovision. From a technical standpoint, it was easy to defeat. So we tried to solve it legislatively.
What you describe still isn't "right." You shouldn't use .dev for anything since you don't own the TLD. Google can't actually *stop* you from doing this on their local network. But the browser will refuse to do http with anything that ends in .dev and require https. So now if you have an incorrect setup, you can either (a) stop using the .dev TLD incorrectly or (b) generate a bunch of bogus self-signed certificates and updated your browsers to accept the CA. Since both of these require effort, the hope is that people will do the right thing and stop using .dev at all since they don't own any subdomains within .dev (Google doesn't sell them) Maybe you are missing the point that there is no correct way to use .dev.
There are some really poor UI designs out there. But generally the UI is somewhat of secondary issue. Many problems require deep domain knowledge to solve and we keep trying to build electronic systems that can be used without the prerequisite skills. Those will continue to fail. Things like Facebook are useful regardless of UI as long as it is even tolerable. So the issue is not UI improvement in most cases.
I don't know whether they do these email focus groups or not, but if they do, they aren't very effective. My wife's car has a picture of a tire tread with an exclamation mark that indicates low tire pressure. Looks confusingly similar to a thermometer in water so you may think you have an overhead. The check engine light is useless if you have never seen an engine on a test stand. Honestly text would work way better than icons for these interfaces. A 16 character display with an actual text message would take up less space and convey more information. Of course it's not language-neutral which is a disadvantage but it's much more expressive.
DRM schemes aren't going away and having standards around them seems like the best path forward. Without DRM, you can't have content rental systems. It's been said many times that information wants to be free, but the content creators need to eat and the studio executives need to fuel a lavish lifestyle. Without some form of DRM you wouldn't be able to have subscription services like HBO Go or Amazon Prime. It's a fair criticism that when you "purchase" a movie or TV show using Amazon Prime or Apple TV or similar that it's really a long-term rental. There was a time when a DRM-free purchase seemed like a great idea. But that was when we wanted to do things like download an entire movie and play on various devices. Now everything is streaming and you don't even notice the DRM. New standards will make it even less intrusive. Yes part of Stallman's "Right to Read" is coming true in that you can't lend your DRM purchases very well and sharing your password isn't a great idea. But also the prices have come down so much that there's no *need* for this. Everybody can have their own access for a very affordable price so the doom and gloom predictions are not materializing. I'm glad EFF resigned because I'd like to see them focus their attention on more important issues.
Using .example, .invalid, and .localhost complies with the RFCs. Using .dev (when it's an in-use TLD) most certainly does *not* comply with the RFC. But, even if it did, it would be foolish. If I have a bunch of URLs like myserver.dev that work on my corporate network and then I leave the office, I could accidentally load those URLs and leak data to a third-party. So even if the RFCs allowed this it would be foolish. The issue here is that people aren't using the TLDs in the RFCs. They are using the wrong ones. Google is making a change to Chrome to push them in the right direction. I have no idea why this wouldn't be universally celebrated.
That's a very fair point. The expansion of TLDs was a huge problem. But we also have *reserved* TLDs that can safely be used for testing. Any other TLD may get sold in the future. So, as has been pointed out other places, if you just use either the reserved TLD or a domain that you own for your servers, you are future proof against future TLD expansion. The fact that people are pretending that the new TLDs don't exist and haven't reconfigured their servers is quite shocking given how long ago this happened.
Seriously are people really using .dev URLs to point to local resources where there could be a name collision with a real TLD? So you have a bunch of links to [].dev that people have stored. And then they switch networks where .dev resolves correctly and they start erroneously sending data to third parties. And we don't all see why that is an awful problem? /. is starting to sound like its the new hangout for Equifax CSO candidates.
As people get older, they tend to have less cavities. The teeth get harder. I don't know why as I'm not a dentist.
Nessus and Nikto will only find this if they find the vulnerable systems. If the apps are in a "forgotten" DMZ this won't help one bit.
Although I think your point has some validity, in many large organizations, there is no application portfolio management whatsoever so you don't even have a list of deployed systems never mind information about their internals or patches.
She should be skewered for hiding her background, though. If her profile was incomplete, she could add her additional credentials. If she really was unqualified and got the job via dubious means she should just come out and say it. But to go into hiding after something like this, regardless of any other facts, her current behavior is worthy of a skewering.
People who think they might get rich through luck have a legitimate fear that the current system would make them poor again. If I'm going to get a one-time windfall and have to make it last, of course I don't want a large portion to go to taxes. If I can do something that adds value continuously so I always have income, then I'm not so concerned.
The sun's energy is, for practical purposes, infinite. So if we got to a point where we can harvest it efficiently, it's reasonable to think that there wont be conflict over finite resources. Of course this has never happened so there is no evidence. But it's a reasonable prediction. However, people will probably still have conflict over power and control and other more abstract things and the ability to cause more destruction.
Well you can save up to buy the more expensive laptop. Then you'll drop it again and it turns out you would have been way better off buying a much cheaper one and keeping the extra cash in the bank. Warranties don't cover accidental damage. And you could get an outlier that lasts only the warranty period. In general, other than perhaps housing and vehicles, if you have to "save up" to buy something, you are better off saving up and then not buying it.
Except that you can't figure out which equipment is durable and reliable. You might be getting better headphones for $200 or you might be getting $12 headphones that are marked up. Well if you buy the $12 version, your total risk is $12. If you buy the $200 version, your risk is $200. So given that you can't be sure that the order-of-magnitude more expensive option is actually better, you have to go with the cheaper option. Furthermore even a "durable and reliable" piece of equipment is subject to accidental damage which isn't covered by warranty. So you're still better off going with the low risk option sometimes even if the higher priced option is genuinely better.
I think you are right. I confused them with the other headphones because I actually read the link in the article to the BoM breakdown which was for the over-the-ear beats headphones!
Yes but the later post points out that the counterfeits are almost identical and that the genuine ones aren't any better. So this kind of contributes more to the original point that the "value is in the brand," (i.e. they suck but are expensive)
They have "beats" in really large letters so that everybody else in the gym can notice that you are wearing them which is the only reason you would buy such a ridiculous product as these to begin with. Unfortunately, having the beats headphones isn't going to provide the attention from the cute girls in the gym who are in better shape and not interested. You can't file a class action suit saying that the headphones didn't increase your sex appeal, though.
Ohio and/or Florida
Don't carry electronic devices with any data across the border. There's really no need to do so. Carry burner devices.
Well except that Google has already issued a patch going back to Android Marshmallow. But since it seems Apple never had the vulnerability this is +1 for Apple although I don't have any long-running statistics on security.
No, having the car stop and disable the "feature" permanently would have, however.
Well the software should know the speed limit and refuse to engage if you are even 1mph above it.