No, although a man-in-the-middle attack can be used as a delivery method. But if you visit our page, we get data without breaking any security policies.
Check out our webpage . The tone of the article is not Dan's doing. He has been more than generous with the credit, and was involved with our project and of invaluable assistance the entire time.
Credit cards in cached web pages, passwords, any small bit of information we can reconstruct with repeated, targeted, searches. Certainly also to verify the existance of some files... we didn't consider that. Our search allows us interactivity, though, so we can search for random four-digit numbers, if we hit a credit card, keep looking until we get all of it, etc.
Not quite. Again, I recomend checking the webpage , but since I know most of you won't (I wouldn't)...
Go install google desktop. Go to google.com. Do a search. Notice it says 'local results found:' and includes small snippets of the local results. We can get those snippets for arbitrary searches by making our own requests to Google. The local data is integrated after the reponse comes back from Google, but before we get it. The only tricky bit is making the requests to google.com through an applet, since the applet is not allowed to connect to google.com, only the originating host. Luckily we can run a web proxy on our originating host and still get the integration results. We don't even have to return the right google.com search result... we can just replay an old page.
Google never sends the data to an external host. check the report and explanation The composition flaw is in the integration of external, possibly active, web page with local data intended to be integrated only into static pages. The security policies for active web pages don't take in account the possiblity of data intended only for the local computer.
Actually, the flaw is that we have one domain: public http pages, mixed with a second domain: private user data. The security model for the first domain generally allows web pages to access their own content. It is assumed that the site the page originated from is supposed to be able to get it's hands on what it sent, including sending it back. Thus when we mix in the second domain: static information from the user's local files that should not be part of active content, a security vulnerabilty is created.
This is all said much better in our report, of course... this is me rambling on Slashdot, the other is a thoughtful discussion of the material.
There is a real time deque algorithm presented in the book, IIRC. And yes, it's very ugly. I'll have to look into the marshalling stuff. I do wonder if that's not an OCaml thing, because it seems strange that you can't marshall, say, haskell code. Not that I've tried.
But, assuming there was 'true' concurancy, would lazy evaluation in the presence of an atomic force present any problems? I can't see any, but that doesn't mean much. In the above model I doubt you'd get an atomic force (since the time between 'fetch' and 'evaluate' could be non-trivial), but it's possible.
I'm also curious about problems you mentioned with marshalling... are you mashalling data or data types?
heh, perhaps we should take to email.
Strange. It shouldn't matter, in concurant situations, as long as force is atomic, no? (Not that I'm sure it is, but if it is, then there should be no problems). The entire point of laziness is that it's a side-effect which cannot change the value of any call, so it doesn't matter when it happens. Does your cf_deque.t type use lazy_t or a reference? Now I'm curious.
Going to have to disagree. Java/C++/C# are painful in that way, yes, but smalltalk, for instance, is almost as much a pleasure to use as OCaml. I'm a big FP fan, but OO can be done well.
Slashdot Mirror
I do not abdicate my personal rights to property and privacy when I am on private property.
The first link doesn't seem to be valid. Shame, cause I was interested.
You have a set of DFA's which are linked to their neighboor. At each point in time their input is the state of their two neighboors. They are all identical, save for the two on the ends. They all (again, except for the ends), start at the same state. They transition simultaniously. An unknown number of them are hooked up, but they are hooked up linearly, with two end-points. Your goal is to arrange for them all to switch into a unique 'Firing' state at the same moment in time. Describe the DFA.
You do not send out local searches. We are talking about normal web searches.
No, although a man-in-the-middle attack can be used as a delivery method. But if you visit our page, we get data without breaking any security policies.
Check out our webpage . The tone of the article is not Dan's doing. He has been more than generous with the credit, and was involved with our project and of invaluable assistance the entire time.
See our for more information, but iirc they embeded the local search results in an iframe, which separates the security concerns so that the java applet and javascript security models prevent us from accessing local information.
This actually has nothing to do with windows in the least. It is a combination of Google's security model and the Java applet security model.
Note that the applet can never talk to the local server, as that is outside of it's 'sandbox'.
This is not an official comment, but from my limited point of view Google was very helpful and polite throughout the entire process.
This is unnecessary. You can disable the integration option, which is a minor feature anyway. Check our webpage
This is different. We get access when you visit our website, not through looking at that file.
Credit cards in cached web pages, passwords, any small bit of information we can reconstruct with repeated, targeted, searches. Certainly also to verify the existance of some files... we didn't consider that. Our search allows us interactivity, though, so we can search for random four-digit numbers, if we hit a credit card, keep looking until we get all of it, etc.
Not quite. Again, I recomend checking the webpage , but since I know most of you won't (I wouldn't)... Go install google desktop. Go to google.com. Do a search. Notice it says 'local results found:' and includes small snippets of the local results. We can get those snippets for arbitrary searches by making our own requests to Google. The local data is integrated after the reponse comes back from Google, but before we get it. The only tricky bit is making the requests to google.com through an applet, since the applet is not allowed to connect to google.com, only the originating host. Luckily we can run a web proxy on our originating host and still get the integration results. We don't even have to return the right google.com search result... we can just replay an old page.
Google never sends the data to an external host. check the report and explanation The composition flaw is in the integration of external, possibly active, web page with local data intended to be integrated only into static pages. The security policies for active web pages don't take in account the possiblity of data intended only for the local computer.
Actually, the flaw is that we have one domain: public http pages, mixed with a second domain: private user data. The security model for the first domain generally allows web pages to access their own content. It is assumed that the site the page originated from is supposed to be able to get it's hands on what it sent, including sending it back. Thus when we mix in the second domain: static information from the user's local files that should not be part of active content, a security vulnerabilty is created. This is all said much better in our report, of course... this is me rambling on Slashdot, the other is a thoughtful discussion of the material.
Wow, I'm famous enought that people are getting karma for knowing me.
As a note, you can find a tech report on our webpage at http://seclab.cs.rice.edu
As a note, OCaml has lazy evaluation (and it is easy enough to build in once you have side effects anyway).
There is a real time deque algorithm presented in the book, IIRC. And yes, it's very ugly. I'll have to look into the marshalling stuff. I do wonder if that's not an OCaml thing, because it seems strange that you can't marshall, say, haskell code. Not that I've tried.
But, assuming there was 'true' concurancy, would lazy evaluation in the presence of an atomic force present any problems? I can't see any, but that doesn't mean much. In the above model I doubt you'd get an atomic force (since the time between 'fetch' and 'evaluate' could be non-trivial), but it's possible. I'm also curious about problems you mentioned with marshalling... are you mashalling data or data types? heh, perhaps we should take to email.
Strange. It shouldn't matter, in concurant situations, as long as force is atomic, no? (Not that I'm sure it is, but if it is, then there should be no problems). The entire point of laziness is that it's a side-effect which cannot change the value of any call, so it doesn't matter when it happens. Does your cf_deque.t type use lazy_t or a reference? Now I'm curious.
Not sure what that is, but if I have two int lazy_t's returned, which have side effects when evaluated, I can evaluate them in any order.
let x : int lazy_t = f foo in
let y : int lazy_t = f bar in
force x; force y
or
force y; force x.
The side-effect order can be changed.
They have. F#.
Why is laziness not pure? Lazy evaluation is a very functional feature. I've certainly never heard of it outside of a functional language.
Going to have to disagree. Java/C++/C# are painful in that way, yes, but smalltalk, for instance, is almost as much a pleasure to use as OCaml. I'm a big FP fan, but OO can be done well.