[chromium-dev] OS X Sandbox design doc updated
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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 path is considered? I think it means that idea to try to open local file and it that fails open remote one as bad. The exact scheme which answers should we try local file or remote file? is not very important (Firefox scheme looks Ok to me), but the situation where EXACT SAME command line can open local file or remote one is surprising and dangerous. 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 correctly. ☆PhistucK On Thu, Jan 14, 2010 at 11:31, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: 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 path is considered? I think it means that idea to try to open local file and it that fails open remote one as bad. The exact scheme which answers should we try local file or remote file? is not very important (Firefox scheme looks Ok to me), but the situation where EXACT SAME command line can open local file or remote one is surprising and dangerous. 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 the same way in the future... On Thu, Jan 14, 2010 at 12:37 PM, PhistucK phist...@gmail.com wrote: 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 correctly. ☆PhistucK On Thu, Jan 14, 2010 at 11:31, 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.comsecure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: OS X Sandbox design doc updated
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 pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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.
Regards,
Simon
On Thu, Jan 14, 2010 at 3:26 PM, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 input of internationalized characters that would
otherwise need IME to be input.
While this could be really useful for international characters, the
main use I had in mind was action keystrokes, like tab, arrow keys,
enter, Ctrl-+, etc. - so for these I think a keycode is needed, right?
- Dominic
Regards,
Simon
On Thu, Jan 14, 2010 at 3:26 PM, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 keyboard layout
opens the findbar, while just pressing f opens an IME.
If you want to use this for actons, I would find it more useful to
have a performUiAction() function instead though, since keyboard
shortcuts are different across platforms (all mac shortcuts use cmd
instead of ctrl for example, and the letters for a few shortcuts are
different on OS X too for various reasons).
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 to use keycodes.
Text-to-speech is a different problem; this is for actions.
For example, on OS X hitting cmd-f with a hiragana keyboard layout
opens the findbar, while just pressing f opens an IME.
If you want to use this for actons, I would find it more useful to
have a performUiAction() function instead though, since keyboard
shortcuts are different across platforms (all mac shortcuts use cmd
instead of ctrl for example, and the letters for a few shortcuts are
different on OS X too for various reasons).
I completely agree; I would like to add many functions along the lines
of performUiAction. However, there are a few actions for which typing
a key really is the right thing to do - for example pressing Tab to
move to the next control.
There's also testing. This function will allow you to use only
javascript to test that a particular capability can be accessed using
only the keyboard. I'm already using this for testing this API, by
simulating pressing Ctrl+L to focus the location bar and then checking
to see that the proper focus event is generated.
So the way I look at it is: there are some great uses for this
function. There are also things that this function could be used for
but there'd be a better way. It could also be abused to do things that
make no sense.
I don't think that's an argument not to allow the function; I think it
just means we should make sure it's defined properly for the intended
use, and over time try to provide better alternatives for other
possible uses.
- Dominic
Nico
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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
characters, while something that (say) hits cmd-f to open the find bar
probably wants to use keycodes.
Text-to-speech is a different problem; this is for actions.
For example, on OS X hitting cmd-f with a hiragana keyboard layout
opens the findbar, while just pressing f opens an IME.
If you want to use this for actons, I would find it more useful to
have a performUiAction() function instead though, since keyboard
shortcuts are different across platforms (all mac shortcuts use cmd
instead of ctrl for example, and the letters for a few shortcuts are
different on OS X too for various reasons).
I completely agree; I would like to add many functions along the lines
of performUiAction. However, there are a few actions for which typing
a key really is the right thing to do - for example pressing Tab to
move to the next control.
Maybe performUiAction('focusNextViewInKeyLoop')?
(By the way, OS X has a system-level setting that configures if tab
should focus only text fields or all controls such as buttons etc. I
don't think Chrome/Mac honors it, but I think there are plans to
support it. Stuff like this is surprising for a caller that sends
tab characters, while an explicit focus next element function
could have clearly defined semantics).
There's also testing. This function will allow you to use only
javascript to test that a particular capability can be accessed using
only the keyboard. I'm already using this for testing this API, by
simulating pressing Ctrl+L to focus the location bar and then checking
to see that the proper focus event is generated.
Some (most?) accessibility shortcuts will vary by platform too. For
example, focus toolbar is ctrl-f5 on OS X, but only if full keyboard
access has been enabled (ctrl-f1). Cocoa the OS X framework don't
always trigger with synthetic keyboard events. (I'm not an a11y expert
– Avi, comments?)
So the way I look at it is: there are some great uses for this
function. There are also things that this function could be used for
but there'd be a better way. It could also be abused to do things that
make no sense.
I don't think that's an argument not to allow the function; I think it
just means we should make sure it's defined properly for the intended
use, and over time try to provide better alternatives for other
possible uses.
- Dominic
Nico
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
[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 would understand what we're talking about could trivially write a shell script or alias to handle it, if they care to.] On Thu, Jan 14, 2010 at 9:15 AM, Scott Hess sh...@google.com wrote: 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 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Date of M5 drop?
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: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Date of M5 drop?
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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 'fake scheme' part, just so the user will be somewhat notified. ☆PhistucK On Thu, Jan 14, 2010 at 19:15, Scott Hess sh...@google.com wrote: 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 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 we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit Linux (valgrind layout), revision 36252
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 --= Automatically closing tree for compile on Webkit Linux (valgrind layout) =-- Revision: 36247, 36248, 36249, 36250, 36252 Blame list: atwil...@chromium.org,e...@google.com,er...@google.com,jcam...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests
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 updating. Will get on that ASAP.
On Wed, Jan 13, 2010 at 6:47 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you never run layout tests or modify test_expectations.txt, you can
stop reading.
As part of the process to upstream our layout test infrastructure, I
have just checked in a change that changes our test infrastructure to
conform to WebKit's in how we specify test names.
Specifically, instead of saying LayoutTests/fast/html/foo.html, you
now just say fast/html/foo.html. This affects specifying tests on
the command line to run_webkit_tests, and also specifying test names
in test_expectations.txt .
In the near future, we will also be moving all of the baselines from
src/webkit/data/layout_tests/platform/chromium-{mac,win,linux}/LayoutTests/*
to platform/chromium-{mac,win,linux}/*, again to match WebKit's
structure.
Two notes:
1) I believe the rebaselining tool is working correctly, but I'm not
100% sure. If you have any problems, let me know.
2) I may have just corrupted the data sets used by the flakiness
dashboard. I will be checking this with Ojan and (hopefully) fixing it
later this evening if I did.
Any questions or problems to me. Thanks!
-- Dirk
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] WebApp that displays a list of Chrome releases
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 url is: http://omahaproxy.appspot.com/ Example output: cf,dev,4.0.266.0 cf,beta,0.0.0.0 cf,stable,0.0.0.0 linux,dev,4.0.288.1 linux,beta,4.0.249.43 linux,stable,0.0.0.0 mac,dev,4.0.288.1 mac,beta,4.0.249.49 mac,stable,0.0.0.0 win,dev,4.0.288.1 win,beta,4.0.249.64 win,stable,3.0.195.38 Specific queries are easy too, with 2 additional parameters os=(win|mac|linux|cf) and channel=(dev|beta|stable). http://omahaproxy.appspot.com/?channel=devos=win win,dev,4.0.288.1 -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests
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 wrote:
I think the data for the dashboard is fine. There's just some dashboard
logic that needs updating. Will get on that ASAP.
On Wed, Jan 13, 2010 at 6:47 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you never run layout tests or modify test_expectations.txt, you can
stop reading.
As part of the process to upstream our layout test infrastructure, I
have just checked in a change that changes our test infrastructure to
conform to WebKit's in how we specify test names.
Specifically, instead of saying LayoutTests/fast/html/foo.html, you
now just say fast/html/foo.html. This affects specifying tests on
the command line to run_webkit_tests, and also specifying test names
in test_expectations.txt .
In the near future, we will also be moving all of the baselines from
src/webkit/data/layout_tests/platform/chromium-{mac,win,linux}/LayoutTests/*
to platform/chromium-{mac,win,linux}/*, again to match WebKit's
structure.
Two notes:
1) I believe the rebaselining tool is working correctly, but I'm not
100% sure. If you have any problems, let me know.
2) I may have just corrupted the data sets used by the flakiness
dashboard. I will be checking this with Ojan and (hopefully) fixing it
later this evening if I did.
Any questions or problems to me. Thanks!
-- Dirk
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests
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:
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 wrote:
I think the data for the dashboard is fine. There's just some dashboard
logic that needs updating. Will get on that ASAP.
On Wed, Jan 13, 2010 at 6:47 PM, Dirk Pranke dpra...@chromium.orgwrote:
Hi all,
If you never run layout tests or modify test_expectations.txt, you can
stop reading.
As part of the process to upstream our layout test infrastructure, I
have just checked in a change that changes our test infrastructure to
conform to WebKit's in how we specify test names.
Specifically, instead of saying LayoutTests/fast/html/foo.html, you
now just say fast/html/foo.html. This affects specifying tests on
the command line to run_webkit_tests, and also specifying test names
in test_expectations.txt .
In the near future, we will also be moving all of the baselines from
src/webkit/data/layout_tests/platform/chromium-{mac,win,linux}/LayoutTests/*
to platform/chromium-{mac,win,linux}/*, again to match WebKit's
structure.
Two notes:
1) I believe the rebaselining tool is working correctly, but I'm not
100% sure. If you have any problems, let me know.
2) I may have just corrupted the data sets used by the flakiness
dashboard. I will be checking this with Ojan and (hopefully) fixing it
later this evening if I did.
Any questions or problems to me. Thanks!
-- Dirk
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 anything related to keyboard events in a browser.
http://www.w3.org/TR/DOM-Level-3-Events/
Here are some random points based on your initial proposal.
Thanks.
I would far prefer to follow an existing standard rather than
re-invent the wheel here, and this spec looks very complete. Would it
make sense for this method to simply take an object of type
keyboardEvent, as defined in the DOM level 3 event draft? Do we
already have support for turning a keyboardEvent into a native event
on each platform, or is there a logical place to put such code?
Writing new keyboard event conversion code specifically for this
extension api seems like the wrong idea - I'd far prefer to tie this
to existing effort in Chrome or WebKit...
- Dominic
- You also need 'meta' modifier support (meta maps to the command key on Mac).
- You need to distinguish and allow both left and right modifier keys.
This is important for things like Bidi switching and language
switching
- There needs to be some way to do keydown and keyup (as well as textInput)
- Using keyIdentifier seems like the way to go.
- You probably also need to support something similar to keyLocation
(which covers left and right shift)
- Also look at DOM textInput event which is the attempt to fix the
keypress event and it handles things like IME and other methods for
inputting text.
erik
On Thu, Jan 14, 2010 at 07:26, Dominic Mazzoni dmazz...@google.com wrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Modules Mac, revision 36268
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, 36267, 36268 Blame list: al...@chromium.org,apatr...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Date of M5 drop?
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 to 5? If so, the timing is kind of irrelevant, because that alone doesn't mean much. We could change it today, or next week, or whenever, as long as (a) version 4 has already branched and (b) version 5 hasn't branched yet. The best way to figure out what will be in some particular stable release is to look at whatever branch the beta releases are shipped from, as that represents the thing that's being stabilized. On Windows, the last several beta releases have been on the 249 branch, so that's the best representation of version 4. If you're looking for a branch date for version 5, we don't generally announce those, I don't think. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Date of M5 drop?
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 looking for a branch date for version 5, we don't generally announce those, I don't think. There used to be dates for M4 on the release calendarhttp://dev.chromium.org/developers/calendar. There aren't any events for M5, though. As an external contributor, I think it'd be helpful to have this information available. rsesek / @chromium.org -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Setting global preferences/settings in code
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.
See browser_main.cc around line 540, the part that mentions
ProcessMasterPreferences:
http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=chrome/browser/browser_main.cc;h=ff1d17d7277b5df9a9e1d901adaf326ee6c2c6ff;hb=HEAD#l539
You could probably follow the Windows implementation of
ProcessMasterPreferences (see first_run_win) to make a Linux one, but
it will of course be rather different.
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 first_run_gtk.cc. It looks like for Windows much of the work for
processing the file is done using install_util, which doesn't appear
to even be included in the build for Linux. So, I have a couple of
questions...
What would be the preferred approach to processing the
master_preferences file in Linux? At a glance, it looks like
chrome/installer/util/master_preferences.cc might have everything
needed if it was built it for Linux, but should the parsing be done
somewhere more general and/or more portable? Documentation says
that chrome/installer has source files and projects for making the
installer (MSI package).
My other question is about the location of the master_preferences
file. In Windows, the file is required to be located in the same
directory as the chrome EXE (DIR_EXE). For Linux, I'm not sure that
this would fit. Any thoughts?
I will attach what I've come up with so far, in case someone is
interested. There are probably things I've done already that are
completely wrong :)
Thanks much,
Brian
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-devdiff --git a/chrome/browser/browser_main.cc b/chrome/browser/browser_main.cc
index 521513f..884968b 100644
--- a/chrome/browser/browser_main.cc
+++ b/chrome/browser/browser_main.cc
@@ -59,6 +59,7 @@
#include chrome/common/result_codes.h
#include chrome/installer/util/google_update_settings.h
#include chrome/installer/util/master_preferences.h
+#include googleurl/src/gurl.h
#include grit/chromium_strings.h
#include grit/generated_resources.h
#include net/base/cookie_monster.h
@@ -258,7 +259,14 @@ void AddFirstRunNewTabs(BrowserInit* browser_init,
#else
// TODO(cpu): implement first run experience for other platforms.
void AddFirstRunNewTabs(BrowserInit* browser_init,
-const std::vectorstd::wstring new_tabs) {
+const std::vectorGURL new_tabs) {
+ std::vectorGURL::const_iterator it = new_tabs.begin();
+ while (it != new_tabs.end()) {
+std::cout *it std::endl;
+if (it-is_valid())
+ browser_init-AddFirstRunTab(*it);
+++it;
+ }
}
#endif
@@ -550,6 +558,26 @@ int BrowserMain(const MainFunctionParams parameters) {
AddFirstRunNewTabs(browser_init, first_run_tabs);
#endif // OS_WIN
+#if defined(OS_LINUX)
+// Process master preferences differently for Linux
+std::vectorGURL first_run_tabs;
+
+/*
+// specify some first_run_tabs urls manually just to test that this works
+// in Linux
+GURL a(http://www.landrover.com;);
+GURL b(http://www.pizzahut.com;);
+first_run_tabs.push_back(a);
+first_run_tabs.push_back(b);
+*/
+first_run_ui_bypass = !FirstRun::ProcessMasterPreferences(user_data_dir,
+FilePath(), first_run_tabs, homepage_defined, import_items,
+dont_import_items);
+
+if (first_run_tabs.size())
+ AddFirstRunNewTabs(browser_init, first_run_tabs);
+#endif
+
// If we are running in App mode, we do not want to show the importer
// (first run) UI.
if (!first_run_ui_bypass
diff --git a/chrome/browser/first_run.h b/chrome/browser/first_run.h
index 3b2d996..3667ae3 100644
--- a/chrome/browser/first_run.h
+++ b/chrome/browser/first_run.h
@@ -11,6 +11,7 @@
#include app/gfx/native_widget_types.h
#include base/basictypes.h
#include chrome/browser/browser_process_impl.h
+#include googleurl/src/gurl.h
class CommandLine;
class FilePath;
@@ -63,6 +64,14 @@ class FirstRun {
int* do_import_items,
int* dont_import_items);
#endif // OS_WIN
+#if defined(OS_LINUX)
+ static bool ProcessMasterPreferences(const FilePath user_data_dir,
+ const FilePath master_prefs_path,
+ std::vectorGURL* new_tabs,
+ bool* homepage_defined,
+ int*
Re: [chromium-dev] Re: Setting global preferences/settings in code
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 first_run_gtk.cc. It looks like for Windows much of the work for processing the file is done using install_util, which doesn't appear to even be included in the build for Linux. So, I have a couple of questions... What would be the preferred approach to processing the master_preferences file in Linux? At a glance, it looks like chrome/installer/util/master_preferences.cc might have everything needed if it was built it for Linux, but should the parsing be done somewhere more general and/or more portable? Documentation says that chrome/installer has source files and projects for making the installer (MSI package). I don't remember this code too well, but it sounds like perhaps processing the master preferences belongs in a shared location. Or maybe it's already in the appropriate shared location and we can build a minimal Linux installer_util library that just includes the master preferences code you want. See installer_util.gypi and chrome.gyp's mention of intaller.gyp to see where you'd need to tweak this. I'd take a look at the code that *uses* the master preferences to judge what makes sense to do here. My other question is about the location of the master_preferences file. In Windows, the file is required to be located in the same directory as the chrome EXE (DIR_EXE). For Linux, I'm not sure that this would fit. Any thoughts? It doesn't seem too terrible to me. We currently don't put any files outside of /opt for the Google Chrome packages; I guess at some point it would be nice to put data /usr/share, etc. at which point maybe it'd make sense to extend PathService to provide additional directories. But that's probably outside the scope of the change you're trying to make. I will attach what I've come up with so far, in case someone is interested. There are probably things I've done already that are completely wrong :) It is tons easier to look at patches if you upload them to our review site. It's pretty easy to do; see http://www.chromium.org/developers/contributing-code if you're using svn. You can set me as the reviewer and write in your message just looking for feedback, not ready to commit yet and I can look there. One thing I'd consider is how this might work on the Mac. I don't think you should worry about implementing it, but I find considering how code *could* be shared helps me think of the appropriate abstraction layers and locations to implement these pieces. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 twenty folders of hierarchy on my disk inside the browser, and it sucks. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. I know. You do what Firefox does, is my answer. I don't think Victor's objections have merit. The number of users who supply filenames on the command line is small, but of those users, I think pretty much all would prefer the Firefox method to our current method, so I see no reason to leave things as they are. The only thing that the small userbase affects is the priority of this implementation, which should be low. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 works (according to Scott) and I'd be surprised if Linux was different. In other words, I'm not asking for new surface area from this purported attack possibility. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
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 sh...@google.com wrote: 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 requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [linux] printing webcore strings in gdb
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! http://code.google.com/p/chromium/wiki/LinuxDebugging#Printing_Chromium_types (You can still use commands x/10hc to inspect the UTF-16 memory values, of course.) If you have any other GDB extensions useful for Chrome, please add them to that file/directory and send them my way for review. I'm considering adding printers for e.g. Harfbuzz strings. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] RFC: Extensions Incognito
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 proposal: https://docs.google.com/Doc?docid=0AbzUSl_g6CjAZGdzZHJnanJfM2RiY3N3dmZzhl=en Changes: - No more separate incognito instance of extension pages. - Users have to opt-in to enable an extension in incognito. - Extension developers can mark their extension incognito safe. We might warn the user if he tries to enable an unsafe extension in incognito. - Some API changes to support incognito data. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] changes to specifying test names (and test_expectations.txt) for Layout tests
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, Ojan Vafai o...@chromium.org wrote:
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:
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 wrote:
I think the data for the dashboard is fine. There's just some dashboard
logic that needs updating. Will get on that ASAP.
On Wed, Jan 13, 2010 at 6:47 PM, Dirk Pranke dpra...@chromium.orgwrote:
Hi all,
If you never run layout tests or modify test_expectations.txt, you can
stop reading.
As part of the process to upstream our layout test infrastructure, I
have just checked in a change that changes our test infrastructure to
conform to WebKit's in how we specify test names.
Specifically, instead of saying LayoutTests/fast/html/foo.html, you
now just say fast/html/foo.html. This affects specifying tests on
the command line to run_webkit_tests, and also specifying test names
in test_expectations.txt .
In the near future, we will also be moving all of the baselines from
src/webkit/data/layout_tests/platform/chromium-{mac,win,linux}/LayoutTests/*
to platform/chromium-{mac,win,linux}/*, again to match WebKit's
structure.
Two notes:
1) I believe the rebaselining tool is working correctly, but I'm not
100% sure. If you have any problems, let me know.
2) I may have just corrupted the data sets used by the flakiness
dashboard. I will be checking this with Ojan and (hopefully) fixing it
later this evening if I did.
Any questions or problems to me. Thanks!
-- Dirk
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Keyboard codes to use for a chrome extension api that enables automation?
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 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. While this could be really useful for international characters, the main use I had in mind was action keystrokes, like tab, arrow keys, enter, Ctrl-+, etc. - so for these I think a keycode is needed, right? The keycode is essentially an indication of which physical key was pressed on the keyboard, not which letter the user means to input (where the charcode may be more useful) Even on a standard US keyboard, it's possible to get the same letter via different keycodes just by changing the layout used. Throw international keyboards (such as my UK one, or my colleagues German ones) and you're in a whole world of pain and discomfort. Add choices such as mapping the caps lock key to ctl and the picture becomes muddier still. Worse, unless you provide constants, not many people know which keycode normally maps to which key. Which is a painfully long way of saying that I really think that the keycode is a poor choice. Fortunately, there are at least two pieces of prior art here: 1) MS's SendInput function, which takes a formatted string 2) WebDriver's mechanism for performing similar action keystrokes. I wrote WebDriver's implementation in order to allow testing of a complex application which demanded high fidelity simulation of user input. This seems to broadly overlap your stated goal, so here's the gist of what we do: * All keyboard input is modeled as normal strings * In the simple case of a lower-case string, we do a direct mapping from character to keystroke * In the case where a capital letter is shown, we automatically simulate holding down the shift key * The same applies to any character on the current keyboard layout which can be typed by holding down the shift key * We have defined constants in a unicode PUA for meta characters, such as control, shift, tab, escape and so on. * Meta characters are assumed to be sticky, that is, if we see the ctl character, we assume that the control key is held down until we see another ctl character (where we release the key) or the end of the string or a release all meta keys character is seen, in which case all meta keys are released in the reverse order they were held down in (so most recently pressed is released first) * For characters which have well known mappings in strings (\n, \t) we simulate using the expected key The advantage of this scheme is that the common case (of a user simply typing into a textarea or input element) is easy to read and makes sense to someone not familiar with the test or the API. The more complex case of a user wanting to simulate pressing a normal keyboard shortcut is also handled intuitively because of the behaviour seen when we reach the end of a string. Finally, it is possible to encode relatively complex chording and interactions using this mechanism. Example usages of this API can be seen here: http://selenium.googlecode.com/svn/trunk/common/test/js/typing_test.html FWIW, webdriver's API is already available for Firefox via JS, and there is already work to get this working with Chrome. I'd be happy to provide more information. Regards, Simon -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Keyboard codes to use for a chrome extension api that enables automation?
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 to base the extension API on this
structure.
-Darin
On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni dmazz...@google.comwrote:
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 is:
{
name: simulateKeyPress,
type: function,
description: Simulate pressing a key.,
parameters: [
{
type: object,
name: keyInfo,
properties: {
key: {type: integer, description: The code of
the key to press, corresponding to event.keyCode.},
control: {type: boolean, optional: true,
description: True if the control key is down.},
shift: {type: boolean, optional: true,
description: True if the shift key is down.},
alt: {type: boolean, optional: true,
description: True if the alt key is down.}
}
}
]
}
What do you think? Should the key be a keyCode? A charCode?
Should it be cross-platform, or should it match what would be returned
by an onKeyDown handler? Are those even mutually exclusive?
My current thinking is: the symmetry of using the same key codes
returned by onKeyDown is appealing. Also, even though there are some
differences, the most common keys needed to automate the UI (tab,
enter, arrows, alphanumerics) are already consistent across platforms.
Thanks,
- Dominic
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
