What you were replying to was "For cases like this something like Arm&Hammer should be approved for oral ingestion and shouldn't carry any additional liability." That was the context in which I was replying, as well. What the fuck does injecting shit have to do with oral ingestion? Nada.
Maybe Arm & Hammer is fine, and maybe it will kill 90% of patients when administered internally.
Go look at a few cake recipes. Does cake kill 90% of people who eat it? Cake contains baking soda and we aren't reading reports of cake related deaths, so I'm gonna go out on a limb and just guess the former is more likely than the latter.
By definition, reagent grade must be absolutely pure. You can't get more pure than reagent grade, you can only label it differently and charge more for it, which is what pharmaceutical grade really means.
You've worked for a lot of companies, haven't you? I mean short stints with security escorts out of the building shortly after your logins stop working.
I never said most of those events were over a decade ago, I said all of the events were spread over 17 years of phone ownership. Assuming roughly equal timing between events, that puts roughly 60% of them in the past decade; and that's being generous to your position as, if anything, I've become clumsier as I've aged, but I still climb those ladders.
Also, the screens have always been glass, though they've often been stuck behind a layer of plastic. And do you really think I've never dropped a phone on its corner in 17 years of phone ownership (a decade of which has been glass-front smartphones)?
As for your explanation of why running the phone over twice didn't kill it, recall that it was in a puddle as well.
Hell, I had one fall out of my pocket getting into the car and get driven over twice, once when I backed out, and again when I pulled back into the parking spot when I realized it wasn't in my pocket and thought I had left it inside. It was in a puddle when this happened.
Running it over would have applied external pressure, squeezing air out and drawing water in when that pressure was relieved. Twice. And this was well before IP68 compliance was a line item on a phone's feature list, not that IP68 specifications make any mention of that type of potential water ingress in the first place (they don't).
But yeah, these phones are so damn fragile they just explode into hundreds of pieces if you look at them wrong. Riiiiiiiiiiiiiiight...
Sure, some people have bad luck. A friend of mine, for example, had one fall about a foot and a half onto commercial (e.g. thin and unpadded) carpet and shatter. But that is such an exceedingly rare occurrence and likely had more to do with a hairline crack he hadn't noticed, or some other defect in the phone's screen, than it did with how the phone landed. If such breakage were actually a common occurrence, I'm certain I'd have broken at least one of them by now.
So, when a free software zealot tells him he should use Libre Office instead of Microsoft Office, he's supposed to just smile and keep his mouth shut? Yes, I know that's not what happened in this case, but it is what happens often enough to warrant heading it off before it does, which is what happened here.
An eternal game of catch up means you are always behind and have partially implemented systems that suck in comparison to the original.
You needn't implement every feature, but you absolutely must implement the features your intended userbase needs. If you lack those features, then you must not pester people who need them when they choose a different product.
It's far better to innovate and make something that it better and let closed source software try to catch up with you.
Once you have the features your intended userbase needs, yes, I agree, it is better to differentiate yourself by coming up with our own unique feature set on top of those required features, rather than piecemeal copying the competition. What's missing, here, is those required features. In the form of a car analogy, it is useless to make a car that can accelerate from 0 to 60 in a tenth of a second, but not implement the all-importante feature we call braking; nobody would buy such a car -- in fact, you couldn't even legally sell it -- and nobody would wonder why. Why is that so hard to understand when applied to free software? I emphasized free because the closed software community seems to understand that people will only use your shit if it does what they need, while many open projects miss this point entirely.
Generalizations like this are easily proven false.
I used a qualifier: seriously. Nobody serious puts the ability to view the source code over the actual functionality of the software; if it can't do what is needed and can't trivially be made to do what is needed, it is useless. If it is open and does what is needed, all the better, but openness does not trump functionality. If you can do without interoperability with the larger business world, you are, by definition, not a serious user.
No, they do something similar but it's very different and everything that works great isn't compatible with Windows' proprietary shit. This proves my point, not yours.
By your account, Apache must not work that well, as it is compatible with proprietary Windows technologies; it can serve ActiveX controls and.Net code with no issues whatsoever. Apache does the very same thing IIS does; many other open source projects mimic their closed source counterparts and a large number of those projects do so more reliable and securely than the closed source "originals". You think you've proved your own point here, but the reality is that you've simply missed mine.
Where it falls apart is where it's playing catch up with Windows. This proves my point yet again.
What is the open-source replacement for Active Directory that can work across all popular platforms? That's not playing catch up with Windows, that providing functionality that is absolutely necessary to any large computer installation with a dynamic userbase. I'm still not sure what your point is, but you're far from proving it.
If Windows suddenly became better then it wouldn't be a Microsoft product, so I wouldn't hold your breath.
I'm not even sure how to classify that argument, but it appears to contain more snark than substance and, again, completely misses the point. Like most free software zealots, you're good at that but not very good at getting actual work done. Mind you, I'm not saying that free software can't be used to get a
Sufficiently-privileged malware could install its own key in the scanner when the device is unlocked, providing a way to remotely obtain a copy of the user's fingerprint.
This statement represents a fundamental misunderstanding in how the fingerprint scanner on the iPhone (and, indeed, those found in current model Android devices) works. As such, I stopped reading here.
The sensor sends fingerprint data to the secure storage processor, which then calculates a hash and either stores it (if in storage mode) or compares it to stored hashes (if in authentication mode). The finger print itself is never stored and the hash that is stored is not the value sent to the chip for authentication. That is, even if you were able to read the hash values from that chip (hint: you're not without physical access and a bunch of other, much more unlikely, occurrences), you couldn't use them to unlock the phone so, no, you're not getting a copy of the user's fingerprint that way. At best, you'd get a hash that you could install in your own device to allow that user to use their fingerprint to unlock your device; in reality, you wouldn't even get that.
But, even that ignores the fact that the storage processor (secure enclave in the case of the iPhone) does not exchange authentication data with the device via software. The processor receives commands via pins which share a common bus with the CPU, but not data; this allows the device to set the mode of the processor (list, store, compare, delete, etc) and to receive a result ("list" might return "fingerprint 1, fingerprint 2" to indicate that there are two fingerprint hashes stored, "store" might return "true" to indicate that the new hash was successfully stored, "compare" might return "false" to indicate that no match was found, and "delete" might return "success" to indicate that a hash was successfully deleted), but the communication between the fingerprint scanner and the processor is direct; the processor only receives the fingerprint image from the scanner itself. The same would apply to the pairing key; a "rekey" command could be added (in fact, one must already exist as Apple can already do this in their own facilities), which would cause the processor to prompt the scanner for its key and output a result via the CPU bus.
Yes, I suppose an attacker could inject that command onto the bus and set the storage processor into "rekey" mode. However, my proposal wouldn't make that any more likely as, again, such a command must already exist for Apple to be able to pair new fingerprint scanners (which then can do) or, in fact, to perform the initial pairing (which nobody can dispute they actually do). That must mean it is either sufficiently difficult to do this, or that Apple has taken sufficient security precautions to prevent it.
Ok, I lied, I actually did continue reading after I wrote the above, then I stumbled across this gem:
This isn't quite as secure against local compromise as Apple's, because in Apple's the attacker would need to extract the secret from the scanner of every device they wish to unlock, which is expensive
Local attack is precisely what Apple's design (which predates Apple's us of such a design, by the way) is intended to protect against. Making it less secure against that is not an option.
TL;DR: The functionality already exists, Apple routinely uses is in the initial manufacturing process, as well as the repair process, and it's literally just a matter of them exposing it to the end user in a sane manner. Remote attacks aren't possible as they cannot replace the physical hardware that provides the key once "rekey" mode is entered and local attacks won't be any more likely if this feature exists because, well, it already exists and we aren't hearing about local attacks.
And yes, Apple does have this capability. You can go to an Apple store with a cracked screen and home button and, if your store has a repair facility (many do), they will replace the screen and home button right there, on the spot. If your store lacks a repair facility, they replace the phone, and I've seen it handled both ways, but they most certainly can re-key the secure enclave.
It sounds to me like he did pay for it to be implemented. He bought Office.
If open source wants to seriously compete with closed software, they need to do everything closed software does, better than closed source, and they need to be compatible with that same closed software while doing it.
Case in point, Linux and BSD in server environments. Nobody seriously uses over Linux or BSD over Windows on their servers because it's free, we use them because they do the same things and they do them better. Where that falls apart (running as an AD DC for newer versions of Windows, as a singular example), we use Windows because we need it to work.
Sure, you can tell me about all of your friends who run Linux on the desktop and, well, they're developers and fairly well paid ones at that. Sure, and I can point out they they're either employed by someone else or doing very small-time contract work where they don't necessarily have to interact with many proprietary systems. Kudos to them for being able to make their living that way, but if their choice of tools is based solely on freedom, sacrificing effectiveness and efficiency, they're not serious.
TL;DR: If Windows suddenly became better at running servers than Linux or BSD distros, there would suddenly be a whole lot more Windows servers out there. Oh, and the guy you're bitching at did pay for the features he wanted.
As a programmer, when my wife needed a simple way to track sales for her print business, I gave her an Excel spreadsheet with a few macros.
By taking that shortcut (and using the access management facilities which already exist in Office) I was able to avoid building an entire I/O interface complete with entry forms and reports, didn't have to worry about infrastructure or what the database should look like, and could skip right over authentication. For what amounts to a single user system, it actually makes perfect sense.
This was done done during my workday, it took me about 2 hours; I could have spent a week, full-time, developing the database, implementing a secure authentication system, designing and implementing the forms, designing and implementing the reports, and tweaking all of that until it made sense to the end user, an it would have cost between $2600 and $6000 depending on which client(s) I was setting aside in order to get that done. In the end, I worked two hours extra the day I did it, so it didn't cost me anything; but there's no way I would have put in an extra 40 for that.
Now, when someone's paying me they're gonna get the whole enchilada, because that's what they're paying me for... and because I can bill for it. But, even then there are times when they tell me it's for one person, or one event, or some other single-use reason, and they don't want to pay for it -- I point out how the work may be useful in the future and, when they can show me that it won't be, they get an Office "application" if that's what they're after.
Sometimes the right tool for the job is the tool that can do the job quickly, cheaply, and without requiring a bunch of other tools.
Not my misunderstanding, no, but my mistake in assuming you could follow a conversation.
After all, I did say:
If they sold schematics, tools, and parts -- all of which these techs are getting their hands on regardless -- they'd get money from that. It would be a net win all around.
If I thought Apple was selling them parts, why would I have suggest Apple could make more money by selling them parts?
Once again, my point is that they're getting tools, parts, and schematics regardless of Apple.
To recap our conversation thus far, since you apparently don't know how to click your way up the comment tree and read it yourself: Your argument to the above was that it would hurt Apple's repair side if the big box stores were allowed to do Apple repairs, which I replied to by showing you that those stores (the ones which do repair, at least) already do. You then (incorrectly) pointed out that you can't do these repairs unless you're approved by Apple, which I responded to by making mention of the large community of 3rd party repair facilities that do, in fact, exist. Your response was to imply that those 3rd party repair facilities must be Apple approved; my response was to prove that false.
And here we are, back to you completely forgetting the point, Chad... Creative. I see you converse like you maintain websites -- poorly. Your wide experience really does show in everything you do; it just doesn't show you in the best light.
Hello? 16 foot from from a ladder onto concrete? Thrown through drywall? Through a car window? Yeah......... you ignored all the instances that meet your "will easily break" criteria.
No... they're not. That's just one example, in no way affiliated with Apple and in no way unique. Did you really think I was talking about authorized repair partners?
Except that yes, you can get the parts. And the tools. And the schematics. Plenty of 3rd party repair shops do these repairs in a daily basis. You have to be willfully ignorant of this fact in order to believe otherwise; please, don't be willfully ignorant.
This guy's all over the place... First he suggests the FCC might buy the patent for $10B (non-negotiable, because eminent domain), then he suggests that it's worth more than that if Apple might want to foot the bill. I suggest that if, as in this case, a patent is being weaponized, that it is in everyone's best interest for the government to take ownership of that patent and freely license it, or to simply invalidate the patent as an abuse of the system.
Patents are intended to protect inventions, not to allow you to collect royalties on top of the sale of those inventions. If this were about Qualcomm chasing royalties for Apple's use of Intel chips implementing Qualcomm technologies (in which case they'd have to be chasing Intel, as they're the ones implementing and selling those technologies), that would fall under the purview of a patent. But it's not; it's about collecting royalties from someone who already paid them when they bought the parts directly from Qualcomm. That's weaponization and should be grounds for immediate invalidation without prejudice.
You know how much easier it would be to enforce legitimate patents applied in a legitimate manner if we didn't allow so many abuses? It would boil down to:
- Does this case look like one of the obvious abuses? (IF YES, Invalidate the patent for abuse, throw out the case based on lack of applicable valid patent)
- Is the defendant using the claimant's technology? (IF NO: Throw out the case for no grounds)
- Did the defendant buy the technology, whether from the patent holder or a 3rd party? (IF YES: Throw out the case for no grounds; if a 3rd party seller violates a patent, that seller, not the buyer, is responsible for that, go try to sue *them*)
- Did the defendant pay royalties already? (IF YES: Throw out the case for no grounds)
- If the above tests all pass and we get to this rule, then we hear the case to determine how much the defendant should owe.
While that's an over-simplification of the issue, it's only a slight over-simplification. There are a handful of edge cases to add to that, but the tests for whether the case should even be heard in the first place really are simple.
More people care about smartphones and the laws that apply to smartphones would apply to tractors. Shut up and let the larger group throw their weight around for your benefit.
Further, it can't be too easy to pair a different scanner because then the attacker could just do that.
So only allow pairing a new scanner when the device is unlocked. Install a new scanner? PIN/password unlock, enter the service menu (which shouldn't be accessible on a locked device in the first place) and select "Pair Fingerprint Scanner".
If the reason for not allowing it is so that someone can't use an altered or imposter scanner to unlock the device, requiring the user to be able to unlock the device first is sufficient security, as it proves that... well... the user can unlock the device. Preventing a user who can unlock the device already from pairing a new scanner doesn't prevent that user from unlocking the device... because... that... user... can... already... unlock... the... device...
While the first part of your statement is correct, the second part is pretty far off base. They already have the repair guides, they distribute them to their authorized repair techs.
And nobody's asking for it for free, we're willing to pay.
Slashdot Mirror
Huh, I always thought reagent stock had to be exceptionally pure to avoid side reactions. Really interesting to learn that this is not the case.
There's probably a reason I didn't get into chemistry in any real capacity.
What you were replying to was "For cases like this something like Arm&Hammer should be approved for oral ingestion and shouldn't carry any additional liability." That was the context in which I was replying, as well. What the fuck does injecting shit have to do with oral ingestion? Nada.
It doesn't have to do everything proprietary software does, just the stuff people want to do.
Like, oh my God, that's like, totally the point I was like trying to make and junk. Like, totally!</valleygirl>
But, seriously, I've made that point twice in this thread, in as many posts.
Interesting. Any good references for this information?
Someone with mod points, please mod my earlier comment down so it doesn't spread misinformation.
Maybe Arm & Hammer is fine, and maybe it will kill 90% of patients when administered internally.
Go look at a few cake recipes. Does cake kill 90% of people who eat it? Cake contains baking soda and we aren't reading reports of cake related deaths, so I'm gonna go out on a limb and just guess the former is more likely than the latter.
By definition, reagent grade must be absolutely pure. You can't get more pure than reagent grade, you can only label it differently and charge more for it, which is what pharmaceutical grade really means.
You've worked for a lot of companies, haven't you? I mean short stints with security escorts out of the building shortly after your logins stop working.
True, I haven't thrown a phone through a wall or a windows in over a decade, but... car windows aren't very hard?
Also, the screens have always been glass, though they've often been stuck behind a layer of plastic. And do you really think I've never dropped a phone on its corner in 17 years of phone ownership (a decade of which has been glass-front smartphones)?
As for your explanation of why running the phone over twice didn't kill it, recall that it was in a puddle as well.
Hell, I had one fall out of my pocket getting into the car and get driven over twice, once when I backed out, and again when I pulled back into the parking spot when I realized it wasn't in my pocket and thought I had left it inside. It was in a puddle when this happened.
Running it over would have applied external pressure, squeezing air out and drawing water in when that pressure was relieved. Twice. And this was well before IP68 compliance was a line item on a phone's feature list, not that IP68 specifications make any mention of that type of potential water ingress in the first place (they don't).
But yeah, these phones are so damn fragile they just explode into hundreds of pieces if you look at them wrong. Riiiiiiiiiiiiiiight...
Sure, some people have bad luck. A friend of mine, for example, had one fall about a foot and a half onto commercial (e.g. thin and unpadded) carpet and shatter. But that is such an exceedingly rare occurrence and likely had more to do with a hairline crack he hadn't noticed, or some other defect in the phone's screen, than it did with how the phone landed. If such breakage were actually a common occurrence, I'm certain I'd have broken at least one of them by now.
Then he has no need to drone on about it.
So, when a free software zealot tells him he should use Libre Office instead of Microsoft Office, he's supposed to just smile and keep his mouth shut? Yes, I know that's not what happened in this case, but it is what happens often enough to warrant heading it off before it does, which is what happened here.
An eternal game of catch up means you are always behind and have partially implemented systems that suck in comparison to the original.
You needn't implement every feature, but you absolutely must implement the features your intended userbase needs. If you lack those features, then you must not pester people who need them when they choose a different product.
It's far better to innovate and make something that it better and let closed source software try to catch up with you.
Once you have the features your intended userbase needs, yes, I agree, it is better to differentiate yourself by coming up with our own unique feature set on top of those required features, rather than piecemeal copying the competition. What's missing, here, is those required features. In the form of a car analogy, it is useless to make a car that can accelerate from 0 to 60 in a tenth of a second, but not implement the all-importante feature we call braking; nobody would buy such a car -- in fact, you couldn't even legally sell it -- and nobody would wonder why. Why is that so hard to understand when applied to free software? I emphasized free because the closed software community seems to understand that people will only use your shit if it does what they need, while many open projects miss this point entirely.
Generalizations like this are easily proven false.
I used a qualifier: seriously. Nobody serious puts the ability to view the source code over the actual functionality of the software; if it can't do what is needed and can't trivially be made to do what is needed, it is useless. If it is open and does what is needed, all the better, but openness does not trump functionality. If you can do without interoperability with the larger business world, you are, by definition, not a serious user.
No, they do something similar but it's very different and everything that works great isn't compatible with Windows' proprietary shit. This proves my point, not yours.
By your account, Apache must not work that well, as it is compatible with proprietary Windows technologies; it can serve ActiveX controls and .Net code with no issues whatsoever. Apache does the very same thing IIS does; many other open source projects mimic their closed source counterparts and a large number of those projects do so more reliable and securely than the closed source "originals". You think you've proved your own point here, but the reality is that you've simply missed mine.
Where it falls apart is where it's playing catch up with Windows. This proves my point yet again.
What is the open-source replacement for Active Directory that can work across all popular platforms? That's not playing catch up with Windows, that providing functionality that is absolutely necessary to any large computer installation with a dynamic userbase. I'm still not sure what your point is, but you're far from proving it.
If Windows suddenly became better then it wouldn't be a Microsoft product, so I wouldn't hold your breath.
I'm not even sure how to classify that argument, but it appears to contain more snark than substance and, again, completely misses the point. Like most free software zealots, you're good at that but not very good at getting actual work done. Mind you, I'm not saying that free software can't be used to get a
Sufficiently-privileged malware could install its own key in the scanner when the device is unlocked, providing a way to remotely obtain a copy of the user's fingerprint.
This statement represents a fundamental misunderstanding in how the fingerprint scanner on the iPhone (and, indeed, those found in current model Android devices) works. As such, I stopped reading here.
The sensor sends fingerprint data to the secure storage processor, which then calculates a hash and either stores it (if in storage mode) or compares it to stored hashes (if in authentication mode). The finger print itself is never stored and the hash that is stored is not the value sent to the chip for authentication. That is, even if you were able to read the hash values from that chip (hint: you're not without physical access and a bunch of other, much more unlikely, occurrences), you couldn't use them to unlock the phone so, no, you're not getting a copy of the user's fingerprint that way. At best, you'd get a hash that you could install in your own device to allow that user to use their fingerprint to unlock your device; in reality, you wouldn't even get that.
But, even that ignores the fact that the storage processor (secure enclave in the case of the iPhone) does not exchange authentication data with the device via software. The processor receives commands via pins which share a common bus with the CPU, but not data; this allows the device to set the mode of the processor (list, store, compare, delete, etc) and to receive a result ("list" might return "fingerprint 1, fingerprint 2" to indicate that there are two fingerprint hashes stored, "store" might return "true" to indicate that the new hash was successfully stored, "compare" might return "false" to indicate that no match was found, and "delete" might return "success" to indicate that a hash was successfully deleted), but the communication between the fingerprint scanner and the processor is direct; the processor only receives the fingerprint image from the scanner itself. The same would apply to the pairing key; a "rekey" command could be added (in fact, one must already exist as Apple can already do this in their own facilities), which would cause the processor to prompt the scanner for its key and output a result via the CPU bus.
Yes, I suppose an attacker could inject that command onto the bus and set the storage processor into "rekey" mode. However, my proposal wouldn't make that any more likely as, again, such a command must already exist for Apple to be able to pair new fingerprint scanners (which then can do) or, in fact, to perform the initial pairing (which nobody can dispute they actually do). That must mean it is either sufficiently difficult to do this, or that Apple has taken sufficient security precautions to prevent it.
Ok, I lied, I actually did continue reading after I wrote the above, then I stumbled across this gem:
This isn't quite as secure against local compromise as Apple's, because in Apple's the attacker would need to extract the secret from the scanner of every device they wish to unlock, which is expensive
Local attack is precisely what Apple's design (which predates Apple's us of such a design, by the way) is intended to protect against. Making it less secure against that is not an option. TL;DR: The functionality already exists, Apple routinely uses is in the initial manufacturing process, as well as the repair process, and it's literally just a matter of them exposing it to the end user in a sane manner. Remote attacks aren't possible as they cannot replace the physical hardware that provides the key once "rekey" mode is entered and local attacks won't be any more likely if this feature exists because, well, it already exists and we aren't hearing about local attacks.
And yes, Apple does have this capability. You can go to an Apple store with a cracked screen and home button and, if your store has a repair facility (many do), they will replace the screen and home button right there, on the spot. If your store lacks a repair facility, they replace the phone, and I've seen it handled both ways, but they most certainly can re-key the secure enclave.
What do the executives use? You know... the relevant office, as far as business is concerned.
It sounds to me like he did pay for it to be implemented. He bought Office.
If open source wants to seriously compete with closed software, they need to do everything closed software does, better than closed source, and they need to be compatible with that same closed software while doing it.
Case in point, Linux and BSD in server environments. Nobody seriously uses over Linux or BSD over Windows on their servers because it's free, we use them because they do the same things and they do them better. Where that falls apart (running as an AD DC for newer versions of Windows, as a singular example), we use Windows because we need it to work.
Sure, you can tell me about all of your friends who run Linux on the desktop and, well, they're developers and fairly well paid ones at that. Sure, and I can point out they they're either employed by someone else or doing very small-time contract work where they don't necessarily have to interact with many proprietary systems. Kudos to them for being able to make their living that way, but if their choice of tools is based solely on freedom, sacrificing effectiveness and efficiency, they're not serious.
TL;DR: If Windows suddenly became better at running servers than Linux or BSD distros, there would suddenly be a whole lot more Windows servers out there. Oh, and the guy you're bitching at did pay for the features he wanted.
As a programmer, when my wife needed a simple way to track sales for her print business, I gave her an Excel spreadsheet with a few macros.
By taking that shortcut (and using the access management facilities which already exist in Office) I was able to avoid building an entire I/O interface complete with entry forms and reports, didn't have to worry about infrastructure or what the database should look like, and could skip right over authentication. For what amounts to a single user system, it actually makes perfect sense.
This was done done during my workday, it took me about 2 hours; I could have spent a week, full-time, developing the database, implementing a secure authentication system, designing and implementing the forms, designing and implementing the reports, and tweaking all of that until it made sense to the end user, an it would have cost between $2600 and $6000 depending on which client(s) I was setting aside in order to get that done. In the end, I worked two hours extra the day I did it, so it didn't cost me anything; but there's no way I would have put in an extra 40 for that.
Now, when someone's paying me they're gonna get the whole enchilada, because that's what they're paying me for... and because I can bill for it. But, even then there are times when they tell me it's for one person, or one event, or some other single-use reason, and they don't want to pay for it -- I point out how the work may be useful in the future and, when they can show me that it won't be, they get an Office "application" if that's what they're after.
Sometimes the right tool for the job is the tool that can do the job quickly, cheaply, and without requiring a bunch of other tools.
Not my misunderstanding, no, but my mistake in assuming you could follow a conversation.
After all, I did say:
If they sold schematics, tools, and parts -- all of which these techs are getting their hands on regardless -- they'd get money from that. It would be a net win all around.
If I thought Apple was selling them parts, why would I have suggest Apple could make more money by selling them parts?
Once again, my point is that they're getting tools, parts, and schematics regardless of Apple.
To recap our conversation thus far, since you apparently don't know how to click your way up the comment tree and read it yourself: Your argument to the above was that it would hurt Apple's repair side if the big box stores were allowed to do Apple repairs, which I replied to by showing you that those stores (the ones which do repair, at least) already do. You then (incorrectly) pointed out that you can't do these repairs unless you're approved by Apple, which I responded to by making mention of the large community of 3rd party repair facilities that do, in fact, exist. Your response was to imply that those 3rd party repair facilities must be Apple approved; my response was to prove that false.
And here we are, back to you completely forgetting the point, Chad... Creative. I see you converse like you maintain websites -- poorly. Your wide experience really does show in everything you do; it just doesn't show you in the best light.
Yet a 16 foot drop onto concrete does nothing.
And do you really think I've never dropped a phone as you describe in 17 years?
It's in a thread about how "easy" it is to break a phone. I was demonstrating otherwise.
Hello? 16 foot from from a ladder onto concrete? Thrown through drywall? Through a car window? Yeah......... you ignored all the instances that meet your "will easily break" criteria.
Oh, and before you try to claim that Rossmann Group is an Apple Authorized Repair Partner... No.
No... they're not. That's just one example, in no way affiliated with Apple and in no way unique. Did you really think I was talking about authorized repair partners?
Except that yes, you can get the parts. And the tools. And the schematics. Plenty of 3rd party repair shops do these repairs in a daily basis. You have to be willfully ignorant of this fact in order to believe otherwise; please, don't be willfully ignorant.
The big name stores are already authorized repair facilities, so your argument isn't holding a whole lot of water.
Yes, I only linked to Best Buy... which other big name store still does repair?
This guy's all over the place... First he suggests the FCC might buy the patent for $10B (non-negotiable, because eminent domain), then he suggests that it's worth more than that if Apple might want to foot the bill. I suggest that if, as in this case, a patent is being weaponized, that it is in everyone's best interest for the government to take ownership of that patent and freely license it, or to simply invalidate the patent as an abuse of the system.
Patents are intended to protect inventions, not to allow you to collect royalties on top of the sale of those inventions. If this were about Qualcomm chasing royalties for Apple's use of Intel chips implementing Qualcomm technologies (in which case they'd have to be chasing Intel, as they're the ones implementing and selling those technologies), that would fall under the purview of a patent. But it's not; it's about collecting royalties from someone who already paid them when they bought the parts directly from Qualcomm. That's weaponization and should be grounds for immediate invalidation without prejudice.
You know how much easier it would be to enforce legitimate patents applied in a legitimate manner if we didn't allow so many abuses? It would boil down to:
- Does this case look like one of the obvious abuses? (IF YES, Invalidate the patent for abuse, throw out the case based on lack of applicable valid patent)
- Is the defendant using the claimant's technology? (IF NO: Throw out the case for no grounds)
- Did the defendant buy the technology, whether from the patent holder or a 3rd party? (IF YES: Throw out the case for no grounds; if a 3rd party seller violates a patent, that seller, not the buyer, is responsible for that, go try to sue *them*)
- Did the defendant pay royalties already? (IF YES: Throw out the case for no grounds)
- If the above tests all pass and we get to this rule, then we hear the case to determine how much the defendant should owe.
While that's an over-simplification of the issue, it's only a slight over-simplification. There are a handful of edge cases to add to that, but the tests for whether the case should even be heard in the first place really are simple.
More people care about smartphones and the laws that apply to smartphones would apply to tractors. Shut up and let the larger group throw their weight around for your benefit.
Further, it can't be too easy to pair a different scanner because then the attacker could just do that.
So only allow pairing a new scanner when the device is unlocked. Install a new scanner? PIN/password unlock, enter the service menu (which shouldn't be accessible on a locked device in the first place) and select "Pair Fingerprint Scanner".
If the reason for not allowing it is so that someone can't use an altered or imposter scanner to unlock the device, requiring the user to be able to unlock the device first is sufficient security, as it proves that... well... the user can unlock the device. Preventing a user who can unlock the device already from pairing a new scanner doesn't prevent that user from unlocking the device... because... that... user... can... already... unlock... the... device...
While the first part of your statement is correct, the second part is pretty far off base. They already have the repair guides, they distribute them to their authorized repair techs.
And nobody's asking for it for free, we're willing to pay.