Il 26/01/2014 17:27, Roland Perry ha scritto:

In message <D1AC4482BED7C04DAC43491E9A9DBEC3901E9E87@BK-EXCHMBX01.blacknight.local>, at 15:08:24 on Sun, 26 Jan 2014, Michele Neylon - Blacknight <michele@blacknight.com> writes

...

And I thought this paper was about domains more than domain registries?

Well, actually both of them are covered in my draft.

Yes, which is why the paper should positively avoid the inclusion of confusing examples such as domains operated by I* entities.

Within the document I used the example.com domain just to give readers a name which was "neutral" and easy to remember; my intention was not to use the example.com "technical background" such as the real NSs operated by IANA. Anyway if you believe that it could confuse more expert readers it can be replaced with another, as suggested by Roland. In this case maybe it could be useful to find as many sample domains as the cases covered by the document, each domain reflecting the specific technical configuration each time described. My only fear is that this may lead to a more difficult reading for non-expert people (who are the real audience). -- Pier Carlo Chiodi http://pierky.com/aboutme The opinions expressed here represent my own and not those of any organization, entity or committee to which I may hold a position.

Il 26/01/2014 18:30, Roland Perry ha scritto:

...

my intention was not to use the example.com "technical background" such as the real NSs operated by IANA.

Except your diagrams quote "a.iana-servers.net" as the NS, which is where the potential for great confusion kicks in.

That's right, the diagram on page 6 uses the real authoritative nameservers for example.com, because there I show how really example.com works. In the rest of the document I used the example.com in other scenarios too, many of them fictitious (blog.example.com, criminal.example.com), just for the purpose of describing the specific situation.

I think a suitably-chosen example would be much less difficult for the non-experts (they won't go away with the impression that IANA runs everyone's NS).

Would not this just move the problem toward the new domain's registry and NSs? If the impression that the document gives is this, maybe something else should be changed too.

Choosing an example isn't easy (if it was, I'd have suggested one already). In a perfect world we'd have Ripe-NCC set up a dedicated one with the desired characteristics for us. (Something like target-domain.org, with three NS in different parts of the world, none of them on I* networks.)

A RIPE-NCC members feedback would be greatly appreciated on that! :) P.S.: in the meanwhile I fixed two typos on diagrams of page 13 and 15: blog.example.com instead of blog.www.example.com. -- Pier Carlo Chiodi http://pierky.com/aboutme The opinions expressed here represent my own and not those of any organization, entity or committee to which I may hold a position.

I am extremely concerned about giving even the slightest [mistaken] impression that anyone's NS are located at IANA [other than a handful of I* community sites of course].

I understand your concerns; if we want to replace example.com IMHO we must find a couple of suitable, short and easy names, maybe also fictional, and use them to label the target domain and its authoritative servers. Can we use something on the ripe.net zone?

Perhaps we could use something like example-network-A.com, example-network-B.com, example-network-C.com as the Name Server host networks.

They could be valid but I'm afraid that they are too long and too similar.

I realise that if users of *some* legacy systems can employ circumvention it's still a problem, but the migration to mobile platforms is rapid and significant, and they are much less susceptible to user customisation.

While providing a mobile-focused overview may be a good idea, I think that we should not suggest governors and lawmakers to positively judge a blocking measure just because it's not easy to circumvent on some devices (and that's not totally true too - please see below). I think we should pursue a globally valid criterion and we must avoid recommendations based only on difficulties that users may encounter to bypass blocking systems. Moreover, most of the issues I can see are not related to the efficacy of blocking measures, but to damage and side effects that they imply.

On my Android phone, for example, I can't even see a way to change it from DHCP (which I assume it's using) to a fixed DNS server of *my* choice. I imagine an iPhone or iPad is the same.

On your wifi network you can change your DHCP server configuration and send them your preferred DNS servers. An app to change DNS on Android and an iPhone guide follow; I can't tell you if they work, but from a quick search on Google it seems that's not so hard to change configurations on mobile devices. Also VPNs are easy to setup on both systems. https://play.google.com/store/apps/details?id=uk.co.mytechie.setDNS http://www.macinstruct.com/node/558 -- Pier Carlo Chiodi http://pierky.com/aboutme The opinions expressed here represent my own and not those of any organization, entity or committee to which I may hold a position.

Roland Perry wrote: [...]

...

Can we use something on the ripe.net zone?

It seems unlikely that such a domain would have nameservers outside the I* community, and many (I have looked) have six or more NS, which is also a bit unusual and potentially giving the wrong impression.

(And if you mean literally within the ripe.net zone, I already noted that it has six NS, located at RIPE-NCC and at I* colleagues: nic.fr, apnic.net, isc.org and arin.net)

