E-mail may often be considered a medium of communication that tends to be between two individuals. However, it has been made so that it can be a one-to-many communication medium in addition to being a one-to-one communication medium. Electronic mailing lists have been in existence for a long time, so e-mails have been sent in bulk without them being considered spam for a long time. Also, websites that are often updated tend to include the option for users to receive updates about them via e-mail. Some websites simply send e-mail alerts to users who have accounts set up on them by default. This type of e-mail gets sent out so often, the term “Bacn” was coined for it. Users can limit the amount of Bacn that they receive by not subscribing to e-mail lists, and by subscribing to RSS feeds instead whenever possible. However, e-mail updates can sometimes be necessary.

E-mails from mailing lists and websites tend to be characterized as being sent from the same sender, and these e-mails tend to have similar text in their subject lines. Therefore, users can easily set up filters in Gmail so that messages that match characteristics of Bacn that they receive can have appropriate labels applied to them. For example, I use a WordPress plugin named “WP-DB-Backup” to send myself backup copies of the database that this blog uses via e-mail. The e-mails sent by this plugin all list “WordPress” as the sender of them, and have “Jake Kasprzak Online Database Backup” in the subject lines of these e-mails. As these e-mails have these characteristics, I was able to set up a filter so that all messages that have these characteristics will have the label of “blog backup” applied to them. Therefore, any time I want to display only the backup copies of this blog that I have received via e-mail, I can select the appropriate label. There may also be times that I may not want to see my inbox cluttered with Bacn such as this. As I tend to label the Bacn that I receive, I display only unlabeled messages to filter out the Bacn in my inbox. There are Greasemonkey user scripts for displaying only unlabeled messages in Gmail, and I use those ones. One titled “Gmail Unlabelled” can be used with the older version of Gmail and the version of this script that can be used with the newer version of Gmail can be found here.

There are other reasons to use these labels. This is because e-mail account inboxes are sometimes used for purposes other than storage of messages from other people. When e-mail services offer large amounts of space for storing messages, users use these services for storing large files. The storage capacity offered to Gmail users is one of the reasons many Gmail users, myself included, use it to store files. In fact, GmailFS was created for storing files on Gmail accounts. However, Google’s terms of use prohibit the use of their services by any automated means or any means other than through the interface provided by Google, so GmailFS violates these terms. Nevertheless, Gmail can be useful for storing files, albeit through non-automated means. I sometimes store files there, and I sometimes perform searches through Gmail’s interface to find these files. I also create filters that apply labels to essentially save the searches that I perform most often.

In the time that I have spent blogging, I have sometimes found that I have needed to send notes to myself. I sometimes need to e-mail links to myself, and I annotate these links with information on them. I am often at different locations when I find interesting information on the web, and so I often have my information stored on and accessible from my Gmail account. As you may have surmised, sending myself many e-mails leads to clutter in my inbox. I have found that when I e-mail information such as links to myself, I tend to use similar subject lines. I often include the word “notes” in the subject lines of these e-mails that I send myself. Therefore, I can create a filter that looks for what I tend to include in the subject lines of these messages, and applies appropriate labels to them. I can also have these filters search for appropriate text within the messages that I may want to bring up at later times.

What I have mentioned here may certainly not be considered novel or innovative by those who already try to get the most out of Gmail. I do not plan on being one of those who will submit a video on how I organize my Gmail inbox. However, there may be many who may not be getting the most out of Gmail, and may find that it is even more useful than they thought it was. This blog entry is intended for those who have yet to see how useful Gmail can be. E-mail accounts may often be used for storing personal information, and Gmail seems to have been designed with that in mind. Gmail truly is an e-mail service that has been made better than users have previously imagined an e-mail service could be.

I found that I needed to update the Greasemonkey user script that I wrote titled “Do Not Remember Me” a few weeks ago. There was a very minor adjustment that I needed to make to it after a change was made to the Google Accounts login form. I chose not to write a blog post about this update, as this update was a very minor one. However, if I had a Twitter account at the time, information on this update could have been posted there. Also, the Firefox extension that I wrote titled “Bookmark Current Tab Set” is now considered public and is no longer considered experimental. This change of the status of this Firefox extension is more information that I thought would be better suited to a Twitter post than to a post to this blog.

You may find me on Twitter here. I am not sure how often I will be posting to my Twitter account. However, I plan on posting to it, as I plan on continuing to post to this blog, and I plan on “tweeting” about updates to this blog.

