July 2018 - cypherpunks-legacy

[tahoe-lafs-weekly-news] TWN #14
by Patrick R McDonald 06 Jul '18

06 Jul '18

o;?========================================================= Tahoe-LAFS Weekly News, issue number 14, October 10, 2011 ========================================================= Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: http://tahoe-lafs.org .. _View TWN on the web: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: http://tahoe-lafs.org/~marlowe/TWN14.html Announcements and News ====================== Tahoe-LAFS v1.8.3 Released -------------------------- The Tahoe-LAFS project released version 1.8.3_ and 1.9.0a2 to address a security issue. A vulnerability was discovered in all versions from 1.3.0 to 1.8.2 and 1.9.0a1. This vulnerability allowed a malicious attacker to delete files. To be able to delete the file, an attacker must know its 'storage index'. An upgrade to 1.8.3 resolves this issues. The `known issues document`_ provides the technical information regarding this issue. .. _1.8.3: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006675.html .. _known issues document: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/known_issues.rst Announcing the Second International Tahoe-LAFS Summit ----------------------------------------------------- The *Second International Tahoe-LAFS Summit* will take place November 7 through November 11, in San Francisco. `Mozilla`_ |mozilla| has generously offered to host us in their nice new San Francisco office. (`Google`_ |google|, `Adobe`_ |adobe|, and `Microsoft`_ |microsoft| also offered to help out in case Mozilla's facilities weren't availablebthanks to them as well.) The Summit will have technical presentations of new features, design discussions, and probably a lot of coding! There will be live audio and video available for remote participants. `Help us organize the Summit`_ on the wiki. .. _Help us organize the Summit: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Summit .. _Mozilla: https://www.mozilla.org .. |mozilla| image:: Mozilla_logo-35x35.svg :height: 35 :alt: Mozilla :target: https://www.mozilla.org .. _Google: https://google.com .. |google| image:: Google-logo-x35.svg :height: 35 :alt: Google :target: https://google.com .. _Adobe: https://www.adobe.com .. |adobe| image:: Adobe_logo-x35.svg :height: 35 :alt: Adobe :target: https://www.adobe.com .. _Microsoft: https://www.microsoft.com .. |microsoft| image:: Microsoft_Logo_Historical.svg :height: 25 :alt: Microsoft :target: https://www.microsoft.com 1.9.0a2 Release --------------- 1.9.0a2_ was released. In addition to the security fix mentioned above, this release incorporates the following fixes: * 'tahoe debug' commands now understand MDMF caps and shares (`#1507`_) * Recent Uploads And Downloads shouldn't miss 'tahoe put' (`#1079`_) * tests run slightly faster, still kinda painful * 'tahoe put --mutable-type=.." implies --mutable * fewer dropped errors (and lost-progress bugs) in mutable retrieve * tolerate linux-3.0 in platform detection code (`#1536`_) The following work remains for the 1.9.0 release: * docs improvements * minor fixes: really really minor * packaging tests * Foolscap needs a new release, so make sure Tahoe-LAFS is compatible We highly encourage everyone to throughly test this release. The more bugs we find in the alpha, the less in the beta and the quicker 1.9.0 arrives. Currently, there is a possibility of a Halloween release of 1.9.0. .. _1.9.0a2: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006697.html .. _#1507: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1507 .. _#1079: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1079 .. _#1536: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1536 tahoe-lafs.org Outage --------------------- tahoe-lafs.org `experienced multiple outages`_ over the last several days. The outages were the result of a router which was acting up. The router has been replaced. We apologize for any inconvenience these outages may have caused. We are in the process of migrating the server to a new virtual server with professional hosting instead of being an old server humming away in someone's garage. .. _experienced multiple outages: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-October/006701.html Free/Open Source Project of the Week ==================================== The *Free/Open Source Project of the Week* is HekaFS_, formerly known as "CloudFS". Like Tahoe-LAFS, HekaFS offers provider-independent confidentiality by encrypting all of the data on the client side, with an encryption key unknown to the server. It is built on top of GlusterFS_, and it inherits most of the performance and scalability of GlusterFS. It also has the same network and filesystem semantics of GlusterFS. In contrast, Tahoe-LAFS invents new semantics such as provider-independent immutability. The HekaFS project is lead by Jeff Darcy |jeffdarcy| and sponsored by RedHat |redhat|. In addition to sponsoring HekaFS, RedHat just announced that they are buying the Gluster company. .. _HekaFS: http://hekafs.org .. _GlusterFS: http://gluster.org .. |jeffdarcy| image:: jeff_darcy-bw.png :height: 35 :alt: Jeff Darcy :target: http://pl.atyp.us .. |redhat| image:: RedHat-logo-x35.svg :height: 35 :alt: RedHat :target: https://www.redhat.com/ Commercial Supporter of the Week ================================ The Tahoe-LAFS project would like to thank `Atlas Networks`_ |AtlasNetworks| for their generous donation of four servers. In addition to the generosity of their hardware donation, Atlas Networks provide the Tahoe-LAFS project with remote consoles and technical support, including complete OS reinstalls. .. _Atlas Networks: http://atlasnetworks.us .. |AtlasNetworks| image:: AtlasNetworks.png :height: 35 :alt: Atlas Networks :target: http://atlasnetworks.us >From the tahoe-dev Mailing List =============================== Performance Measurements ------------------------ Brian Warner |brian| has been using the Atlas Networks servers to do performance measurements of Tahoe-LAFS. These measurements `show some performance issues`_, including one that arises when using large values of K (number of shares needed). Ticket 1264_ has details. .. _1264: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1264 .. _show some performance issues: .. http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006683.html Tahoe-LAFS web-app ------------------ Brian Warner `suggested`_ the notion of a "Tahoe-LAFS web-app", in which both the data and the code (Javascript) are stored in a Tahoe-LAFS grid and the browser loads them and runs the Javascript app. This would have a similar effect to the `TiddlyWiki-on-Tahoe-LAFS`_ hack, and to the `Unhosted`_ |unhosted| project. .. _TiddlyWiki-on-Tahoe-LAFS: http://tahoe-lafs.org/trac/tiddly_on_tahoe .. _Unhosted: http://unhosted.org .. _suggested: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006690.html .. |unhosted| image:: unhosted-logo.png :height: 35 :alt: Unhosted :target: http://unhosted.org Ifconfig Error Message ---------------------- Kill Your TV posted an issue with `Arch Linux and 1.8.3`_. The issue was the result of the inability of tahoe to find ifconfig. Ticket `#1536`_ was opened to provided more user friendly error messages involving finding and using ifconfig. .. _Arch Linux and 1.8.3: .. http://tahoe-lafs.org/pipermail/tahoe-dev/2011-September/006676.html Patch Needing Review of the Week ================================ There are six (6) tickets still needing review for 1.9: * 393_: MDMF * 1265_: New Visualizer is insufficiently labelled/documented (plus layout problem) * 1398_: make docs/performance.rst more precise and accurate * 1547_: the WUI controls for setting the type of an uploaded file are confusing * 1552_: web-API: replace ?mutable-type with ?format={chk,sdmf,mdmf} * 1556_: fix bugs found by 'check-miscaptures' script Let's see if we can't get these reviewed and 1.9 out the door. .. _393: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393 .. _1265: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _1398: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1398 .. _1547: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1547 .. _1552: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1552 .. _1556: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1556 ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* |zooko| *, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |brian| image:: warner.png :height: 35 :alt: brian :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Anonymity on mobile devices
by Christian Beil 06 Jul '18

