On Fri, Sep 18, 2009 at 6:27 AM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Although the draft has expired, the concept lives on in various tools. For
example DownThemAll for Firefox supports this. There was some discussion
about including it into FF3, but then the draft was dropped and
Brian Warner war...@lothar.com writes:
From what I can tell, the Sparkle update framework (for OS-X)[1] is doing
something like what I want for firefox: the Sparkle-enabled application will
only accept update bundles which are signed by a DSA privkey that matches a
pubkey embedded in the app.
On Thu, Aug 27, 2009 at 11:57 PM, Brian Warner war...@lothar.com wrote:
== Integrity ==
To start with integrity-checking, we could imagine a firefox plugin that
validated a PyPI-style #md5= annotation on everything it loads. The rule
would be that no action would be taken on the downloaded
On Sep 15, 2009, at 4:12 PM, James A. Donald wrote:
The ideas used in Tahoe are useful tools that can be used to solve
important problems.
Yes, and I'd be happy to opine on that as soon as someone told me what
those important problems are.
--
Ivan Krstić krs...@solarsail.hcs.harvard.edu
On Wednesday,2009-09-16, at 14:44 , Ivan Krstić wrote:
Yes, and I'd be happy to opine on that as soon as someone told me
what those important problems are.
The message that you quoted from Brian Warner, which ended with him
wondering aloud what new applications could be enabled by such
On Aug 27, 2009, at 2:57 PM, Brian Warner wrote:
I've no idea how hard it would be to write this sort of plugin. But
I'm
pretty sure it's feasible, as would be the site-building tools. If
firefox had this built-in, and web authors used it, what sorts of
vulnerabilities would go away? What
Ivan Krsti wrote:
What you're proposing amounts to a great deal of complex and complicated
cryptography. If it were implemented tomorrow, it would take years for
the most serious of implementation errors to get weeded out, and some
years thereafter for proper interoperability in corner cases.
Nicolas Williams wrote:
One possible problem: streaming [real-time] content.
Brian Warner wrote:
Yeah, that's a very different problem space. You need
the low-alacrity stuff from Tahoe, but also you don't
generally know the full contents in advance. So you're
talking about a mutable stream
James A. Donald wrote:
Nicolas Williams wrote:
One possible problem: streaming [real-time] content.
Brian Warner wrote:
Yeah, that's a very different problem space. You need
the low-alacrity stuff from Tahoe, but also you don't
generally know the full contents in advance. So
[sent once to tahoe-dev, now copying to cryptography too, sorry for the
duplicate]
At lunch yesterday, Nathan mentioned that he is interested in seeing how
Tahoe's ideas and techniques could trickle outwards and influence the
design of other security systems. And I was complaining about how the
Hi Brian, all;
I'm all for including merkle trees with HTTP GETs, two items that
spring to mind:
- Appending the location of the hash as you suggest in
#hashtree=ROOTXYZ;http://otherplace which requires no changes to the
webserver.
- Adding a HTTP header with this data but requires something
Michael Walsh wrote:
- Adding a HTTP header with this data but requires something like a
server module or output script. It also doesn't ugly up the URL (but
then again, we have url shortner services for manual typing).
Ah, but see, that loses the security. If the URL doesn't contain the
12 matches
Mail list logo