Despite these facts, some websites have the option to be remembered by them selected by default. However, some users may want to try to make it less likely that others will access their accounts by ensuring that the option to be remembered would never be selected. And some might consider it a nuisance to need to deselect the option to be remembered by a site each time they want to log into a site. For these reasons, I decided to write a Greasemonkey script that would remove the checkmarks from checkboxes for indicating that the user wants to be remembered by websites.

This Greasemonkey script that I titled “Do Not Remember Me” is one that looks for checkboxes on web pages and determines whether or not they are for remembering users by checking nearby page material. By default, it is set to work with all websites. However, some users may want to be remembered by some websites. For that reason, this script is one that users of it may want to configure so that it will not be used by some websites.

This script, like other Greasemonkey scripts that are made to work with all websites, might possibly not actually work with all websites. Some users might find errors in it that will cause it to not work with some websites. However, I have found that it does work with the websites that made me want to write this script. Some who often log into Userscripts.org, the website where this and many other Greasemonkey scripts can be found, may want to use this script. As you can see if you view the login page on Userscripts.org, the option to be remembered by that site is selected at first. I myself did not want to keep removing the checkmark from the option to be remembered by that website. It also works with the login page on Google Accounts, which also remembers its users by default. I have also found that it works with Hotmail’s login page. I also set it up so that it would actually add checkmarks to checkboxes that say “public terminal” beside them, as one can see by viewing Slashdot with the script enabled. In addition to ensuring that it works with as many sites as possible, I have tried making it as efficient as possible. It might not currently be as efficient as it could and should be. However, I chose to release it as it is so that I could allow others to critique it.

I could make this post less boring by mentioning some more interesting facts about it. I originally decided to call this script “Don’t Remember Me.” However, it might then be referred to as “DRM.” Many consider that the acronym for Digital Rights Management. I wanted to avoid this acronym collision, even though I did not think that this script would ever be listed on Wikipedia’s disambiguation page for DRM. Some who would look through the code may not be entertained when viewing it. However, I thought of mentioning that the purpose of one function in the script was to “check checkboxes to check if they should be unchecked” and eventually decided to choose clarity over comedy in my comments.

If you have Greasemonkey installed, then you can install this script if you click here. As always, I would be pleased to answer any questions about this script. I could go into greater detail about the implementation of what I wrote, although I do not tend to be asked questions about the implementation details of what I write. I will say that I have also considered writing a very similar script titled “Do Not Remember My Passwords.” As you may have surmised, it would deselect checkboxes for indicating that passwords are to be remembered. I considered combining these two scripts into one titled “Do Not Remember Me and Do Not Remember My Passwords Either” although I thought it might be best to keep these scripts separate. However, what I do next with this script and any related ones may depend on any suggestions that I may receive.

These surrogate scripts handle the situations in which 3rd party scripts from sites such as Yieldmanager.com look for page content that is blocked by NoScript. These surrogate scripts cause pages to be more likely to be error-free by replacing blocked scripts with similar scripts. Some concerned “non-geeks” have wanted to know if these surrogate scripts send any data to 3rd party sites. However, those who have viewed and understand the source code in these scripts can assure these individuals that these scripts simply try to prevent web pages from being broken. There are some users of NoScript who had previously found that some pages were broken unless scripts from sites such as Yieldmanager.com were allowed. I found that when scripts from Yieldmanager.com were blocked, pages on Imageshack.us appeared to be broken. However, these pages did not appear to be broken when the surrogate script for Yieldmanager.com was used. I have also found that these surrogate scripts cut down on the clutter that appears in the error console, as there would be fewer errors on pages when these surrogate scripts are used.

Users who have used the more recent versions of NoScript may have used these surrogate scripts without even knowing that they used them. However, there are those who might want to more easily configure these scripts. At this time, there is no user interface for configuration of surrogate scripts, because as NoScript author Giorgio Maone says, those who would configure these scripts and options regarding them would likely not need one. Still, a UI would be convenient, as adjustments to configuration settings may sometimes be necessary. One might want to more easily adjust which sites use surrogate scripts and which ones do not. Also, one might want to be informed when sites are using these surrogate scripts. In fact, I decided to make a few adjustments to surrogate scripts so that they would display information that says surrogate scripts are being used right on these pages where they are used.

