From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 27AB621FC8E; Fri, 25 Sep 2015 14:40:03 -0700 (PDT) Received: by oibi136 with SMTP id i136so65420135oib.3; Fri, 25 Sep 2015 14:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SovhsXxJi2FN4IOMuIX9pXdJrS/+MzHfFqvgxEWBoMg=; b=v7rB5/CWtmr6Q/uOp7Pm1HhI6p5EPr6TOneckY45IIf/wku14RGgSMo05Fwyz4tpl8 5rIyPUkbaI7sKPGTAnsSbZ5B6afUXlclhiD3lBYxrSpX3pqmYFhuxywLZMJ92EjFT/Aw x2Ruc89238Sy5TJWUJooP01eD76lTcxApH1Fhexcz4n8PMI5v/idfBFYqgYXvrlaaNBU 1r9Sn3RNCRqaxlBQ3f0A0eKLInljGjT802W4VNTPn+QBR0dGeYDye20rtuQRX8Mzgnw2 TCO1NlhJYno/W17n3f5x7Hx16uXOp3dkgAsb5Yb8MjRsx8WhzcPe5DqwRqAGsL8A4qQY h+OQ== MIME-Version: 1.0 X-Received: by 10.202.203.194 with SMTP id b185mr4134960oig.104.1443217202954; Fri, 25 Sep 2015 14:40:02 -0700 (PDT) Received: by 10.202.108.212 with HTTP; Fri, 25 Sep 2015 14:40:02 -0700 (PDT) In-Reply-To: <49d53a3e-b7a0-4069-a87b-d9778bb8a229@reed.com> References: <49d53a3e-b7a0-4069-a87b-d9778bb8a229@reed.com> Date: Fri, 25 Sep 2015 22:40:02 +0100 Message-ID: From: Dave Taht To: "David P. Reed" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , fcc@lists.prplfoundation.org Subject: Re: [Make-wifi-fast] [Cerowrt-devel] some comments from elsewhere on the lockdown X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 21:40:26 -0000 The core of the FCC letter is currently this. comments? snip snip In place of last year=E2=80=99s and the new proposed regulations, we propos= e a system of rules that would foster innovation, improve security, make Wi-Fi better, and overall improve usage of the Wi-Fi spectrum for everybody. 1) Mandate that: for a SDR, wireless, or Wi-Fi radio of any sort - in order to achieve FCC compliance - full and maintained source code for at least the device driver and radio firmware be made publicly available in a source code repository on the internet, available for review and improvement by all. 2) Mandate that: the vendor supply a continuous update stream, one that must respond to regulatory transgressions and CVEs within 45 days of disclosure, for the warranted lifetime of the product + 5 years after last customer ship. 3) Mandate that: secure update of firmware be working at shipment, and that update streams be under ultimate control of the owner of the equipment. Problems with compliance can then be fixed going forward. 4) Failure to comply with these regulations will result in FCC decertification of the existing product and in severe cases, bar new products from that vendor from being considered for certification. 5) In addition, we ask that the FCC review and rescind the rules for anything that conflicts with open source best practices, and/or which causes the vendors to believe they should hide the mechanisms they use by shipping undocumented =E2=80=9Cbinary blobs=E2=80=9D of compiled code. = This had been an ongoing problem to all in the internet community trying to do change control and error correction on safety-critical systems. On Fri, Sep 25, 2015 at 9:16 PM, David P. Reed wrote: > Those of us who innovate at the waveform and MAC layer would argue > differently. The cellular operators are actually the responsible control > operators and hold licenses for that. They may want to lock down phones' > cellular transmitters. But U-NII and ism bands are not licensed to these > operators. There is no license requirement for those bands to use particu= lar > waveforms or MAC layers. > > So this is massive overreach. The control operator of the "licensed by ru= le" > Part 15 radios in your phone or home are licensed to the device user and = not > to the mfr at all. For example, the user is responsible that the device n= ot > interfere with licensed services, and that the device stop transmitting i= f > such harmful interference is called to their attention, *even* if the dev= ice > passed certification. > > Lock down has not been demonstrated to be necessary. This is all due to > fearful what - if speculation by people who have no data to justify the > need, plus attempt to stop innovation by licensees who want to exclude > competitors from being created, like LTE operators proposing LTE-U which > will be locked down and is the stalking horse for taking back open part 1= 5 > operation into a licensed regime based on property rights to spectrum. > > > On Sep 24, 2015, Dave Taht wrote: >> >> a commenter that I will keep anonymous wrote: >> >> >> Regarding the FCC firmware lockdown issue, I=E2=80=99m sure you=E2=80=99= re aware that >> baseband firmware in cellphones has been subject to similar >> restrictions for some time. In fact, the FCC effectively mandates that >> baseband functionality is implemented on a whole separate subsystem >> with its own CPU to make it easier to isolate and protect. Also, the >> cellphone system is designed so that a misbehaving node can be easily >> identified and blocked from the network, making it useless and >> removing most of the incentive to find ways around regulatory >> restrictions. Wi-Fi devices have none of these protections. >> >> I believe this new attention to Wi-Fi devices is a consequence of many >> factors: >> >> The precedent from cellphone baseband firmware control; regulators are >> easily inspired by success stories in related areas >> The substantial increase in flexibility offered by SDR implementations >> Technical ignorance, for example of the difference between OS, >> protocol, and UI firmware and baseband firmware >> The expansion of allowed capabilities in Wi-Fi hardware (from 5.8 GHz >> ISM to the U-NII bands, increases in transmit power allowances, etc.) >> The improved spectrum utilization of newer Wi-Fi modulation schemes >> Inconsistencies among international regulations for spectrum allocation >> Spectrum sharing between Wi-Fi and life safety applications >> The relative lack of attention to (and sometimes, the deliberate >> flouting of) regulatory constraints in open-source firmware >> The increased availability of open-source firmware for higher-power >> and narrow-beam Wi-Fi devices (not just the WRT-54G :-) >> >> >> And probably more I can=E2=80=99t think of off the top of my head, but w= hich >> regulators are obsessing over every day. >> >> Although I agree with the spirit of your FCC email draft letter, it >> does not address most of these factors, so it=E2=80=99s likely to be see= n as >> missing the point by regulators. If you want to reach these people, >> you have to talk about the things they=E2=80=99re thinking about. >> >> What you ought to be pushing for instead is that Wi-Fi devices be >> partitioned the same way cellphones are, defining a baseband section >> that can be locked down so that the device can=E2=80=99t operate in ways= that >> are prohibited by the relevant local regulations, so that the OS, >> protocol, and UI code on the device can be relatively more open for >> the kinds of optimizations and improvements we all want to see. >> >> It=E2=80=99s possible that the partition could be in software alone, or = in >> some combination of hardware and software, that doesn=E2=80=99t require = a >> cellphone-style independent baseband processor, which would add a lot >> of cost to Wi-Fi devices. For example, the device vendor could put >> baseband-related firmware into a trusted and _truly minimal_ binary >> module that the OS has to go through to select the desired frequency, >> power, and modulation scheme, even for open-source solutions. That >> doesn=E2=80=99t mean the source code for the binary module can=E2=80=99t= be published, >> or even that there can=E2=80=99t be a mandate to publish it. >> >> I=E2=80=99m sure that doesn=E2=80=99t sound like a great solution to you= , but making >> it easy for end users to configure commercial devices to transmit at >> maximum power on unauthorized frequencies using very dense modulation >> schemes doesn=E2=80=99t sound like a great solution to regulators, and t= he >> difference between you and the regulators is that they are more >> determined and, frankly, better armed. It will do you no good to >> constrain the range of the solutions you=E2=80=99ll accept so that it do= esn=E2=80=99t >> overlap with the solutions they will accept. >> >> . png >> >> >> On Sep 21, 2015, at 5:10 AM, Dave Taht wrote: >> >> >> Dave, >> >> >> Huh. I have been interested in mesh networking for a couple of years >> now, and curious about Battlemesh, but I had no idea I knew someone >> who was active in it. >> >> >> Are there any other reports online from this year or last year? The >> website doesn't seem to serve any purpose beyond announcing the event. >> >> >> >> As you can tell I am way, way behind on my email. I've mostly been >> chasihg funding for my main project, make-wifi-fast for over a year >> now - I added in the mill and the "cake switch chip" to that overall >> list as I tried to climb the financial ladders. My funding at google >> dried up suddenly (due to the re-org), and I was forced to chase other >> avenues. I think i got a grant from comcast coming in, but it is for >> 1/10th the total I needed for make-wifi-fast... and it is hung up in >> legal, and in the fact the work has to mostly happen in europe. >> >> So I've moved to europe, trying to find bases in bristol, england, >> berlin, and sweden. That's taken a while (I dropped out of the mill >> process in may or so due to the sudden google silences, and the lack >> of compiler - and I view mill's biggest problem is funding, so it >> seems like just combining my own quest with yours the right thing) >> >> I was very involved in the early days of wireless networking but >> dropped out by 2002 or so, much to my now, later regret. The only devs >> left that understand it at more than one level all go to battlemesh, >> so I've been there twice. I still find it quite discouraging how few >> grok the minstrel algorithm, or what is wrong with packet aggregation. >> A billion+ users that all think wifi "just works", and "always >> sucked"... :( I gave a talk on the latter as well at at this >> battlemesh. >> >> anyway the videos and results from this battlemesh are all now online. >> I am pushing on all fronts, but being a manager was a bit wearying so >> I took time out to do some recording at a place called theconvent.net >> for the past 2 weeks. Haven't played the piano so much in 5 years! >> >> Youtube videos: >> >> https://www.youtube.com/channel/UCxfh-2aOR5hZUjxJLQ2CIHw >> >> blog post: >> https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-storie= s/ >> >> The test results were dismal, as expected. Finally knocking a few >> heads to use abusive network tests like what toke and I developed were >> hopefully an eye-opener, and a lot more people grok what >> make-wifi-fast is really about, and how to do it. >> >> http://docs.battlemesh.org/ >> >> one very positive outcome of the fcc talk was a level of net outrage >> and organisation over some new fcc rules I have not seen before. My >> letter to the fcc, in progress, with vint cerf and other >> co-signers is up for review at: >> >> >> https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq5= 7ysFtAA/edit?usp=3Dsharing >> >> A similar letter has to go to the eu, as they just passed similar rules. >> >> as much as I would like to be working on the mill, it seems politics, >> finance, and organisation are in more need of my attentions right now. >> but I will keep plugging y'all at every opportunity. >> >> But, but... as I said, I just took a few weeks off and am picking up >> the pieces and trying to figure out what to focus on, at the moment. >> >> If you wish a faster response to my email, please use dave.taht@gmail.co= m >> >> >> > > -- Sent with K-@ Mail - the evolution of emailing. --=20 Dave T=C3=A4ht endo is a terrible disease: http://www.gofundme.com/SummerVsEndo