The codes are legally presented as something that only the owner of the physical disk can have.
Before or after the sale? (AFTER -- on the paper the code is printed on, which you can't read until you buy and unwrap the disc)
Can Redbox return the discs after they've opened them and learned that they can't resell the codes? (NO -- Once you open a DVD, you're no longer allowed to return it)
If you can't know the terms of the purchase before the purchase, for literally every non-IP product we know those terms don't apply. Why should IP be any different? What if the terms were "by keeping this product after opening it, you agree to give us 100% of your income for the remainder of your natural life"? Oh, and you can't return it once you've opened it... and you can't know that's a term of the sale until you open it... and you can't open it before you buy it.
I doubt the digital license was printed on the packaging below the offer so the consumer could decide they don't agree with it before making the purchase and unwrapping the product which can't be returned once opened. In other words, oops, you should make it clear on the packaging that the digital downloads are non-transferrable so I have the option of not buying it if I was going to buy with the intent of transferring the digital download; otherwise, tough titties if I do unless you're going to take the damn purchase back and return the full price I paid including any tax or shipping.
In short: If you're going to apply terms to the use of a purchased product, those terms had damned well be available to me in full on the packaging, in which case my purchase signifies an agreement to those terms, or you had damn well better offer me a full refund if I don't agree to terms you didn't provide to me before the sale.
Put another way, there are protections on basically everything non-IP product you buy that say the seller can't add terms to the sale after the sale has occurred -- why the fuck should IP be any different? And yes, applying terms I can't know until after the sale is applying them after the sale, even if I might know there are additional terms -- because I can't know what those additional terms are until I've read them or had them read to me. Simply saying "additional terms inside" doesn't suffice because, for example, I may be willing to accept "you may not use the software contained within on another device" while I may not accept "we reserve the right to shoot you in the face from the top of a neighboring building with a sniper rifle as you exit the store after buying this". Of course, that clause would never hold up in court anyway; it was an extreme example, but you get my point.
I know the Supreme Court has upheld shrinkwrap licenses, but anyone with any critical thinking ability whatsoever can see how that decision was wrong.
If your internal hostnames don't overlap with any public hostnames, you are not violating the standard. If you own the domain in question, you can guarantee that. What's the problem? Don't put *.dev.yourdomain.com in public END and you're golden.
Google, in this case, is wrong for assuming Chrome is connected to the internet and enforcing internet rules in-browser. There is no reason for that on, say, an air-gapped LAN, where Chrome will happily run.
Things like phone and messages I would expect to run in the background regardless, but I would also expect to see them using less than 1% battery if you haven't used them. Of course, I've never really looked at the IOS battery usage menu that closely, as my iPad all last days, with the one I use as a Chromecast remote lasting weeks between charges; does IOS not list the radios separately from the apps using them?
I do think you're right, though, that the OS ignores some of those settings, at least for it's own uses. In both IOS and Android, mind you, so that's not a dig at Apple. One place where Android gets it right, though... And it's ironic that it's a direct result of the fragmentation I keep hearing people complain about... The vendor can still choose to honor htose settings, because they can build from source after adding they I own support layers, which include their own versions of those settings. A double-edged sword, for sure, and usually used to crap-up the device, but I know the settings work on my S8+ because I actually see the impact they have on battery life.
proxy
präks/
noun
noun: proxy
1. the authority to represent someone else, especially in voting.
By definition, you can not proxy for yourself. If you own the proxies, the proxies are you and you gain no privacy through them; everything they do on your behalf, you are doing because you own them.
Or you're just a shit-tier troll. That actually makes more sense in this context, so I'd just roll with that explanation if I were you.
I was looking at this from the viewpoint of the people complaining that they can't use Chrome on their private.dev hosts without HTTPS, as though you were suggesting they use a different domain instead. Now that I see what you were getting at, you are right, but I'd like to point out that you can register domains for a lot less that $15/yr.
Even if you buy myinternaldomain.dev, Chrome will force HTTPS on it.
And really, it costs $0 to generate a new internal domain (source: dnsmasq, bind9, or any other DNS server you can self-host) and $0 per year to keep it. When you pay to register a domain, you're paying for the ability to make it publicly resolvable.
There's nothing wrong with using.com for internal machines, provided your internal hostnames don't overlap with your public hostnames. It's actually a common (I'd say standard) practice and would be fine with.dev as well if Google wasn't doing this (or if you don't use Chrome).
Indeed. The operating systems on these devices are simply performing too many undocumented and unwanted tasks to allow the CPUs and radios to ever enter a true idle or low power state. There is no reason, other than inefficient software, for a device to last less than several days with the screen off if, as we're constantly told, the screen is the biggest power draw.
It's only as big of a deal as a similar bug in Windows would be. I don't think either of us think it's that huge of a deal since it's easy to mitigate and anyone following best practices wouldn't have been affected to begin with. That said, you and I both know that most Mac users don't follow best practices as far as security is concerned; they bought their Mac precisely so they didn't have to be a sysadmin, so this is actually a pretty big deal for a lot of users and will remain so until those users apply the patch -- which might be never for those who turned off automatic updates and don't want to be sysadmins. Admittedly, that's a small number, but we both know it's not 0.
That bit about checking shipping status, by the way, 100% truthful. Brand new space gray MBP due in tomorrow.
I thought it required physical access, as well; then I read reports of people being able to access screen sharing and AFP shares using this method. I don't have a system running High Sierra to be able to verify those claims, but it seems plausible.
This just isn't a bug you accidentally introduce into a properly designed auth system. That means either someone was acting maliciously, or the system was designed with extreme incompetence. Since we're talking about Apple, I don't think many fanbois will accept the incompetence explanation, so we'll go with malice to avoid triggering them. Since they allow Apple to maliciously empty their wallets, they seem to be okay with malice...
...
... I write as I check the shipping status of my new MabCook Pro.
But, then, I'm a user, not a fanboi -- and I placed the order before this was made public.
Personally, and I do realize that I'm a sample size of 1 and statistically irrelevant, I find the charge speed of Samsung's wireless fast charger to be sufficient; and it doesn't make the phone super hot like every other Qi charger I've used. That charge rate is still (slightly) slower than a 12 watt wall wart, even when using a Samsung quick charger (which is required to get the thing into fast charge mode), so it cooks the battery even less than a cheap charging cable.
Of course, if I do need to charge while out and about, I try to avoid quick charging via cable.
7 months in and I haven't noticed any notable loss in battery capacity yet. Patience seems to pay off when dealing with Li-po.
Slashdot Mirror
The codes are legally presented as something that only the owner of the physical disk can have.
Before or after the sale? (AFTER -- on the paper the code is printed on, which you can't read until you buy and unwrap the disc)
Can Redbox return the discs after they've opened them and learned that they can't resell the codes? (NO -- Once you open a DVD, you're no longer allowed to return it)
If you can't know the terms of the purchase before the purchase, for literally every non-IP product we know those terms don't apply. Why should IP be any different? What if the terms were "by keeping this product after opening it, you agree to give us 100% of your income for the remainder of your natural life"? Oh, and you can't return it once you've opened it... and you can't know that's a term of the sale until you open it... and you can't open it before you buy it.
Nope. The Supreme Court agrees, too.
I doubt the digital license was printed on the packaging below the offer so the consumer could decide they don't agree with it before making the purchase and unwrapping the product which can't be returned once opened. In other words, oops, you should make it clear on the packaging that the digital downloads are non-transferrable so I have the option of not buying it if I was going to buy with the intent of transferring the digital download; otherwise, tough titties if I do unless you're going to take the damn purchase back and return the full price I paid including any tax or shipping.
In short: If you're going to apply terms to the use of a purchased product, those terms had damned well be available to me in full on the packaging, in which case my purchase signifies an agreement to those terms, or you had damn well better offer me a full refund if I don't agree to terms you didn't provide to me before the sale.
Put another way, there are protections on basically everything non-IP product you buy that say the seller can't add terms to the sale after the sale has occurred -- why the fuck should IP be any different? And yes, applying terms I can't know until after the sale is applying them after the sale, even if I might know there are additional terms -- because I can't know what those additional terms are until I've read them or had them read to me. Simply saying "additional terms inside" doesn't suffice because, for example, I may be willing to accept "you may not use the software contained within on another device" while I may not accept "we reserve the right to shoot you in the face from the top of a neighboring building with a sniper rifle as you exit the store after buying this". Of course, that clause would never hold up in court anyway; it was an extreme example, but you get my point.
I know the Supreme Court has upheld shrinkwrap licenses, but anyone with any critical thinking ability whatsoever can see how that decision was wrong.
I agree, but just to add, if you "own" the example.com, you can add pretty much any subdomain you want under it, e.g., thegibson.dev.example.com.
Bingo.
You care to link to a standards document that backs you up?
Autocorrect... END == DNS
If your internal hostnames don't overlap with any public hostnames, you are not violating the standard. If you own the domain in question, you can guarantee that. What's the problem? Don't put *.dev.yourdomain.com in public END and you're golden.
Google, in this case, is wrong for assuming Chrome is connected to the internet and enforcing internet rules in-browser. There is no reason for that on, say, an air-gapped LAN, where Chrome will happily run.
Things like phone and messages I would expect to run in the background regardless, but I would also expect to see them using less than 1% battery if you haven't used them. Of course, I've never really looked at the IOS battery usage menu that closely, as my iPad all last days, with the one I use as a Chromecast remote lasting weeks between charges; does IOS not list the radios separately from the apps using them?
I do think you're right, though, that the OS ignores some of those settings, at least for it's own uses. In both IOS and Android, mind you, so that's not a dig at Apple. One place where Android gets it right, though... And it's ironic that it's a direct result of the fragmentation I keep hearing people complain about... The vendor can still choose to honor htose settings, because they can build from source after adding they I own support layers, which include their own versions of those settings. A double-edged sword, for sure, and usually used to crap-up the device, but I know the settings work on my S8+ because I actually see the impact they have on battery life.
I can't speak for the AC, but I'd be down to experiment with a pile of motherboards and a power drill if someone else is buying.
And I have met my proxy provider, and I am he.
I don't think that means what you think it means
proxy
präks/
noun
noun: proxy
1. the authority to represent someone else, especially in voting.
By definition, you can not proxy for yourself. If you own the proxies, the proxies are you and you gain no privacy through them; everything they do on your behalf, you are doing because you own them.
Or you're just a shit-tier troll. That actually makes more sense in this context, so I'd just roll with that explanation if I were you.
I was looking at this from the viewpoint of the people complaining that they can't use Chrome on their private .dev hosts without HTTPS, as though you were suggesting they use a different domain instead. Now that I see what you were getting at, you are right, but I'd like to point out that you can register domains for a lot less that $15/yr.
But it does require you to enter the password of a user authorized to unlock the disk. You did enable FileVault, right?
I only mind whether the can tie the connections to me and aggregate and/or sell data.
Why do you care? And what makes you think your proxy provider isn't doing just that?
The thing is, even if you do own the .dev domain you're using, Chrome is going to force the use of HTTPS on it. That's the real problem, here.
There's nothing stopping your browser from establishing a new connection/session for each request. Follow?
Even if you buy myinternaldomain.dev, Chrome will force HTTPS on it.
And really, it costs $0 to generate a new internal domain (source: dnsmasq, bind9, or any other DNS server you can self-host) and $0 per year to keep it. When you pay to register a domain, you're paying for the ability to make it publicly resolvable.
Established at connection time = different for each connection = not persistent = not a viable method of tracking. Follow?
There's nothing wrong with using .com for internal machines, provided your internal hostnames don't overlap with your public hostnames. It's actually a common (I'd say standard) practice and would be fine with .dev as well if Google wasn't doing this (or if you don't use Chrome).
Before you take it in, put 20v through the flash chips on the soldered-in SSD. You do have backups, right?
Sad thing is, I'm not sure he was trolling in my case.
Indeed. The operating systems on these devices are simply performing too many undocumented and unwanted tasks to allow the CPUs and radios to ever enter a true idle or low power state. There is no reason, other than inefficient software, for a device to last less than several days with the screen off if, as we're constantly told, the screen is the biggest power draw.
It's only as big of a deal as a similar bug in Windows would be. I don't think either of us think it's that huge of a deal since it's easy to mitigate and anyone following best practices wouldn't have been affected to begin with. That said, you and I both know that most Mac users don't follow best practices as far as security is concerned; they bought their Mac precisely so they didn't have to be a sysadmin, so this is actually a pretty big deal for a lot of users and will remain so until those users apply the patch -- which might be never for those who turned off automatic updates and don't want to be sysadmins. Admittedly, that's a small number, but we both know it's not 0.
That bit about checking shipping status, by the way, 100% truthful. Brand new space gray MBP due in tomorrow.
Oh hahaha I assure you that was a typo. I would never purposely honor Tim Cook in that way.
Very unintentional, as is most of my best material... I'll file that one away for later use, though; thanks for pointing it out.
I thought it required physical access, as well; then I read reports of people being able to access screen sharing and AFP shares using this method. I don't have a system running High Sierra to be able to verify those claims, but it seems plausible.
...
... I write as I check the shipping status of my new MabCook Pro.
This just isn't a bug you accidentally introduce into a properly designed auth system. That means either someone was acting maliciously, or the system was designed with extreme incompetence. Since we're talking about Apple, I don't think many fanbois will accept the incompetence explanation, so we'll go with malice to avoid triggering them. Since they allow Apple to maliciously empty their wallets, they seem to be okay with malice...
But, then, I'm a user, not a fanboi -- and I placed the order before this was made public.
Personally, and I do realize that I'm a sample size of 1 and statistically irrelevant, I find the charge speed of Samsung's wireless fast charger to be sufficient; and it doesn't make the phone super hot like every other Qi charger I've used. That charge rate is still (slightly) slower than a 12 watt wall wart, even when using a Samsung quick charger (which is required to get the thing into fast charge mode), so it cooks the battery even less than a cheap charging cable.
Of course, if I do need to charge while out and about, I try to avoid quick charging via cable.
7 months in and I haven't noticed any notable loss in battery capacity yet. Patience seems to pay off when dealing with Li-po.