141–150 of 236 posts
Earlier quoted context omitted.
If these tracking pixels are in iframe elements instead of img elements.
If they were iframe elements, they'd still be sandboxed from the parent page, and unable to phone-home with information, right?
A testament to one of the worst decisions in computing history - not to fail displaying a web page with an error message in case it is not a valid HTML document.
They started making browsers more lenient since there was so much poor malformed HTML being produced
A testament to one of the worst decisions in computing history - not to fail displaying a web page with an error message in case it is not a valid HTML document.
Being flexible about what markup is accepted has meant the web could gain new features and gracefully degrade, and has made it more fault-tolerant. It's not at all a failing. Compare that to JavaScript, which will happily fail if you use new syntax or a missing function, and thus web pages which rely on JS often show up as just a full screen of white when something goes wrong, which it frequently does. That's not to…
Earlier quoted context omitted.
Not to be rude, but in the USA (where SWIFT or bank wire transfers can be expensive) an email address as a recipient of an online fund transfer is a pretty common; ie: paypal, venmo, chase quickpay now specifically in this case, lcamtuf (at google security) is joking and doesn't want your money. this hack is actually pretty crazy - an arbitrary HTML / jpeg polyglot file that fooled a browser could be used for js inje…
This has been done in the past. I remember seeing an advisory as far back as 2010, but at the moment can only find these two more recent advisories: https://websec.io/2012/09/05/A-Silent-Threat-PHP-in-EXIF.htm... https://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-ex... The way we protected ourselves against it at (since we allowed image uploads at a variety of locations) was to decode and recode the image befo…
Earlier quoted context omitted.
Well of course if correctness is not a requirement then it's not being paid attention to. That doesn't in any way indicate that it was a good decision not to require it in the first place.
If it had been made as difficult as possible for enthusiasts learning a markup language to get what was essentially text document to actually display anything, it's probably not too much of an exaggeration to say the World Wide Web wouldn't have existed in its current form. It's not as if many of the web's security holes are related to whether a page displays valid HTML markup or not.
Earlier quoted context omitted.
Being flexible about what markup is accepted has meant the web could gain new features and gracefully degrade, and has made it more fault-tolerant. It's not at all a failing. Compare that to JavaScript, which will happily fail if you use new syntax or a missing function, and thus web pages which rely on JS often show up as just a full screen of white when something goes wrong, which it frequently does. That's not to…
There's nothing wrong with some tolerance, like ignoring tags that it doesn't know. But if the syntax is wrong, it shouldn't try to fix it or guess what the user meant, just display an error. Accepting invalid syntax means all HTML parsing becomes vastly more complicated. Which creates room for bugs, exploits, and unexpected situations like OP's post.
Why push the complexity onto the user? Someone who just wants to make a working website doesn't care about your pedantry.
Do they want their page to fail to render entirely when PHP outputs a warning? Do they want their website to be completely broken because they forgot to convert some of their text from Latin-1 to UTF-8 before pasting it into the document? Should we really expect them to have to modify their blogging software to validate custom HTML snippets, lest the entire page become unusable? Will they be pleased when their style of code falls out of favour in future, is deprecated, and then their page doesn't work at all later?
Moreover, strictness can backfire when you have such a diversity of implementations.
> Which creates room for bugs, exploits, and unexpected situations like OP's post.
The OP is not so much an unexpected situation as a carefully engineered one that's completely within the constraints HTML sets.
You can use URI to embed images too, not sure how this is done though, why not just use URI?
Data URIs are useful for embedding resources in a page (e.g. a single HTML file containing all of its own CSS, JS, images, etc.) This is different: it's a single file which can be parsed as either a HTML page or a JPEG. Hence, when a program expects a HTML page (like a browser loading a Web page), it will be parsed and displayed as a HTML page. When a program expects a JPEG file (like a browser loading the "src" of a…
Prior discussion, years ago, many comments: https://news.ycombinator.com/item?id=4209052
which begs the question: where are all the "essential squirrel facts" that were promised?
Earlier quoted context omitted.
I kinda agree, but one has to concede that XHTML has failed for a reason.
XHTML failed because doing the old, broken, tag-soupy mess still worked exactly as well from the user perspective. You just can't get people to work harder for invisible benefits. In a sense, it's a reason, but it doesn't mean that tag soup is a good thing. I often wonder how different the internet would be if Postel's prescription never gained traction and fail-fast behavior were the norm instead.
Maybe it would be so bad that somebody else would make a new, more permissive standard that took off instead.
Maybe all of that has already happened.
Maybe that line from Battlestar Galactica was right - All of this has happened before; all of this will happen again.