justinschuh

10 ms·

31.
by justinschuh 11y ago
We've invested quite a bit of energy in static analysis tools over the years, but so far the return hasn't been there. There are still ongoing efforts, and we'll see if those pan out, but up to this point we've just run
32.
by justinschuh 11y ago
Like Aaron mentioned, the renderer was originally split into a separate DLL because we hit the limits of Microsoft's linker at the time. Later, we ended up relying on that split for disabling win32k inside the sandbox (otherwise we wou
33.
by justinschuh 11y ago
I think you're reading something different than what I intended. I don't work on V8, and what I know about their priorities is no different from what they've stated publicly. That is, the V8 team wants to improve asm.js perfo
34.
by justinschuh 11y ago
It's not hostility. It's just that you're a very passionate Mozilla employee and a very passionate creator of asm.js. And from past experience I expect that you'll be willing to continue a debate longer than I can. Plus,
35.
by justinschuh 11y ago
I want to be clear that I fully intend to spend my weekend with my family, and not arguing this with you. So, I'll avoid rehashing any of our past discussions regarding technical concerns with asm.js. However, as the person responsible
36.
by justinschuh 11y ago
> If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI? I think you might have a few misconceptions. Chrome employs an outer process sand
37.
by justinschuh 11y ago
Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features. It absolutely does not use a strict PPAPI sandbox and does not run under NaCl. To explain some differences, the Flash plugin is no
38.
by justinschuh 11y ago
System credential managers are the established way to do this properly. They are user configurable, generally maintain credentials in a separate security context, derive a strong key from the user logon credential, can more easily support h
39.
by justinschuh 11y ago
The obfuscation isn't really intentional IIRC. It's an artifact of the assumption that a proper base credential will be available from either libsecret, Gnome Keyring, or KDE Wallet. The fixed key is just a placeholder that gets u
40.
by justinschuh 11y ago
That's a bit out of date, because libsecret is supported as well: https://code.google.com/p/chromium/codesearch#chromium/src/c... But yeah, it pretty much looks for any sort of secure credential ma
41.
by justinschuh 11y ago
> Of course, this is unacceptable - but there are very few alternatives. For the record, we - rawstream - don't do this as its crazy to compromise security like this. So we had to find other means. So, then you're using extensi
42.
by justinschuh 11y ago
From my own experience, actually making the purchase is likely to be perceived negatively. He had already successfully demonstrated the race condition allowing the transfer, so he had enough to clearly make his point. That stated, were I in
43.
by justinschuh 11y ago
Interesting... to me at least. I was stationed there for manual Morse school back in 1997.
44.
by justinschuh 12y ago
Pretty much. It would probably be an interstitial on navigation (similar to how certificate errors are handled) and a page action for subresources (similar to the shield page action for mixed content).
45.
by justinschuh 12y ago
FWIW, the title is beyond sensationalist, and outright wrong. The title on the link is "Block sub-resource loads from the web to private networks and localhost".
46.
by justinschuh 12y ago
I'm sorry, I know this is an earlier comment but I wanted to correct this framing of the threat and proposed mitigations. My response to you here explains why these measures don't solve the attacks that we're trying to addres
47.
by justinschuh 12y ago
As I explained elsewhere, the origin header in WS(S) allows a server to overtly protect itself from a client. Unlike CORS, it doesn't allow the browser to make security decisions regarding requests, and so would not address any of the
48.
by justinschuh 12y ago
We'd be blocking sub-resources and navigation from web to private. Of course, direct navigation via a bookmark or the omnibox would still work. And navigation or resource inclusion from private to the web would still work. As I expla
49.
by justinschuh 12y ago
A subresource is basically additional content that a page includes via a URL (e.g. script, iframe, images). The problem underlying this is that any page on the web can currently probe and then attack devices and servers on your internal net
50.
by justinschuh 12y ago
I'm sorry, but I don't understand the argument you're making here. I've already explained that we plan to provide a portable mechanism for private and localhost opt in. It's just not going to be the mechanism you pr
51.
by justinschuh 12y ago
We'll be changing the mixed-content detection soon to treat localhost as a secure transport (because it is from the network perspective), which will address the mixed content issue.
52.
by justinschuh 12y ago
Potentially, yes, and it's one of the ways we're looking at addressing per-page opt-in.
53.
by justinschuh 12y ago
As I explained in my other comment, the origin header in websockets doesn't help in addressing the attacks we see, because it is a server-side measure.
54.
by justinschuh 12y ago
That's not the way the origin header works. The origin header in websockets is provided from the client to the server, and the server must take overt measures to protect itself or scope origins that are allowed. Given that we're w
55.
by justinschuh 12y ago
As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the
56.
by justinschuh 12y ago
I mentioned this above, but we plan to let the localhost/private page support an explicit opt-in, maybe via CORS headers. Those details may not be captured in the bugs yet because currently no one is actively working on this.
57.
by justinschuh 12y ago
I filed this bug (along with http://crbug.com/458362 ), and there's a bit of context that may be missed. First, this is to protect weak devices and services on private networks or localhost, that really can't be sa
58.
by justinschuh 12y ago
Your response is utter nonsense. If you had any legitimate argument to make here you'd be citing something to support these wild accusations, but you have nothing of the sort.
59.
by justinschuh 12y ago
Do you really think a code drop from an obscurely named github repo qualifies as open development? Because it can just as easily be interpreted as hiding in the noise, particularly when the eventual asm.js unveiling was done as a giant PR b
60.
by justinschuh 12y ago
Fair enough that v8 is an odd case, but it's an external dependency that predates Chrome/Chromium with its own core team, development processes, third-party obligations, and ecosystem. And accepting that, v8 does have third-party

More ›