06 Jul '18

Hi, developing on a project which uses Tor, I hope to get some opinions from you. I'm working with the mobile business group at my university in Germany. We are developing a platform for location-based and context-based applications. We also want to provide security and anonymity to the users of these locaion- and context-based services. Beside using pseudonyms, we want to apply an anonymizing service like Tor. Our tests with some quite fast mobile devices (PDAs) showed that Tor could not (yet) be applied directly on the client. In the first place performance of the PDAs is too low for the (many) publice key operations, and secondly setting up a circuit causes much traffic which takes long and costs money; e.g. the OR list is quite big. So we switched to a different architecture: now there is gateway to which the user connects to and which does all the anonymizing for him. This means we have a single point of failure, but we only need to connect securely (TLS,VPN,...) to the gateway. Additionally we want to enable the user to choose the way of anonymizing, e.g. using Jap or Tor. Because of this and because we use the gateway for some other things, we had to design our own protocol which is similar to Socks, but has some additional parameter for the anonymity configuration. So our architecture looks like this: the mobile client connects securely (by VPN) to the gateway, then it sends a Socks-like connect request along with the configuration parameters to the gateway, the gateway sends a request to the chosen anonymity service (e.g. talking socks5 to Tor on port 9050) and after the connection has been established the gateway forwards all incoming data. What do you think of this architecture and of anonymity on mobile devices in general? There was a system called mCrowds which implemented Crowd's Jondos on WAP-gateways. Does anyone know it? Christian ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

