Although fiber is the necessary infrastructure for every policy goal we have -- advanced healthcare, the emergence of new forms of industries, a chance for every child to get an education, managed use of energy, and on and on
No. Maybe faster internet is necessary infrastructure for those things. Maybe not. There are enough other comments exploring the truth of that assertion.
But fiber is just one possible medium for delivering faster internet. Believe it or not, I get incredibly fast internet (500/100 Mbps) over coaxial cable. I used to get 200/200 over microwave. Both of them were affordable ($60 for the super premium plan).
Also, at least in the United States, the use of coal for power generation is dropping significantly due to the lower cost of natural gas power plants and wind (regardless of what the politicians do). What this means is that the efficiency of EVs is increasing as coal usage drops since natural gas power plants tend to be more efficient and release around half the CO2 of an equivalent coal plant.
And the lower cost of natural gas is itself largely due to advances in hydraulic fracking. But mention that fracking is driving a huge net reduction in greenhouse gases and watch the more emotional (and less scientific) wing of the environmental movement start to spin around itself a bit.
First off, I think you mean conceited, not conceded.
And I think the point was that I was admitted forthrightly that, in the areas in which I have expertise, I also have strong opinions that make me non-neutral. In fact, it seems almost inevitable that anyone with significant experience in some domain would have to have generated some thoughts and opinions about it.
There's a subtle distinction here that's often lost - I see it muddled together a few places in TFA and also in the comments -- between the right to repair a device and the right to demand (?) redesign of a device in a way that makes repair easier.
The former seems quite reasonable, and the auto manufacturers got it done so that dispels the feasibility complaints, even for technology-stuffed modern cars. But I don't see MA (or anyone else) going so far as to say that car manufacturers should be required ex-ante to change the way cars are designed, built and assembled.
For electronic devices, however, there seem like there are real engineering tradeoffs between repairability and legitimate design goals such as parts cost, assembly cost, weight and size. Replacing all the glue holding a tablet together with screws might improve repairability while adding $0.14 to the cost and a few grams to the weight. A removable battery might be the same cost but add 3mm to the thickness. In some cases, it might be heuristically worth it, but I struggle in vain for any intellectually sound way to make those things commensurable.
And as an engineer, I surely shudder in fear of someone with no domain expertise in a problem that I spent years solving second-guessing my tradeoffs. Especially since they have no accountability to produce a workable design that can be actually shipped on time. At the same time, I recognize that the engineers with domain expertise are hardly neutral deciders of what tradeoffs are legitimate and which design elements serve no purpose other than to impede repairs.
So there I have it -- I don't see a scientific way to judge whether it's worth it and my choices for who to ask is either someone impartial with no idea of the specifics or someone that knows but has no incentive to impartiality.
[ Actually, the latter is kind of a pervasive problem. You can have folks with a ton of experience, or you can have folks that are neutral with no preconceived biases. But you can rarely have the same person with both. ]
So, to nit-pick a bit, does the Right to Repair include a right to make manufacturers change the parts choice or design of their device? Only if the change desired is trivial (and who decides that?) or even if it has some actual tradeoff?
FAR does not say that the Air Carrier has to have logical rules.
I agree, their rules are illogical and possibly even internally inconsistent and surely not drafted to the level of technical precision demanded by engineers on/.
Nevertheless, the law stands. One thing you learn after a while is that criticisms of the substance of something are orthogonal to the question of who has the authority to define it. And while you can appeal to my engineering sense (and indeed I agreed above), that doesn't change the facts that Congress-->FAA-->Carrier are surely authorized to make the rules, irrespective of whether they make smart or dumb ones.
OK, you're right on the point that Airplane Mode is just a UI button and is not legally required to actually make the phone usable in an airplane.
There was a looser chain of causality that I was following. Which is:
"Users (logically) expect that the Airplane Mode button will do the needful in order to comply with the law regarding the use of portable electronic devices. Since at least one carrier prohibits the use of GPS, this means that the button shall disable GPS.
A phone whose Airplane Mode button did not comply with the law would be unwittingly placing the users in legal jeopardy and possibly creating civil liability for the phone manufacturer as being deceptive and unfit for purpose."
(a)General Penalty.â" (1) A person is liable to the United States Government for a civil penalty of not more than $25,000 (or $1,100 if the person is an individual or small business concern) for violatingâ" [...] (B) a regulation prescribed or order issued under any provision to which clause (A) of this paragraph applies;
and 49 USC 46316 says:
(a)Criminal Penalty.â" Except as provided by subsection (b) of this section, when another criminal penalty is not provided under this chapter, a person that knowingly and willfully violates this part, a regulation prescribed or order issued by the Secretary of Transportation (...) under this part, or any term of a certificate or permit issued under section 41102, 41103, or 41302 of this title shall be fined under title 18.
So the chain of causality is: Congress made it a crime to violate any regulation made by the FAA. The FAA made it a violation to operate any portable electronic device not approved by the Air Carrier. At least one Air Carrier prohibits the use of any device that transmits or receive.
That said, I agree, I will retract my statement and add the "at least one major carrier" qualifier. What I was was over-inclusive.
"Airplane mode is required to disable GPS in order to make the device compliant with the approval for at least one US carrier. FAA regulations forbid the operation of any portable electronic device on a commercial flight except those approved by the carrier. It is a crime not to obey the FAR."
Or, to put it another way, if you shipped a phone in which GPS was not disabled by Airplane Mode, then United passengers would be forced to either GPS off manually when entering Airplane Mode (or turn the phone entirely off) or else be in criminal and civil violation of the law.
Finally, I think it's ridiculous to claim that the GPS isn't a radio within the meaning of the United policy.
[ Also, the United policy itself is silly. I'm not arguing about the substance of it. Also, welcome to the administrative state:-) ]
Sure, the security model doesn't assume that these things can't be compromised. In fact, we routinely model what happens when a credential that is used to authorize the HSM is lost or stolen.
At least in that case you have centralized reporting of what was done -- for instance the trojanized SSH install packages were surely logged as they were signed, making them far easier to revoke. Etc . . .
I can't stress enough how it's all the model (not for you, but for the general audience).
FAA regulation 91.21, which punts it to the airlines:-)
Wait, so you entered Airplane Mode (which disables all the radios) and then you clicked a button saying "Enable GPS" and you are shocked that . . . GPS is enabled?!
You know I can play Candy Crush or Soul Caliber or fill out the NYT Crossword while in Airplane Mode, right? And those probably aren't safe to do while driving . . .
Also, you realize that if driving in a car made the phone enter an "automatic non-overridable airplane mode" then there would be no way for phone to figure out the exit condition since it isn't able to reliably figure out its velocity without GPS (which is now off).
And if it did periodically "pop out" to do a GPS, it would likely be violation of FAA rules in the case you were on a plane. Which it cannot figure out in advance.
Wow,/. really went from "I own this device, I should control what code runs on it" to "the State can (benevolently) require phone manufacturers to lock users out against their will".
Also, this poster has never had a 45 minute bus commute or taken a 5 hour inter-city bus.
[ Or thought about Airplane Mode, which is required by law to disable GPS. ]
You simply cannot guarantee the security of any hardware NOT under direct control.
Or you could build that into your threat model. For instance, I've seen a secure setup in which a plain off-the-shelf database was used to store data that was cryptographically pinned to an HSM. The database was then replicated into the cloud for availability and synchronization purposes. If you stole the data or otherwise compromised the cloud service, you would gain nothing but encrypted files for which you didn't have the keys. If you tampered with the data, you would trigger an integrity check. And this was within the realm of a small-to-medium sized company. Imagine my shock when a major player like Equifax just kept their entire database in the clear.
So yeah, you cannot guarantee the security of hardware that's not under direct control. But you can use hardware that's not known to be secure if you model it properly.
[ Or, in other words, the art of security is in writing down all the ways that things are insecure and working through them. Not by insisting that the officer printer/copier run SELinux and get regular kernel updates (hint: they write that software once and fuggedaboutit). ]
If you want/need to run proprietary software, stick to games. For anything important, it doesn't make sense to use any software that treats you like an adversary.
That's true.
(2017 and the above opinion is probably still considered controversial. Everyone knows it's true but some people feel compelled to pretend that common sense is too "inconvenient.")
That's because, in addition to that true statement above, there is another true statement which is that there do not exist non-proprietary software for all use-cases. I'm not going to get into a holy war about which FOSS software can adequately fulfill those niches, only to appeal to your reason that there exists at least some such proprietary tools for which there is no FOSS alternative[1].
So we are caught between two true statements -- on the one hand we don't want to use software that treat us poorly[2], on the other hand it is inconvenient but true that we don't have a choice in some particulars.
The real world is a bit more complicated that a single truth . . .
[1] And if you don't believe that there is literally single such tool, then I guess I'll appeal to the third party reader to evaluate whether that's a tenable proposition.
[2] Indeed, I've worked with some proprietary software whose creators treated me well, kept my data in an open and documented database format that I could directly access, and generally weren't jerks. YMMV, Void Where Prohibited, Results May Vary.
No matter how you represent the key syntactically (as a string, as a reference to a string, with an additional 'bool key_valid' parameter, in hex or in base64) the underlying bug is a state machine bug.
What you've said is true, because you are using the nullity of the key to represent state information (in fact, every mutable variable represents...drumroll... program state). Specifically, you are definition a state transition rule that says that you cannot install a null key (OK) and that when you install a key you must set it to NULL (OK). That's reasonable, although it's against the (ill-advised) logic of the 802.11 spec saying that MSG3 can be re-transmitted.
In your state machine (and anyone else that implements it, regardless of whether they represent it in memory the way you suggest, link-level failures of MSG3 require that you go back to the start. Which is probably the simplest design that maintains the security properties that we want -- and the cost is fairly minor.
There are a few basic categories of cheating by modifying your client software. In order of simplest-to-most-complicated.
(1) Rendering. For obvious reasons rendering the 3D scene is done on the client side. A malicious client can replace opaque textures with transparent ones so as to see through walls. This is more advantageous in games where bullets go through walls.
More advanced rendering hacks involve replacing enemies/targets/powerups such that they appear in garish colors, emit light or even messing with their poly configuration so they appear huge.
(2) Data reveal. Since much of the data has to be transmitted from the server to local, much of it not "visible" to the player, another class of hacks intercepts this data (either in-memory from the victim process or from the network stack) and displays it out-of-band, e.g. on a minimap running on a second screen. I can imagine in a game like PUBG (or Starcraft) this would be a huge advantage.
(3) Input cheating. Most likely to get you banned -- this is basically an aim-bot that synthesizes the right input based on either reading the screen or, more likely, hovering data as in (2). Fairly easy to spot from looking at the server replay, as it will basically be a few milliseconds from when an enemy comes into view and when a perfectly-placed shot is fired. Also, in my experience looking at replays, humans almost always overshoot when aiming and then correct back. Aimbots somehow manage to decelerate right on target . . .
Expensive things very often cost quite a bit less than cheap things.
Go to the hardware store and buy the cheapest socket wrench they have, and do it against every time it breaks. Or buy the cheapest garden hose, then some duct tape for the leaks, then curse at it a bit, then eventually buy another decent one.
I understand there are legitimate times in which the best solution is a a worse one. IKEA desk/dresser for a college apartment that is necessarily temporary and it doesn't make sense to buy a nice one. I would think that a municipal office is not that case.
I've found you can reliably run a low/moderate magstripe transaction flow (10 txn/minute) over even a 2G EDGE modem. Remember, these technologies were designed and deployed when everything was "trunked" via ISDN or even 14.4Kbps modem.
The statement that you can't run a credit or ATM transaction when the fiber is out is like saying you can't light a candle because you don't have a flamethrower and it would be ridiculous to have a "backup flamethrower".
Slashdot Mirror
And so the goal should be to get you high speed internet, medium be damned.
Also, what kind of rifle? I know some folks with a .50cal that will easily clear 1 mile, that's a long run for DSL :-)
Or at least it will be able to vote for King when the rest of the citizens can as well.
Although fiber is the necessary infrastructure for every policy goal we have -- advanced healthcare, the emergence of new forms of industries, a chance for every child to get an education, managed use of energy, and on and on
No. Maybe faster internet is necessary infrastructure for those things. Maybe not. There are enough other comments exploring the truth of that assertion.
But fiber is just one possible medium for delivering faster internet. Believe it or not, I get incredibly fast internet (500/100 Mbps) over coaxial cable. I used to get 200/200 over microwave. Both of them were affordable ($60 for the super premium plan).
Also, at least in the United States, the use of coal for power generation is dropping significantly due to the lower cost of natural gas power plants and wind (regardless of what the politicians do). What this means is that the efficiency of EVs is increasing as coal usage drops since natural gas power plants tend to be more efficient and release around half the CO2 of an equivalent coal plant.
And the lower cost of natural gas is itself largely due to advances in hydraulic fracking. But mention that fracking is driving a huge net reduction in greenhouse gases and watch the more emotional (and less scientific) wing of the environmental movement start to spin around itself a bit.
First off, I think you mean conceited, not conceded.
And I think the point was that I was admitted forthrightly that, in the areas in which I have expertise, I also have strong opinions that make me non-neutral. In fact, it seems almost inevitable that anyone with significant experience in some domain would have to have generated some thoughts and opinions about it.
There's a subtle distinction here that's often lost - I see it muddled together a few places in TFA and also in the comments -- between the right to repair a device and the right to demand (?) redesign of a device in a way that makes repair easier.
The former seems quite reasonable, and the auto manufacturers got it done so that dispels the feasibility complaints, even for technology-stuffed modern cars. But I don't see MA (or anyone else) going so far as to say that car manufacturers should be required ex-ante to change the way cars are designed, built and assembled.
For electronic devices, however, there seem like there are real engineering tradeoffs between repairability and legitimate design goals such as parts cost, assembly cost, weight and size. Replacing all the glue holding a tablet together with screws might improve repairability while adding $0.14 to the cost and a few grams to the weight. A removable battery might be the same cost but add 3mm to the thickness. In some cases, it might be heuristically worth it, but I struggle in vain for any intellectually sound way to make those things commensurable.
And as an engineer, I surely shudder in fear of someone with no domain expertise in a problem that I spent years solving second-guessing my tradeoffs. Especially since they have no accountability to produce a workable design that can be actually shipped on time. At the same time, I recognize that the engineers with domain expertise are hardly neutral deciders of what tradeoffs are legitimate and which design elements serve no purpose other than to impede repairs.
So there I have it -- I don't see a scientific way to judge whether it's worth it and my choices for who to ask is either someone impartial with no idea of the specifics or someone that knows but has no incentive to impartiality.
[ Actually, the latter is kind of a pervasive problem. You can have folks with a ton of experience, or you can have folks that are neutral with no preconceived biases. But you can rarely have the same person with both. ]
So, to nit-pick a bit, does the Right to Repair include a right to make manufacturers change the parts choice or design of their device? Only if the change desired is trivial (and who decides that?) or even if it has some actual tradeoff?
Which is why a lot of States limit the taxed value from rising more than a certain percentage each year, even if the assessed value skyrockets.
he has caused the Mac to lose about a third of its users.
Citation? Over 8 years, Mac sales appear to be flat, but I don't see them declining.
FAR does not say that the Air Carrier has to have logical rules.
I agree, their rules are illogical and possibly even internally inconsistent and surely not drafted to the level of technical precision demanded by engineers on /.
Nevertheless, the law stands. One thing you learn after a while is that criticisms of the substance of something are orthogonal to the question of who has the authority to define it. And while you can appeal to my engineering sense (and indeed I agreed above), that doesn't change the facts that Congress-->FAA-->Carrier are surely authorized to make the rules, irrespective of whether they make smart or dumb ones.
OK, you're right on the point that Airplane Mode is just a UI button and is not legally required to actually make the phone usable in an airplane.
There was a looser chain of causality that I was following. Which is:
"Users (logically) expect that the Airplane Mode button will do the needful in order to comply with the law regarding the use of portable electronic devices. Since at least one carrier prohibits the use of GPS, this means that the button shall disable GPS.
A phone whose Airplane Mode button did not comply with the law would be unwittingly placing the users in legal jeopardy and possibly creating civil liability for the phone manufacturer as being deceptive and unfit for purpose."
49 U.S. Code  46301 says
(a)General Penalty.â"
(1) A person is liable to the United States Government for a civil penalty of not more than $25,000 (or $1,100 if the person is an individual or small business concern) for violatingâ"
[...]
(B) a regulation prescribed or order issued under any provision to which clause (A) of this paragraph applies;
and 49 USC 46316 says:
(a)Criminal Penalty.â"
Except as provided by subsection (b) of this section, when another criminal penalty is not provided under this chapter, a person that knowingly and willfully violates this part, a regulation prescribed or order issued by the Secretary of Transportation (...) under this part, or any term of a certificate or permit issued under section 41102, 41103, or 41302 of this title shall be fined under title 18.
So the chain of causality is: Congress made it a crime to violate any regulation made by the FAA. The FAA made it a violation to operate any portable electronic device not approved by the Air Carrier. At least one Air Carrier prohibits the use of any device that transmits or receive.
That said, I agree, I will retract my statement and add the "at least one major carrier" qualifier. What I was was over-inclusive.
"Airplane mode is required to disable GPS in order to make the device compliant with the approval for at least one US carrier. FAA regulations forbid the operation of any portable electronic device on a commercial flight except those approved by the carrier. It is a crime not to obey the FAR."
Or, to put it another way, if you shipped a phone in which GPS was not disabled by Airplane Mode, then United passengers would be forced to either GPS off manually when entering Airplane Mode (or turn the phone entirely off) or else be in criminal and civil violation of the law.
Finally, I think it's ridiculous to claim that the GPS isn't a radio within the meaning of the United policy.
[ Also, the United policy itself is silly. I'm not arguing about the substance of it. Also, welcome to the administrative state :-) ]
FAA regulation 91.21 makes it a crime to use any portable electronic device that is not approved by the Carrier.
United Airlines (just to pick one) prohibits all radio receivers and transmitters.
So, are you going to retract your statement about transmission vs reception?
Sure, the security model doesn't assume that these things can't be compromised. In fact, we routinely model what happens when a credential that is used to authorize the HSM is lost or stolen.
At least in that case you have centralized reporting of what was done -- for instance the trojanized SSH install packages were surely logged as they were signed, making them far easier to revoke. Etc . . .
I can't stress enough how it's all the model (not for you, but for the general audience).
FAA regulation 91.21, which punts it to the airlines :-)
Wait, so you entered Airplane Mode (which disables all the radios) and then you clicked a button saying "Enable GPS" and you are shocked that . . . GPS is enabled?!
This seems like crystal clear UI to me, but YMMV.
People thought that they would like to get up to date route and hazard information.
You can take the point of view that we shouldn't give people what they want, but remember that would apply to you and what you want as well.
You know I can play Candy Crush or Soul Caliber or fill out the NYT Crossword while in Airplane Mode, right? And those probably aren't safe to do while driving . . .
Also, you realize that if driving in a car made the phone enter an "automatic non-overridable airplane mode" then there would be no way for phone to figure out the exit condition since it isn't able to reliably figure out its velocity without GPS (which is now off).
And if it did periodically "pop out" to do a GPS, it would likely be violation of FAA rules in the case you were on a plane. Which it cannot figure out in advance.
Wow, /. really went from "I own this device, I should control what code runs on it" to "the State can (benevolently) require phone manufacturers to lock users out against their will".
Also, this poster has never had a 45 minute bus commute or taken a 5 hour inter-city bus.
[ Or thought about Airplane Mode, which is required by law to disable GPS. ]
You simply cannot guarantee the security of any hardware NOT under direct control.
Or you could build that into your threat model. For instance, I've seen a secure setup in which a plain off-the-shelf database was used to store data that was cryptographically pinned to an HSM. The database was then replicated into the cloud for availability and synchronization purposes. If you stole the data or otherwise compromised the cloud service, you would gain nothing but encrypted files for which you didn't have the keys. If you tampered with the data, you would trigger an integrity check. And this was within the realm of a small-to-medium sized company. Imagine my shock when a major player like Equifax just kept their entire database in the clear.
So yeah, you cannot guarantee the security of hardware that's not under direct control. But you can use hardware that's not known to be secure if you model it properly.
[ Or, in other words, the art of security is in writing down all the ways that things are insecure and working through them. Not by insisting that the officer printer/copier run SELinux and get regular kernel updates (hint: they write that software once and fuggedaboutit). ]
If you want/need to run proprietary software, stick to games. For anything important, it doesn't make sense to use any software that treats you like an adversary.
That's true.
(2017 and the above opinion is probably still considered controversial. Everyone knows it's true but some people feel compelled to pretend that common sense is too "inconvenient.")
That's because, in addition to that true statement above, there is another true statement which is that there do not exist non-proprietary software for all use-cases. I'm not going to get into a holy war about which FOSS software can adequately fulfill those niches, only to appeal to your reason that there exists at least some such proprietary tools for which there is no FOSS alternative[1].
So we are caught between two true statements -- on the one hand we don't want to use software that treat us poorly[2], on the other hand it is inconvenient but true that we don't have a choice in some particulars.
The real world is a bit more complicated that a single truth . . .
[1] And if you don't believe that there is literally single such tool, then I guess I'll appeal to the third party reader to evaluate whether that's a tenable proposition.
[2] Indeed, I've worked with some proprietary software whose creators treated me well, kept my data in an open and documented database format that I could directly access, and generally weren't jerks. YMMV, Void Where Prohibited, Results May Vary.
No matter how you represent the key syntactically (as a string, as a reference to a string, with an additional 'bool key_valid' parameter, in hex or in base64) the underlying bug is a state machine bug.
What you've said is true, because you are using the nullity of the key to represent state information (in fact, every mutable variable represents ...drumroll... program state). Specifically, you are definition a state transition rule that says that you cannot install a null key (OK) and that when you install a key you must set it to NULL (OK). That's reasonable, although it's against the (ill-advised) logic of the 802.11 spec saying that MSG3 can be re-transmitted.
In your state machine (and anyone else that implements it, regardless of whether they represent it in memory the way you suggest, link-level failures of MSG3 require that you go back to the start. Which is probably the simplest design that maintains the security properties that we want -- and the cost is fairly minor.
The sum total of my argument is that purchase price is only one determinant of long term cost.
Maybe I can help you understand: "Things that are expensive in purchase price very often cost less over the long term than things that are cheap".
This is why the following statement that you wrote
Apparently expensive software costs less than free software.
can in fact be true, because you've conflated purchase price with long-term cost.
There are a few basic categories of cheating by modifying your client software. In order of simplest-to-most-complicated.
(1) Rendering. For obvious reasons rendering the 3D scene is done on the client side. A malicious client can replace opaque textures with transparent ones so as to see through walls. This is more advantageous in games where bullets go through walls.
More advanced rendering hacks involve replacing enemies/targets/powerups such that they appear in garish colors, emit light or even messing with their poly configuration so they appear huge.
(2) Data reveal. Since much of the data has to be transmitted from the server to local, much of it not "visible" to the player, another class of hacks intercepts this data (either in-memory from the victim process or from the network stack) and displays it out-of-band, e.g. on a minimap running on a second screen. I can imagine in a game like PUBG (or Starcraft) this would be a huge advantage.
(3) Input cheating. Most likely to get you banned -- this is basically an aim-bot that synthesizes the right input based on either reading the screen or, more likely, hovering data as in (2). Fairly easy to spot from looking at the server replay, as it will basically be a few milliseconds from when an enemy comes into view and when a perfectly-placed shot is fired. Also, in my experience looking at replays, humans almost always overshoot when aiming and then correct back. Aimbots somehow manage to decelerate right on target . . .
Expensive things very often cost quite a bit less than cheap things.
Go to the hardware store and buy the cheapest socket wrench they have, and do it against every time it breaks. Or buy the cheapest garden hose, then some duct tape for the leaks, then curse at it a bit, then eventually buy another decent one.
I understand there are legitimate times in which the best solution is a a worse one. IKEA desk/dresser for a college apartment that is necessarily temporary and it doesn't make sense to buy a nice one. I would think that a municipal office is not that case.
I've found you can reliably run a low/moderate magstripe transaction flow (10 txn/minute) over even a 2G EDGE modem. Remember, these technologies were designed and deployed when everything was "trunked" via ISDN or even 14.4Kbps modem.
The statement that you can't run a credit or ATM transaction when the fiber is out is like saying you can't light a candle because you don't have a flamethrower and it would be ridiculous to have a "backup flamethrower".