"At Least 500 Million Yahoo Accounts Hacked in Late 2014" via Macrumors.

Yahoo today confirmed that "at least" 500 million Yahoo accounts were compromised in an attack in late 2014, leaking customer information like names, email addresses, telephone numbers, birthdates, hashed passwords, and both encrypted and unencrypted security questions and answers.

Does this surprise anyone at this point?

You know, I think if I had a huge cloud company with hundreds of millions of users, I'd consider having at least three sets of teams writing at least the fascade of the software -- the server-side controller methods -- so I could rotate from one to another every sprint or so to throw off would-be hackers. As soon as they made progress hacking one, it'd be replaced by Team 2. By the time we got back around to Team 1, they'd have iterated once or twice, and the hackers would have to, if not start over, pivot. Or maybe any user would have an X% chance of bringing up Team 1, Y% 2, Z% 3 each time they started a session.

I'd likely do the same for the users' data, splitting them into into several different databases, and maybe rotating users back and forth. Several different architectures using several different databases, all pitching to a consistent UI and user experience. If you interface well, it's no problem.

I realize there are obvious downsides. Maybe Team 2 has a horrible design, and it's easily cracked. That is, I'm in some sense three times as likely to get hacked as before, even if it's a much smaller set of users that's compromised.

But even more importantly would seem to be to sniff your network traffic like heck to see when 500 million sets of birthdays had left the network. Bizarre.

Ultimately, though, RMS (hrm, apparently not Stallman) is on point: If it's on a computer, in a network, given enough time, it'll eventually be free to anyone else on that network. Networked zeroes and ones want to be free.

Labels: encryption, free, rms, security, yahoo

From DaringFireball:

A new Rolex needs to look like a Rolex. A Leica needs to look like a Leica. A new Coca-Cola bottle needs to look like a Coca-Cola bottle.

I mean, I get the point that each is iconically designed, generally, but, um...

Put another way, Andy Warhol would've only included one of those in his pop-art series (mais quelle ironie, non?)

Labels: design, gruber

The only thing I can do is wish you a good luck as the situation totally unfolds on you.

They had me up until that poorly translated line.

(Okay, no, no they didn't. But it was a hilarious/horrible ending. If you're going to pay to robocall tons of people, you might as well translate your threat properly first.)

I posted to Medium, so now I get a daily "newsletter". It's not super, but this morning I checked out Why Silicon Valley is all wrong about Apple’s AirPods by Chris Messina.

He starts, give or take, with this:

Last week, Apple did it again, but for some reason, nearly everyone in Silicon Valley is confused about what just happened. I mean, I understand the confusion, but do people really think that the most significant announcement was the removal of the 3.5mm analog headphone jack? I mean, it was, but not for the reasons everyone’s [in a tizzy].

Apple doesn’t give [two shakes] about neckbeard hipsters who spent thousands of dollars on expensive audiophile gear that rely on 100-year-old technology to transmit audio signals. They’ll readily drop them faster than Trump drops facts to make an argument in a televised debate.

Apple is securing its future, and to do that, it must continue to shrink the physical distance between its products and its customers’ conceptions of self. The Apple ᴡᴀᴛᴄʜ came first, busting our sidekick supercomputer out of our pockets and onto our skin. Apple’s next move will put its products literally within earshot of our minds.