RE: more on Search queries *can* contain personal information
by Bill Stewart 06 Jul '18

06 Jul '18

Lauren commented on the wide range of things that people search for, and it keeps getting wider as Google and other search engines add features. I regularly type in names, phone numbers, addresses, and lat/longs, IP addresses, AS numbers, patent numbers, Cisco part numbers, etc., sometimes to find maps, or businesses, or phone book information, and there are a number of websites I use for business for which Google is a much more effective search tool than the site's own indexes. Sometimes I've even typed in my own name when looking for cached versions of mailing list articles in the distant past (non-specific ego-surfing isn't very useful if your name's not sufficiently unique - AltaVista had over 50,000 hits for people with similar names when it first came out - but there are times that specific searches are useful.) As somebody who regularly used Google during the specified period, do I have a right to object to the court if Gonzales wants my data? I hereby declare any phone numbers, addresses, and medical information in my searches to be Confidential, though the subpoena doesn't allow the recipients to declare their entire document as Confidential. Furthermore, the subpoena indicates that for every document not produced by Google due to confidentiality or trade secrecy, the respondents want the authors' and recipients' names, addresses, dates, etc. - but for this type of information, that disclosure includes the confidential portion and more, not less. Gonzales et al. allege that they're looking for information about the effectiveness of web filters as a tool for protecting children, so they want to look at popular search terms to see what people are looking at. But if I search for a term like "Scooter Libby", am I looking for information about him as an friend, or a Republican Henchperson, or a well-known pornographer? His original request wanted _all_ the search terms, including my attempts to find relatives' current mailing addresses, and makes it available to all attorneys and employees of the Department of Justice who are involved in the case - but that's all of them, given Gonzales's War on Obscenity, and nothing in the subpoena forbids them from making other uses of the information, such as using my searches for medical marijuana information for Drug War purposes. Brad Templeton talks about issues of identifying IP addresses, and the Tor project certainly helps - but there are other web surfing privacy tools, like The Anonymizer and other proxies, which are generally faster, more scalable, and effective at protecting content, though they're still susceptible to subpoenas for any information that they may have retained. Thanks; Bill Stewart ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] more on Search queries *can* contain personal information
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Anonymity on mobile devices
by Christian Beil 06 Jul '18

06 Jul '18

Hi, developing on a project which uses Tor, I hope to get some opinions from you. I'm working with the mobile business group at my university in Germany. We are developing a platform for location-based and context-based applications. We also want to provide security and anonymity to the users of these locaion- and context-based services. Beside using pseudonyms, we want to apply an anonymizing service like Tor. Our tests with some quite fast mobile devices (PDAs) showed that Tor could not (yet) be applied directly on the client. In the first place performance of the PDAs is too low for the (many) publice key operations, and secondly setting up a circuit causes much traffic which takes long and costs money; e.g. the OR list is quite big. So we switched to a different architecture: now there is gateway to which the user connects to and which does all the anonymizing for him. This means we have a single point of failure, but we only need to connect securely (TLS,VPN,...) to the gateway. Additionally we want to enable the user to choose the way of anonymizing, e.g. using Jap or Tor. Because of this and because we use the gateway for some other things, we had to design our own protocol which is similar to Socks, but has some additional parameter for the anonymity configuration. So our architecture looks like this: the mobile client connects securely (by VPN) to the gateway, then it sends a Socks-like connect request along with the configuration parameters to the gateway, the gateway sends a request to the chosen anonymity service (e.g. talking socks5 to Tor on port 9050) and after the connection has been established the gateway forwards all incoming data. What do you think of this architecture and of anonymity on mobile devices in general? There was a system called mCrowds which implemented Crowd's Jondos on WAP-gateways. Does anyone know it? Christian ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

