Hi,
I've updated the OS X Sandboxing design
dochttp://sites.google.com/a/chromium.org/dev/developers/design-documents/sandbox/osx-sandboxing-design
to
better reflect the current state of affairs.
Edits/corrections are welcome.
Best regards,
Jeremy
--
Chromium Developers mailing list:
On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
Thanks for the responses. However, I'm not sure about the next steps.
Did you mean it's a security risk, don't do it, or the risk is
negligible, do it? How about requiring a --file switch before a
relative file
But this way will not trigger the file access code (as far as I understand),
since you will start Chrome with an http://;, which means it is a URL, so
Chrome will not open the file.
And even if they click on the file, it is a .com file, not a URL shortcut.
Or maybe I did not understand you
Sure. It's the way to exploit naive scheme (open local file, then try to
open remote one if this fails). If you distinguish local/remote using
filename only and don't involve the filesystem the scheme fails: people will
not create shortcuts which don't work! And if they worked once they'll work
On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote:
Consider this attack vector: URL file on Desktop. Chrome will be started
from known directory, now we need to put malicious file there. Hmm. Easy:
create archive with some valuable data AND file http:/www.google.com (as
On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote:
On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote:
Consider this attack vector: URL file on Desktop. Chrome will be started
from known directory, now we need to put malicious file there. Hmm. Easy:
Awesome! Thanks!
On Thu, Jan 14, 2010 at 3:13 AM, Jeremy Moskovich jer...@chromium.org wrote:
Hi,
I've updated the OS X Sandboxing design doc to better reflect the current
state of affairs.
Edits/corrections are welcome.
Best regards,
Jeremy
--
Mike Pinkerton
Mac Weenie
Hi Darin,
Erik suggested you might have some thoughts. In my proposed extension
api for accessibility (http://codereview.chromium.org/402099) one of
the functions is to simulate a key press. How should the client
express the key they would like to press? The current proposed
function prototype
The easiest thing for someone who's attempting to use the
accessibility API may be to avoid using keycodes, and instead allow
the input of the desired displayed value. The advantage of this would
be to allow the input of internationalized characters that would
otherwise need IME to be input.
On Thu, Jan 14, 2010 at 8:01 AM, Simon Stewart
simon.m.stew...@gmail.com wrote:
The easiest thing for someone who's attempting to use the
accessibility API may be to avoid using keycodes, and instead allow
the input of the desired displayed value. The advantage of this would
be to allow the
It probably depends if you want to use this for text input or action
inputs. A text-to-speech extension would probably want to set unicode
characters, while something that (say) hits cmd-f to open the find bar
probably wants to use keycodes.
For example, on OS X hitting cmd-f with a hiragana
On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber tha...@google.com wrote:
It probably depends if you want to use this for text input or action
inputs. A text-to-speech extension would probably want to set unicode
characters, while something that (say) hits cmd-f to open the find bar
probably wants
On Thu, Jan 14, 2010 at 8:37 AM, Dominic Mazzoni dmazz...@google.com wrote:
On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber tha...@google.com wrote:
It probably depends if you want to use this for text input or action
inputs. A text-to-speech extension would probably want to set unicode
On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote:
On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote:
On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote:
Consider this attack vector: URL file on Desktop. Chrome will be started
from
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine requiring explicit fully-qualified URLs and be done
with it. If it doesn't start with a protocol, we don't open it.
99.99% of the users who even
Hi, I've been scouring the groups and can't find the answer anywhere,
what time scale are we looking at until the dev branch hits m5?
Cheers
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
My guess is within a month.
☆PhistucK
On Thu, Jan 14, 2010 at 14:48, OwenCM owencmo...@googlemail.com wrote:
Hi, I've been scouring the groups and can't find the answer anywhere,
what time scale are we looking at until the dev branch hits m5?
Cheers
--
Chromium Developers mailing list:
I would say that with systems where you can actually use a scheme (http://;)
as a file name (or folder, or something like that), there should be an
indication that this is a file and not a URL, just for the sake of phishing
protection. Even put a red strike (like you do with invalid https) on the
Automatically closing tree for compile on Webkit Linux (valgrind layout)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%20layout%29/builds/4979
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%20layout%29
--=
I just updated
http://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests
to
reflect these changes as well.
On Thu, Jan 14, 2010 at 10:40 AM, Ojan Vafai o...@google.com wrote:
I think the data for the dashboard is fine. There's just some dashboard
logic that needs
For everyone who has asked the question what's currently version of Chrome
deployed on the YY channel on the XX platform there is now a
mostly-reliable automated answer. The results aren't particularly fancy,
but they are near real time and parse-able so they should be
generally consumable.
The
Actually, the data is messed up. It's the windows bots. The path isn't being
made relative properly. It's getting full windows paths in the results.json
file. We'll need to do a cleanup pass. Dirk, you want to do that, or should
I?
On Thu, Jan 14, 2010 at 10:40 AM, Ojan Vafai o...@google.com
Ugh. It looks like the data all got clobbered as well. That should only
happen if the JSON file got corrupted somehow. Not really sure how that
happened. In either case, all there is to do right now is to fix the windows
paths.
On Thu, Jan 14, 2010 at 11:43 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Jan 14, 2010 at 9:54 AM, Erik Arvidsson a...@google.com wrote:
Keyboard events in browsers has and is a compatibility nightmare. I
feel like the current working draft for DOM level 3 Events is making
good progress in cleaning this up and it is worth a read if you are
planning to do
Automatically closing tree for update on Modules Mac
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Mac/builds/19467
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Mac
--= Automatically closing tree for update on Modules Mac =--
Revision: 36266,
On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote:
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine requiring explicit fully-qualified URLs and be done
with it.
:( This
On Thu, Jan 14, 2010 at 4:48 AM, OwenCM owencmo...@googlemail.com wrote:
Hi, I've been scouring the groups and can't find the answer anywhere,
what time scale are we looking at until the dev branch hits m5?
What do you mean by hits m5? Do you mean, the major version stamp gets
changed from 4
On Thu, Jan 14, 2010 at 4:21 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 14, 2010 at 4:48 AM, OwenCM owencmo...@googlemail.com wrote:
Hi, I've been scouring the groups and can't find the answer anywhere,
what time scale are we looking at until the dev branch hits m5?
If you're
On Sun, Dec 20, 2009 at 03:03:23AM -0800, Evan Martin wrote:
On Sat, Dec 19, 2009 at 9:32 PM, cpu c...@chromium.org wrote:
Yes, the MasterPreferences is what we use so far. It is just a json
file in a particular path. I am not sure if we have enabled this for
the linux build.
It hasn't.
On Thu, Jan 14, 2010 at 1:33 PM, Brian G. Merrell bgmerr...@gmail.com wrote:
Okay, I started looking into this. After a bit of work, I'm to the
point where I need to process the master_preferences json file.
That is, I am currently writing a ProcessMasterPreferences function
in
On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote:
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine
On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess sh...@google.com wrote:
If you try to open a
relative path and it doesn't work, you go Oh, right, relative path.
No, actually, what I say every time is What the heck, why did it try to
open this as a hostname? and then I laboriously navigate through
On Thu, Jan 14, 2010 at 2:05 PM, Peter Kasting pkast...@google.com wrote:
I don't think Victor's objections have merit.
(For public benefit)
Partly because you can't put ':' in a filename on Windows, which is the OS
where local files aren't resolved. On the Mac opening local files already
BTW, AFAICT on both Mac and Linux, chrome-cmd file.html opens
file:///path/to/cwd/file.html. Mac works for opening relative
http:/file.html. Since http: is not a valid filename for Windows,
I'd say making them all consistent would make sense.
On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess
We had a section of our wiki page with a GDB trick for printing webcore types.
I just cleaned up and checked in that code.
The wiki now just has the recipe on how to source this file into your
GDB. It's easy, and now my GDB can display WebCore::AtomicString,
UChar*, etc. as nice Unicode strings!
After the feedback I received, I realized that my original proposal didn't
actually meet one of the goals I intended (that existing extensions would
work in incognito transparently). I decided to dial it back a bunch and
incorporated some other feedback from Erik and Aaron.
Here is v2 of the
The dashboard is working again. Let me know if you see bugs. Unfortunately,
the data loss is permanent. If anyone wants to work on making the data for
the dashboard persist and/or to make it so we store more than a month's
worth of data, you can talk to me.
Ojan
On Thu, Jan 14, 2010 at 11:51 AM,
On Thu, Jan 14, 2010 at 4:15 PM, Dominic Mazzoni dmazz...@google.com wrote:
On Thu, Jan 14, 2010 at 8:01 AM, Simon Stewart
simon.m.stew...@gmail.com wrote:
The easiest thing for someone who's attempting to use the
accessibility API may be to avoid using keycodes, and instead allow
the input
Ultimately, I believe we'll need to generate a sequence of WebKeyboardEvent
objects from this data. (See
http://trac.webkit.org/browser/trunk/WebKit/chromium/public/WebInputEvent.h)
WebKeyboardEvent is the data that we send to WebKit corresponding to a
keyboard event. I think it is reasonable
39 matches
Mail list logo