He then goes on to recap my Medium post on AirPods (not actually my post, I don't think, but exactly the same ideas, all the way to deriding businessmen who wore Jawbones), but wasted words, less direction, and better pictures.

Labels: apple, design, iphone, medium, W1 chip

Note to self: Never create images for documentation until you're done with your release. No, no no. ALL the way done with your release. I thought I could "get started" on my docs a little early, so I did. Not the worst idea ever, but I recently added a new toolbar button or two. I got lucky, I think, and can use my old images, like this one:

... since it's so tiny you can barely see what's in the toolbars. But if it'd shown one extra in the bottom or all of the top, I'd be remaking them now.

See that header button way over on the right? That's new.

And then for some strange reason I put the "Find" button on the bottom. Argh. That was close.

I won't say anything about that tab close "X" in the first image next to the "New 0" file tab. Except that if you'd been reading, you'd know I just added that. That may or may have been retroactively added to the original image. Ms. Paint, indeed.

Labels: fail, images, indie, markupdown, paint

Ouch. "When not to buy a Macintosh." Seriously, it's well past time, folks.

Labels: apple fail, business, mac

Oh, Pivots in UWP, you so crazy.

You may have heard that I'm writing a Markdown editor, MarkUpDown. It can have several files open at once, of course, and I'm using a UWP Pivot control to handle navigation.

As I got closer to releasing, it hit me that Ctrl-W, though common, isn't the most discoverable way to close those PivotItems. And now that I'm maintaining state between starts, so that whatever tabs you have open when you close the app are back on restart, closing each file "on purpose" is a lot more important than when they all closed on each restart.

That is, it looks like I need a UI for closeable tabs.

Not as easily said as done. You can customize the Header of the PivotItem pretty easily. In fact, a Header can be any object. You create a custom UserControl, throw in your favorite UI widgets, and you're golden.

In that UserControl, I put a TextArea and an icon of some sort, here a box with an X in it donated from Material Design Icons... Took a little experimenting to figure out exactly how to put text and an icon into the header presentably, though. I initially used a ViewBox, which seemed to scale the Path style image I'm using fairly well, no resizing necessary, but the ViewBox hated responding to clicks (or, in this case, "Taps" and "Presses"). Apparently you can manually set something called HandledEventsToo to make it catch events that are already caught by something with higher priority, but that strange Boolean reminds me of CSS' !important a little too much.

I replaced the ViewBox with a Button to be conventional, and then placed the Path style icon in there. I've got decent click event handling now, though it was difficult (well, at least "non-trivial") to get the icon to display centered. I went through the old process of using WPF Geometry Transformer to "Tansform" [sic] the Path into something smaller, and poof... -ish.

<PivotItem
    x:Class="CloseableTabs.CloseableTabHeader"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:CloseableTabs"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300"
    d:DesignWidth="400">

    <StackPanel Orientation="Horizontal">
        <TextBlock Margin="0,0,0,0" Name="txtHeader" FontSize="18">Test</TextBlock>
        <Button Background="White" Click="Button_Click">
            <Button.Content>
                <PathIcon Data="M13.3000001907349,2.09999990463257L3.5,2.09999990463257 2.51005053520203,2.51005053520203 2.09999990463257,3.5 2.09999990463257,13.3000001907349 2.51005053520203,14.2899494171143 3.5,14.6999998092651 13.3000001907349,14.6999998092651 14.2899494171143,14.2899494171143 14.6999998092651,13.3000001907349 14.6999998092651,3.5 14.2899494171143,2.51005053520203 13.3000001907349,2.09999990463257 M13.3000001907349,13.3000001907349L3.5,13.3000001907349 3.5,3.5 13.3000001907349,3.5 13.3000001907349,13.3000001907349 M11.8999996185303,5.87999963760376L9.3799991607666,8.39999961853027 11.8999996185303,10.9200000762939 10.9200000762939,11.8999996185303 8.39999961853027,9.3799991607666 5.87999963760376,11.8999996185303 4.90000009536743,10.9200000762939 7.42000007629395,8.39999961853027 4.90000009536743,5.87999963760376 5.87999963760376,4.90000009536743 8.39999961853027,7.42000007629395 10.9200000762939,4.90000009536743 11.8999996185303,5.87999963760376z" />
            </Button.Content>
        </Button>
    </StackPanel>
</PivotItem>

That's fun, isn't it?

That looks okay, but there are still two problems.

1. How do I set the Label (now placed in txtHeader) of my UserControl in XAML?
2. How I do I remove the PivotItem once its button is clicked.

Okay, three problems -- I really should change the icon to a greyed-out version when the PivotItem's not active. That looks awful. Mark that down for version two.

Accessing a property in custom XAML from C

I found the answer to the first pretty easily: You have to use a Dependency Property, of course!

Dependency property values are not stored as fields on the class, they are stored by the xaml framework, and are referenced using a key, which is retrieved when the property is registered with the Windows Runtime property system by calling the DependencyProperty.Register method.

But wait! There's more!

Defining a dependency property can be thought of as a set of concepts. These concepts are not necessarily procedural steps, because several concepts can be addressed in a single line of code in the implementation. This list gives just a quick overview. We'll explain each concept in more detail later in this topic, and we'll show you example code in several languages.

• Register the property name with the property system (call Register), specifying an owner type and the type of the property value.
• There's a required parameter for Register that expects property metadata. Specify null for this, or if you want property-changed behavior, or a metadata-based default value that can be restored by calling ClearValue, specify an instance of PropertyMetadata.
• Define a DependencyProperty identifier as a public static readonly property member on the owner type.
• Define a wrapper property, following the property accessor model that's used in the language you are implementing. The wrapper property name should match the name string that you used in Register. Implement the get and set accessors to connect the wrapper with the dependency property that it wraps, by calling GetValue and SetValue and passing your own property's identifier as a parameter.
• (Optional) Place attributes such as ContentPropertyAttribute on the wrapper.

Note If you are defining a custom attached property, you generally omit the wrapper. Instead, you write a different style of accessor that a XAML processor can use. See Custom attached properties.

... [Oh, but there's more... -mfn] ...

In some scenarios, you are defining dependency properties for objects that are used on more than one UI thread. This might be the case if you are defining a data object that is used by multiple apps, or a control that you use in more than one app. You can enable the exchange of the object between different UI threads by providing a CreateDefaultValueCallback implementation rather than a default value instance, which is tied to the thread that registered the property.

I feel like the Knights of the Round Table after they've considered whether to go to Camelot. Okay, nevermind. 'Tis a silly place. I won't make these new headers XAML-friendly for "version mvp". We're going to set the Label somewhere outside of XAML. Moving on to #2...

Removing a PivotItem on custom UI click

My first bright idea, which I've used before, is to take the sender, cast to the appropriate widget, find its Parent, and just slowly climb my way back up the UI hierarchy until I find what I need. That is, I'll drill up, like a jQuery closest, until I have the PivotItem, then the Pivot, that I need. Then I can remove the PivotItem from the Pivot's Items collection. Easy, right? The best part is that this normally doesn't change, and you can have the PivotItem remove itself without any serious hooking in with what's around it. (I could probably do this more impressively with reflection, and essentially hook an extension method up for UIElement that parallels the jQuery closest method I references earlier.)

But crimminy. Here's the drill-up code I ended up with, originally in the UserControl's Button's Click event. Remember that this is just exploratory code at this point.

System.Diagnostics.Debug.WriteLine("Click");
Button btn = (Button)sender;
System.Diagnostics.Debug.WriteLine(btn.Parent.GetType());

var spam = (StackPanel)(btn.Parent);

var header = (CloseableTabHeader)(spam.Parent);
var headerItem = (PivotHeaderItem)(header.Parent);

PivotHeaderPanel headerPanel = (PivotHeaderPanel)(headerItem.Parent);
Grid weirdPiGrid = (Grid)headerPanel.Parent;

ContentControl contentControl = (ContentControl)weirdPiGrid.Parent;
Grid anotherGrid = (Grid)contentControl.Parent;
PivotPanel pivotPanel = (PivotPanel)anotherGrid.Parent;
ScrollViewer scrollViewer = (ScrollViewer)pivotPanel.Parent;
Grid yaGrid = (Grid)scrollViewer.Parent;
Grid yaGrid2 = (Grid)yaGrid.Parent;

That's interesting, right? Not only is it much more convoluted a design than I would've expected, we also never get a PivotItem or a Pivot -- yaGrid2 is the "root element" of the page, I think. And the stuff we do get, like PivotPanel, come with warnings like this:

PivotPanel isn't typically used for general XAML UI composition.

/sigh This was easy, wasn't it? My UI traversal has me lost in the funhouse rather than in a cleanly executed UI widget hierarchy that follows its own mental model. Feels like I went out of the back door and I'm seeing the outside of the house isn't finished quite yet. Unfortunately, I get the impression that UWP is held together by chicken wire and duct tape a lot more than I'm used to seeing in a Microsoft UI toolkit.

There's probably some easy way to save what I'm trying to do from the fire, but forget it. For version mvp, I'm changing the CloseableHeader constructor from this...

public CloseableTabHeader(string headerText) : base()
{
    this.InitializeComponent();
    txtHeader.Text = headerText;
}

... to this...

public PivotItem itemParent = null;
public Pivot pivotParent = null;

public CloseableTabHeader(string headerText, PivotItem itemParent, Pivot pivotParent) : base()
{
    this.InitializeComponent();
    txtHeader.Text = headerText;
    this.itemParent = itemParent;
    this.pivotParent = pivotParent;
}

I think you see where I'm going. Yes, I feel a little dirty too. Now I can remove it easily in the Button's Click event:

private void Button_Click(object sender, RoutedEventArgs e)
{
    if (null != this.itemParent && null != this.pivotParent)
    {
        this.pivotParent.Items.Remove(this.itemParent);
    }
}

Hrm. Perhaps "parentPivot" is better than "pivotParent", and same with itemParent. In any event, you want to bubble up to the closest PivotItem and Pivot, and this makes that stupidly straightforward, though I do wonder how much Dispose-ing I should be doing.

I don't love that set-up, and I really dislike the way the buttons' bounds "highlight" simply when you mouse over the icon, like this:

... but overall, that's a workable solution that will make discovery for tab closure much more straightforward for non-keyboard addicts.

Labels: c#, coding, markupdown, uwp

There's only one word for Apple's strategy after watching yesterday's keynote: Untethered.

We've seen the start of this with Handoff, but we saw the carry-through yesterday with the watch, with its built-in GPS and the disconnected hiking app demo, and particularly in the AirPods -- but also sneakily in the Lightning port. More on that last one in a second.

The AirPods obviously constitute the cleanest vision of untethering. First, Apple's embraced and extended Bluetooth. Forget nasty pairing, but also say hello to pair once, access anywhere, as long as you’re in your personal niche of the Apple ecosystem.

And the AirPods do access. They’re not secondary to hearing sound, not limited like even your fanciest 3.5mm headphones. AirPods are more than just a set of controls to pause & skip, maybe answer and end a call (and what a hack it is getting just that much interaction to work over the 3.5mm).

No, the AirPods are much more than earphones. AirPods are an interface. They are your Star Trek communicators. You tap, you get Siri, you ask whatever [Apple] device is near you to do what you need. They're commoditizing device access.

The AirPod isn't just a decent earphone, though it is that. It isn't just a silly salesman's Bluetooth earpiece, though it is that too (you can use one at a time, if you want, and it's Jawbone city all over again). It's not just a way to listen to music on your computer, though it is that too.

The AirPod is Apple's interface to audio-augmented realty. This is the HoloEar to Microsoft's HoloLens.

What really clued me in was my own absolute embrace of Lightning-only input. Now look, I love the legacy audio port. When I called the Beats acquisition as the end of the 3.5mm in 2014, I said the following:

I've often thought of the 3.5mm headphone jack as one of the most impressive wins for open standards. Everything I've used to listen to music portably since I was listening to a tape of my Falco album during runs as a kid to my iPhone today has had one, which means that there's one type of hardware with the potential to last even longer than my monitors -- my headphones.

I still appreciate that, but it's simply not the way Apple's does design. The 3.5mm port is a distraction. Why would you have two audio-out ports? Lightning works fine for audio, and, much more importantly, the Lightning port allows [digital] data to go both ways. Note when the keynote talked about the way the JBL headphones could adjust the amount of noise cancellation based on communication with the phone over Lightning. That's not a great example, but it gets across Apple's point:

For Apple, headphones should no longer be passive. They should be full players in your digital life. They should be interfaces.

Whether that's Apple's Bluetooth++ or Lightning headphones or an Apple watch or macOS Handoff, what's important is that every device works both ways with every other, that every device is literally an I/O port. The new digital hub is completely distributed.

This increasingly distributed digital world is exactly what we should expect to get more of from Apple. You, untethered from any one specific device, with a wealth of ways to access any of them. And as that interface gets less and less substantial, less and less cumbersome, the interface will gradually fade until it converges with what we now conceptualize of as augmented reality. But when it actually hits, we’ll just call the augmentation our phone. Or watch. Or PC. Or nothing at all.

This freedom is what device & software integration — that is, having Apple provide all of your devices — buys us, and it’s impressive seeing how what, on their face, appear to be such minor advances (“Oh wows. Apple’s made Bluetooth headphones. Yays.”), really are small pieces moving on a much, much larger chess board.

How I put it at Michael Tsai's blog:

"The way Apple justified this was pretty disappointing—no real reason was given."

I think this is a softball. Apple likes [imo, etc] to design without concern for legacy when they can. If you were going to design the perfect iPhone today, would it have two audio-out ports? No. Even more, would you add a legacy port that was inferior -- at best equal -- at audio-out? Goodness no.

And we should've seen it coming. Buying Beats signaled the end of the 3.5mm. This seemingly small move has been a long time coming, and Apple has much bigger plans for what you can do with what you wear on your head than the control hacks we've seen with 3.5mm. The JBL example at the keynote, though weak, was telling. Think of headphones as interface, not as audio-out devices limited to music control and a mic for calls.

Though I totally agree with the lack of courage. If this is better, quit with the adapter as a pack-in. If everyone needs an adapter, you screwed up.

Labels: apple, augmented reality, business, interface, iphone, music, W1 chip

Watching the latest iPhone announcement made me think back to when my SE was released. The SE really is impressive, if you ask me. It's the cheapest iPhone by $150, but, at least until the 7 comes out, it also has the fastest processor and best camera available in an iPhone. That's a heck of a deal.

If the iPhone SE has one leg in the future, it's also got one firmly stuck in the past. The "FaceTime"/selfie camera is exactly the same as the iPhone 5S from two and a half years prior to the SE's released. So is the Touch ID. Hey, wait, so is the 4" display.

I didn't see a single Apple rag mention the reason this happened... it has to be so that Apple doesn't have to change a thing about that assembly line. You sluff the 5S out of production, but you keep the entire front face and likely most of the case exactly the same.

I never saw that confirmed, and finally dug back around on the iFixit SE teardown today. Sure enough...

A side-by-side comparison of displays out of the 5s (left) and SE (right) reveals... they're pretty much identical!
The similarities are more than skin deep. After a little testing, we found the 5s display is plug-and-play in the SE—fitment, connectors, and functionality are the same. It fires right up.

That's pretty danged smart. You take parts from a line that's underperforming, the 6S, and do the minimum amount of reengineering to use them in your previous phone, even keeping the previous assembly lines unchanged, and poof -- it's not a Frankenphone so much as an efficiently sourced entry device.

No, what the iPhone SE really is is an exceptional refactoring. Take the part that needs to change, find a good interface between it and legacy code that hasn't rusted, and only change that part. Plug it back in, and you're off and running, efficiently.

(Though the iPod touch having iPhone 6 innards should've warned us this was coming.) And now that the silly Wizard of Oz gaming demo is over, back to watching Phil...

In other news, what a heck of a lot of engineering to go from 1x to 2x in the iPhone 7's camera. You're still a heck of a long ways away from the power of an SLR.

Doubt me? Check this review (via DaringFireball):

However, I do not recommend the digital zoom beyond 2x. The quality of digital zoom degrades quickly and I find it unusable for photography (although it’s actually kind of nice as an animal spotting tool).

I have a Nikon D3100 with a nice 300mm lens, which is a 450mm equivalent in FX. That's give or take 7.7x optical zoom. The lens is, at its most compact, about six inches. You can't [easily? ever?] put that on a phone.

I get tired of the idiotic stories that say the iPhone is going to be as good as a DSLR. It's not. As Phil says, it won't be. It can be a great point and short with a short focal length, and it's neat that it can sorta do zoom now, as a clever hack.

Same with changing aperture. I guess there's some reason these things can't do a real iris, and you have to approximate depth of field in software. Still, ain't no DSLR. Apple knows it. It's time the Apple press learned it too.

Airpods for "just" $150?!?!!/1!

Labels: business, creative, iphone, refactoring, style

I think I was reading about CommonMark when I saw this mentioned.

Sad because true?

Honestly, I think CommonMark is probably a pretty good idea, all things considered. There are people that are going to get concerned with a "spec" that's, as CommonMark puts it, "ambiguous". You don't want strange edge cases that seem to conflict with reasonably hard and fast rules. I think the best complaint I've seen (and I can't dig the source back up in 10 mins of googling) is the "underline for headers" issue.

What do you do here?

This is a header. Or is it the last thing in a section before a horizontal line?
--------------------------------------------------------------------------------
I'm not sure. You tell me.

Apparently the original spec didn't address many edge cases like this, and you'd have to go to the code. I can't recall why that code wasn't good enough, other than folks occasionally disagreeing with it. And different users do have different needs, so I think that's a fair complaint.

And most importantly for coders, CommonMark gives you a test suite. We like to have explicit pass/fail conditions. You're only as good as your metrics and QA.

But yeah, any time somebody's providing something called Babelmark to help you see what's going on in different flavors of a markup format with unresolved edge cases, you've got a fragmentation problem.

Also worth mentioning: Is HTML a Humane Markup Language? from Atwood. Probably as good a visualization of why we might prefer Markdown to some other markup language that's got some traction right now as I've seen, though Atwood here (contra Atwood now, afaict) strangely decides that HTML is easier to eyeball than Markdown.

In other news, I had this choice definition of POJO open from Martin Fowler's site. I was pretty confident when I read "Anemic Domain Model" that he'd meant Plain Old Java Object, but the backstory is both hilarious and tragic.

POJO An acronym for: Plain Old Java Object.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely.

(ー_ー﹡)

Labels: coding, fowler, markdown, standards

Tried to update an app from the Windows App store.

So that was useful.

Labels: design, fail, windows

Finally. Thargoids. Am I right? (Haven't played in months, but I miss my Mk III.)

Labels: elite dangerous, gaming, Other Stuff

Ah, the power of MSPaint.exe. (Just realized there's a Ms. Paint pun in there somewhere. How many years have I been using this?)

I'm writing a Markdown editor. Its super-original name is MarkUpDown. (I'd originally thought I'd name it MarkUpMarkDown, but emailed John Gruber to see if that was kosher, since that really is too close to Markdown, and he objected to CommonMark's original name, "Standard Markdown". No response, though I could see how "Standard" seems presumptuous in a way I trust a bad pun like MarkUpDown is not.) I used Fiverr to get some icon artwork made, and it was pretty good. Just one problem that didn't occur to me until a few weeks later.

It's not MarkDownUp, it's MarkUpDown. /sigh

I have the psd, so I, in theory, could make my own lossless changes (I spent a little more than Fiverr's $5 to get that, but not much more), but when I tried, the export from the Gimp was super pixelated.

I really like the Gimp, I do. I used it to create the animated gifs on my MarkUpDown home page. But sometimes it takes a lot longer to figure out than it's worth to get something simple done.

^{(I'm suspicious I should pay $1500 for a good Gimp training course and watch that pay back insane dividends over the rest of my career, but I also don't want to get to be known as "the image hack guy" either.)}

Anyhow, I put together a request for my Fiverr guy, and included an image I'd hacked in Ms. Paint (and then Skitch) to show what I needed changed. Took me a little longer than I would've thought, but showed what needed to get done.

And then it hit me: That image on the right didn't look half bad. If I didn't hear back (and I didn't. He at least temporarily closed shop shortly after I left the request), I figured I had another option. If I took a little more care to line the arrows up where they were initially, I'd have something.

Not too shabby for a few hours' work (I actually did this and three other images, two of which were wider than tall and required some more serious editing), right?

Looking at it again, it looks like the down arrow needs to go a little further towards the edge to match the original, but I think I'm okay with it.

I'll blog about figuring out badges and icons and naming conventions for Visual Studio later, perhaps. Right now, I'm going to relax in my reasonable success with crazy mspaint.exe.

(You might wonder if the Fiverr design copied the "Markdown icon" too closely. I don't think that's a problem -- it was designed, and copylefted (actually put into the public domain), by Dustin Curtis.)

Labels: fiverr, gimp, images, indie, markupdown, paint