In a former job we wanted an example domain for use in marketing material, so we registered one but never used it. I checked just now the domain is still registered to the successor business. If a commercial organisation can keep a domain registered for 17 years following an aborted marketing campaign I am confident that people in this community could register and maintain a domain for use in educational material for as long as the material remains relevant. Regards, Leo Vegoda

On Tue, Jan 28, 2014 at 12:25:58PM +0000, Roland Perry wrote:

I realise that if users of *some* legacy systems can employ circumvention it's still a problem, but the migration to mobile platforms is rapid and significant, and they are much less susceptible to user customisation.

that's probably true, but I'm not sure what follows in the context of this group. The return of walled gardens and gated access to Internet infrastructure - incumbents' dark desires - appear part of the problem rather than of the solution to me - even if that happens by customer "demand". -Peter

On 26 jan 2014, at 17:27, Roland Perry <roland@internetpolicyagency.com> wrote:

...

And I thought this paper was about domains more than domain registries?

Yes, which is why the paper should positively avoid the inclusion of confusing examples such as domains operated by I* entities.

My view is that a paper should include example domain names that are defined to be example domain names. See RFC2606 / RFC6761 (i.e. BCP32). I.e. I think the author of this document has done the right thing. Patrik

The structure is really good, and the lively debate on this thread indicates that the work here is on the right path.

Thanks for your feedback Meredith, greatly appreciated. My hope is that, thanks to our work, RIPE can soon have its own document to support governments in outlining pros and cons of various content filtering methods and, above all, to help them in understanding limits [1] and collateral damage that most of the currently deployed measures have.

With that, I have one high-level, two-paragraph comment that I hope adds to the discussion.

I would suggest removing the target audience --

That's right, also the title ("An analysis on web filtering methods for law enforcement purposes") should be changed ;-)

Page 8 and 9 suggest means of using these techniques for "preventing access to illicit content." I would suggest removing this section

[...]

Insofar as this is a document focused on the means, not the ends, speculating on "good" vs. "bad" modes of filtering/blocking, even implicitly, leads quickly to our having to justify one or another ethical viewpoints

Perhaps changing it rather than removing it may have the same effect. "Illicit content" could be changed in "unwanted"/"undesired" and something like the introduction of [2] may be used to depict the scope of application. Since I wrote the whole text considering only the law enforcement perspective, as soon as I can I will review the whole document to have a more clear idea of changes to bring in in order to make it detached from any ethical viewpoint.

At this stage, I would suggest thinking of others we might want to bring into the discussion.

It may be useful to bring in both technical and non-technical people. Innocenzo Genna [3] might get involved in: I don't know him well, I just follow his blog [4], but, as far as I can see, he recently participated in the November coop-wg meeting with EU Parliament and he's active in the tlc and internet regulation & policies areas. He might offer a non stricly technical point of view about our work. Do you think he could be of help for the cause? [1] It looks like someone is already realizing them - https://publicaffairs.linx.net/news/?p=10264&utm_source=rss&utm_medium=rss&utm_campaign=dutch-appeal-court-removes-pirate-bay-block [2] "Technical Considerations for Internet Service Blocking and Filtering" - http://tools.ietf.org/html/draft-iab-filtering-considerations-05 [3] "Innocenzo is an expert of European regulation and policy in the areas of Internet and telecommunications" - http://www.innocenzogenna.com/en/bio.php [4] http://radiobruxelleslibera.wordpress.com/ -- Pier Carlo Chiodi http://pierky.com/aboutme The opinions expressed here represent my own and not those of any organization, entity or committee to which I may hold a position.

Il 30/01/2014 17:04, Peter Koch ha scritto:

On Tue, Jan 28, 2014 at 05:42:17PM -0500, Meredith Whittaker wrote:

...

I would suggest removing the target audience -- here started as law enforcement and governments -- and dedicating this work more broadly to anyone who's interested in this topic and would like a basic understanding

so, this paragraph in the draft was one that I like very much because it is forgotten too often and helps focus the document. It also frames expectations on the side of the raeder.

Accepting Meredith's remark, but also keeping focus on my original aim, I changed the paragraph of page 4: This document is _particularly_ addressed to legislators, agencies, stakeholders, courts and to whoever may be involved in Internet governance and engaged in law enforcements on the network, and also to who is interested in this topic and would like a basic understanding of mechanisms and approaches used by whoever to block or prevent access to contents. In my opinion this paper should stay focused on RIPE coop-wg target audience, which is especially governments and regulators.

seconded. Also, the actors (LEA in this case) could better be left away. It's not important for the method who's asking/ordering/threatening/volunteering.

