Tuesday, 9. January 2007, 00:19:22
Embedded Images Do Not Work In IMG Elements in 9.10
This appears to be a regression from earlier versions of Opera. In earlier versions you were able to do something like this:<img src="data:image/png;base64,<insert base64 encoded stuff here>"/>
Something like that would show an image. It doesn't seem to do so anymore. It still does work through CSS like if you do something like this:
div
{background-image: url(data:img/png;base64,<insert base64 encoded stuff here>);}
I've set up a document that has an embedded image in it and have attached it to the post. If it worked properly should show a caution triangle with an exclamation mark in it.
test.html
I've also filed a bug report. Bug #246649.
Tuesday, 9. January 2007, 00:25:16
Well, I get the warning triangle in 9.10... you didn't disable some things, like images etc? I'm using Windows, but this doesn't look like a platform issue to me.
Tuesday, 9. January 2007, 00:44:50
I haven't disabled images. I checked if I triggered it accidentally again. After I made the post I tested it in Windows just to make sure and it shows up fine. Dunno. I'll see if redownloading it will work on this Mac. If not I'll test it at home to see if it works fine there. If it doesn't it might just be a Mac bug.
Tuesday, 9. January 2007, 01:08:52
Ahh I found the culprit. Stupid me. I downloaded the urifilter.ini file distributed around here and it blocked it for some reason, but I don't know why it would block it as I can't see anything in it that would do it. It's also odd that it would block it only when used in image elements. If embedded through CSS it works just fine. Urifilter usually blocks it regardless. I've attached the ini file here. I've tested it on both OS X and Windows XP with the ini file in effect and it doesn't show the image. Weird.
urlfilter.ini
urlfilter.ini
Tuesday, 9. January 2007, 10:18:11
Nice, you got it... 
Couldn't this be considered as a flaw in the content blocking algorithm?
I believe, such base64 encoded stuff for embedded objects or generally embedded objects: shouldn't they be skipped by that algorithm...
But I'm no web-designer, M/B there are still other cases which could then contain ads?
Couldn't this be considered as a flaw in the content blocking algorithm?
I believe, such base64 encoded stuff for embedded objects or generally embedded objects: shouldn't they be skipped by that algorithm...
But I'm no web-designer, M/B there are still other cases which could then contain ads?
Tuesday, 9. January 2007, 16:57:30
Yeah the content filter stuff shouldn't be matching things inside base64 encoded stuff at all, actually. The encoded crap could potentially match any random block such as the /AD4 that blaabjerg found (thanks btw). I think it should disregard base64 encoded URI's unless you tell it to block base64.
People could embed ad images using base64, but it's unlikely at the present time because IE still doesn't have support for base64 encoded images (even in IE 7). It could potentially be a problem in the future if IE ever supports it as I'm sure spammers will see it as an ideal way to feed their annoying ads.
People could embed ad images using base64, but it's unlikely at the present time because IE still doesn't have support for base64 encoded images (even in IE 7). It could potentially be a problem in the future if IE ever supports it as I'm sure spammers will see it as an ideal way to feed their annoying ads.
Tuesday, 9. January 2007, 17:27:17
Originally posted by Khadgar:
Never mind, if this happens, the content blocker must be able to block this image, it's still an image and also declared as such in HTML!People could embed ad images using base64...
No need however to scan the whole base64 stuff, this has to be skipped completely.
Any SW-dev could implement this in a short time...
BTW, did you already mention this thread in your BUG-report?
If not, could you please send an email to said report, pointing to the URL of this thread.
TIA
Wednesday, 10. January 2007, 09:30:11 (edited)
Originally posted by xErath:
I don't understand...How else will you block a base64 encoded image ?
There's always a header, e.g. <img src="data:image/png;base64,##### and an end e.g. #####" with an apostrophe, the stuff in between is coded in base64 (#####...##### in my example), which has to be skipped!
Where's the problem?
In order to identify the image on the page, do some enumeration - no need to identify said image by its real (whole) contents...
Wednesday, 10. January 2007, 23:52:40
Originally posted by xErath:
Of course, this would be silly and that's why I didn't even think to propose such a nonsense! You forgot my enumeration solution, that's needed, for sure...Sniffing for the header blocks ALL base64 encoded images, which is very bad.
Leave that base64 stuff alone! It's not controllable.
Monday, 15. January 2007, 03:43:24
Like I've said before, generic url filters are BAD ! And your is the worst I've seen in that regard. All dots next to asterisks were removed.
Some context:
http://thedailywtf.com/Articles/The_Great_Google_Banner_Ad_Conspiracy_.aspx
Some context:
http://thedailywtf.com/Articles/The_Great_Google_Banner_Ad_Conspiracy_.aspx
Forums » Opera Community » Opera for desktop » Opera browser