RE: more on Search queries *can* contain personal information
by Bill Stewart 06 Jul '18

06 Jul '18

Lauren commented on the wide range of things that people search for, and it keeps getting wider as Google and other search engines add features. I regularly type in names, phone numbers, addresses, and lat/longs, IP addresses, AS numbers, patent numbers, Cisco part numbers, etc., sometimes to find maps, or businesses, or phone book information, and there are a number of websites I use for business for which Google is a much more effective search tool than the site's own indexes. Sometimes I've even typed in my own name when looking for cached versions of mailing list articles in the distant past (non-specific ego-surfing isn't very useful if your name's not sufficiently unique - AltaVista had over 50,000 hits for people with similar names when it first came out - but there are times that specific searches are useful.) As somebody who regularly used Google during the specified period, do I have a right to object to the court if Gonzales wants my data? I hereby declare any phone numbers, addresses, and medical information in my searches to be Confidential, though the subpoena doesn't allow the recipients to declare their entire document as Confidential. Furthermore, the subpoena indicates that for every document not produced by Google due to confidentiality or trade secrecy, the respondents want the authors' and recipients' names, addresses, dates, etc. - but for this type of information, that disclosure includes the confidential portion and more, not less. Gonzales et al. allege that they're looking for information about the effectiveness of web filters as a tool for protecting children, so they want to look at popular search terms to see what people are looking at. But if I search for a term like "Scooter Libby", am I looking for information about him as an friend, or a Republican Henchperson, or a well-known pornographer? His original request wanted _all_ the search terms, including my attempts to find relatives' current mailing addresses, and makes it available to all attorneys and employees of the Department of Justice who are involved in the case - but that's all of them, given Gonzales's War on Obscenity, and nothing in the subpoena forbids them from making other uses of the information, such as using my searches for medical marijuana information for Drug War purposes. Brad Templeton talks about issues of identifying IP addresses, and the Tor project certainly helps - but there are other web surfing privacy tools, like The Anonymizer and other proxies, which are generally faster, more scalable, and effective at protecting content, though they're still susceptible to subpoenas for any information that they may have retained. Thanks; Bill Stewart ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] more on Search queries *can* contain personal information
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[i2p] weekly status notes [apr 12]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, update time again * Index 1) Net status 2) SSU status 3) Bayesian peer profiling 4) Q status 5) ??? * 1) Net status Last week's 0.5.0.6 release seems to have fixed the netDb issues we were seeing (yay). Sites and services are much more reliable than they were on 0.5.0.5, though there have been some reports of trouble where a site or service would become unreachable after a few days uptime. * 2) SSU status There's been lots of progress on the 0.6 UDP code, with the first batch of commits already made to CVS. Its not anything you could actually use yet, but the fundamentals are in place. Session negotiation works well and the semireliable message delivery performs as expected. There's still a lot of work to do though, test cases to write, and oddball situations to debug, but its progress. If things go well, we may have some alpha testing next week, just for people who can explicitly configure their firewalls/NATs. I'd like to get the general operation hammered out first before adding in the relay handler, tuning up the netDb for faster routerInfo expiration, and selecting relays to publish. I'm also going to take this opportunity to do a whole slew of testing, as there are several critical queueing factors being addressed. * 3) Bayesian peer profiling bla has been churning away at some revisions to how we decide what peers to tunnel through, and though bla couldn't make it to the meeting, there's some interesting data to report: <+bla> I've performed direct node speed measurements: I've profiled some 150 nodes by using OB tunnels of length 0, IB tunnels of length 1, batching-interval = 0ms <+bla> In addition, I've just done some _very_ basic and _preliminary_ speed estimation using naive Bayesian classification <+bla> The latter was done using the default expl. tunnel lengths <+bla> The intersection between the set of nodes on which I have "ground truth", and the set of nodes in the current measurements, is 117 nodes <+bla> Results are not _that_ bad, but not too impressive either <+bla> See http://theland.i2p/estspeed.png <+bla> Basic very-slow/fast separation is ok-ish, but fine-grained separation among the faster peers could be much better <+jrandom2p> hmm, how'd the actual values get calculated - is that full RTT or is it RTT/length ? <+bla> Using the normal expl. tunnels, it's next to impossible to prevent batching delays. <+bla> The actual values are the ground-truth values: those obtained using OB=0 and IB=1 <+bla> (and variance=0, and no batching delay) <+jrandom2p> the results look pretty good from here though <+bla> The estimated timings are those obtained using Bayesian inference from _actual_ expl. tunnels of length 2 +/- 1 <+bla> This is obtained from 3000 RTTs, recorded over a period of about 3 hours (that's long) <+bla> It does assume (for the moment) that peer speed is static. I've yet to implement weighting <+jrandom2p> sounds kickass. nice work bla <+jrandom2p> hmm, so the estimate should equal 1/4 actual <+bla> jrandom: No: All measured RTTs (using the normal expl. tunnels), are corrected for the number of hops in the round-trip <+jrandom2p> ah ok <+bla> Only after that, the Bayesian classifier is trained <+bla> For now, I bin the measured times-per-hop into 10 classes: 50, 100, ..., 450 ms, and an additional class >500 ms <+bla> E.g., small delays-per-hop could be weighted using a larger factor, as could complete failures (>60000 ms). <+bla> Though.... 65% of the estimated timings, fall within 0.5 standard deviations from the actual node time <+bla> However, this has to be redone, since the standard deviation is influenced heavily by the >60000 ms failures After further discussion, bla pulled up a comparison against the existing speed calculator, posted @ http://theland.i2p/oldspeed.png Mirrors of those pngs are up at http://dev.i2p.net/~jrandom/estspeed.png and http://dev.i2p.net/~jrandom/oldspeed.png (for terminology, IB=inbound tunnel hops, OB=outbound tunnel hops, and after some clarification, the "ground truth" measurements were obtained by 1 hop outbound and 0 hop inbound, not the other way around) * 4) Q status Aum has been making lots of headway on Q as well, most recently working on a web based client interface. The next Q build will not be backwards compatible, as it includes a whole slew of new features, but I'm sure we'll hear more info from Aum when there's more info to be heard :) * 5) ??? Thats about it for the moment (gotta wrap this up before meeting time). Oh, as an aside, it looks like I'll be moving earlier than planned, so perhaps some of the dates in the roadmap might shift around while I'm in transit to wherever I end up. Anyway, swing on by the channel in a few minutes to harass us with new ideas! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXCZwWYfZ3rPnHH0RAkFGAJwPHpB7/VkZjOtpLNojf+210p0CeACfeC7t ONGe96zS1hmVNeAzqQgjeUo= =0FjK -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[i2p] weekly status notes [apr 12]
by jrandom 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, update time again * Index 1) Net status 2) SSU status 3) Bayesian peer profiling 4) Q status 5) ??? * 1) Net status Last week's 0.5.0.6 release seems to have fixed the netDb issues we were seeing (yay). Sites and services are much more reliable than they were on 0.5.0.5, though there have been some reports of trouble where a site or service would become unreachable after a few days uptime. * 2) SSU status There's been lots of progress on the 0.6 UDP code, with the first batch of commits already made to CVS. Its not anything you could actually use yet, but the fundamentals are in place. Session negotiation works well and the semireliable message delivery performs as expected. There's still a lot of work to do though, test cases to write, and oddball situations to debug, but its progress. If things go well, we may have some alpha testing next week, just for people who can explicitly configure their firewalls/NATs. I'd like to get the general operation hammered out first before adding in the relay handler, tuning up the netDb for faster routerInfo expiration, and selecting relays to publish. I'm also going to take this opportunity to do a whole slew of testing, as there are several critical queueing factors being addressed. * 3) Bayesian peer profiling bla has been churning away at some revisions to how we decide what peers to tunnel through, and though bla couldn't make it to the meeting, there's some interesting data to report: <+bla> I've performed direct node speed measurements: I've profiled some 150 nodes by using OB tunnels of length 0, IB tunnels of length 1, batching-interval = 0ms <+bla> In addition, I've just done some _very_ basic and _preliminary_ speed estimation using naive Bayesian classification <+bla> The latter was done using the default expl. tunnel lengths <+bla> The intersection between the set of nodes on which I have "ground truth", and the set of nodes in the current measurements, is 117 nodes <+bla> Results are not _that_ bad, but not too impressive either <+bla> See http://theland.i2p/estspeed.png <+bla> Basic very-slow/fast separation is ok-ish, but fine-grained separation among the faster peers could be much better <+jrandom2p> hmm, how'd the actual values get calculated - is that full RTT or is it RTT/length ? <+bla> Using the normal expl. tunnels, it's next to impossible to prevent batching delays. <+bla> The actual values are the ground-truth values: those obtained using OB=0 and IB=1 <+bla> (and variance=0, and no batching delay) <+jrandom2p> the results look pretty good from here though <+bla> The estimated timings are those obtained using Bayesian inference from _actual_ expl. tunnels of length 2 +/- 1 <+bla> This is obtained from 3000 RTTs, recorded over a period of about 3 hours (that's long) <+bla> It does assume (for the moment) that peer speed is static. I've yet to implement weighting <+jrandom2p> sounds kickass. nice work bla <+jrandom2p> hmm, so the estimate should equal 1/4 actual <+bla> jrandom: No: All measured RTTs (using the normal expl. tunnels), are corrected for the number of hops in the round-trip <+jrandom2p> ah ok <+bla> Only after that, the Bayesian classifier is trained <+bla> For now, I bin the measured times-per-hop into 10 classes: 50, 100, ..., 450 ms, and an additional class >500 ms <+bla> E.g., small delays-per-hop could be weighted using a larger factor, as could complete failures (>60000 ms). <+bla> Though.... 65% of the estimated timings, fall within 0.5 standard deviations from the actual node time <+bla> However, this has to be redone, since the standard deviation is influenced heavily by the >60000 ms failures After further discussion, bla pulled up a comparison against the existing speed calculator, posted @ http://theland.i2p/oldspeed.png Mirrors of those pngs are up at http://dev.i2p.net/~jrandom/estspeed.png and http://dev.i2p.net/~jrandom/oldspeed.png (for terminology, IB=inbound tunnel hops, OB=outbound tunnel hops, and after some clarification, the "ground truth" measurements were obtained by 1 hop outbound and 0 hop inbound, not the other way around) * 4) Q status Aum has been making lots of headway on Q as well, most recently working on a web based client interface. The next Q build will not be backwards compatible, as it includes a whole slew of new features, but I'm sure we'll hear more info from Aum when there's more info to be heard :) * 5) ??? Thats about it for the moment (gotta wrap this up before meeting time). Oh, as an aside, it looks like I'll be moving earlier than planned, so perhaps some of the dates in the roadmap might shift around while I'm in transit to wherever I end up. Anyway, swing on by the channel in a few minutes to harass us with new ideas! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXCZwWYfZ3rPnHH0RAkFGAJwPHpB7/VkZjOtpLNojf+210p0CeACfeC7t ONGe96zS1hmVNeAzqQgjeUo= =0FjK -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p(a)i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [ZS] Re: AGI optimism.
by Bryce Lynch 06 Jul '18

06 Jul '18

On Wed, Feb 6, 2013 at 5:04 PM, Dirk Bruere <dirk.bruere(a)gmail.com> wrote: > I find it difficult to believe that at least the NSA is not funding AI > to this level. > The thing about government agencies (US government agencies, in particular) is that they are brutally pragmatic. If they thought - really, really thought - that having a human-equivalent AGI running in a data center would let them accomplish their goals, they'd do it in a heartbeat. There's no guarantee that it would actually happen, because the government/contractors system is horribly inefficient, but an attempt would be made. It seems, by all accounts, that the NSA is more concerned with being able to break crypto than they are having a human-equivalent intelligence. From what I've heard from more-or-less reliable sources, they need raw number crunching power and disk space for huge rainbow tables to do what they need to do and be able to show results. If anything, I think the DoD would be more interested in having an AGI, but they have more than enough trouble to deal with on the infosec side of the house. -- The Doctor [412/724/301/703] [ZS|Media] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero --- You received this message because you are subscribed to the Google Groups "Doctrine Zero" group. To unsubscribe from this group and stop receiving emails from it, send an email to DoctrineZero+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0