I wanted to know when the surrogate script for code from YieldManager.com was being used. So I added a JavaScript alert statement to the surrogate script for YieldManager.com to determine this. As those who are familiar with JavaScript know, that statement would make a pop-up window appear when that script is executed. I then decided to make that code more complex by adding code to it that would execute when the page is finished loading so that text would be added directly to pages to indicate that this surrogate script is being used with these pages. However, it would be preferable for information on when these scripts are being used to instead be in the browser UI.

Users of the web may always need to choose between security and convenience. The newer versions of NoScript make it so that less convenience would need to be sacrificed for improved security. Still, it would be more convenient for there to be a UI to work with these surrogate scripts used by NoScript. However, it is good to know that the decision to choose security over convenience when browsing the web now seems to be a less difficult one to make.

While some might like to be able to view data that is being sent to and from a web browser, there are those who may find that the Tamper Data extension is not what they need. Those who want to be able to view the data that is sent via web forms may want something more simple, and something that is specialized to the task of displaying the data that is sent through forms. The Web Form Data Analyzer script is for those who only need the software to perform the task that it performs. In addition, the script displays the form data that would be sent through the form without the data ever being sent to the website to which form data is supposed to be sent. Therefore, those who would prefer to simply view the data that would be sent through a form without actually submitting it to the site where it is supposed to go may prefer to use this script.

There may be those who are not sure if the page to which the script redirects submitted form data will accurately display this submitted data. However, the source code that this page apparently uses can be viewed here. As one can see by viewing that code, it is simply PHP code that displays values that would be stored in variables when form data is submitted. And if one does not think that that page actually uses that source code, then the script could be modified so that the page to which it redirects form data will be different. What would be needed in that case would be a web server to host a page that uses code that displays this data. One would likely be using Firefox when using this script, and so one would likely be able to use an extension called Plain Old Webserver to set up a web server. Going through this process of setting up a web server that hosts this page might seem like more work than it is worth, although it is a way to ensure that the data returned will be accurate.

This script may be useful for those who trust the official reference website for the book titled “Webbots, Spiders, and Screen Scrapers.” Those who do not trust it may find that there are other methods for determining what data is sent through web forms. Opinions on whether or not that page can be trusted may differ, and this script is useful for those who believe that the page that this script uses is reliable.

What was discovered may not be considered a bug, as not displaying links below embedded videos that are no longer available on YouTube might be considered expected from this script. However, when I found the time to work on this, I found that the script would add links below videos that are no longer available on YouTube when the option to display video titles is not selected. I needed to find a more appropriate way for this situation to be handled, as the script did not handle this case consistently.

I decided to update the script so that it will always add links below embedded YouTube videos that are no longer available on YouTube. However, it will also add information saying that the title of the video is not available in this case. This information will not be displayed if the option to display titles is not selected. I personally think that this may be considered an appropriate way to handle this situation. However, some might prefer that information on whether or not the video is available always be included in the links added by the script.

If any users have any ideas on better ways to handle this situation, I would like to know what they are. Once again, suggestions from end users will likely be implemented.

This Greasemonkey script that I wrote did not work with embedded videos that were embedded a certain way, and so I made the necessary corrections to it. I also added a feature to it so that it would not add links to YouTube pages on the main Google Video page. This was done because there already is a link below the embedded video that is featured on that page to the page on YouTube where that video can be found. These updates were quite minor, although they needed to be made.

In version 0.2.0 of the Firefox extension that I wrote, I added a menu option that brings up a dialog box. However, it was only after releasing this version of the extension that I thought that I should add an ellipsis to the end of the title of this menu option. I could have checked the extension more thoroughly for errors both in functionality and in the user interface before releasing version 0.2.0 of the extension. However, as is it often said that those who write this kind of software should release early and release often, I chose to release it before I could check for all errors that I might have made in writing it.

I am currently trying to decide on what kind of software to write next, and I am not sure what my focus should be. However, I am sure that I will continue to make the necessary updates to what I have already written.

This second error was one that I discovered after Googling myself. This egosurfing indirectly led me to this page, which actually has information on this script. However, the page actually contains an embedded YouTube video to which my script did not add a link. After checking the parameters in the tags used to embed the video, I found that the .SWF extension was added to the end of the URL of the YouTube page where the video can be found. Therefore, I once again needed to update this script to handle a case that I did not think it would need to handle. Once again, however, only slight modifications needed to be made to correct this error.

