2015 Oct 26, 9:03 2015 Aug 16, 1:09 2015 Apr 6, 8:51 2015 Mar 30, 12:19
For the second time today, I've added a new feature to Fiddler only to
discover it was already there.
2015 Mar 8, 9:44 2015 Feb 26, 3:16 2015 Feb 26, 2:01
Does using Facebook make you sad? The answer: yes, if you use it in certain ways...
http://dlvr.it/8lzYyS
2015 Feb 24, 7:41 2015 Feb 20, 4:19 2015 Feb 10, 6:35 2015 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.
humor security ad facebook 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.
technical security csp web 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
news twitter 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
hash.
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
When writing a JavaScript library that uses postMessage and the message event, I must be considerate of other JS code that will be
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
new MessagePort.
The best solution is likely all of the above.
Photo is
Sharing by
leezie5. Two squirrels sharing food hanging from a bird
feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.
DOM html javascript messagechannel postMessage programming technical 2013 Jun 24, 1:00
Having worked on Windows 8 I'm not in a neutral position to review aspects of it, however I'll say from a high level I love taking the following various positives from smart phone apps and app
stores and applying it to the desktop:
- Independent developers can easily publish apps.
- One trusted place for a user to find apps.
- User can trust apps are limited to a declared set of capabilities.
- One common and easy way for users to buy and try apps.
- Easy mechanism for independent developers to collect revenue.
Relieving the independent developer of software development overhead, in this case Windows taking care of distribution and sales infrastructure is wonderful for me with my third party
developer hat on. This combined with my new found fun of developing in JavaScript and the new Windows Runtime APIs means I've been implementing and finishing various ideas I've had - some for fun
and some for productivity on my Surface. Development notes to follow.
store technical windows windows-store