Q: What's the name of your working group? A: Right. Q: "Right" is the name of your working group? A: No, WHAT is. Q: What is what? A: WHAT is the name of my working group. Q: That's what I just aksed you. A: No, that's what I just told you. Q: No, no -- just tell me the name of your working group! A: WHAT. Q: I said, tell me the name of your working group. A: WHAT. Q: WHAT'S THE NAME OF YOUR WORKING GROUP, DAMMIT!? A: Right! But my name's not Dammit... (strangling noises)
Frankly, it's a waste of my time to animate the zoom from continental view to street -- just show me what I want to see. I tried using map24, and it (1) takes forever to load, (2) is less readable and much smaller than Google Maps, and (3) spammed by browser with Java errors when I killed it's tab. Google's interface seems much more lightweight, robust, and readable.
But the stuff posed in this article will give you a headache.
Instead, check out David Cope's Experiments in Musical Intelligence. You can download mp3s of some great pieces modeled after great composers. And the computer science behind it is also cool: Cope's approach involved developing a grammar for music, such that the generated pieces followed this grammar. Much easier on the ears:)
It's fun to think about how they'll do failover between the primary and the backup: move the backup into position directly over the primary, then move the primary out of the way, and presto -- the backup is in position (maybe 100M too high, but this should be close enough to provide some service until it can descend to the correct altitude). Meanwhile, the primary can land and get serviced.
research paper on visualizing intrusions
on
Computer Forensics
·
· Score: 1
A recent research paper from University of Michigan, Backtracking Intrusions, presents a tool for identifying and visualizing the cause of suspicious behaviors (e.g., "where did the file/tmp/rootkit come from?"). A very nice paper and a significant contribution to intrusion forensics.
I did a co-op as an undergraduate that taught me many things (source control, new programming languages, team projects) that made it far easier to get a job. The CS degree is vital, of course, for you to learn how to approach complex computational problems and reason about various solutions (is this the right data structure for this problem? how to I optimize the common case in this system? what are the invariants for objects of this class?). Its the two together -- real experience and the CS background -- that will make you an attractive job candidate. The name of the school matters far less than your mastery of the fundamentals and your experience applying them.
The problem with public terminals is that every person who logs in acts as the same user, therefore later users see the data for earlier ones. What's interesting is that some public terminals go to great lengths to scrub the data between logins so that later users don't see earlier ones' impacts.
But this scrubbing doesn't clear Google Desktop, so its data spans logins. I suppose one could extend the inter-login scrub to also clear GDS, but what's the point? Might as well just omit GDS altogether. But one must also prevent users from installing GDS when they use the terminal. You could do this by disallowing all downloads, but this may be too strict (especially if you want to encourage users to use your terminal for a long time, and so they may want to install software for the duration of their session, e.g, Putty). In this case, the terminal has to prevent the installation of GDS but allow other software.
All in all, this issue is more subtle than it appears on the surface. Hopefully the response will be better public terminal software, rather than worse GDS software!
I agree -- I'm more of a Star Wars fan than a trekkie, but I think Star Trek has more well-understood races than Star Wars, thanks to all the shows. It would be pretty cool to be able to play as RPG in 3 environments: on planets, on space stations, and on large ships -- all 3 are large enough to have full economies of their own. And compared to Star Wars, Star Trek offers many more factions: instead of just Empire and Rebel, there are each of the separate races, as well as the Federation and everyone else. Plus there's more content to draw on than Star Wars (SWG didn't do much of anything interesting content-wise). All-in-all, the idea has potential, and I hope they do a good job with it!
(Ferengi would make the perfect merchant class, btw)
Your use of quotes around "efficient" is very telling. Los Angeles is one of the most high-traffic, polluted cities in the US (Houston has recently beaten it for the title, thanks much to GWB). I grew up in Houston, went to college in upstate New York, have lived in Boston the last several years, and am about to move to New York City. I see the attraction in wide open rural areas, and I see the attraction in dense walking cities like Boston and New York. But I really don't see why sprawling cities like Houston and LA are any good. They're ugly, and it takes just as long to get place-to-place in a sprawl city as in a denser city or rural area. Perhaps flying cars could somehow give us the best of both worlds?
Another of the problems with these approaches (besides the need to send cover traffic, as you mentioned) is that pseudo-random path selection may not be random enough. Certainly an "omnicient" adversary could run various correlations to determine who is sending data to whom, and it becomes very difficult to make convincing arguments as to whether more realistic adversaries can glean information from the traffic they observe. If there's one lesson we've learned from crypto research, it's that smart mathematicians can usually find patterns in pseudo-random data, so the real question is whether a system provides "sufficient" anonymity (since perfection is likely impossible to achieve). Another question is how long that anonymity lasts, say, against offline analyses by semi-omnicient observers (agencies?). Is a month long enough? A year? Or "as long as men are capable of doing evil"? These are not simple questions to answer, unfortunately, as much as we might wish that anonymity were something simple to achieve!
The id Store doesn't seem to be selling Doom 3. Clicking "Buy Now" from the Doom 3 site provides links to EB Games, Gamestop, and Best Buy. I guess the other comments were right about id wanting to develop good relations with their retailers!
A possible inquiry could be: I am searching for topics about peer-to-peer technologies.
As a result Bibster returns bibliographic entries concerning peer-to-peer technologies.
Next, they'll perfect image search:
A possible inquiry could be: I want to see defiance in the face of insurmountable odds.
As a result Imagester returns images depicting defiance in the face of insurmountable odds.
Seriously, are they offering anything better than standard keyword and author search? What I'd really like to see is such a bibliography database that ranks search results usign a PageRank-like algorithm (as I recall, the idea for PageRank derived from research on citation graphs, so this would bring things full circle).
I'd also like to see Google start parsing publications and indexing them by author, year, and citations. The bibliography databases that I'm familiar with require manual input of new entries; it would be cool if this could be done automatically instead. Of course, there will need to be some interface to correct erroneous entries, and this opens up a large can of worms.
Yeah, that's the general problem with cryptographic endorsement systems. Sites like Amazon and CNet support ratings of items without every suing crypto, because we trust those sites to accurately represent the ratings we give. There's no real reason why Wikipedia can't do the same for endorsements. Crypto is only needed if we want to avoid trusting Wikipedia for some reason.
That seems doubtful. A home page that anyone can edit would get old really quick.
Perhaps; but as is being discussed in other threads, there are many ways to control bad edits in a Wiki. Worst case, you can restrict your home page to be editable only by you.
What's unclear to me is whether a social-network-Wiki is really better than a traditional social network system. Most traditional social networks are very structured: you tell the system who your links are, how well you know the people you're linked to, and lots of specific data about yourself (gender, age, hometown, interests). The system uses this to provide services like search filtering and interest matching.
Using a Wiki to define your links and interests might make implementing these features difficult. Perhaps a hybrid would make sense: you have structured ways to define links, etc, but you also have a Wiki to create your personal page and host discussions.
I agree that signatures should be downloadable and verifiable by the public. All I suggested is that we trust Wikipedia to provide the correct MD5 hash of the article as a matter of convenience. But you're right that we can remove this level of trust if Wikipedia can also provide the canonical source of the article (so that people can verify the hash / signature themselves).
You bring up an interesting point: if we're willing to trust Wikipedia completely, then we can omit the crypto altogether. This would certainly simplify things:) I think the fundamental challenge with using digital signatures for endorsements is ease-of-use. Wouldn't it be nice if your web browser connected to GPG in such a way such that answering "Yes" to "Do you endorse this article?" popped up a window saying "You are about to sign a statement saying 'I believe the following Wikipedia article is correct to the best of my knowledge:....'; enter your password to complete the signature'.
And yeah, I noticed that it's just you and me here. And why not? Small teams are more agile anyway:)
Just a quick followup: Perhaps it would make sense to add and MD5 namespace to Wikipedia. The idea is that the URL http://wikipedia.org/wiki/MD5:3f804f5d6d89e5e74429 923207a56165 would refer to the Wikipedia page whose content has that MD5 hash. This makes it particularly easy to refer to specific versions of an article, not just for endorsements, but also when discussing the content of an article, etc. Of course, Wikipedia would not need to actually keep the entire content of each version; it could keep diffs a la CVS to save storage (and I'm sure it already does this).
P.S. A quick glance at the MD5 Wikipedia entry reminds me that MD5 is was shown to be insecure in 1994, so we should probably use SHA-1 instead:)
Sounds good, though since articles are large, it might be easier for the user to sign its fingerprint (e.g., the output of md5sum on the raw source of the article). This would also avoid problems of different platforms interpreting the raw text differently (in terms of line breaks, etc). Crypto buffs may not like this becase the user doesn't see exactly what is being signed; but since we have to trust Wikipedia to correctly represent our endorsements, we might as well trust it to provide the correct hash.
The command to endorse an article is simply: % echo 3f804f5d6d89e5e74429923207a56165 | gpg -ab where "3f...65" is the fingerprint of the article being signed.
The output is something like: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQBBCCRbITsEC6QWw+8RAqDrAJ9zxIqKmk4HX5bBDUeM wf lT4nXdIACfc+vy s82TXI8pFnt5lv28JuNBDGY= =ty+t - ----END PGP SIGNATURE----- which can be pasted back into a web form, as you suggested.
Since signatures are small in binary form, I think keeping them around for recovery should be okay. But clearly Wikipedia should verify a given signature only once!
Yes, I was agreeing with you about the signing. I just wanted to point out that later changes invalidate the signature. We seem to agree on how to handle this.
Showing the trusted information by default seems sensible, but I suspect some people will want a "bleeding edge mode" that reverses the logic, i.e., "Here's the latest version; the last time someone you trusted endorsed this page was 5 revisions / 2 months ago. Click here to see that version; click here to highlight the diffs."
Of course, bootstrapping a trust network is always a bit tricky. As you suggested, you might do this by reading a bunch of articles and noticing which people have endorsed the articles you like. But I wonder whether people will also want "show me the Wikimedia-endorsed subset of Wikipedia," where "Wikimedia-endorsed" refers to endorsements by some set of volunteers who are in turn authorized by the Wikimedia people to declare pages "ready for release." It might be an interesting way to define "releases" in this kind of dynamic environment.
The problem is that changes to a Wikipedia page may (or may not) invalidate an endorsement. We might imagine heuristics for determining whether a change is substantial enough to require re-endorsement, but this seems error-prone.
Instead, each endorsement can (and should) record which version of a page it refers to (a digital signature includes a hash of the page, but the system would need to keep a copy of the actual content). Then, we can view either the endoresed version of a page or the current version with the diffs since the endorsement highlighted.
I've noticed that several well-known individuals have Wikipedia pages (rms, Dubya, Ghandi).
So I wonder, at what point is it appropriate to add a person to Wikipedia? At one extreme, every person who wants a page for him or herself could create one; in fact, one's Wikipedia page could replace one's home page. But this doesn't seem right somehow. Certainly a personal wikipedia page could contain an (auto)biography and links to related topics and people. But other stuff---like vacation photos and fan sites---do not really belong there (and we wouldn't want to clutter "the sum of all knowledge" with this).
Is this just a matter of good sense and public consensus? Would it make sense to have some kind of Wiki-social-network thing?
Slashdot Mirror
The index is out of date; Google's cache still says:
"And information that they are deleting."
Q: What's the name of your working group?
A: Right.
Q: "Right" is the name of your working group?
A: No, WHAT is.
Q: What is what?
A: WHAT is the name of my working group.
Q: That's what I just aksed you.
A: No, that's what I just told you.
Q: No, no -- just tell me the name of your working group!
A: WHAT.
Q: I said, tell me the name of your working group.
A: WHAT.
Q: WHAT'S THE NAME OF YOUR WORKING GROUP, DAMMIT!?
A: Right! But my name's not Dammit...
(strangling noises)
Frankly, it's a waste of my time to animate the zoom from continental view to street -- just show me what I want to see. I tried using map24, and it (1) takes forever to load, (2) is less readable and much smaller than Google Maps, and (3) spammed by browser with Java errors when I killed it's tab. Google's interface seems much more lightweight, robust, and readable.
But the stuff posed in this article will give you a headache.
:)
Instead, check out David Cope's Experiments in Musical Intelligence. You can download mp3s of some great pieces modeled after great composers. And the computer science behind it is also cool: Cope's approach involved developing a grammar for music, such that the generated pieces followed this grammar. Much easier on the ears
It's fun to think about how they'll do failover between the primary and the backup: move the backup into position directly over the primary, then move the primary out of the way, and presto -- the backup is in position (maybe 100M too high, but this should be close enough to provide some service until it can descend to the correct altitude). Meanwhile, the primary can land and get serviced.
A recent research paper from University of Michigan, Backtracking Intrusions, presents a tool for identifying and visualizing the cause of suspicious behaviors (e.g., "where did the file /tmp/rootkit come from?"). A very nice paper and a significant contribution to intrusion forensics.
I did a co-op as an undergraduate that taught me many things (source control, new programming languages, team projects) that made it far easier to get a job. The CS degree is vital, of course, for you to learn how to approach complex computational problems and reason about various solutions (is this the right data structure for this problem? how to I optimize the common case in this system? what are the invariants for objects of this class?). Its the two together -- real experience and the CS background -- that will make you an attractive job candidate. The name of the school matters far less than your mastery of the fundamentals and your experience applying them.
The problem with public terminals is that every person who logs in acts as the same user, therefore later users see the data for earlier ones. What's interesting is that some public terminals go to great lengths to scrub the data between logins so that later users don't see earlier ones' impacts.
But this scrubbing doesn't clear Google Desktop, so its data spans logins. I suppose one could extend the inter-login scrub to also clear GDS, but what's the point? Might as well just omit GDS altogether. But one must also prevent users from installing GDS when they use the terminal. You could do this by disallowing all downloads, but this may be too strict (especially if you want to encourage users to use your terminal for a long time, and so they may want to install software for the duration of their session, e.g, Putty). In this case, the terminal has to prevent the installation of GDS but allow other software.
All in all, this issue is more subtle than it appears on the surface. Hopefully the response will be better public terminal software, rather than worse GDS software!
I agree -- I'm more of a Star Wars fan than a trekkie, but I think Star Trek has more well-understood races than Star Wars, thanks to all the shows. It would be pretty cool to be able to play as RPG in 3 environments: on planets, on space stations, and on large ships -- all 3 are large enough to have full economies of their own. And compared to Star Wars, Star Trek offers many more factions: instead of just Empire and Rebel, there are each of the separate races, as well as the Federation and everyone else. Plus there's more content to draw on than Star Wars (SWG didn't do much of anything interesting content-wise). All-in-all, the idea has potential, and I hope they do a good job with it!
(Ferengi would make the perfect merchant class, btw)
Your use of quotes around "efficient" is very telling. Los Angeles is one of the most high-traffic, polluted cities in the US (Houston has recently beaten it for the title, thanks much to GWB). I grew up in Houston, went to college in upstate New York, have lived in Boston the last several years, and am about to move to New York City. I see the attraction in wide open rural areas, and I see the attraction in dense walking cities like Boston and New York. But I really don't see why sprawling cities like Houston and LA are any good. They're ugly, and it takes just as long to get place-to-place in a sprawl city as in a denser city or rural area. Perhaps flying cars could somehow give us the best of both worlds?
Step 1: Knock opponent down.
Step 2: Sit on opponent.
Step 3: Profit!!!
BSD: Bondage, Sexual Domination
no GPL: no viral effects, please!
non-Apple fangirl: Fiona is too skinny. Curves good.
into promiscuous sex: er, I agree with the other post---this seems like a bad idea!
Unless you then drop it.
Or kick it for not working.
Another of the problems with these approaches (besides the need to send cover traffic, as you mentioned) is that pseudo-random path selection may not be random enough. Certainly an "omnicient" adversary could run various correlations to determine who is sending data to whom, and it becomes very difficult to make convincing arguments as to whether more realistic adversaries can glean information from the traffic they observe. If there's one lesson we've learned from crypto research, it's that smart mathematicians can usually find patterns in pseudo-random data, so the real question is whether a system provides "sufficient" anonymity (since perfection is likely impossible to achieve). Another question is how long that anonymity lasts, say, against offline analyses by semi-omnicient observers (agencies?). Is a month long enough? A year? Or "as long as men are capable of doing evil"? These are not simple questions to answer, unfortunately, as much as we might wish that anonymity were something simple to achieve!
The id Store doesn't seem to be selling Doom 3. Clicking "Buy Now" from the Doom 3 site provides links to EB Games, Gamestop, and Best Buy. I guess the other comments were right about id wanting to develop good relations with their retailers!
Next, they'll perfect image search:
A possible inquiry could be: I want to see defiance in the face of insurmountable odds.
As a result Imagester returns images depicting defiance in the face of insurmountable odds.
Seriously, are they offering anything better than standard keyword and author search? What I'd really like to see is such a bibliography database that ranks search results usign a PageRank-like algorithm (as I recall, the idea for PageRank derived from research on citation graphs, so this would bring things full circle).
I'd also like to see Google start parsing publications and indexing them by author, year, and citations. The bibliography databases that I'm familiar with require manual input of new entries; it would be cool if this could be done automatically instead. Of course, there will need to be some interface to correct erroneous entries, and this opens up a large can of worms.
Yeah, that's the general problem with cryptographic endorsement systems. Sites like Amazon and CNet support ratings of items without every suing crypto, because we trust those sites to accurately represent the ratings we give. There's no real reason why Wikipedia can't do the same for endorsements. Crypto is only needed if we want to avoid trusting Wikipedia for some reason.
That seems doubtful. A home page that anyone can edit would get old really quick.
Perhaps; but as is being discussed in other threads, there are many ways to control bad edits in a Wiki. Worst case, you can restrict your home page to be editable only by you.
What's unclear to me is whether a social-network-Wiki is really better than a traditional social network system. Most traditional social networks are very structured: you tell the system who your links are, how well you know the people you're linked to, and lots of specific data about yourself (gender, age, hometown, interests). The system uses this to provide services like search filtering and interest matching.
Using a Wiki to define your links and interests might make implementing these features difficult. Perhaps a hybrid would make sense: you have structured ways to define links, etc, but you also have a Wiki to create your personal page and host discussions.
I agree that signatures should be downloadable and verifiable by the public. All I suggested is that we trust Wikipedia to provide the correct MD5 hash of the article as a matter of convenience. But you're right that we can remove this level of trust if Wikipedia can also provide the canonical source of the article (so that people can verify the hash / signature themselves).
:) I think the fundamental challenge with using digital signatures for endorsements is ease-of-use. Wouldn't it be nice if your web browser connected to GPG in such a way such that answering "Yes" to "Do you endorse this article?" popped up a window saying "You are about to sign a statement saying 'I believe the following Wikipedia article is correct to the best of my knowledge: ....'; enter your password to complete the signature'.
:)
You bring up an interesting point: if we're willing to trust Wikipedia completely, then we can omit the crypto altogether. This would certainly simplify things
And yeah, I noticed that it's just you and me here. And why not? Small teams are more agile anyway
Just a quick followup:9 923207a56165
:)
Perhaps it would make sense to add and MD5 namespace to Wikipedia. The idea is that the URL http://wikipedia.org/wiki/MD5:3f804f5d6d89e5e7442
would refer to the Wikipedia page whose content has that MD5 hash. This makes it particularly easy to refer to specific versions of an article, not just for endorsements, but also when discussing the content of an article, etc. Of course, Wikipedia would not need to actually keep the entire content of each version; it could keep diffs a la CVS to save storage (and I'm sure it already does this).
P.S. A quick glance at the MD5 Wikipedia entry reminds me that MD5 is was shown to be insecure in 1994, so we should probably use SHA-1 instead
Wikipedia is not...
This pretty much covers my questions
Sounds good, though since articles are large, it might be easier for the user to sign its fingerprint (e.g., the output of md5sum on the raw source of the article). This would also avoid problems of different platforms interpreting the raw text differently (in terms of line breaks, etc). Crypto buffs may not like this becase the user doesn't see exactly what is being signed; but since we have to trust Wikipedia to correctly represent our endorsements, we might as well trust it to provide the correct hash.
M wf lT4nXdIACfc+vy
- ----END PGP SIGNATURE-----
The command to endorse an article is simply:
% echo 3f804f5d6d89e5e74429923207a56165 | gpg -ab
where "3f...65" is the fingerprint of the article being signed.
The output is something like:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQBBCCRbITsEC6QWw+8RAqDrAJ9zxIqKmk4HX5bBDUe
s82TXI8pFnt5lv28JuNBDGY=
=ty+t
which can be pasted back into a web form, as you suggested.
Since signatures are small in binary form, I think keeping them around for recovery should be okay. But clearly Wikipedia should verify a given signature only once!
Yes, I was agreeing with you about the signing. I just wanted to point out that later changes invalidate the signature. We seem to agree on how to handle this.
Showing the trusted information by default seems sensible, but I suspect some people will want a "bleeding edge mode" that reverses the logic, i.e., "Here's the latest version; the last time someone you trusted endorsed this page was 5 revisions / 2 months ago. Click here to see that version; click here to highlight the diffs."
Of course, bootstrapping a trust network is always a bit tricky. As you suggested, you might do this by reading a bunch of articles and noticing which people have endorsed the articles you like. But I wonder whether people will also want "show me the Wikimedia-endorsed subset of Wikipedia," where "Wikimedia-endorsed" refers to endorsements by some set of volunteers who are in turn authorized by the Wikimedia people to declare pages "ready for release." It might be an interesting way to define "releases" in this kind of dynamic environment.
The problem is that changes to a Wikipedia page may (or may not) invalidate an endorsement. We might imagine heuristics for determining whether a change is substantial enough to require re-endorsement, but this seems error-prone.
Instead, each endorsement can (and should) record which version of a page it refers to (a digital signature includes a hash of the page, but the system would need to keep a copy of the actual content). Then, we can view either the endoresed version of a page or the current version with the diffs since the endorsement highlighted.
Ghandi).
So I wonder, at what point is it appropriate to add a person to Wikipedia? At one extreme, every person who wants a page for him or herself could create one; in fact, one's Wikipedia page could replace one's home page. But this doesn't seem right somehow. Certainly a personal wikipedia page could contain an (auto)biography and links to related topics and people. But other stuff---like vacation photos and fan sites---do not really belong there (and we wouldn't want to clutter "the sum of all knowledge" with this).
Is this just a matter of good sense and public consensus? Would it make sense to have some kind of Wiki-social-network thing?