I changed paragraphs on page 8 too and also any occurrence of "illicit" / "LEAs" with "unwanted/undesired/forbidden" and a generic "requestors" or "requesting governments". Web blocking and filtering are measures usually requested by governments [...] addressed to prevent access to illicit contents such as pedo-pornography [...] or even to constrain access to opposing political or religious contents or to quiet debates that threaten the parties in power. These measures are particularly used when the _undesired_ content is hosted on servers that are out of the jurisdiction of the _requesting party_, so when it’s not possible or very difficult to order the website operator to remove the _unwanted_ material from its servers. In such cases ISPs operating under the jurisdiction of the requestor are imposed to prevent their customers to access the identified resources. Optionally, they may be asked to redirect customers who try to access the _forbidden_ content to a web page reporting additional information, such as the legal notice about the blocking measure (“stop-page”).

The draft could benefit from a terminology pass sooner than later.

Yes, I'm the first to admit it, it needs a review on both technical terminology and grammar (as you can see my English is not very good); now the document is hosted on Google Drive, if someone wants to take care about that I can give him/her write permissions.

We've already has some debate about "authoritative servers", where that was meant to be registrations at the second (or third, for that matter) level.

I missed that debate so, for clarity, this is what I meant in the document (please refer to diagram on page 8): - root servers: servers that hold TLD-registries mappings; - registries: servers that hold TLD-domain mappings; - authoritative servers: servers that hold the domain zone. I know that "authoritative" is something else, every server is authoritative for zones it directly serves, but I preferred to use a not strictly proper terminology for the sake of reading easiness. Any suggestions/corrections would be appreciated.

I'd also suggest to skip the part about domain name "takedowns". It has similar side effects but is really different from filtering.

Because domain name takedowns are actually used to prevent users from accessing contents I think it's correct to include them in this document and to show their pros and cons there. Am I the only one to think that?

Speaking of side effects, the language chosen in that section sounds tentative and defensive to me ("may", "could be"). While applicable in an academic debate, the other party is absolutely undoubtful about their doing the Right Thing.

Sorry, my fault; here a native English speaker can render the idea better than me.

While at it, I'd not support the myth that DNSSEC and suppressing DNS responses are incompatible. While the changes applied are either detected and suppressed by the validating resolver or injected at that very place (again, the ISP), the result usually is either you receive the government enhanced response with the seal of the validator or you get an error response, in which case the end user still can't access the site.

DNSSEC and response suppression are not incompatible, even if DNSSEC is implemented in the resolver the final result is anyway achieved and the user is anyway prevented from accessing the website (maybe he/she will not get the stop-page but of course he/she will not open the website too). I'm more concerned about the fact that such blocking measures can have impact on the background philosophy that is behind DNSSEC, impair trust on it and slow down its deployment rather than about technical issues. Please refer to this Paul Vixie's post [1]; he explains far better what I mean. Do you think that's only a vague and unfounded fear?

Careful with the risk assessments:

DNS blocking techniques may be used to defeat cybercrime too, by blocking those domain names which are dedicated to frauds, phishing or malware distribution (viruses, trojans, #). If users decide to change their device configuration and use public open resolvers to access (over-) blocked content any local anti-cybercrime activity is vanished.

Sounds either like an encouragement to restrict/regulate access to alternative resolution mechanisms or like a "then don't do that".

I think it's a side effect of measures that don't solve the problem but just hide it. Maybe the paragraph can be arranged in another way if you think it leads to wrong impressions.

Finally, again on wording, apologies,

These topics are complex and we need to find the better way to explain them.

we should not call the mechanisms "content filtering" because all they do is fiddling with levels of indirection that mediate access to the content rather than the content itself.

Correct, in the overblocking paragraph a distinction is already made between domain seizure and content filtering, anyway I changed some occurrences of "content filtering" in the rest of the document.

To that extent, referring to the DNS as the "phone book" has helped quite a couple of times. People understand that de-listing does not make the number inaccessible. YMMV.

It's a very good example, easy to understand, I'll see how to merge it in the document: any suggestions?

PS: my contribution to the bikeshed part of the debate: for diversity, but especially in a European context, we could use somthing other than the COM gTLD in the examples. That's even more important for those parts that I suggested to skip, since it will emphasize that ICANN is not in the game in many cases.

Roland Perry speculated about the chance for a dedicated domain set up by RIPE for our purposes... this would be the perfect solution. Thanks for your feedback Peter, they have given the chance to take stock of the situation! [1] "Defense in Depth for DNSSEC Applications" - http://www.circleid.com/posts/defense_in_depth_for_dnssec_applications/ -- Pier Carlo Chiodi http://pierky.com/aboutme The opinions expressed here represent my own and not those of any organization, entity or committee to which I may hold a position.