The attachment is a screenshot of Chrome Developer Tools when looking at Google+ HTML. Note the ~random classnames:
The source for unreadable identifiers can be:
minification
obfuscation
random Id generation
Google Plus is probably implemented as a GWT (or similar framework) application with minified resources (javascript and css files) and automatically generated identifiers. Minification is also widely used as a tool for obfuscating the code so the unreadability is partly intentional too.
Obfuscation can be used to reduce code size, as well as reduce code readability for an "unauthorized" user to make it harder to reverse-engineer a product/program or steal ideas. Someone asked a pretty similar question here, that should answer any more questions that you have.
Related
I have couple of Js files including jQuery in my website.
Google says:
The last time Google tested a site on this network was on 2013-02-14, and the last time suspicious content was found was on 2013-02-14.
Do you have any idea in what conditions Google may detect malware in Js files? Problem with code or malware in file?
Sorry for the vague answer, but without more details I can't be more specific. In general there are certain patterns and code techniques that are commonly used by malware to overflow buffers in browsers, thus giving the attacker control of the system. The Javascript itself is just used as a conduit to the browser. Often, Shellcode bytes are encoded into javascript for delivery to an unsuspecting user's browser. If you have encoded data being delivered through Javascript, it may appear as suspicious to Google's heuristics engine.
It is also possible that you are using similar techniques to poisonous scripts (sometimes used for Cross-site scripting (XSS) and Cross-site request forgery (CSRF)) to accomplish some of your work, and this is a good way to get flagged by Google.
Another possibility is that your website code is fine, but it has a security hole that causes Google concern because a malicious user can exploit your site. To determine this I recommend using a web scanner such as Nikto, Burp Suite (my personal favorite), Acunetix, etc. to try and find security holes.
You can also find a lot of great info at OWASP
I hope this helps, as having your site flagged by Google can cause a lot of frustration and anxiety. Good luck!
If Google says they found malicious (or suspicious) code in your files, there is malicious or suspicious code in your files.
Sorry but, Google doesn't scan for vulnerabilities - only bad code already existing on your site. Without knowing more about your website, operating system, software, etc. it's impossible to give you more information on how it happened.
If they detected it in your .js files, you may have a document.write statement either at the very beginning or the very end of those files. The problem for you is that even if you find and remove the infectious code, you still don't know how it happened. Without knowing that and taking steps to prevent it, it will return.
I'm architecting an enterprise web application using python, django. My final decision to make is which javascript library to use. I'm thinking about using Google's closure library or YUI3. Most of the development, I've used jQuery.I can code fast with jQuery but doesn't seem right for enterprise use.
YUI 3 seems pretty good. It includes most widgets I want to use, but Closure library does almost the same. Better offer with Closure library is they have Closure Compiler, but seems like Closure requires to write much more code than YUI 3. Documentation from YUI 3 is pretty good too.
The application will be for both web and mobile devices, so the library should not break in mobile device such as Android or iPhone.
If you were me, what decision would you make?
Disclamer
I mostly draw on comment about jQuery in enterprise environment and since I lack experience in YUI, I can not give any conscious advice for [not] using it over Closure.
But in lack of any other answers I'll share my experience with Closure.
Closure library
As for Closure library, which I have been using for last few projects but am, by no means, expert at it, I can say only good things.
Library provides the core components you need when building any kind of UI. But, unlike jQuery, it does not come with trillions of "ready-to-deploy" plugin-in scripts, or as some would say, with no batteries included.
It's got basic events, controls, xhr, dialogs, form components etc., and by my account the most important thing, namespaces (or at least something looking like them...).
With this you can create your own custom UIs limited only by your imagination and the power of JavaScript (and JS is very powerful language even if it does have its own annoyances).
And with help of Closure compiler, which not only minifies the code but it excludes all unused code, does type checking, gives warnings useful for debuging and so forth, it looks like solid foundation for building large applications ground up by teams of any size.
In my opinion, main reason for using Closure over jQuery in enterprise projects is consistency. Plugins are awsome but they tend to include inconsistency at all levels, either programming practices, visual styles and structure, performance, usage, you name it. Removing these small inconsistencies on large project can waste lot of time.
So in conclusion, if you have large project needing custom UI and a lot of flexibility Closure is the Right tool for the job. And with "namespaces" it even feels all Pythonish.
P.S. We also use Django on server side.
You have touched on most of the important aspects here, the type checking, minification, namespaces, but I would like to add a few more. Alongside is the templating sollution they offer, which is not only super fast and has full internationalisation support, this mixes in and compresses with the library. It also compiles down to java code so you can render on both the server and the client from the same template.
Then there is the component architecture which has a complete livecycle, seperates renderers from components, (if you are familiar with swing or flex you will get the idea), it has two models, one is client side rendering and the other is decoration which plays beautifully alongside the server side rendering.
The testing sollutions are well defined and now the
We have thousands upon thousands of lines of javascript and without closure it would have been an unmaintainable mess IMO.
I'd go with YUI 3. Especially if the only reason you're considering Google's Closure is the compiler. As this works well in YUI 3, with much better compression than the YUI compresser. I'm sure it doesn't do as good a job as it could with Closure code, but that's pretty hard to test.
The modular framework in YUI 3 is awesome, and there is enough sugar to give you a tooth ache without being too heavy. Yahoo use it for all their sites, and they have a strong emphasis on performance (so it can't be all bad).
In the tests I made, Google Advanced Compress is the better, and after the the Yahoo! YUI Compressor. You can make the tests here:
http://jsperf.com/closure-vs-yui
I want to build a custom CMS where users a Rich text editor is the main way to create content rather than wiki markup.
Besides stability and performance, I want the RTE to be easily extensible. The latter point is very important because I intend to extend it to my needs.
For example I want the users to be able to embed OpenSocial gadgets and whiteboard (based on canvas) into the page. I also the want the users to embed media source like (youtube, slideshare etc).
My preliminary investigation shows that Dojo's (dijit) RTE and TinyMCE are pretty good. How would you compare the two in terms of stability, performance and extensibility. Any other RTE's I should be looking at that fit the bill?
PS: I am using dojo as the main js library.
Hava a look here (blog post with some very helpfull informations).
My own opinion is that there are two free available rtes that are close to each other in comparison. Those are CKEditor and Tinymce. My experience lies on the tinymce side and i can say that the extensibility using own plugins is great with it. Some independent tests have shown that tinymce seems to be more adavanced than CKEditor, others claim CKEditor is better. You will have to decide on your own (development is advancing further each day and new functionality has been developed since those tests).
You may also have a look here for comparisons and discussions:
http://verens.com/2007/09/27/fckeditor-vs-tinymce-vs-everything-else/
http://verens.com/2007/09/27/fckeditor-vs-tinymce-vs-everything-else/
http://www.mediacurrent.com/blog/wysiwyg-shootout-and-winner
Having been inspecting a few elements on Google, i noticed that their naming conventions are fairly funky, ie.
.n-Wa-q-Dc, .n-xb .n-Wa-q-Dc:hover
This is clearly not readable/manageable by a human. Is it the opinion that Google's CSS and class names are largely auto generated by server side technology.
I cant see people maintaining such a CSS file myself.
Would it be advisable for such a large system (Google) to have any people managing the CSS and just to let the systems handle it?
They should have a version that is human-readable (for development) and, from that, generate the obfuscated version (for deployment). Most likely, a search-n-replace is performed on the names of the scripts or stylesheets (from using human-readable to obfuscated ones) before deployment.
It looks as though they probably ran their css through a minifier to reduce the size of the css file. As
As background, I currently develop for a university, and we have problems with departments demanding "web 2.0 content" and accessibility requirements.
How do really big sites that are JavaScript based deal with 508 Compliance? Some sites degrade, and others require enabling JavaScript. How much impact does one decision have versus the other?
Also, in a realistic sense, how much development time should be devoted the accessible versions of sites versus the "main" versions?
I'm a blind developer and find it possible to use many Web 2.0 sites - this is most certainly possible.
Firstly, I strongly advise against making a separae accessible site, regardless of how many people advise you to do this. This is bad practice and will end up being more work, even if it initialy seems simpler.
Next, try to use progressive enhancement (particularly if this is a new site). Code the site without any Javascript; it's not just accessibility which benefits. Then, in your OnLoad() go through and attach Click events to the anchor tags; this way if you have Javascript you'll see the Ajax version, otherwise you will have a full page refresh and see another HTML page.
Luckily, there is a new standard, WAI-Aria (www.w3.org/WAI/intro/aria.php) which makes this much simpler. You attach attributes to HTML tags to identify the semantics of an Ajax control, for example. The only problem with Aria is that it only works with newer screen readers and web browsers. The university may well require the site be accessible to people running older software.
I'm a screen reader user and often use Javascript enabled sites. Javascript is not an accessibility issue, the way it is used can be. For example if the site uses javascript that requires the use of a mouse and doesn't have keyboard alternatives it will not be 508 compliant. An example of a site that uses Javascript and is accessible is stackoverflow.com. The only feature that isn't accessible is the ability to determine if you have accepted an answer to a question. I would take a look at the links in Annie's answer. All the blind college students I know use a fairly modern browser with Javascript enabled, Lynx is no longer popular in the blind community. If you want to try using a screen reader a good open source one for windows can be found at
http://www.nvda-project.org/
and it works well with firefox. If you want to try using the web with out Javascript install the Noscript addin.
Sites don't have to disable JavaScript to be accessible. Many sites use ARIA roles to work better with screen readers. There's a giant list of articles on accessible AJAX applications here. You could try something like AxsJAX.