Please fix "print kb shortcuts" for chrome users

Ideas & suggestions
#1

If I have google chrome as my default browser and I try to print the kb shortcuts, it will open chrome with a blank window. The short of the reasoning behind this is that Chrome will not render local xml files transformed by local xsl files - Why? It’s a security risk. I’m not going to get into the details on how or why it’s a security risk.

I would suggest updating the transform method or just rendering the shortcuts to a flat simple HTML file instead of the method that’s been used for renoise since before chrome existed. I’ve suggested this a few times but it never got addressed.

Not a huge deal but it would be nice to get current and not have to copy that url to firefox just to view my shortcuts. I run into this every time a new beta comes out and I go back to tweaking my shortcuts to accommodate for new features, etc.

Thanks for considering… uber low priority but also really really easy to fix.

EDIT: Found this great description of the risk behind transforming XML locally:
Imagine this scenario:
[i]
You receive an email message from an attacker containing a web page as an attachment, which you download.

You open the now-local web page in your browser.

The local web page creates an

Because you are logged in to Gmail, the frame loads the messages in your inbox.

The local web page reads the contents of the frame by using JavaScript to access frames[0].document.documentElement.innerHTML. (An Internet web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)

The local web page places the contents of your inbox into a and submits the data via a form POST to the attacker’s web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.

There is nothing Gmail can do to defend itself from this attack.

I do agree its annoying, as a fix you’ve got 2 solutions:

Try running chrome with the --allow-file-access-from-files switch (I’ve not tested this myself)

Upload it to a host, and everything will be fine.[/i]

#2

The local web page reads the contents of the frame by using JavaScript to access frames[0].document.documentElement.innerHTML. (An Internet web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)

This is exactly why the people at Google do not understand much about programming and security, they seem to be as worse as Microsoft programmers regarding security.

Not that i want to be a drag but…
Try running chrome with the --allow-file-access-from-files

#3

That works great when starting chrome from an automator script on os x but not when chrome is autolaunched from another application because it is your default browser.
Thanks for your opinions on google programmers. It really added a lot to the conversation and was incredibly professional of you.

#4

On Windows, you can alter the registry to add specific parameters into the Mime execution keys so that these parameters are always used.
I have seen a solution for linux to incorporate that parameter (someone was asking to make it “permanent”) by default, it might work as well for OSX, being that OSX is a *nix platform.

I’m just a volunteer giving a personal opinion here, i’m not hired at all.
Xslt/Xml are valid formats and schemes, are not quite as ancient compared to HTML and should not be blocked just because they are stored/recalled locally.

The quick solution would be that Renoise simply plays a local webserver, but it would be a silly workaround to circumvent the method that Chrome is using to solve their personal security issue and it also demonstrates that their particular solution is not waterproof because the files are in that case still loaded locally but then cloaked with a HTTP reference and they can still do damage if they would contain malicious code ;)

#5

Thanks for the reply vV… your first post came off a bit snarky. - I work full time with chrome programmers at google HQ. I trust them over you that modifying my system to allow local XML transforms can be a security threat. Since much of the work I do on my laptop on which I also use renoise (for sound design for google products in fact!) is indeed incredibly sensitive I’m not running the risk, period.

Well said that XML is less ancient than HTML. of course it is, my point is that it really wouldn’t be all that difficult to update the method to one that chrome has no issue with. Chrome wasn’t even around when the current method was written. … but again… super low priority not that big of a deal just thought that from looking at the xslt and seeing the file was last commented in 1999 and I’m certainly not the only renoise user running chrome as my default browser it might be worth considering updating how that kb shortcut file gets its style.

so if this does not get addressed i’ll just continue doing what I was doing - copy paste the xml to firefox. I’m wasting more time just coming here to point out the cause of the issue… :) I thought since I knew the cause and possibly some @ renoise were scratching their heads as to why print kb shorts pulls up a white page in chrome I’d share the reason with hope that it could be resolved not just for me but for all users.

not to be a drag but what search engine did you use to find your “–allow-file-access-from-files” work-around?
touche :)


EDIT: btw your make permanent for linux “solution” was for ubuntu and involves simply editing the launcher - does not apply here at all. It wouldn’t even apply in ubuntu unless you first launch chrome by clicking it’s launcher - would do nothing to address the issue when chrome is your default browser and it was opened by another application.

#6

Yes i perfectly understanding their recognition of the thread, but simply using the similar security mechanisms that every browsers applies for Javascripts or Java applets would have been most sufficient here:A warning dialog with user confirmation. Various browsers even offer multiple security toggles for risky situations:
Always allow (not recommended!)
Warn
Always reject

I’m not judging you for the choice of browser you make, that is completely yours, i’m just pointing out there are other solutions out there that are less intimidating

Bing! (yeah, i’m lying ;) )