I was recently reviewing a collective bargaining agreement (after being approached by a campaign to add my job category to an existing union at my employer), and was surprised to find that it forced arbitration for all employee disputes, with no opt out. It's not just employers that use binding arbitration to take away workers' rights.
Adversaries don't always ask nicely. Sometimes they break in and silently take the data. These services centralize traffic flows and make it so that an adversary only needs to tap one or two circuits to get a full picture for all users of a service.
CIA is not stupid enough to break into a guarded data center in Switzerland or one of the less America friendly EU countries. They tell the NSA to look for security holes and spread narratives that only criminals use VPN hoping that a politician will notice and try to ban them, like what's happening in the UK.
Big tech services are less private than you think but almost every provider who cares about privacy is safer than you expect. Most of the people who work there are committed to their mission, and if they ever get a gag order someone will leak it in no time because they know exactly how to do it without exposing their identity.
Are you sure? Someone broke into a Hetzner data center and a Linode one, physically intercepted the Ethernet cables for jabber.ru, and got certificates signed on their behalf.
dear sockpuppet =) I think the above commenter meant illegal physical access. The jabber.ru MitM situation was likely carried out by a cybercrime unit of the German police forces with a court order... and this is the adversary most people forget about.
Lesson to learn: Let's Encrypt does not protect against MitM by a state-level actor, unless you take precautions.
*let's assume network admins won't MitM your server for personal vengeance reasons
Why would they serve a secret subpoena and gag order, when instead they can just drive to a secluded location 5km away from the super secure datacenter, dig a few meters down, passively tap a strand or two, facility and service operators none the wiser?
They’ve already done both. When they can get a cooperative party (AT&T, for example), they colocate their splitter equipment. When they can’t, they tap undersea and overland cables.
When it’s a hostile environment entirely, they hack and do secret operations and bribe.
The data would/should be encrypted; while the NSA did successfully tap Google's inter-datacenter traffic before the Snowden leaks, since then it is encrypted, too. Hopefully other providers won't fall for that trick anymore, either.
IIRC, Google addressed the incident you're referring to by adding E2E encryption to sensitive inter-DC RPC sessions, rather than by fully encrypting inter-DC traffic at the link level. It would be nice to be able to reasonably expect carrier/ISP backbones to be secure against this threat, but in our actual reality this seems like fantastical thinking.
Please correct me if I am mistaken, but unless there’s a local resolver for every single one of your clients, aren’t the DNS requests sent in plaintext to the upstream of your local resolver?
That might not be an issue for your situation, but I recall the benefit of something like Quad9’s offering is the encryption between client and their endpoint(s), particularly for untrusted ISP or similar.
Yes, that's a real benefit in many situations. Everything on your lan can do normal DNS queries to your local forwarder, which talks DNS over TLS or DNS over HTTPS to Quad9.
Downside is Quad9 can see all your DNS traffic. But without it if you run your own recursive resolver your ISP sees all your queries, and many others see portions of them, unencrypted.
> I prefer to run my own local recursive resolver.
Used to be fine. I stopped doing it when average TTL dropped to 300 seconds and it takes far too long for my local recursor to get the answer >100ms, when 3rd party resolver delivers in <10ms.
The old locality domains still exist, and in many localities you can still register them today by the same "email a request to some sysadmin" process. https://news.ycombinator.com/item?id=48122635
Your beach.santa-cruz.ca.us domain is still in DNS, just with a broken delegation chain. You could reclaim it right now by setting up a nameserver at reality.samiam.org.
OMG. That is appalling! So the document that Spiridonov submitted clearly shows how Verisign blatantly and repeatedly lied to ICANN on their application. That is absurd. I mean, they are Verisign. To just outright lie like that, about the "life-cycles of domains" and say that there is zero effect, when there are 22,000 customers affected. By Verisign. How can anyone trust them if they blatantly and verifiably lie, in writing, to ICANN? That seems like fraud to me. By Verisign, of all people.
It's genuinely hard for me to to tell which parts of your comment are supposed to be a sarcastic reaction and which parts are supposed to be serious, which could well be a failure of mine rather than yours, but, taking it all in good faith:
Summary (if you quote anything in response please try to do it from the details section as it's more accurate):
Many of the fields you may have missed explicitly say such entries will be deleted and when. None of the other fields, when interpreted in the way ICANN uses them in this process rather than personal interpretations, state there will be no impact to such registrations. The exact quantity is not really relevant nor does ICANN need that in the request form to know. The links above are about ICANN reviewing and confirming there was no error, lack of information, or false reporting in the process.
.
Details:
Changes to the life-cycles of domains is a question meant to ask if this seeks to modify the life cycle policy, which is a separate type of change from termination of the service as a whole. I.e. this does not seek to change the life cycle policy, it seeks to terminate the service offering completely - making the life cycle policy irrelevant. It'd be like saying "on the form to scrap the car they said they aren't planning to change the paint. That's fraud because after it's scrapped the paint won't be the same!" - it sounds correct if you feed it through a set of boolean gates but falls apart when you realize the request is one about getting rid of the entire car rather than about requesting to change the paint color.
The links greyface- provided are from a request to ICANN to review this particular concern. The Ombudsman looked at the same material you have seen (and more) to find:
> On the basis of the following substantive evaluation, it is evident that ICANN followed the relevant policies and underlying process thoroughly, had sufficient information, and did not rely on false or inaccurate information in taking action on the relevant RSEP Requests.
Importantly, they further say on this particular subject:
> Approximately, 22,000 domain names may seem material, and it may or may not be—in either case, it
was disclosed to ICANN by the Registry Operator as part of the collaborative process before
submitting its RSEP Requests.
With the further detail for the fields you're referencing:
> Finally, I consider whether ICANN relied on false and/or inaccurate information: None was relied on
the subject matter expert told me, nor does it appear that any such information was provided to
ICANN relating to these RSEP Requests and their preceding collaborative processes. While the
Requestor is of the view that statements provided by the Registry Operator in the RSEP Requests (“no
effect on the lifecycle of domains” “no effect on competition” and “no effect on the domain market”)
may be false or inaccurate in light of the discontinuation and termination of the approximately 22,000
registrations,28 as discussed in the preceding sections, the approximately 22,000 registrations are not
relevant to ICANN’s determination at hand, and further, as also noted above, this information was
disclosed to ICANN in the collaboration phase.
There were also several other issues raised in the reconsideration request, all were similarly found to be rooted in invalid understandings of this form or process.
That's not accurate. A valid understanding of the form/process should result in an expectation of a referral to RSTEP to evaluate the impact on security and stability. But that didn't happen.
Today I feel like some guy who spent 6 years studying the curvature of iguana toes (or something equally random) and finally sees questions about them for the first time in his life :D.
Significant effort is spent detailing the relevant parts the RSEP process, confirming and detailing exactly how it was followed correctly. This specifically included whether certain matters were considered for referral (or should have been referred) to RSTEP for review. It's a tragedy to disagree with the well written reconsideration request document without responding to where you feel its analysis was incorrect & why, particularly content from sections:
- 4.2.1, designated to contain inquiries related to the RSEP process and if it was accurately followed, including:
- 4.2.1.3 referencing the parts of the RSTEP process defining when RSTEP should be engaged
- 4.2.2.1 highlighting how voluntary advanced collaboration prior to starting the RSEP process has made the dedicated referral processes referenced in 4.2.1.3 rarely relevant
- 4.2.2.2 containing a confirmation by the Ombuds that the preliminary portion of the process was done correctly and with the required info (including the list of 22k domains shared voluntarily before the preliminary phase began, without need to formally refer to RSTEP)
- & 4.3 concretely explaining in more plain terms why the Ombuds is sympathetic to the user but believes ICANN correctly followed the RSEP process in not engaging RSTEP for the concerns raised and re-raised
About the only thing I think could have been pre-emptively added was a reference to the definitions of Security and Stability concerns, which helps explain why it would have made no sense for RSEP to declare Security or Stability issues in need of referral during preliminary review, let alone "significant" and even ignoring the voluntary early engagement activity:
> 1.2 Security - An effect on security by the proposed Registry Service shall mean (A) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (B) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.
> 1.3 Stability - An effect on stability shall mean that the proposed Registry Service (A) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (B) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services.
Requesting authorization to terminate a given service & related registrations is clearly neither an unauthorized action/disclosure on registry data as well as clearly not against an IETF RFC. Notably, "Stability" is not defined as "has impact to users" - as well stated towards the end of the reconsideration request:
> Second, on the consideration of material information – the loss of approximately 22,000 is important
to the individuals–however, this is not relevant to the strictly defined, community-developed policy
One can find the source for the material quoted in the reconsideration request response as well as the definitions I I added in above at https://www.icann.org/rsep-en/
> a person or entity that distributes an operating system or application under license terms that permit a recipient to copy, redistribute, and modify the software
which at least doesn't choose specific winners and losers among licenses. It does disfavor license-free and public domain software, which isn't great.
Technically you could argue that public domain works don't have license terms that make them free so the exception can't apply. Only an ignorant or ultra literalist judge would see it that way but you never know.
On the other hand a public domain dedication is a binding term that gives you permission (or license) to do what you want...
It only applies to software distributed under a license. Public domain software isn't distributed under a license. It's in the public domain; no license is needed.
Sure, but of minimal practical impact. The Free and Open Source community has long discouraged releasing software into the public domain, as it has clear drawbacks compared to just using a permissive licence. The legal intricacies of the public domain vary between jurisdictions. Not all jurisdictions even allow copyrights to be surrendered in this way. [0]
Licence-free isn't a concern. That isn't even close to Free and Open source software, it's the opposite: software that you aren't permitted to acquire, use, modify, or distribute. [1][2]
This is exactly what GP was talking about: entrenching a preference for one style of licensing over another. We all know what set of licenses the FOSS zealots would prefer for us to release code under, and those who release license-free or public domain software anyway typically do it with full knowledge of such arguments.
> entrenching a preference for one style of licensing over another.
Sure, that's true. The intent of the law is to give a special carve-out for, in essence, Free and Open Source software. It seems clear that it was deliberately written so as not to include proprietary freeware, say.
> We all know what set of licenses the FOSS zealots would prefer for us to release code under, and those who release license-free or public domain software anyway typically do it with full knowledge of such arguments.
Like what? Really, it's very rare for code to be released into the public domain like this. I've never seen a compelling argument for doing so. If your intention is to make the code available to all, to do with as they wish, the legal reality is that the best way to achieve this is to release the software under a permissive licence, rather than releasing it to the public domain.
If the exemption really doesn't cover public domain software, that presumably means that, as the copyrights on Free and Open Source software eventually expire and they enter the public domain, they will no longer be exempt. Again though this isn't of practical concern.
edit Come to think of it, publicly available software developed by the US federal government is released into the public domain, right? There doesn't seem to be much software like this though.
djb's software is the canonical example here: qmail, djbdns, etc. Widely used; distributed without explicit license until 2007, and placed in the public domain thereafter. No legal disputes ever arose from this.
Of course Bernstein isn't about to file lawsuits against his users, given his motives, but (prior to the public domain dedication) he might have stood a chance in court if people were downloading and using his copyrighted software without a licence. Under modern copyright law, all rights are reserved 'by default' (at least in the US). I'm not sure if a case like that has ever ended up in court, but I can't imagine any corporate lawyer signing off on acquiring and using software in that fashion.
An absence of lawsuits is not the yardstick for success here anyway. It's possible the public domain dedication deterred adoption compared to using a permissive FOSS licence. Consider Google's caution about public domain software for instance [0]. It could also be possible for software to be adopted but, if tested in future, this could be found to be legally murky.
If your intention is to make the code available to all, to do with as they wish, there's no legitimate reason to release it to the public domain rather than just using a permissive licence. If anyone with a deep knowledge of copyright law disagrees on this point, I'd be interested if you could post a link.
I'm not clear if you're doubting the correctness of what I said in my previous comment. I'm not making this stuff up, I already gave sources. The Creative Commons CC0 licence was created purely to address the legal complexities of the public domain. [1][2] (For other reasons of legal nuance, Creative Commons licences should not be used for software works, [3] but the point stands.)
> I'm not clear if you're doubting the correctness of what I said in my previous comment.
I don't dispute any of the factual or legal claims you've made. I even agree that a FOSS license is probably the best choice if the author's goal is to protect the user from the scenario where they turn evil and renege on their gift of code to the public.
In situations where I'm the author, this isn't always my goal. You know that Bernstein isn't going to go after his users, and I know that I'm not going to go after mine. Most users aren't going to be concerned about this possibility, either. Those who are concerned about it are likely to be for-profit corporations or their lawyers, and I'm not losing any sleep over making them nervous or losing them as users. I don't care to over-formalize things by invoking or even acknowledging IP law in my act of publication.
Each author's motives and goals are going to vary. It's not reasonable to enforce that "maximize assurances provided to user" is always at the top of the list for everyone.
IPFS doesn't fetch or store content that the user has not explicitly requested. If your application allows strangers to request arbitrary IPFS objects, this might be a concern. Otherwise, no, simply running a node doesn't expose you to this risk.
I was recently reviewing a collective bargaining agreement (after being approached by a campaign to add my job category to an existing union at my employer), and was surprised to find that it forced arbitration for all employee disputes, with no opt out. It's not just employers that use binding arbitration to take away workers' rights.
reply