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.
