I think this might be part of the issue though - I saw another article about this plan that said people often _don't_ try to contribute because their welfare benefits are subject to them not doing certain things.
For instance - you get $X from welfare, you could make $Y doing some work despite your disability, but $Y < $X, and if you make $Y, the government won't give you $X - therefore there is no reason to pursue $Y.
Even if you don't have money, often if you're on disability anything that might show you aren't "so disabled" can stop it. Therefore even if you want to, there is really a strong reason not to try to do things.
That is what basic income is meant to really alleviate - there becomes no reason not to do other stuff, because it's unconditional - those already on welfare no longer have all those requirements.
I'm not saying it would be perfect, but I do think it would address at least part of this problem. I wish I had an actual study on the numbers of people that don't try to get jobs/be productive while on welfare because of the risk of losing the primary income stream they get from welfare, but I can't find anything. I have known several people in this situation though, and watching the system treat them that way was kind of heartbreaking.
"I saw another article about this plan that said people often _don't_ try to contribute because their welfare benefits are subject to them not doing certain things."
A good point.
But basic income is generally sold as an arts and hobby thing, where they're not going to make any money anyhow. Basic income participants who are going to take the money but not do a "real job" aren't going to go out and dig ditches or something.
Since this isn't a binary thing, we should expect to be able to find an effect if this is going to happen, even if disability isn't evenly distributed and even if certain categories are impaired due to welfare rules. Who's on disability making art or music or something who would otherwise be stuck in a job? Alternatively, show me a work of art or something from the cases of basic income that were tried that couldn't have been done without it.
(We'd really like to see a sufficiently strong pattern before we run this sort of experiment at scale, and we'd really like it to be somehow some appreciated work, but I'll start with asking just for one instance.)
If doing a little of this sort of thing does not produce a little of the desired result at this scale, there is no rational reason to believe that doing more is going to produce the desired result either. (Italicized words very important. It could indeed be the case that doing more would in fact produce the desired result, but there's no data to lead you to that belief rationally.) The rational belief becomes to discard the idea that basic income is going to be used for arts and music and stuff, because we can stop speculating about what people do under those circumstances and just look.
Because if basic income really is paying people to do nothing, it won't work at scale. We can't afford to pay everybody to do nothing. The economics would simply adjust such that the basic income is not a livable wage anymore via inflation mechanisms. (Which is basically one of my great fears; basic income combined with voting creates a one-way ratchet, and so far, I've heard no mechanism to even slow down the ratchet, let alone reverse it.)
I find this amusing because I'm generally suspicious of sites that don't include some form of reference to wherever the information was retrieved - perhaps a habit from when I did more stuff in academia. Things don't exist in vacuum except things that are basically pure opinion articles - just about everything else is based on something and should probably be showing it.
I think that's his point - he doesn't want a license to protect this, at the end he even explicitly states in spite of this he won't change his process - he just wishes people wouldn't be jerks about this kind of thing. It felt, to me, like he doesn't think he should need a license to enforce this kind of behavior, and instead is going to just call out that the guy is being a jerk.
It's also kind of stupid to rip someone off. Assuming all the information here is accurate, this could really come back to bite the guy who ripped him off - someone is going to google what you've done and will end up with this blog post slamming you. If it was an honest mistake, the author should probably take the time to fix the posts and apologize.
I actually was thinking that the graceful degrade was how it was implemented initially and was about to write it off until I got to that part. Interesting.
At this point I still don't buy that Apple is doing this to hold things back. Do you have other examples of when they've been behind on features with no clear explanation of why? It's okay if not - you said you were only casually following - but curious.
They wouldn't have very much to gain in my mind - none of their core business relies on locking in/out web development. They have an app market, and I guess you could argue they're trying to drive that, but they have implemented a lot of other features, and early extensions in many cases, that doesn't really align with them trying to hold web back.
I actually completely agree with you on this - what they're proposing is going to stifle a lot of wireless hacking and will be overall harmful to try to avoid what is probably already at best a marginal problem. Most people that overpower their equipment already burn it out very quickly, and I don't think I'd worry about it as much as they are.
I think the alarmist point of view on this actually hurts his points though - because it comes off as a less legitimate concern than I think it actually is. It is something we should be concerned with, because FCC rules are often hard to change once they're made.
This is because this is entirely intended for software defined radio and modular radio - around which the entire point is the RF component does not contain as much signal processing logic, and that is done in software. Restricting software defined radios to specific frequencies in hardware would take away the entire point of modular/software defined radio.
Did you miss the conversation about how this fucks over people who want to install custom firmware on their routers for legitimate administration and traffic-shaping? There are plenty of uses for radio software that don't involve going outside approved frequencies.
I agree - but this rules doesn't apply to anything except SDR and modular systems that are also consumer devices - which are not most consumer devices.
That said - I am not condoning the FCC policy at all - I'm actually against it - I just don't really care that much because it impacts nothing I do and so few use cases I care about.
You sure have spent a lot of time ITT explaining to everyone, advocating, practically that the FCC ruling is unimportant because you think that your own interests will be unaffected. Well, congratulations, but if we were all so short-sighted we'd eventually be reduced to only the hobbies and activities that a majority of us approve. We get it. You don't care, because you don't think it affects you.
I've actually said a few times I think it's a bad ruling - I'm just not practically impacted by it :). That said though I think being alarmist about it does not help the cause - it makes people less likely to actually listen to you once they realize you were being an alarmist. I actually agree with the points in the article - I just disagree with how they were made.
In this thread my only point is the FCC hardware restricting instead of requiring software restriction neuters SDR to begin with so is a dead end. It's all or nothing insofar as "protections" go. My view is still it should be nothing, but I don't think it is as big a deal as its being made out to be.
Even if it does apply, the radios on modern phones are already black boxes and completely detached from the rest of the phone. Some consider them a significant security threat already.
Contrary to the common interpretation, I've yet to see where in the new rules it is required that manufacturers implementing the new 5GHz U-NII device software security requirements is required to forbid 3rd-party firmware. Yes, there is an administrative document that asks questions about how such updates are prevented, but if you read the full document in context it also asks a lot of other redundant questions, and the FCC have since responded to Ars questions stating that it was not their intention to ban alt firmwares - just that the administrative processes starting up at the moment probably assumed that it would be necessary for the host device to do this to meet the new requirements. And since when does answering a regulatory compliance question in the negative mean that your application will automatically be rejected? All of the responses are used to help an FCC assessor arrive at a proper conclusion, potentially with further clarification sought on each point - it is not a hard script that you must always answer every requirement in the positive (in fact in many cases this would be impossible).
The new regs themselves do not state this requirement. It lists several possibilities for manufacturers to guarantee conformant emissions from their device, several which will continue to allow 3rd-party OS firmware.
Admittedly, the brave new world looks like region-locked devices and cheaper routers that truly are locked down in the exact ways we don't want, but that is not a hard FCC requirement, just a side-effect of the new regs on APs that have poor separation between OS and radio module.
There are plenty of uses for radio software that don't involve going outside approved frequencies.
Except unlike ISM bands, U-NII 5GHz spectrum has been carved up with consultation of the 5GHz primary (licensed) users in each country and granted exclusively for U-NII conformant devices.
Unlike 2.4GHz ISM, nothing gives you the right to transmit on 5GHz U-NII bands (well, there's a bit that overlaps with secondary amateur spectrum) than otherwise permitted through the same FCC approvals process every device manufacturer must undergo.
That was the case before the new rules. Now the new rules are imposing sucky requirements for U-NII device software security.
However, that's been largely misinterpreted in every discussion I've seen recently.
You really don't want U-NII devices configured for Japan to be stomping on licensed spectrum in the US; you also need all that power negotiation, radar/interference avoidance algorithms in your radio so we don't get the same 2.4GHz mess happening in 5GHz.
You can make it difficult and very hard in practice through antenna and component design in the case of small internal radios - in radios with external antennas it becomes a great deal harder though, and in radios that are open for modifications it becomes even more difficult.
That being said though - this is meant to apply to software defined/modular radios - that is systems wherein the entire point is that it does what the software tells it instead of having hardwired components meant only to receive certain frequencies.
This title is kind of click-bait - they aren't prohibiting operating systems, they _might_ be prohibiting installation of operating systems that are not approved on certain types of devices that allow software defined radio - that is, transceivers that can be tweaked easily by software.
That is not at all the same thing as banning an operating system.
This is already present insofar as hardware requirements in radios - radios cannot be permitted to listen on frequencies reserved for cell phones, and must not be restricted in such way as they can be easily modified to enable it (e.g., a header/jumper). This really just extends this requirement that it is non-trivial to enable illegal broadcasting or reception on software defined radios.
Now - insofar as if this should impact open source operating systems, we have a good question. I don't think it does that - my interpretation, potentially wrong of course, just as the article's could be wrong, is that you would have to restrict the actual firmware in question to a blob that communicates with the hardware in a secure way. This would prevent open/free components insofar as the actual driver, but would not permit the operating system itself from being installed. They mention this, but only at the end of the article.
I also doubt the impact of this for non software-defined/modular radio systems. I don't see a way this would really impact everyday wifi or non-modular systems in a way most people would care about. That isn't to say it isn't _bad_ but once again, it just seems super misleading and alarmist.
Whether or not the FCC should or shouldn't do this is a different question, but the link's title seems intentionally misleading.
> they aren't prohibiting operating systems, they _might_ be prohibiting installation of operating systems that are not approved on certain types of devices that ...
"prohibit installation" means to ban.
"operating systems that are not approved on certain types of devices that ..." means specific operating systems.
So, the FCC "might ban specific operating systems"; you've paraphrased what the title says.
I disagree - saying they might ban operating systems, with no context, leaves out the fact they're only talking about modular radio systems or software defined radio systems.
Edit: also to be clear, as another comment pointed out, this doesn't have any impact on test/kit equipment that is not compliant with FCC regulations anyway and requires a separate license to use - this is targeting consumer equipment. So I still think it's pretty misleading.
The rest is the fact that I think the article is wrong anyway :)
It's a title. Of course it's lacking context. If you want context, you read the rest of the essay, which explains everything you're doing much better than you are, and makes a solid case for why the FCC is, indeed, banning certain operating systems.
I still think it's kind of alarmist, but I can see your point of view as well. My goal was not to be better than their explanations, but only to summarize why I think they're being alarmist - I agree it's a topic worthy of discussion though :).
But the FCC regulates a great deal of equipment, and this is only targeting a very specific subset of that equipment - not all of it. I was initially pretty concerned as I'm a Ham radio operator, but this really does not concern me overly much now that it's clear it's:
Quite a bit of "consumer" equipment is halfway to an SDR already, and a ruling like this would mean you could never write or release FOSS firmware for a wireless card. (Note that wireless cards with FOSS firmware exist today.)
Yeah - it sucks and this FCC rules is concerning, but not as concerning as I initially thought it was.
Don't get me wrong - I think this is a stupid rule, but I just don't think it's as big a deal as the article, and title in particular, make it out to be.
Including the software that controls it. Which, in practice, includes the OS of a laptop or the firmware of a router, as discussed in the article. Technically that might not be the "entire device", but it's the part that matters.
> Which, in practice, includes the OS of a laptop or the firmware of a router, as discussed in the article.
The article is continuing to imply that the FCC is explicitly banning alt firmware for 5GHz WiFi devices. That is only the case if the module manufacturer fails to come up with any other way of getting their device approved. I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.
Given that this also means a brave new world of region-locked/region-specific 5GHz WiFi devices, and the added compliance burden for integrators ("host device manufacturers") trying to use modular transmitters that rely on host device manufacturer controls to achieve FCC approval, I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.
The situation where a modular transmitter places additional avoidable test/conformance/approval burden on the host device will also be a PITA for manufacturers, not just end-users.
> I don't see anywhere in the regs where banning alt. firmware is a goal of the regs.
It's not an explicit goal. But the article argues (and I tend to agree) that the practical result will be manufacturers locking down their devices to prevent alt firmware from being loaded, since that will be the easiest and cheapest way for them to demonstrate compliance.
> I am hopeful that this will change the way that WiFi manufacturers lock down their radio firmware - and that is exactly what the FCC wants.
Are you saying the manufacturers will come up with some way of locking down their radio firmware that still permits something like OpenWRT to be installed on a router (or Linux on a laptop, for that matter)? Why would they bother when they could just lock the device down completely?
> Are you saying the manufacturers will come up with some way of locking down their radio firmware that still permits something like OpenWRT to be installed on a router (or Linux on a laptop, for that matter)? Why would they bother when they could just lock the device down completely?
Yes. In the actual regs (which nobody seems to read), they suggest a list ("including but not limited to") a number of mechanisms by which manufacturers may choose to control the portion of their radio software that would impact the validity on their RF testing/validation/compliance results. One of them is signed firmware blobs: to me, that's the easiest, cheapest non-invasive method for WiFi module makers that won't create a huge compliance burden on the host device manufacturer. You go from having to load an unsigned firmware blob anyway, to a signed one. Which is a huge step in the right direction for firmware security anyway. As for modules which don't have blobs but do have the means to create non-compliant emissions just through the driver: it doesn't seem like much of a stretch that they could run new region-locked revs of their modules, or at least move those previously adjustable RF parameters/behaviours over to a signed image in a $0.10 SPI EEPROM chip.
All of this isn't just a PITA for users, it's a PITA for the device manufactures as well.
Particularly for laptop manufacturers. They could save $5 locking down the entire laptop, something they've never been able to do even when they try, or they could spend the extra $5 and get the module that's got a stand-alone certification and only requires them to submit a reference to the module's own FCC approval and some demonstration that the gain of the antennas in their product are in-spec.
I'm not sure I understand what you're describing here. Suppose I have a router and I want to run OpenWRT on it. Are you saying that the router will have basically two "firmwares" in it? One that controls the radio chip only, and is signed, and has some kind of defined driver interface; and another that controls the rest of the device, and has a driver that talks to the signed blob, so as long as OpenWRT has that driver, I'm good?
Or suppose I have a laptop and I want to load Linux on it. Are you saying the wifi chip inside the laptop will have a signed firmware blob that controls the radio, and has a Linux driver interface, so I can load Linux on the laptop and talk to the chip?
Assuming the above is correct, how different is it from the way these devices are designed now?
FCC is talking about the radio firmware blobs which drive the radio MCU/DSP chip. That is where you have the capability to drive the device out-of-spec. Not (necessarily) the Linux environment it is being driven from. This is a discrete, separate part to the main ARM or x86 CPU running Linux (though some SoCs are blurring those lines).
We already use firmware blobs on WiFi chips. It's why OpenWRT and friends are locked into old kernel versions for some routers: they don't have the source to the WiFi radio blob and can't recompile or reverse-engineer to make it work on newer kernels with different ABI. It's why we have a /lib/firmware directory for certain drivers in Linux: the device doesn't bother with flash memory, you have to load its firmware onto the device every power cycle into the DSP chip's memory.
So for many devices currently in existence, separate radio firmware is already how things are architected.
Some devices are flashed though, and don't require the host computer to load its own firmware, which is why I discussed a smaller EEPROM that would store signed config locking down the RF parameters and other aspects affecting certification.
Basically separate radio and OS firmware are how mobile phones currently work. That's why you see separate baseband versions from your OS version info in "about this phone": these new rules for SDR devices (separate to U-NII discussion here) will actually require a whole new FCC approval for each radio firmware change.
EDIT: And we haven't properly distinguished FCC approval process differences between modular WiFi transmitters (Eg. miniPCI-e cards) used in laptops and more expensive routers, which can self-contain and solve these issues by themselves without requiring the host device to care about U-NII security measures at all, versus cheaper/integrated products that may be crappy enough to require security measures in the main host device firmware in order to guarantee the radio firmware integrity to the FCC's satisfaction.
> for many devices currently in existence, separate radio firmware is already how things are architected
This makes me feel better about things like laptops and routers (at least the more expensive ones), but this...
> cheaper/integrated products that may be crappy enough to require security measures in the main host device firmware in order to guarantee the radio firmware integrity to the FCC's satisfaction.
...makes me wonder about the future, since the trend for pretty much every category of device is towards "cheaper/integrated products". You mention that some SoCs blur the lines already.
> these new rules for SDR devices (separate to U-NII discussion here) will actually require a whole new FCC approval for each radio firmware change.
To make sure I understand, this would be an incentive for mobile phone manufacturers (for example) to continue to have separate radio firmware, even if they move to cheaper SoC designs, correct? Since otherwise (if there were only one firmware blob that contained both the OS and the radio controls), they would have to get FCC approval every time they wanted to push an OS update.
> ...makes me wonder about the future, since the trend for pretty much every category of device is towards "cheaper/integrated products". You mention that some SoCs blur the lines already.
Yes, that's a legitimate concern, but there's a small consolation that this is a problem only for existing SoC architectures doing 5GHz. The new regs don't rule out new SoC architectures which would implement the enforced separation in silicon somehow. Although you're still stuck not having access to modular transmitter rules but that was the case already.
> To make sure I understand, this would be an incentive for mobile phone manufacturers (for example) to continue to have separate radio firmware, even if they move to cheaper SoC designs, correct?
Indeed, although I have oversimplified somewhat - some basebands do run on the same CPU as the OS, but something resembling a secure hypervisor (with secured boot, among other things) is used to enforce isolation between the baseband and OS (see OKL4).
Are you being obtuse on purpose? The headline is intentionally worded in such a way to make people believe the FCC is going to ban OSX, Linux, or Windows.
If the author believes it's an important issue, he should be intellectually honest about it, because otherwise he risks having people write him off as a quack. It makes it look appear as if there aren't many valid arguments in his favor, so he has to resort to FUD.
> This is already present insofar as hardware requirements in radios - radios cannot be permitted to listen on frequencies reserved for cell phones, and must not be restricted in such way as they can be easily modified to enable it (e.g., a header/jumper). This really just extends this requirement that it is non-trivial to enable illegal broadcasting or reception on software defined radios.
As I recall, they got around this by not being FCC licensed - in other words, HackRF is classified as a kit/developer component, and is not legal to operate unless you hold an independent license from FCC (e.g.: if you're a Ham you can use it on Ham frequencies you are licensed for). Read the disclaimer at bottom
> HackRF One is test equipment for RF systems. It has not been tested for compliance with regulations governing transmission of radio signals. You are responsible for using your HackRF One legally.
Realistically you're not going to probably get in trouble, but I _will_ caution you - if you use this kind of equipment illegally, the FCC does have radio direction finding equipment and will send someone out to find you if you piss them off - they've done this for people that were on Ham frequencies without authorization, people doing nasty things on government frequencies, and anything disturbing people who paid for a license.
Re: GNURadio The software itself has no requirement - there is no "if you run radio software, it has to do X" and there still is no requirement under proposed rules for that as far as I can tell - it's just if you build hardware, your hardware must enforce that only certain software can be installed :).
There seems to be some incredibly bizarre idea floating around here that it is illegal to MONITOR using the equipment (id est "listen") and that is simply not true, except for listening to cell frequencies. That is in American law, but here's the thing: They will not be able to determine that you're listening on those frequencies without looking at your equipment. You can possess and operate your equipment in monitor mode without a license. One must simply get a license (in most countries) to transmit using the equipment. Now, the other thing I want to mention is that the parent comment is right that the FCC has dogs of war that will chase you down and put you in jail (or levy heavy fines) for operating without a license. And they do chase people down with location equipment. I'm not advocating operating a station without a license, but if you keep the power very low and use it sparsely for testing, you have a very, very small chance of being caught by the FCCs enforcement arm. And in most of these cases of nerds transmitting without a license, they are satisfied with merely confiscating your equipment.
I've seen some of the enforcement actions - on a first offense they often just give you a stern warning unless it's clear you were doing it willfully and maliciously (interfering with a company's communications because you have a bone to pick, for instance).
Amusingly, there's been a few cases local law enforcement has asked the ham community to RDF people using their frequencies - at least here most law enforcement uses APCO-25 without encryption, so is easy to monitor and mess with by and large - because it's easier than having FCC get involved.
My favorite mistaken transmission was when a friend noted spurs coming off the strategic command in Omaha that were ending up on ham frequencies. We reported it, an hour later all their spurs were gone.
In any event - yes - monitor mode stuff they won't be able to detect unless they see your equipment, but most equipment is required to restrict the cell frequencies in such a way it's not easy to modify to detect. Most other equipment you have a jumper to enable "everything but cell" TX/RX (Looking at you Yaesu VX-9).
That rule was put in place in the early, analog, days of cell phone usage to help build confidence that J Random Somebody wasn't listening to your calls. Cordless phones at the time were well known for being easy to listen to, and the wireless industry didn't want that stigma on cell phones.
I'm not in the US and I don't know much about US laws, so can you enlighten me on the relevant laws regarding this? Would it be illegal to stick a 4k camera on your window sill? What about for surveillance purposes?
Agreed - they're more concerned about transmission, which is part of why they have more strict requirements around scanners to try a lot harder to avoid this.
> This would prevent open/free components insofar as the actual driver, but would not permit the operating system itself from being installed.
If the SDR has a microcontroller, you potentially only need the firmware of the microcontroller to be signed (with the microcontroller checking the signature), and can have a fully free driver around it. You can even release the source of the firmware (and allow reproducible builds!) because it's guaranteed by the signature, not by the availability of the source.
Good call - similar to how you load firmware for Wifi using a blob a lot of the time. But for a lot of advocates of this they still might not be okay with this as they don't want any blobs. Which I can get, but even more reason it's kind of alarmist in my view.
The law dates back to the days when cell phone tranmissions were analog and could be picked up with a consumer-grade police scanner. As I recall, it was passed soon after an incident where a congressman's conversation with his mistress was picked up and publicized, but I don't have a authoritative source for that.
Even with modern phones being digital and encrypted, the law remains in effect.
The regulation you linked to appears to date to 2010, long after analog phones had been replaced.
18 U.S.C. 2512 may be older but I wonder why such a regulation would have been issued so recently.
Also if this regulation is intended to implement 18 U.S.C. 2512 it appears to be broader in scope than that law. The law only prohibits devices that are "primarily useful for the purpose of the surreptitious interception of wire, oral, or electronic communications". The regulation on the other hand restricts scanners that are capable of receiving such communications. I don't see how a broadband scanner that includes cell phone frequencies along with other bands could be considered to be "primarily useful" for intercepting cell phone communications.
This is ancient, dating back to when cell phones didn't use encryption. As opposed to today, when many of them still use fundamentally broken encryption like A5/1 and A5/2, other than the ones doing something vaguely sensible like VoLTE. (Though I haven't heard anything about the ban on such devices being lifted.)
But in general, "you can't listen to this frequency" is completely crazy; "listen all you like but you won't get anything useful" makes more sense (along with "don't broadcast on this frequency above this power without a license").
Depends on the licensing/certification of the device - for consumer equipment (particularly scanners) it's required, for certain experimental and test equipment it is not.
EDIT: I think this happened in 1994 - google "cell blocked" scanner and you'll find stuff on it.
Honestly I don't know what was "going through my head". I think most letter case decisions are handled by my brain below the threshold of conscious awareness. I don't spend a lot of time agonizing over trivialities in my online comments that are completely irrelevant to my question or point.
It's not crazy to assume that "ham" from "ham radio" would be an acronym for something. You're being needlessly confrontational because of a misunderstanding on the internet.
I've heard various things about how this software is written, but in short generally there should be failsafes. I don't know where you live - but I know where I live at least a buddy that worked on writing the control software told me they have a hardware module that basically shuts down the computer controlling the light if two "conflicting" green instructions are to be sent - and sets the light into the flashing red all stop condition.
I have heard, never asked my buddy to check honestly because I never thought much of it, that prolog and various other logic languages are used to do some of the traffic light control work. As I said - I'm not sure if that's true, but if so, it would certainly make sense, and should make these kind of cases near impossible to get into.
'they have a hardware module that basically shuts down the computer controlling the light if two "conflicting" green instructions are to be sent - and sets the light into the flashing red all stop condition.'
For instance - you get $X from welfare, you could make $Y doing some work despite your disability, but $Y < $X, and if you make $Y, the government won't give you $X - therefore there is no reason to pursue $Y.
Even if you don't have money, often if you're on disability anything that might show you aren't "so disabled" can stop it. Therefore even if you want to, there is really a strong reason not to try to do things.
That is what basic income is meant to really alleviate - there becomes no reason not to do other stuff, because it's unconditional - those already on welfare no longer have all those requirements.
I'm not saying it would be perfect, but I do think it would address at least part of this problem. I wish I had an actual study on the numbers of people that don't try to get jobs/be productive while on welfare because of the risk of losing the primary income stream they get from welfare, but I can't find anything. I have known several people in this situation though, and watching the system treat them that way was kind of heartbreaking.