<div dir="ltr">Hello,<div><br></div><div>Is someone adding these arguments to the wiki? </div><div><br></div><div>I apologise that I am totally swamped at the moment, and cannot easily find the time to do so, if I am to also contribute to the text of the submission (which I want to do).</div><div><br></div><div>Paul.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 5, 2015 at 1:38 AM, L. Aaron Kaplan <span dir="ltr"><<a href="mailto:aaron@lo-res.org" target="_blank">aaron@lo-res.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Sep 4, 2015, at 5:53 PM, Amelia Andersdotter <<a href="mailto:teirdes@gmail.com">teirdes@gmail.com</a>> wrote:<br>
<br>
> Thanks Luis and Paul;<br>
><br>
> In whose interest is it to stop unauthorised software?<br>
><br>
</span>As weird as it sounds but actually it really helps keeping the devices terribly insecure.<br>
You guess who would be interested in that...<br>
<span class=""><br>
> To my understanding these directives also cover stuff like wifi<br>
> connected pace-makers and so.<br>
<br>
</span>Oh, now your' talking ;) Sweet!<br>
But there is a problem with that part, see the next sentence.<br>
<span class=""><br>
> Health care apparatuses used for the<br>
> elderly, automobile on board entertainment systems and so forth.<br>
><br>
</span>Well, in that case - at least over here - we are not allowed to update them<br>
anyway. They need to be certified and after certification they MUST NEVER be updated nor changed<br>
unless they will be re-certified (and that usually takes one year).<br>
So nobody does that. I won't talk about the IT security issues of these devices now. You figure :)<br>
<span class=""><br>
<br>
> There are also blanket exemptions in Annex I for anything which is not<br>
> used commercially of the directive.<br>
><br>
</span>Would that cover stuff we are doing in community wireless networks?<br>
<span class=""><br>
> If there is a strong commercial interest behind stopping unauthorized<br>
> software that is clearly a bigger problem than if this is just a<br>
> precautionary measure by the legislature to impose more liability on<br>
> large-scale vendors of radio equipment to various other society sectors.<br>
><br>
</span>true<br>
<span class=""><br>
> One way to certify experimental solutions could perhaps be to ask the<br>
> national regulatory for a de minimis-exception: if the market shares are<br>
> so small that the burden of certification is clearly unreasonable, then<br>
> a market actor can self-certify knowing that failure to do so adequately<br>
> will impose liabilities. This rule could apply for any commercial actor<br>
> which holds less than 5% of the relevant market shares within any<br>
> particular market branch. De minimis is a known concept from competition<br>
> law, and in this case it would serve to help small market players avoid<br>
> impossible costs of certification. Something like this.<br>
><br>
<br>
</span>So this would be an idea for the putting into national law part?<br>
<br>
Best,<br>
a.<br>
<div class="HOEnZb"><div class="h5"><br>
> /a<br>
><br>
> On 09/03/15 23:20, Paul Fuxjaeger wrote:<br>
>>> On 03/09/2015, Amelia Andersdotter <<a href="mailto:teirdes@gmail.com">teirdes@gmail.com</a>> wrote:<br>
>>>> Dear all,<br>
>>>><br>
>>>> I fail to see how the EU directive hinders anyone from putting in<br>
>>>> their own software on a radio device.<br>
>>>><br>
>>>> Could someone update me? It's being implemented in Sweden with a<br>
>>>> deadline for comments in October.<br>
>>>><br>
>> Article 3, point (i) of [1]:<br>
>><br>
>> "radio equipment supports certain features in order to ENSURE that<br>
>> software can only be loaded into the radio equipment where the<br>
>> compliance of the combination of the radio equipment and software has<br>
>> been demonstrated."<br>
>><br>
>> My current interpretation is that for all devices using SoftMAC radio<br>
>> chipsets this necessitates a lockdown of the complete software stack.<br>
>> Because on such devices the code that sets the regulatory rules is<br>
>> executed in the same context as everything else.<br>
>><br>
>> AFAIK, the majority of APs currently on the market is based on such an<br>
>> architecture. Manufacturers have an alternative: switch back to more<br>
>> complex (e.g. FullMAC) architectures that allow to lock down the radio<br>
>> subsystem separately [2].<br>
>><br>
>> To me this FCC document [3] indicates complete lockdown:<br>
>><br>
>> "ENSURE that only properly authenticated software is loaded and<br>
>> operating the device [...] manufacturers may consider applying existing<br>
>> industry standards for strong security and authentication. It is<br>
>> suggested that manufacturers follow existing security standards and<br>
>> definitions: X.800, RFC 2828, and IEEE 802.11i."<br>
>><br>
>> -paul<br>
>><br>
>><br>
>><br>
>><br>
>> [1]<br>
>> <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN" rel="noreferrer" target="_blank">http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A32014L0053&from=EN</a><br>
>><br>
>> [2] Enforcement of local regulatory differences is still an issue as the<br>
>> radio subsystem cannot reliably detect where it is located without the<br>
>> help of the host system.<br>
>><br>
>> [3] <a href="http://www.heise.de/downloads/18/1/5/7/9/4/3/6/GetAttachment.pdf" rel="noreferrer" target="_blank">http://www.heise.de/downloads/18/1/5/7/9/4/3/6/GetAttachment.pdf</a><br>
>><br>
><br>
> _______________________________________________<br>
> Office mailing list<br>
> <a href="mailto:Office@openspectrum.eu">Office@openspectrum.eu</a><br>
> <a href="http://lists.lo-res.org/cgi-bin/mailman/listinfo/office" rel="noreferrer" target="_blank">http://lists.lo-res.org/cgi-bin/mailman/listinfo/office</a><br>
<br>
</div></div><br>_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" rel="noreferrer" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
<br></blockquote></div><br></div>