Hacker Newsnew | past | comments | ask | show | jobs | submit | DrewHintz's commentslogin

I’ve had luck with a workflow similar to:

git clone a repo

Open goose with that directory

Instruct it to discover what the repo does

Ask it to make changes to the code, being detailed with my instructions.

I haven't tried computerController, only Goose’s main functionality.


I tell it to discover that itself by asking leading questions: “What does this repo do?” “How do you run its unit tests?” “What does file foo do?”


I'm guessing an "internal tools scaffold" is something like Goose: https://github.com/block/goose

Instead of just generating a patch (copilot style), it generates the patch, applies the patch, runs the code, and then iterates based on the execution output.


Square | AppSec, vulnerability discovery, pen testing | Remote in North America

We're hiring people to find vulnerabilities in Square products and services! The team is brand-new with lots of opportunity to choose the type of AppSec work you want to focus on. Fully remote is an option. There are more details here: https://smrtr.io/6T58-

We're also hiring for lots of other security roles. Please feel free to email me: dhintz@squareup.com


"Consumer Gmail content will not be used or scanned for any ads personalization after this change."

Original post: https://blog.google/products/gmail/g-suite-gains-traction-in...

Disclaimer: I work for Google, but not on this.



I know about that post from 2013 and I still don't agree.

Just like I don't agree with how Google implemented AMP, making google.com a link redirector that didn't exist before and was actually used in the fishing campaign, specifically:

http://seclists.org/bugtraq/2016/Apr/70

That is what was actively used to fish the logins from Podesta et al.

Google's response:

https://sites.google.com/site/bughunteruniversity/nonvuln/op...

"tooltips are not a reliable security indicator"

Translation: "we don't look at that sh.t"

"poses very little practical risk."

See how Podesta et al. were tricked.

"offers fairly clear benefits"

Translation: "For us. Muahhaha."


Here's the tweet:

"The County was working cooperatively with the FBI when it reset the iCloud password at the FBI's request."

https://twitter.com/countywire/status/700887823482630144


> Yes, we're pushing the notification to a new tab (which can't be blocked or interfered with)

We went through a similar iteration with Password Alert. If you're setting focus on the new tab, an onBlur event could indicate that the current page has lost focus, perhaps due to the warning tab. I think notifying the user is still net-positive for the user's security.


Interesting, I hadn't heard of Password Alert -- we should definitely share notes if you're open to it -- I'd love to be able to generalize what we're doing to other domains if we could -- it's unfortunately cpu intense how we're doing it.


Sure thing, I'm happy to help. Our code is at https://github.com/google/password-alert and feel free to email me any questions at drew@overt.org

However we haven't published a good design document about the client. If you're interested, let me know and I'll try to publish one.


This can be protected against by the extension looking at keyboardEvents and verifying the isTrusted attribute. Here are details about how we do this in Password Alert: https://github.com/google/password-alert/blob/master/SECURIT...

Before Chrome implemented isTrusted, it was a bit more tricky and we had to rely on a variety of attributes that did not have as much of a security guarantee.


Thanks for the helpful explanation! Those seem like fair mitigations.

Reading more on it, though, since isTrusted can apparently be spoofed, it looks like the main obstacles are the (2) rate-limiting and the (3) intentional collisions.

For (2), I suspect typical users would have a memorizable master password that's more susceptible to brute forcing, but of course it depends on the actual rate limit and how long you can keep the script running. Alternatively, I suppose a malicious script could overwhelm the rate limit so that the user wouldn't receive a legitimate warning.

For (3), I wonder whether LastPass has a similar mitigation? From what I understand, they don't store the actual password, so all you would need is a matching hash.

I'd be interested to know more details about LastPass's protections.

Edit: I just saw pwman's response above.


> isTrusted can apparently be spoofed

isTrusted cannot be spoofed in this situation, which is its intended use in Chrome. A Chrome extension in the isolated world is receiving events from the main world and checking isTrusted for those events.


Thanks for the clarification. I assume the spoofability applies only to JS in the main world then? And extensions can receive the event before a script has a chance to fiddle with it?

Sorry for the questions, just trying to figure out how this all works, and Googling doesn't give me a clear answer.


> LastPass also detects you enter your master password on an incorrect domain and notifies you immediately of your mistake

Interesting! How does it do this?


I'm assuming by the same mechanism that offers to save previously-entered passwords. It's always sniffing anything you type into a password field.


How would it know it's a password field and not just some text input box that uses * characters?


<input type="password" /> I assume


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: