Uhhhh. Did you check for spacing in the names? If you just copied and pasted the URL's there might have been some spaces accidentally included in the Slashdot posting.
This all seems like a moot point anyway. I guess that's why Google Print is listed in Beta status. Obviously most non-IE browsers can easily bypass this DRM. Those IE users can simply choose View --> View Source from the IE menu bar. Perform a search for.theimg and then copy and paste the background-image.url value into the Address field of IE.
Here is an excerpt from a Mozilla blog regarding this. The parent URL of the print.google.com example is http://print.google.com/print?id=ULQSG0Zs7vcC&lpg= 3&pg=0_1&sig=O0-GVU5AdfrMmUtu0N5mNM7sUCg.
Next idea: use the DOM Inspector to inspect the entire browser XUL. This means that the context menu will still work. It's more difficult to do, because you can't locate elements by clicking in the content area - it only works for the chrome. Still, we finally track down the clear GIF and delete it. Boom! This time Firefox crashes (taking with it an earlier version of this blog post.):-(
OK, let's try another approach. Let's find the surrounding
in the DOM Inspector, look at its computed style, and copy the URL out of it. Except that the Computed Style view doesn't support copying. Undeterred, and feeling close to the goal, we view the applied styles for the
and try and copy the URL out of the individual background style rule.
Success! This works. We can chop off the CSS gubbins, paste the result into a web browser URL bar, and finally get an image we can save.
In fact, you can also get the URL of the page graphic by viewing the source. It turns out that it's not as hard as I made out, because currently, the
in question has a sensible class name:.theimg { background-image:url("http://print.google.com/prin t?id=ULQSG0Zs7vcC&pg=3&img=1&sig=gv2nFptEf0dj7Gzb8 eZ4U8UdtUo") } so it's easy to find.
"certainly the ability for a remote attacker to disable critical browser features like save, right-click, copy and cut against the user's wishes is a major security vulnerability in Moz/Firefox and should be fixed ASAP"
A little extreme journalism? Such functions (and lacks thereof) have been around across the various browsers for years now. People want to protect their work. Big deal. I'm sure that there will be black hats who will find a way around any copy protection process. Be it for DVD, MP3, Windows Media, AAC, PDF, etc. Legal to do so? Perhaps? Does that make it ethical? Probably not.
As for home users I can see some of the more savvy ones get fed up with MSIE and adopt an alternative. Those less savvy home users will just tough it out and get jammed with tons of exploits and spyware.
Corporate users a lot of times are stuck into software policies and standards. Just jumping ship isn't as easy. Look at the Office -vs- OpenOffice debate that sparks up across so many workplaces. As an example of MSIE quagmire my company has to use certain third party vendor websites for transaction processing and these sites foolishly require MSIE in order to properly function. So either I splinter our software standardization by having both MSIE and a non-MSIE alternative or else I patch and lock down MSIE as best as I can. Unfortunately I am forced to do the latter.
I know many of y'all will say, "Demand that the vendor open up their web development standards" or "Just get a different vendor" but often the real world isn't as cut and dried.
Isn't that the beginning of a recursive function?The author of a book for dummies needs to read his own book for dummies before writing his book for dummies?
Odds are I RTFA. All you have to do is read the Microsoft KB article for the details. If you tried your experiment against a known ASP.NET website, had these results, and know the the one configuration file was untouched then more power to you...
If you'd read the KB article you simply a few lines of code to a global file that resides at the root directory of the web application. While I'll admit the vulnerability is sadly elementary and has existed in previous Microsoft implmentations it's not like Microsoft has asked developers to completely recode every single file of a web application.
It's like saying, hey Samba has this really basic flaw. But if you add an entry in your smb.conf file it's okay. It's not the end of the world. It's crazy to think that the security hole made it past their (supposedly rigorous) peer code review process but the workaround isn't too much to ask.
From what I read on it on Bugtraq it appears to be one of the good old directory transversal flaws. E.G. if you don't have access to http://server/directory/file.asp you can simply go to http://server/directory\file.asp to access it. That or else use some unicode equivalent. Isn't it funny how Microsoft's leading edge Trustworthy Computing is still vulnerable to the same old sploits?
I don't understand your post. If you are saying that Avaya is only traditional telco, they have been selling VoIP equipment for over three years now. The last World Cup matches had the entire setup using VoIP and WVoIP services provided by Avaya...
From my experience over the past several years it's been getting closer to making a big jump. My company has used Avaya products for awhile now, going back to the old AT&T Merlin line even. They have a good selection of VoIP products.
To me the biggest stumbling block is how that traditional PBX'es are more hardware-centric and VoIP is more software-centric. Which do you think traditionally has been more reliable?
Consider mean time between failure rates for tradtional PBX voice services. Then consider a typical VoIP environment. I don't have hard figures, but I would imagine there's still a vast difference. Imagine a facility using VoVPN then extrapolating it out a little further.
If there are cost savings to VoIP and the PHB's for a company are placing that as a higher priority than reliability and security then perhaps things will continue to move toward VoIP. But I personally have worked as both a telco and a data tech and I think that traditional PBX'es are still more bulletproof than newer VoIP packages. If I'm wrong I'd be happy to hear...
I'm amazed how this got modded 'Informative' when the definition isn't even correct. In the article's context they are referring to XAML as the Microsoft Extensible Markup Language. Well...then again I guess I'm not amazed.
Or the worst of the worst? The Yugo. I read somewhere that Renault was finding a way to make an even cheaper version of Le Car. They reportedly scrapped the plans since the product was too low quality. Apparently the government of Yugoslavia salvaged the plans and bought them from Renault. Voila....the Yugo.
I remember when this guy I knew was showing off this used Yugo he had bought. It had all of the options. Even a sunroof. Good thing it had one since all of the manual window cranks were broken so the windows wouldn't roll down!
Good try, but if you re-read the post it mentions that the brakes weren't effective and he couldn't turn off the engine due to the fact it wasn't engaged with an ignition key. The "shove it in neutral" part makes sense, though. Or for a real rip the guy should've kicked it into reverse. The engine would've shot right through the hood!
It is indeed a collaboration. An outside developer cannot step into a business environment and understand workflows and their operational requirements without the customer doing their job as well. So if something fails just as the success of something is shared so is the blame. Poorly conveyed requirements hand off to poorly constructed code which hands off to a poorly tested app which hands off to buggy or clumsy results which finally hands off to an unproductive business environment.
Re:Does he work close to HELL???
on
AMD 90nm Evaluated
·
· Score: 2, Funny
This must be the data center for Kathi Lee Gifford's clothing sweatshop.
Slashdot Mirror
Too bad they didn't contract out these units to a manufacturer that added in built-in fans like the AC adaptors on the VIA Mini-ITX models...
Uhhhh. Did you check for spacing in the names? If you just copied and pasted the URL's there might have been some spaces accidentally included in the Slashdot posting.
.theimg and then copy and paste the background-image.url value into the Address field of IE.
This all seems like a moot point anyway. I guess that's why Google Print is listed in Beta status. Obviously most non-IE browsers can easily bypass this DRM. Those IE users can simply choose View --> View Source from the IE menu bar. Perform a search for
Here is an excerpt from a Mozilla blog regarding this. The parent URL of the print.google.com example is http://print.google.com/print?id=ULQSG0Zs7vcC&lpg= 3&pg=0_1&sig=O0-GVU5AdfrMmUtu0N5mNM7sUCg.
:-(
.theimg { background-image:url("http://print.google.com/prin t?id=ULQSG0Zs7vcC&pg=3&img=1&sig=gv2nFptEf0dj7Gzb8 eZ4U8UdtUo") }
Next idea: use the DOM Inspector to inspect the entire browser XUL. This means that the context menu will still work. It's more difficult to do, because you can't locate elements by clicking in the content area - it only works for the chrome. Still, we finally track down the clear GIF and delete it. Boom! This time Firefox crashes (taking with it an earlier version of this blog post.)
OK, let's try another approach. Let's find the surrounding in the DOM Inspector, look at its computed style, and copy the URL out of it. Except that the Computed Style view doesn't support copying. Undeterred, and feeling close to the goal, we view the applied styles for the and try and copy the URL out of the individual background style rule.
Success! This works. We can chop off the CSS gubbins, paste the result into a web browser URL bar, and finally get an image we can save.
In fact, you can also get the URL of the page graphic by viewing the source. It turns out that it's not as hard as I made out, because currently, the in question has a sensible class name:
so it's easy to find.
A little extreme journalism? Such functions (and lacks thereof) have been around across the various browsers for years now. People want to protect their work. Big deal. I'm sure that there will be black hats who will find a way around any copy protection process. Be it for DVD, MP3, Windows Media, AAC, PDF, etc. Legal to do so? Perhaps? Does that make it ethical? Probably not.
As for home users I can see some of the more savvy ones get fed up with MSIE and adopt an alternative. Those less savvy home users will just tough it out and get jammed with tons of exploits and spyware.
Corporate users a lot of times are stuck into software policies and standards. Just jumping ship isn't as easy. Look at the Office -vs- OpenOffice debate that sparks up across so many workplaces. As an example of MSIE quagmire my company has to use certain third party vendor websites for transaction processing and these sites foolishly require MSIE in order to properly function. So either I splinter our software standardization by having both MSIE and a non-MSIE alternative or else I patch and lock down MSIE as best as I can. Unfortunately I am forced to do the latter.
I know many of y'all will say, "Demand that the vendor open up their web development standards" or "Just get a different vendor" but often the real world isn't as cut and dried.
Isn't that the beginning of a recursive function?The author of a book for dummies needs to read his own book for dummies before writing his book for dummies?
My bad. Here's the parent of the threads I ran across this week pertaining to PHP (in)security.
Odds are I RTFA. All you have to do is read the Microsoft KB article for the details. If you tried your experiment against a known ASP.NET website, had these results, and know the the one configuration file was untouched then more power to you...
Here's a vulnerability or two right here. Too bad they are in the revered PHP platform. Just to show that no one is immune.
If you'd read the KB article you simply a few lines of code to a global file that resides at the root directory of the web application. While I'll admit the vulnerability is sadly elementary and has existed in previous Microsoft implmentations it's not like Microsoft has asked developers to completely recode every single file of a web application. It's like saying, hey Samba has this really basic flaw. But if you add an entry in your smb.conf file it's okay. It's not the end of the world. It's crazy to think that the security hole made it past their (supposedly rigorous) peer code review process but the workaround isn't too much to ask.
Let's all go to http://www.billgates.com/files\private\How Can I Repackage the Same Old Shit in a New Wrapper.doc
From what I read on it on Bugtraq it appears to be one of the good old directory transversal flaws. E.G. if you don't have access to http://server/directory/file.asp you can simply go to http://server/directory\file.asp to access it. That or else use some unicode equivalent. Isn't it funny how Microsoft's leading edge Trustworthy Computing is still vulnerable to the same old sploits?
I don't understand your post. If you are saying that Avaya is only traditional telco, they have been selling VoIP equipment for over three years now. The last World Cup matches had the entire setup using VoIP and WVoIP services provided by Avaya...
From my experience over the past several years it's been getting closer to making a big jump. My company has used Avaya products for awhile now, going back to the old AT&T Merlin line even. They have a good selection of VoIP products.
To me the biggest stumbling block is how that traditional PBX'es are more hardware-centric and VoIP is more software-centric. Which do you think traditionally has been more reliable?
Consider mean time between failure rates for tradtional PBX voice services. Then consider a typical VoIP environment. I don't have hard figures, but I would imagine there's still a vast difference. Imagine a facility using VoVPN then extrapolating it out a little further.
If there are cost savings to VoIP and the PHB's for a company are placing that as a higher priority than reliability and security then perhaps things will continue to move toward VoIP. But I personally have worked as both a telco and a data tech and I think that traditional PBX'es are still more bulletproof than newer VoIP packages. If I'm wrong I'd be happy to hear...
I'm amazed how this got modded 'Informative' when the definition isn't even correct. In the article's context they are referring to XAML as the Microsoft Extensible Markup Language. Well...then again I guess I'm not amazed.
Not since I patched my machines the first time to not be succeptible to the oldschool blaster/dcom styles.
Personally I'm surprised that the French automobile continued to accelerate. If it was true to its nature it should've unconditionally surrendered...
Imagine if they had Onstar. Then they could just have some flunky with 2 weeks of training remotely stop the car for them.
Or the worst of the worst? The Yugo. I read somewhere that Renault was finding a way to make an even cheaper version of Le Car. They reportedly scrapped the plans since the product was too low quality. Apparently the government of Yugoslavia salvaged the plans and bought them from Renault. Voila....the Yugo.
I remember when this guy I knew was showing off this used Yugo he had bought. It had all of the options. Even a sunroof. Good thing it had one since all of the manual window cranks were broken so the windows wouldn't roll down!
What's wrong with Renaults? Oh yeah, two words. Le Car...
Good try, but if you re-read the post it mentions that the brakes weren't effective and he couldn't turn off the engine due to the fact it wasn't engaged with an ignition key. The "shove it in neutral" part makes sense, though. Or for a real rip the guy should've kicked it into reverse. The engine would've shot right through the hood!
Now I know who is the one wasting all of their day on company time reading Slashdot. You're fired. Pack your shit up and get out.
Now.
Sincerely,
Your Boss
I had to follow your link, as I thought you were referring to Peter Gibbons from Office Space. That seemed appropo as well...
It is indeed a collaboration. An outside developer cannot step into a business environment and understand workflows and their operational requirements without the customer doing their job as well. So if something fails just as the success of something is shared so is the blame. Poorly conveyed requirements hand off to poorly constructed code which hands off to a poorly tested app which hands off to buggy or clumsy results which finally hands off to an unproductive business environment.
This must be the data center for Kathi Lee Gifford's clothing sweatshop.