From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Should Emacs provide a uuid function? Date: Sat, 30 Apr 2011 18:22:36 -0400 Message-ID: <1637E3D0-0B95-4A47-9D27-1AE7B576BAFC@raeburn.org> References: <87ipu3v0ru.fsf@stupidchicken.com> <871v0raqub.fsf@uwakimon.sk.tsukuba.ac.jp> <42A7030B-DE0C-4CCA-A768-B82BE70C42F9@raeburn.org> <87y62yafdn.fsf@uwakimon.sk.tsukuba.ac.jp> <2E30D21A-83C0-477A-AB08-2E933A16AC2D@raeburn.org> <8762pxafce.fsf@uwakimon.sk.tsukuba.ac.jp> <09410824-6882-4736-9DB4-7D0A4837A73D@raeburn.org> <87aaf78txz.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1304202169 7747 80.91.229.12 (30 Apr 2011 22:22:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 30 Apr 2011 22:22:49 +0000 (UTC) Cc: Emacs Dev To: Stephen J. Turnbull Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 01 00:22:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QGIYl-00041u-OD for ged-emacs-devel@m.gmane.org; Sun, 01 May 2011 00:22:43 +0200 Original-Received: from localhost ([::1]:56358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGIYl-0007LM-0v for ged-emacs-devel@m.gmane.org; Sat, 30 Apr 2011 18:22:43 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGIYj-0007LF-0t for emacs-devel@gnu.org; Sat, 30 Apr 2011 18:22:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QGIYh-0004Tc-RG for emacs-devel@gnu.org; Sat, 30 Apr 2011 18:22:40 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:43553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QGIYh-0004TX-P7 for emacs-devel@gnu.org; Sat, 30 Apr 2011 18:22:39 -0400 Original-Received: by vxk20 with SMTP id 20so4586062vxk.0 for ; Sat, 30 Apr 2011 15:22:38 -0700 (PDT) Original-Received: by 10.52.69.65 with SMTP id c1mr1511591vdu.301.1304202158810; Sat, 30 Apr 2011 15:22:38 -0700 (PDT) Original-Received: from squish.raeburn.org (c-24-128-48-142.hsd1.ma.comcast.net [24.128.48.142]) by mx.google.com with ESMTPS id p29sm839136vcr.7.2011.04.30.15.22.37 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2011 15:22:38 -0700 (PDT) In-Reply-To: <87aaf78txz.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138930 Archived-At: On Apr 30, 2011, at 14:39, Stephen J. Turnbull wrote: > On the other hand, correlating my location with Suzy's is a waste of > the hacker's time, because it's easy enough to figure out where I am > several days a month from the online university course catalog and > from webserver logs (IP addresses for the rather balkanized campus > network often allows determining probable -- assuming no deliberate > obfuscation -- location within 50m). Just because some of us don't go to such efforts to keep our information = private doesn't mean others don't, or don't want to. One could use Tor = (as you suggested), or a VPN configured to tunnel even traffic destined = for the outside world. Add use of a pseudonym instead of one's real = name, and it gets trickier to trace a location. >> Different sorts of exposures lead to different kinds of >> opportunities for attacks. Just because one hasn't been closed off >> doesn't mean it's not worth looking at others. >=20 > Certainly. I don't think this one justifies an addition to core > because On its own, I'm not sure it does, either. But if any of the use cases = might want stronger privacy guarantees than some of the uuidgen = implementations provide, or there are portability issues, then "just use = uuidgen in each package" looks like a poor solution. > (3) I think the whole idea is currently only half baked, especially > with respect to UUID formats, and it would not hurt to have one or > more implementations in ELPA, which would allow experience to > determine best practice before putting in core. I'm inclined to agree, though if multiple packages in the main = distribution are (and should be) using UUIDs, eventually having a common = function included to generate them doesn't seem like a bad thing. Ken=