On Thu, Jul 22, 2010 at 1:46 PM, Adam Barth wrote:
> On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor
> >
> wrote:
> > On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison
> wrote:
> >> There is no legitimate reason that non-developers would need to paste
> >> "javascript:" URLs into the addressbar, an
On Thu, 22 Jul 2010, Luke Hutchison wrote:
>
> There has been a spate of facebook viruses in the last few months that
> have exploited social engineering and the ability to paste arbitrary
> javascript into the addressbar of all major browsers to propagate
> themselves. Typically these show up
On 24.07.2010 02:33, Bjartur Thorlacius wrote:
Wrong. Plain wrong. Kids who like to test stuff do things like this. I
do agree though that the urlbar isn't the right place, there should be
a different prompt for this kind of stuff. Probably disabled at compile
time by default and accessible by
> 99.% of people have never manually entered a javascript: URL
> into a browser addressbar in their life -- unless duped by a social
> engineering virus.
Wrong. Plain wrong. Kids who like to test stuff do things like this. I
do agree though that the urlbar isn't the right place, ther
I second that call. While your suggestion seems to prevent some existing
social engineering, you must realize that HTML5 isn't going to be
recommended until ~2020. By that time, everything we talk about social
engineering today will be completely obsolete. Things like this are best
left to be ta
On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison
wrote:
[snip]
Comments, please?
This is entirely out of scope of any specification and 100% an user agent
UI issue.
I should add that to complicate things, not all the social engineering
directions make it clear to the user that they will be pasting stuff
into the addressbar: e.g. I got one called "World's Hardest Riddle"
that selected the text in the box for you somehow and then told the
user that to see the ri
On 7/23/2010 6:35 AM, Luke Hutchison wrote:
On Thu, Jul 22, 2010 at 5:39 PM, Boris Zbarsky wrote:
I can see the security benefits of disallowing all cross-origin application
of javascript: (if you don't know where it came from, don't apply it).
Yes, that is actually a really good way to pu
If javascript URI entry support/execution in my address field went away,
I'd be very pissed! A JS console in the dev tools is not the same
usability-wise.
I might get over it *after a while* if it was off by default with an
option to re-enable it though. For example, I could imagine having
Note that for Mozilla this is basically bug 305692:
https://bugzilla.mozilla.org/show_bug.cgi?id=305692 I mentioned
Facebook in comment 9.
Daniel Cater.
On 22 July 2010 21:32, Luke Hutchison wrote:
> There has been a spate of facebook viruses in the last few months that
> have exploited social e
On Thu, Jul 22, 2010 at 7:17 PM, Paul Ellis wrote:
> This seems to be the wrong venue for this discussion but it is worth noting
> that IE8 doesn't allow drag-and-drop of javascript: links to the favorites
> bar. If you do right-click->Add to Favorites for a javascript: link it
> prompts "You are
On Thu, Jul 22, 2010 at 2:48 PM, Mike Shaver wrote:
> On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison
> wrote:
> > On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver
> wrote:
> >> Would a UA that asked for the
> >> user's permission the first time a bookmarklet is used (like some
> >> prompt the firs
On Thu, Jul 22, 2010 at 5:48 PM, Mike Shaver wrote:
> No, I mean like the prompts for geolocation, popup windows, first-use
> helper applications, first-use URL protocols, and similar. But my
> question is more about what you propose to disallow, and why you
> choose "disable" as the requirement.
On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison wrote:
> On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver wrote:
>> What is the proposed change to which specification, exactly? URL-bar
>> behaviour, especially input permission, seem out of scope for the
>> specs that the WHATWG is working on.
>
> Is
On Thu, Jul 22, 2010 at 1:46 PM, Adam Barth wrote:
> On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor
> wrote:
>> On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote:
>>> There is no legitimate reason that non-developers would need to paste
>>> "javascript:" URLs into the addressbar, and the abi
On 7/22/10 5:32 PM, Luke Hutchison wrote:
Well, is it the simplest one, though? If closing it will do nothing for
security but just inconvenience people, what's the point? I'd really rather
not have us doing security theater just to look like we're doing something.
It's not unreasonable to gu
On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver wrote:
> What is the proposed change to which specification, exactly? URL-bar
> behaviour, especially input permission, seem out of scope for the
> specs that the WHATWG is working on.
Is there a better venue to discuss this then? (It seems like even
On 7/22/10 5:03 PM, Mike Shaver wrote:
What should the URL bar say when the user clicks a javascript: link
which produces content?five!
This part the spec actually covers, I think; the url bar is supposed to
say the url of the page that link was on, iirc. Which is what I think
everyone but G
On Thu, Jul 22, 2010 at 4:48 PM, Tab Atkins Jr. wrote:
> These days, though, all major browsers have javascript consoles which
> you can bring up and paste that into.
That doesn't typically apply to content tabs or windows, though.
I have a couple of questions:
What is the proposed change to wh
On Jul 22, 2010, at 1:32 PM, Luke Hutchison wrote:
> There has been a spate of facebook viruses in the last few months that
> have exploited social engineering and the ability to paste arbitrary
> javascript into the addressbar of all major browsers to propagate
> themselves. Typically these sho
On 7/22/10 4:46 PM, Luke Hutchison wrote:
A bookmark is more like a link than a manually-entered URL
What would prevent the viruses in question from saying "drag this link
to your bookmarks bar and then click the bookmark"?
Note that this is something that sites actually do... not necessaril
On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor wrote:
> On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote:
>> There is no legitimate reason that non-developers would need to paste
>> "javascript:" URLs into the addressbar, and the ability to do so
>> should be disabled by default on all browse
A bookmark is more like a link than a manually-entered URL, and as mentioned
in the original email, the browser will have to of course keep working with
javascript: links.
99.% of people have never manually entered a javascript: URL into a
browser addressbar in their life -- unless duped by a
On Thu, Jul 22, 2010 at 1:41 PM, Aryeh Gregor wrote:
> On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote:
>> There is no legitimate reason that non-developers would need to paste
>> "javascript:" URLs into the addressbar, and the ability to do so
>> should be disabled by default on all browse
On Thu, Jul 22, 2010 at 4:32 PM, Luke Hutchison wrote:
> There is no legitimate reason that non-developers would need to paste
> "javascript:" URLs into the addressbar, and the ability to do so
> should be disabled by default on all browsers.
Sure there is: bookmarklets, basically. javascript: U
Personally, I write JavaScript URLs in the address bar all the time,
but I might not be a typical user. :)
This sounds like a great opportunity for a CSP directive.
Adam
On Thu, Jul 22, 2010 at 1:32 PM, Luke Hutchison wrote:
> There has been a spate of facebook viruses in the last few months
There has been a spate of facebook viruses in the last few months that
have exploited social engineering and the ability to paste arbitrary
javascript into the addressbar of all major browsers to propagate
themselves. Typically these show up as Facebook fan pages with an
eye-catching title that as
27 matches
Mail list logo
