Nov 11, 3:03 Nov 6, 12:26 Oct 30, 12:44 Oct 26, 9:03 Aug 16, 1:09 Apr 6, 8:51 Mar 30, 12:19
For the second time today, I've added a new feature to Fiddler only to
discover it was already there.
Mar 8, 9:44 Feb 26, 3:16 Feb 26, 2:01
Does using Facebook make you sad? The answer: yes, if you use it in certain ways...
Feb 24, 7:41 Feb 20, 4:19 Feb 10, 6:35 Jan 17, 6:59 2014 Sep 18, 2:27
“This is the chronicle of the most epic retaliation and how I pranked my roommate with targeted Facebook Ads to the point of complete paranoia and delusion.”
Funny anecdote but also a how-to on creating a Facebook ad campaign that targets a single person.
2014 Jul 8, 1:13
An interesting way to use the report-uri feature of CSP to detect if a user is logged into Google, Facebook etc.
2014 May 29, 4:03
Nieman Journalism Lab - Who’s behind that tweet? Here’s how 7 news orgs manage their Twitter and Facebook accounts
2014 May 22, 9:25
The DOM location interface
exposes the HTML document's URI parsed into its properties. However, it is
ancient and has problems that bug me but otherwise rarely show up in the real world. Complaining about mostly theoretical issues is why blogging exists, so here goes:
- The location object's search, hash, and protocol properties are all misnomers that lead to confusion about the correct terms:
- The 'search' property returns the URI's query property. The query property isn't limited to containing search terms.
- The 'hash' property returns the URI's fragment property. This one is just named after its delimiter. It should be called the fragment.
- The 'protocol' property returns the URI's scheme property. A URI's scheme isn't necessarily a protocol. The http URI scheme of course uses the HTTP protocol, but the https URI scheme is
the HTTP protocol over SSL/TLS - there is no HTTPS protocol. Similarly for something like mailto - there is no mailto wire protocol.
- The 'hash' and 'search' location properties both return null in the case that their corresponding URI property doesn't exist or if its the
empty string. A URI with no query property and a URI with an empty string query property that are otherwise the same, are not equal URIs and are allowed by HTTP to return different content.
Similarly for the fragment. Unless the specific URI scheme defines otherwise, an empty query or hash isn't the same as no query or
But like complaining about the number of minutes in an hour
none of this can ever change without huge compat issues on the web.
Accordingly I can only give my thanks to Anne van Kesteren and the awesome work on the URL standard
moving towards a more sane (but still working
practically within the constraints of compat) location object and URI parsing in the browser.
2013 Aug 7, 7:14
running along side my library. I shouldn't assume I'm the only sender and receiver on a caller provided MessagePort object. This means obviously I should use addEventListener("message" rather than
the onmessage property (see related What if two programs did this?
). But considering the actual messages traveling
over the message channel I have the issue of accidentally processing another libraries messages and having another library accidentally process my own message. I have a few options for playing nice
in this regard:
Require a caller provided unique MessagePort
This solves the problem but puts a lot of work on the caller who may not notice nor follow this requirement.
Uniquely mark my messages
To ensure I'm acting upon my own messages and not messages that happen to have similar properties as my own, I place a 'type' property on my postMessage data with a value of a URN unique to me
and my JS library. Usually because its easy I use a UUID URN. There's no way someone will coincidentally produce this same URN. With this I can
be sure I'm not processing someone else's messages. Of course there's no way to modify my postMessage data to prevent another library from accidentally processing my messages as their own. I
can only hope they take similar steps as this and see that my messages are not their own.
Use caller provided MessagePort only to upgrade to new unique MessagePort
I can also make my own unique MessagePort for which only my library will have the end points. This does still require the caller to provide an initial message channel over which I can
communicate my new unique MessagePort which means I still have the problems above. However it clearly reduces the surface area of the problem since I only need once message to communicate the
The best solution is likely all of the above.
Photo is Sharing
. Two squirrels sharing food hanging from a bird
feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.