This script has been publicly available for a long time. And during the time that it had been publicly available, errors like these had either not been found or were never reported. I certainly hope that the former rather than the latter is the case, for obvious reasons. However, in any case, I will try to decrease the number of pages on the web that have YouTube videos embedded in them with which this script will not work.

I recently received a request from an Internet Explorer user to modify my Greasemonkey user script that redirects users to the older version of Gmail after logging into Gmail so that it could be used with Internet Explorer. And after discovering that I could simply remove the code for toggling whether or not the secure version of Gmail is to be used to make it compatible to Internet Explorer’s add-ons for running user scripts, I made these changes. This option for using HTTPS while using Gmail may have been obsolete for the last few months, as it was a few months ago that Gmail began giving this option for using HTTPS while in Gmail. I tested this modified version of the script with an add-on for Internet Explorer known as Trixie and found that the script worked with that add-on. I also copied and pasted the script code into a script that comes with an add-on called IE7Pro and found that it worked with IE7Pro, although not as efficiently.

This version of the script can be retrieved from here. This script might also work with Safari when its add-on for running user scripts is installed. However, I have been unable to use this add-on, titled GreaseKit, to determine whether or not Safari users can use this script. I have also been unable to test out this script on Google Chrome when it is used with Greasemetal, although users of Google Chrome might possibly be able to use it. This version of the script, however, does not work with Opera. However, I may take the time to make this script work with Opera. Once again, whether or not I will ensure that this script will work with other browsers depends on whether or not there will be demand for this support from users of these other browsers.

As one can see after viewing the video, after an initial attempt at injecting SQL statements into a login form on this page, it was revealed that characters that tend to be used in SQL injection attacks were filtered using JavaScript. Then, it was demonstrated that such JavaScript-based filters can be removed by simply editing the page’s source code and saving it on the local hard drive. Other modifications were made to the page’s source code, such as conversion of a relative URL for submission to an absolute URL, which was necessary as the modified page was to be viewed offline. In addition, the maximum length of the password field needed to be increased in order for the SQL injection attack string to be entered, and so that change was also made. Also, as one would prefer to be able to view all data one is submitting, the password field was changed to a regular text field so that text in that field could have been viewed.

Measures may have been taken to prevent SQL injection attacks through this page. However, as was demonstrated in this video, measures taken through client-side code can be very easily circumvented. As a matter of fact, some of the tasks performed by the individual performing the security audit could have been automated, thus decreasing the amount of effort needed to succeed in performing the attack. Making the password field text visible and increasing the maximum length of the password field can be done automatically via Greasemonkey user scripts. Also, extensions for Firefox such as the Web Developer extension can also automatically perform such tasks as revealing what is typed in password fields. Disabling of JavaScript could also possibly be done to circumvent JavaScript-based filters. And if it is found that the site requires that JavaScript be used, then manual page modification could be done to remove JavaScript. In any case, measures for preventing SQL injections should not be in client-side code, which is an important lesson one can learn after viewing this video.

Also demonstrated in the video are possible implications of SQL injection vulnerabilities. After it was revealed that the attack was successful, it was demonstrated why it was important for security measures to be put in place on that site. Much information on the individual whose account was accessed became visible, as one could see near the latter part of the video. One such piece of sensitive information accessed was that individual’s social security number. And when SSNs can be accessed through a site, one should certainly keep that fact in mind when trying to prevent unauthorized access to the data in databases used by the site.

This video has been viewed over 500,000 times at the time that I have published this entry. However, I am not sure how many times it was viewed before the page was corrected. This video demonstrates how not to prevent SQL injections, although it should not be considered a tutorial on how to perform SQL injections. A very common SQL injection string is used after the easily-circumvented measures taken to prevent it from being submitted are circumvented. Use of the methods used in performing this attack will not work when attempted on many sites. However, one has to wonder how many websites use such a flawed method of preventing SQL injection attacks. Even if 99% of websites use better measures to prevent these attacks, that still leaves many websites vulnerable to this type of attack. And how many of those websites have information as sensitive as SSNs stored in the databases that they use?

This video may not teach those who view it much about how to prevent or perform SQL injection attacks. Its lesson seems to be the importance of preventing these attacks. When sensitive data can be accessed by a user with proper credentials, a website through which this data can be accessed should certainly not fall for some of the oldest tricks in the book.