Is Apple stifling progress in Web standards? - <AUTHOR> http://timkadlec.com/2015/02/apples-web <comment><USER2> People are getting really bogged down in specific standards, but you don't need to talk about pointer events or flexbox or indexeddb or whatever, you can look at this at a macro level.

Here's the ES6 support table: [http://kangax.github.io/compat- table/es6/](http://kangax.github.io/compat-table/es6/)

Safari and IE were laggards, but future IE is going to be very solid while future Safari is still going to be terrible.

Here's the HTML5 support table: [https://html5test.com/results/desktop.html](https://html5test.com/results/desktop.html)

Safari and IE are laggards, and both continue to lag.

Safari used to be a Chrome/Firefox-level "modern" browser, while IE was the consistent laggard, with its slow release cycles and bad standards support. The most optimistic thing you can say about Safari now is that it's on IE's level; and realistically, it's even worse than IE -- certainly the IE team is a lot more transparent about future plans than the Safari team is.

<comment><USER3> > you don't need to talk about pointer events or flexbox or indexeddb or > whatever

But missing functionality is a deal breaker.

* WebRTC - web peer to peer connection: Chrome & Firefox yes, IE 11 incompatible by design (bought Skype for 11b, based on it), Safari no (would be Facetime competitor)

* WebSQL - web relational database: Chrome & Safari (also 95% of all smartphones) yes, Firefox & IE no (declared dead by Oracle and MS devs (biggest SQL vendors), in favour of complicated NoSQL API IndexedDB on W3C mailing list)

* IndexedDB - complicated NoSQL API: Chrome & IE 11 yes, Firefox yes but slow (implemented on top of SQLite, refused to implement WebSQL API, FirefoxOS is the only smartphone OS with no SQL API), Safari yes but buggy

* WebGL - OpenGL 3D accelerated graphics: Chrome & Firefox & Safari(since iOS8) yes, IE 11 barely (old 0.9 instead of 2.0 API, few extensions)

* CSSRegions - desktop publishing stylesheet features like Adobe InDesign/MS Word: Safari & Firefox yes, Chrome yes but removed again, IE 11 yes but older draft

* ContentEditable/HTML editor - a bug free implementation would make MS Word WebApp & Google Docs obsolete: IE 11 yes (invented, based on Frontpage, old HTML4), Firefox & Chrome yes but bugs, Safari barely useable (especially on iOS)

So basically every browser vendor is guilty to some extend. Apple protects its AppStore walled garden, FaceTime and "Pages" word processor, Microsoft its Skype/Lync, Office and DirectX/XBox eco-system, Google its GoogleDocs and Hangout, Mozilla community has some sponsored devs from companies with their own agenda (e.g. against WebSQL API, while using SQLite in Firefox to implement NoSQL API IndexedDB).

<comment><USER4> WebSQL is SQLLite and making that a standard is very hard without including SQLite's bugs and non-standard behavior.

Mozilla had really good reasons for shooting it down. Calling them out on it is meaningless without specifying why you think they've been wrong. You can say anything about IndexedDB, but at least it has a spec.

<comment><USER3> * The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature. SQLite is in public domain, so every company can use it (even Microsoft products already use it!)

* Also the argument of them that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).

Nowadays with the rise of NewSQL movement of people who burnt their fingers with NoSQL, one can only hope someone gives some love to Web SQL.

To sum up, NoSQL has it's place and SQL has one too.

We had this discussion already this week, hopefully W3C board members and Mozilla devs read this: [https://news.ycombinator.com/item?id=9082847](https://news.ycombinator.com/item?id=9082847)

<comment><USER5> > The argument that WebSQL was tailored to a specific SQLite version is > nonsense.

No, the idea that WebSQLDB _was not_ tailored to a specific SQLite version is nonsense. See Section 5 of the last version of the WebSQLDB spec [0]:

 _User agents must implement the SQL dialect supported by Sqlite 3.6.19._

> SQLite supports the official SQL92 standard

SQLite version 3.6.19 does not support all of, or only, the SQL92 standard. WebSQLDB did not mandate support for the SQL92 standard, or any other standard version of SQL, it specified the dialect supported by SQLite 3.6.19.

[0] [http://www.w3.org/TR/webdatabase/#databases](http://www.w3.org/TR/webdatabase/#databases)

<comment><USER3> Everyone knows the "Web SQL Database W3C recommendation" document should be re-evaluated, better formulated and improved. Richard Hipp, the creator of SQLite, stated that the dialect won't change (removing syntax) in SQLite v3 during the WebSQL W3C standardization in the mailing list.

About 95% of all mobile devices already support WebSQL (iOS & Android & WindowsPhone (via official Microsoft sponsored extension)). And all desktop Chrome, Safari, Opera support WebSQL too. The only missing browsers are IE 11 and Firefox/FirefoxOS.

<comment><USER5> > Everyone knows the "Web SQL Database W3C recommendation" document should be > re-evaluated, better formulated and improved.

Everyone does not _know_ this. Some people _believe_ this, other people _believe_ it should die in a fire. But whatever one things about the current state of the abandoned WebSQLDB spec, that is what WebSQLDB is, and you can't talk about -- honestly, at least -- it and pretend that it specifies SQL-92 as the required SQL dialect when, in fact, it specifies "the SQL dialect supported by SQLite 3.6.19".

You are essentially arguing that WebSQLDB should not have been abandoned based on the content of an imaginary WebSQLDB spec that never existed. If WebSQLDB had specified a (explicit, well-defined, use-case appropriate, single-user subset of) SQL-92 that would be different than what it actually specified, and the discussion would be different.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Honestly, not yet.

Apple might one day be fairly accused of holding up web standards, but so far they're still at least 80/20 implementing new proposals. It might be unpopular but it is actually the responsibility of browsers to somewhat govern what standards do or do not move forward.

For example when IE decided not to do WebGL due to security concerns and then successfully got the standard altered as a direct result [0]. That was what browsers are meant to do. That's what Apple does in some cases too, however their primary focus appears to be battery not security.

[0] (end of article) [http://www.techradar.com/us/news/software/applications/why-m...](http://www.techradar.com/us/news/software/applications/why- microsoft-decided-to-put-webgl-into-internet-explorer-1167110)

<comment><USER7> "it is actually the responsibility of browsers to somewhat govern what standards do or do not move forward"

An underappreciated point. Browser developers incl. Apple also have a responsibility to recognize that it's a mobile world. A compute cycle might look like it's getting cheaper, but a mobile CC is vastly more expensive than a desktop CC because of the cost of energy.

We might have three monitors plugged into 100A mains, but the typical end user has a 1900mAh battery and 7.5 seconds between Starbucks and the car door to send log in to the school's website to approve a field trip permission. It will be a while before mobile web standards can progress in the blue sky fashion we'd prefer.

</comment></comment><comment><USER8> What is difficult to argue against, and I'm surprised isn't mentioned in this article, is that Apple have completely eliminated market competition from happening around web standards on the iOS platform.

It is impossible to ship e.g. Chromium on iOS right now. We just collectively buy the arguments put forward by Apple to support that position without appreciating the ramifications of not allowing market forces to drive healthy, competitive development.

In that process we made Apple the gatekeeper of web standards development. They can ship whatever they want, when they want and there is no way to build or work around it (e.g. 'Download this alternative browser!').

All we can do is wait, hope or complain. Apple knows the power it wields. I figure Google understands that too hence their position wrt Pointer Events.

<comment><USER9> To be fair, it's also impossible to ship Firefox on ChromeOS.

<comment><USER10> Actually, it would take quite some work to port Firefox, but you could run a NaCl-compiled browser just fine.

<comment><USER11> Not realistically. The NaCl APIs to support dynamically-generated code have to revalidate every time, so they're too slow to support the heavily self- modifying nature of compiled JavaScript.

</comment></comment></comment></comment><comment><USER12> This article's title got me thinking that Apple, as a company, could actually be interested in suppressing the advancement of the web. Their apps are a shockingly effective alternative to the internet, and the store becomes more comprehensive by the year.

Even at this point, Apple's apps can replace all but some long-tail usages. So, despite the fact that suppressing the progress of the web will hurt the user experience of its own web browser users, that affects users of all operating systems fairly equally. But in the meantime, Apple can keep improving their OS, the app development process, &c; and they could steadily crowd out the web until iOS becomes the primary (or, if Apple gets it way, the solitary) source of networked information distribution/consumption. And after a while, all of what are currently thought of as web or web 2.0 companies would all be at the mercy of Apple. They would, for all intents and purposes, privatize the web.

<comment><USER13> This can't possibly happen because regardless of how big Apple is, it is tiny compared to the Internet and everyone who depends on the open Internet, from Amazon, Facebook, Google, Netflix to whitehouse.gov and data.nasa.gov

<comment><USER14> > it is tiny compared to the Internet

This depends entirely on how you measure scale. If you do it just by number of apps/sites, sure, the vast majority of web URLs don't have a matching iOS app.

However, if you scale each app by the total amount of time users are on it, you'll find that most of humanity is spending their time on a very heavily weighted small slice of the Internet.

From that breakdown, the fraction of human-hours that is covered by sites that also have native iOS apps is much larger.

If the next version of iOS didn't even have a browser, you would be astonished at how little that impacted most users. As long as they can still run Facebook, Instagram, Threes, etc., they'd be fine.

<comment><USER15> > _If the next version of iOS didn 't even have a browser, you would be > astonished at how little that impacted most users._

If time spent in an application is your criterion, true.

But that way you hugely underestimate the importance of, for instance, that daily (or even weekly) Google search the average user performs in their browser. It takes little time compared to your average social feed, but definitely impacts their lives. Just one quick example: a local business' phone number lookup.

</comment></comment></comment></comment><comment><USER16> Isn't the Web a competitor to the App Store? Especially when web apps start to catch up with native apps (and Santa tracker and the rest of Google's Polymer apps seem to suggest this is only a year or so away, and FirefoxOS has certainly made huge strides in this direction) and offline support with web workers is ubiquitous?

My experiences with Web Components, at least, do seem to suggest they're not very proactive and/or dedicated in the standards department, at least. They did put Shadow DOM into their spec at one point, but then removed it. The template tag is in at least, but that is a very, very simple tag (inert content until added to dom).

(I also found IE11 to play much nicer compared to Safari as compared to bug in my apps, not standard support, although that is really an indication of IE11's quality rather than Safari's laggardly standard support.)

</comment><comment><USER17> Are they really? Other browser vendors also refuse to implement things sometimes. IE has taken its sweet time on certain technologies, entirely deliberately. Google have tried to force standards with their marketshare.

Pointer Events is an odd case. It's a Microsoft-backed spec that only Microsoft supports. Apple won't implement it, Google won't, Mozilla's implementation is unfinished. Touch Events is also weird: only Google supports that.

<comment><USER5> > Pointer Events is an odd case. It's a Microsoft-backed spec that only > Microsoft supports. Apple won't implement it, Google won't, Mozilla's > implementation is unfinished.

Google, per the Chrome rep quoted in the article, prefers PE from a technical perspective, and only doesn't support it because it won't be universal because of Apple's resistance.

Unfinished means WIP, it doesn't mean that Mozilla doesn't support it the way Apple doesn't. Apple is the only barrier to adoption here.

<comment><USER17> > Google, per the Chrome rep quoted in the article, prefers PE from a > technical perspective, and only doesn't support it because it won't be > universal because of Apple's resistance.

See below: the Chrome team have other (performance) objections.

</comment></comment></comment><comment><USER18> Playing the devil's advocate but isn't Apple hindering web standards a strategy to keep people using the apps from the AppStore. On mobile, where the iOS market share is huge and it's impossible to use any other rendering engine it would be hugely beneficial to stifle progress as native apps and thus the lock-in they provide, will keep the upper hand.

<comment><USER19> If I look at what features are provided and what are not in HTML5 (especially on iOS), I also get the impression that some features are "conveniently" missing, with the consequence that certain things can only be written as native apps.

Notably: \- Network access. You can't write a BitTorrent or IMAP client in HTML. You could have with Java or Flash, but those have been axed (Apple was a major contributor to that). Of course there were good technical and security reasons for that, but it is a "convenient" side effect. \- Last time I checked at least, touch input and rendering (WebGL/Canvas) was inferior to native.

Now, I'm not convinced there is a concious decision to keep HTML apps limited, but I do believe it plays a role when it comes to Apple supporting certain features and disallowing others.

</comment></comment><comment><USER20> It's not just browsers. I work in storage, and their NFS client (a 25 year old protocol) is without question one of the worst we've seen. The number of hoops we have to jump through and spec violations we've implemented just to get the server to play nice with Macs is a little disgusting.

</comment><comment><USER21> I can't help but wish this was about WebRTC instead of pointer events. I can see so many applications using WebRTC but not so many using pointer events... Still I loath Safari, for locking so many features out of the mobile web.

<comment><USER22> They have conflicting interest with a better web: Apple Store.

</comment></comment><comment><USER23> IE is the only browser that STILL doesn't support EventSource, the simplest realtime technology one can use with browsers: [http://caniuse.com/#feat=eventsource](http://caniuse.com/#feat=eventsource)

How come nobody rants about that? (genuine question)

</comment><comment><USER24> I've noticed recently that Apple removed support for the High Resolution Time API (performance.now and friends) in iOS Safari 8.1. It was fully supported in iOS Safari 8.0. Not sure if I've ever seen a vendor _unimplement_ a (HTML5) feature before.

</comment><comment><USER25> "Apple has shown no interest"

Um, that's an assertion, without which the rest of the piece makes no sense. I would have expected a little evidence to back the assertion up, or are we all supposed to get our pitchforks out on Tim's say-so?

That being said, let's assume that Tim is actually right, and that Apple are being capricious and trying to hold back the Web, because they can. Apple are within their rights to decide to not implement a standards-proposed API. If that API is the greatest thing since sliced bread, web developers will start using it, and Apple will be forced to follow suit or be left behind. If that API is rejected by web developers, then why should Apple waste time implementing it?

Obviously if Apple throw their weight behind an API, that makes developer support much more likely, but I don't see why they should be obliged to expend resources championing an API they don't like, and which is not yet being used by developers. Let browser implementers that see the value in the API do the experimental work, and if it turns out to be popular, Apple can follow along later. I don't see that anybody is being harmed or "stifled" by such a course of action.

<comment><USER26> > Um, that's an assertion, without which the rest of the piece makes no sense. > I would have expected a little evidence to back the assertion up...

How, exactly, would you expect the OP to present evidence of Apple _not_ showing interest? What would that "evidence" look like?

I can't provide evidence that my golden retriever _doesn 't_ have an advanced understanding of quantum mechanics, but I don't think that would get him a job at CERN.

<comment><USER27> The parent makes a solid point, and you're employing this logical fallacy, which is why I am down voting you.:

[http://en.wikipedia.org/wiki/Appeal_to_ridicule](http://en.wikipedia.org/wiki/Appeal_to_ridicule)

<comment><USER28> Say what's wrong, but don't call it "that fallacy". Those "appeals to fallacies" are really what destroys useful Internet discussions.

</comment></comment></comment></comment><comment><USER29> The dream of the modern web is the concept of a single standard/platform that is used for all user facing software. This is a flawed idea and this article demonstrates one of the biggest reasons for that. By definition, features only become part of open web standards if all the main players agree to them. All the players have financial and political incentives to block various things. Corporations can block something that you want to use even though you have no relationship with that corporation. In a capitalist system you have very little leverage against a corporation that you have no financial relationship with. What are you going to do: stop buying the [Apple/Google/Microsoft] products that you already don't use? What's left is people writing angry impotent blog posts against companies that don't care about them in the least.

The list of proposed standards that have been blocked/delayed by one of more of the big browsers is huge. Blocking proposed standards isn't uncommon, if anything it's the norm. mathml, websql, pointer events, h264 video, nacl, flexbox, webgl, jpeg2000, webm, mp3, ogg vorbis, theora, webp etc etc.

Because of its origins as a way of displaying untrusted documents the web has no 'escape hatch'. It's a very tight sandbox. Flash and Java used to fulfil that role but they are on the way out. The web has a very basic trust model - all pages are untrusted and there is no other level of trust available. So if what you want to do hasn't been blessed by all the browser vendors then you are screwed. Does one of the main browser vendors compete with your product? It's quite likely that they do. Yet you want to give them full control over how your code can run all on all users machines?

If you don't like the idea of a corporation being able to veto a web standard then you need to seriously ask yourself if you actually like the idea of open web standards at all. Political vetoing is integral to the idea of open standards created through consensus and it isn't going to go away no matter how much people fantasise about it.

</comment><comment><USER30> How is this from Google...

 _" If we had Apple on board with PE, we'd still be on board too."_

... anything else but a lame excuse? It's deeply unfortunate that Apple won't budge on this because I think PE is a step in the right direction, but Google using Apple as a crutch is just as ridiculous.

<comment><USER31> The author is cherrypicking here. See what Google actually said:

[https://code.google.com/p/chromium/issues/detail?id=162757#c...](https://code.google.com/p/chromium/issues/detail?id=162757#c64)

They make a compelling technical and business argument against it; a reason the author acknowledges and dismisses because doesn't align with his thesis.

</comment></comment><comment><USER32> Mobile development is tricky, you have to support the most common devices and browsers that are out there. That means Safari on iOS, and Chrome and the bundled browser on android. Since a large percentage of users will not seek out an alternate browser we have to support the bundled browser. In my experience, we've been limited by Android as a platform than we have by iOS.

First iOS devices tend to upgrade their software more often, and are more likely to be running a recent version of the web browser.

Second support for features may exist on Android, but we have been unable to use those features because they did not perform in an acceptable manner for what we were attempting to accomplish. We've had a lot of issues with things like 3D/2D CSS transforms. In fact we've had to sniff out Android user agents and provide a substandard experience for certain features due to the abysmal performance.

Apple may be moving slower than the cutting edge on Android, but the cutting edge is so far removed from the reality of what we have to support and work with that it's basically irrelevant.

</comment><comment><USER33> Apple are too sick with lock-in mentality, so of course they'd sabotage any effort if that helps them retaining some grip on the market. The fact that they ban competing browsers on their mobile systems clearly demonstrates the point. And their negative attitude to free codecs is known as well. They are too stuck in their petty hate for interoperability.

</comment><comment><USER34> Apple is not going to support Web Components (Shadow DOM) as well.

FF is working on it and even MS has "under consideration" status.

Even if there were some issues with driving Shadow DOM standardization by Google I suspect that not supporting it by Apple is more defending iOS walled garden than real tech issues with specs.

</comment><comment><USER35> WebRTC is a huge one that comes to mind. With the App Store and Facetime in the same wheelhouse, there's no compelling reason to develop this area for Apple. It would be a HUGE win for the general web if they did, but there's zero reason for them to pursue it.

</comment><comment><USER36> Maybe once Apple brings the rumored iPad Pro with Stylus support, we will see them supporting it. I guess at the moment they just have no reason for it. Maybe they think they would help MS with the Surface, which would benefit from widespread PE support.

</comment><comment><USER37> The answer is a gritty, in-your-face "no".

 _We have a recurring situation where all vendors (save for Apple) show interest in standard, but because Apple does not express that same interest, the standard gets waylaid._

That is literally not true – Google, by some metrics the biggest vendor, has also shown no interest in PE.

Frankly, I don't see that much of a problem with Webkit and its' adherence to standards. Broadly speaking, it adopts new features and standards somewhat later than FF and Chrome, primarily I expect because of the slower release cycle, but it does seem to eventually come on-board.

<comment><USER38> > If we had Apple on board with PE, we'd still be on board too.

You entirely missed this quote in the article. How do you explain that?

<comment><USER39> It seems worth noticing that this is more political than technological argument. Google _choose_ not to implement Pointer Events and used Apple as a scapegoat.

I'm not happy with Apple's decision, but I'm even less happy with Google using Apple as some kind of feature implementation oracle.

<comment><USER40> This isn't Google using Apple as a feature implementation oracle, this is Google looking at pointer events using both their "web developer" and "browser developer" hats and reaching a disappointing conclusion.

As a web developer, Google would have to use Touch Events because that's all that Apple supports. Chrome already supports Touch Events. That covers the overwhelming majority of their touch-enabled users, with code they already have. Rewriting that to use a newer modern standard everywhere is one thing, but writing a second implementation with no path to sunsetting the first is much harder to justify.

Coming full circle, if Google's web developers aren't going to use Pointer Events for the forseeable future, it is hard to justify Google the browser developer putting them high on their priority list.

<comment><USER39> Thanks for the reply, honestly I haven't thought about Google as web developer. Another point that I unfortunately missed is that if Apple implemented Pointer Events in WebKit, then the changes could probably be ported very quickly to Blink (I guess both code bases are still largely similar).

</comment></comment></comment></comment></comment><comment><USER41> Just thinking out loud here:

What if we had a "meta app" which encapsulated individual browsers and created a specification allowing developers to define which browser type to use when opening their web page?

Not saying this can't be done today, but where the transition was seamless. I'm unaware of anything that allows us to do this today. I do recall a project that allowed one to do something similar (IE tabs in Chrome), but I think it wasn't the same in terms of seamless transition, and there was no way for the developer to control the transition.

</comment><comment><USER42> Safari still doesn't fully support Blob URLs ...

[https://github.com/eligrey/FileSaver.js/issues/12](https://github.com/eligrey/FileSaver.js/issues/12)

</comment><comment><USER43> The whole "developer relations as Bigfoot" trope doesn't ring true when it comes to WebKit, in my experience. I've had Apple developers reach out to me when I've mentioned WebKit bugs on Twitter. They're very happy to talk about efforts towards standards, and I actually find it to be one of the least cynical parts of Apple's business.

<comment><USER44> Thanks :)

</comment></comment><comment><USER45> I saw windows applications come and go. I saw ActiveX come and go. I saw Java applets come and go. I saw Flash come and go.

To me, iOS apps don't feel like a threat. Apple does not even have a monopoly like Microsoft had.

</comment><comment><USER46> It's interesting; when Google worked with Apple on WebKit, they were able to pull Apple forward. Now that Google has forked WebKit into Blink, Apple is on their own to keep up.

</comment><comment><USER47> Go ahead and do it anyway. May be just what Apple and Google need to be disrupted.

Not too long ago, Microsoft used to display similar arrogance. Look where they are now.

</comment><comment><USER48> Why do you need touch events at all? Can someone give me an example? I thought mousedown etc worked for touch as well.

<comment><USER49> Multitouch events perhaps?

</comment></comment><comment><USER50> Microsoft significantly stifled progress on the web for a decade. Now, after WebKit's progress wrestled away Microsoft's dominance and eventually forced Microsoft to spend years trying to catch up, Microsoft wants everyone to get out the pitchforks because Apple isn't supporting Microsoft's latest pet standard fast enough.

<comment><USER49> s/fast enough/at all/

<comment><USER50> You can't predict the future, the standards process is messy, and Apple hasn't actively taken a public position, so at this time your comment is disingenuous.

</comment></comment></comment><comment><USER51> Did non-wwbkit browsers really support WebKit css prefixes as this article claims?

</comment><comment><USER52> As always folks, Betteridge's law of headlines [1] is in play here.

The answer? No.

[1] [http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines](http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

</comment><comment><USER53> As far as I'm concerned, Apple still have a bit of time left to bask in the afterglow granted for mortally wounding Flash by keeping it off of iOS.

<comment><USER54> Do you think perhaps the same motivation could have been at play there - stifling web competition to their native app store?

<comment><USER53> Hard to say to what extent. Remember, at least in the early days before there even was a native SDK, they were very pro-webapp for iOS.</comment></comment></comment>


How Apple hides new functionality in iOS: isYoMamaWearsCombatBootsActive - <AUTHOR> https://github.com/JaviSoto/iOS7-Runtime-Headers/commit/6ccf9c4526992fec0dc414d48e4a3f7446e9822f#L10R61

<comment><USER2> Why resubmit this when it spent all day yesterday on the front page with literally the exact same title which you apparently copied _from that submission_ because it isn't on the Github page at all.</comment>


Show HN: OpenCirclez (Feedback welcome) - <AUTHOR> http://www.opencirclez.com/

<comment><USER2> Maybe explain what the site does on the first landing page — took me half-a- dozen click to make sense of it. A big "Find fun things to do near you" would be fine. I'm not sure why 'Circles' are a problem, for instance, or whether you improve from them.

Same problem with location — I didn't know where I was located, but it seemed to be Manhattan; when I tried to change that, I hit the wheel of death.

To face testing, chicken-and-egg, you might want to filter your service to an area with enough density to make sense (but I'm not sure about the most obvious places where you'll find thematic competition).

No cancel button on the "Post a message if anyone want to join you".

Biggest issue that I see so far: how do you improve things from Meetup?

</comment><comment><USER3> Neat idea... 2 things:

1) When I change location In more options while I already have search results for manhattan (Im assuming thats default) it fails to load/is stuck in a loop.

2) The twitter bar on the right side is too far down on the side and elongates your page. I dont believe this is intentional though because it doesnt look good. (screenshot: <http://pexelu.com/Untitled.png>)

</comment><comment><USER4> Using Safari 5.0.2, after clicking "Share my location" and then searching, it used Manhattan as my location, and I had to go and manually change it in the search options.

</comment><comment><USER5> I can't figure out how to change my location from Manhattan (I'm in Australia)

<comment><AUTHOR> Hi

1\. Did you enable the 'Share Location' option in your browser? It should have appeared on pageload.

2\. The 'More Options' should allow you to change the city/area.

Also, could you let me know which browser and OS you're using?

EDIT: corrected typo.

<comment><USER5> Thanks for replying! I didn't see anything on pageload. I'm on Chromium 8.0.552.224 (68599) Ubuntu 10.10.

(EDIT: I reloaded again, and I saw a bar come down asking if I can give this site my location. The bar was in light blue, and it was well camouflaged with the title of your page, and it also disappeared in a few seconds, so I never saw it the first time)

</comment></comment></comment><comment><USER6> what exactly are you trying to do different from other event based sites, say that Facebook and MySpace don't provide ?

<comment><USER7> Not OP, but this lets you find events outside of your social circle (to the best of my knowledge).

<comment><USER6> well just off the top of my head, I know upcoming (yahoo), going (aol), and myspace events all are events sites that allow search by location.</comment></comment></comment>


The Chroma Hash effect - <AUTHOR> http://dy-verse.blogspot.com/2009/08/chroma-hash-effect.html Password entry can be frustrating, especially with long or difficult passwords. On a webpage, secure fields obscure your input with •'s, so others can't read it. Unfortunately, neither can you—you can't tell if you got your password right until you click "Log In".<p>Chroma-Hash displays a series of colored bars at the end of field inputs so you can instantly see if your password is right. Chroma-Hash takes an MD5 hash of your input and uses that to compute the colors in the visualization. The MD5 hash is non-reversible, so no one could know what your password just from the colors. Your password will display the same sequence each time, so you can learn to expect "blue, red, pink", for instance; if you instead see "green, purple, yellow", you'll know you typed it wrong. The visualization also includes a user defined salt to prevent guessing passwords. The visualization is also salted with the domain name, trying out site to user authentication as an experiment. <comment><USER2> Am I the only person that doesn't want passwords echoed to the screen, to any extent, ever?

If I have to do a password confirmation I'd rather submit a form and have it tell me my passwords didn't match than to have immediate feedback with a visualization that isn't accessible.

<comment><USER3> No. These password visualizers are startlingly unsafe and largely useless responses to what is mostly a non-problem.

<comment><USER4> How are they startling unsafe?

If you watch someone type their password, you can get a visual cue that you retyped it correctly without submitting it to the server?

For me, this is like syntax highlighting. It is not necessary, but it's nice to have that colored visual cue so that your brain quickly knows that you got it right.

<comment><USER3> When you watch someone type their password into a PASSWORD input field, the only feedback you get is a dot on the screen.

When you watch someone type their password into one of these password- visualizing fields, you get a visualization of an hash of however many characters they've entered. If you have any ability to capture that hash, you can dictionary the password to a set of candidates.

If the person hesitates typing just long enough to get an interim visualization, you can probably narrow it down to a hand-guessable subset of passwords.

This isn't a reasonable security concession for the value of eliminating a server roundtrip to confirm a password, especially given the fact that less than 2% of your user base will ever use the visualization, but 100% of your user base is exposed to the liability.

<comment><USER5> I didn't look into how it works on the backend, but fetching the images means all the intermediate hashes are being sent out, right?

<comment><USER3> No, it's not fetching images for each of the hashes; it's a pure-JS MD5 which selects CSS background-colors for DOM elements.

</comment></comment></comment></comment></comment></comment><comment> brown9-2 The actual demo of the fork that the article author is discussing seems to be here: <http://axemclion.github.com/Chroma-Hash/>

(not sure why this is not mentioned in his article)

<comment><USER6> Is there a bug? I don't see the effect with Image. "a", "b", "logop" and "logo" all seemed to give the same Image

</comment></comment><comment><USER7> If you aren't groking what this is about the example given in article is awesome. <http://mattt.github.com/Chroma-Hash/>

Mattt-triple-t was our intern at the Yahoo! Developer Network last year and sent us this a couple of weeks ago. It's a really solid example implementation. You should play with it.

<comment><USER3> What makes this "really solid"?

If you mean, as an example of JS interactivity design, then yes. I agree. It's slick and it works as advertised.

If you mean, as an example of a safe extension to the most security-critical part of your application, then no. It's the opposite of solid. It's essentially publishing information that can be used to recover your password to the world.

I'm mystified as to how people could think this is a win.

<comment><USER7> I meant the User Experience rather than the code.

I'm not sure I agree with your security analysis though. The concept is to provide a visual cue for the password that's hard to manually reverse engineer.

<comment><USER3> See elsewhere in the comments for how to break the hash.

</comment></comment></comment></comment><comment><USER5> It aids shoulder-surfing, but not significantly.</comment>


Big catalog = infinite specialty shops - <AUTHOR> http://sivers.org/prism <comment><USER2> My perspective is that the problem with this IS seo.

The article talks about buying 1,000 domains. One big seo factor is domain authority/trust. With 1,000 new domains, you have to build up 1,000 separate properties with authority/trust, that's no small feat as anyone who's tried building up 100 domains at the same time will tell you. The common tactic here is going after the long tail, which is the only way I can see this working and still staying within a sane budget.

Beyond seo the article talks about marketing in general, and how great it will be to market laser targeted niche stores, all 1,000 of them.

So if I've spent a couple of hours finding a great Japanese music site that is PERFECT for listing my Japanese niche music store/domain, then I've just spent a couple of hours on 1 domain, only 999 more domains to start marketing! Yay!

That's horrific.

If you take the approach of a niche property within the same domain, all of your seo and marketing efforts for 1 niche store will transfer over to the rest of your properties, since, of course, you'll inner link them all from within the same domain. This also works great from a long tail perspective.

The marketing/seo execution of 1,000 separate domains is the challenge...

</comment><comment><USER3> I find it odd that there is so much enthusiasm for this idea in the comments on Sivers' blog because to me it seems a bit outdated.

And I agree w/ coffee and sabat that sure, anyone can purchase and setup a bunch of niche sites w/ individual domain names, but gaining trust (both from SEs and from consumers) is the key factor and isn't easy. Google and other search engines won't index these sites well off the bat based on the domains and tailored but not_that_meaningful content. Maybe in the past that was true but certainly the SE ranking logic is smarter than that now.

The other area of trust would need to come from consumers. I know personally, if I was into brazilian funk, stumbled onto a machine-generated site like Sivers describes and find an album that I'm interested in buying, I would just look up that album at Amazon (or CDBaby) because I trust them. And that cycles back to the first point in that since places like CDBaby and Amazon have the authority, the index of brazilian funk results in the SEs are going to include these sites. So setting up these niche sites might make sense for sites w/ authority already, but if they already have authority why bother?

<comment><USER4> Good points.

The enthusiasm is coming from musicians who like anything that might sell more of their music.

(Most of the readers of my blog are musicians.)

<comment><USER5> The top 3 Google results for "Brazilian Funk" are the Wikipedia article, an NPR story, and a compilation CD from CD Universe.

Seems like the least you could do to put up a quick primer on the genre (it will be slicker than wpedia), swap links with prominent bands (better rankings), and maybe put up some announcements and a forum. You could focus the information on making it easier to transition from curious to interested to fandom.

The big questions are how much the musicians would be able to support a site like that, and how willing they'd be to coordinate with each other.

</comment></comment></comment><comment><USER6> Categorizing is the wrong way to go, because different people categorize different ways. Assuming you have enough users, it seems to make more sense to go with some kind of bayesian recommendation system, i.e. "People who liked this product also liked..." That way you conform to the implicit categories people already hold, rather than force-mapping a blob of messy, overlapping categories into arbitrary, artificial divisions.

</comment><comment><USER7> We do exactly this at work. The great benefit which is not mentioned in the article is SEO - Google will love you for it.

<comment><USER8> I don't get it -- why?

</comment></comment><comment><USER9> The problem with this approach is that most people don't try new music because they're into, say, Brazilian chill. There's a need for a trusted reference -- a friend's suggestion, a review piques your interest, whatever. So just setting up a domain for people who like that genre isn't necessarily going to go far. Most of the music would probably be crap, and not worth my time -- hence that need for reference. I won't assume that a domain name means good music, but I do, for instance, take Anji Bee's (<http://www.anjibee.com/category/podcast/chillcast/>) suggestions because she has a proven track record of finding and playing excellent chill.</comment>


Bitcoin's $137k Jackpot - <AUTHOR> http://hackingdistributed.com/2016/04/29/bitcoins-137k-jackpot/ <comment> ryan-c > Remember that time when you tried to transfer your life savings from one > bank account to another for a small fee, but swapped the fee field with the > total transfer amount field, and ended up losing all your life savings? Of > course you don't. There are safeguards to catch and prevent these kinds of > errors. > > But this is a common occurrence in Bitcoin-land.

This mistake is difficult, if not impossible, to make with standard Bitcoin software. The fee field is usually pre-filled and somewhat tricky to change, and newer versions of bitcoin-core will block transactions like this as obviously wrong. It should also be noted the bitcoin fees are implicit in transactions - a transaction will have some amount of funds going in, and some amount going out, and anything left over is the fee. Usually these types of mistakes actually happen when someone manually crafts a transaction and forgets that they need to make a change output for themselves.

It is obviously still _possible_ to create transactions like this, but it currently requires using advanced interfaces and deliberately bypassing safety measures.

<comment><USER2> All types of costly mistakes happen in non-bitcoin land too: _Deutsche Bank accidentally transfers $6bn to hedge fund client_ ([http://www.theguardian.com/business/2015/oct/20/deutsche- ban...](http://www.theguardian.com/business/2015/oct/20/deutsche-bank- accidentally-transfers-6bn-to-a-single-customer))

...as long as humans are involved in transactions (by writing software if anything), human errors seem to be bound to happen.

<comment><USER3> The diference with Bitcoin-land is right there in the article: "and recovered one day later".

<comment><USER4> Miners will typically return obviously erroneous transactions to keep bitcoin users in good faith. It's happened numerous times, including this week.

<comment><USER5> But they don't have to and they aren't going to be held accountable if they don't.

</comment></comment></comment></comment></comment><comment><USER6> This reminds me of a similar error from 2005[1] where a trader mistook the "price" and "quantity" fields of the trading software. Instead of selling 1 share for 610,000 yen, 610,000 shares were sold for 1 yen.

The mistake cost around $225 million.

[1] [http://www.foxnews.com/story/2005/12/09/typing-error- causes-...](http://www.foxnews.com/story/2005/12/09/typing-error- causes-225m-loss-at-tokyo-stock-exchange.html)

<comment><USER7> Damn that's huge. You'd assume that the software checks the dollar amount and asks for a confirmation, or better yet permission from a higher up, if it exceeds some value.

<comment><USER8> it does ask for confirmation. As OP wrote - it was an error, NOT a mistake.

<comment><USER9> What a silly semantic argument to make.

It was an error _and_ a mistake.

In fact, error is a synonym for mistake: [https://www.google.com/search?q=mistake&oq=mistake&aqs=chrom...](https://www.google.com/search?q=mistake&oq=mistake&aqs=chrome..69i57j69i60l2&sourceid=chrome&ie=UTF-8)

</comment></comment></comment></comment><comment><USER10> Can someone else confirm to me that I'm not crazy and the central distinction of this article is totally bogus?

Reasoning: BitCoin isn't, to my knowledge, a scheme where some private identifier is stored inside each "coin" whose ownership is revealed with a zero-knowledge proof; it's simply one where you have public and private keys and use those private keys to sign transactions saying "Take X1 out of my public key K1 and put X2 in public key K2, with X1 - X2 going to the miner." That is, BitCoins themselves, as I understand them, are just points in a big distributed videogame: they do not represent actual packets of data which are individually 'minted' in mining and stored on your computer until you spend them.

If that's correct, then there's no distinction if you tumble-via-miners versus tumble-via-tumblers -- either way the coins are 'freshly minted'; there's simply no other sort of coin.

The only real thing that you seem to be able to do here is to tumble via _both_ the tumblers and the miners, which might create some binary tree of complexity if someone tries to "follow the money" \-- but that doesn't seem to be what the author is saying.

Is there legitimately something in each coin which makes it easier to follow a given bitcoin via tumbling than through miner-money-laundering, or are they really just the same thing performed through different channels, with a much slower rate of success for the MML tumbling?

<comment><USER11> In traditional tumbling, let's say you have ten people who all want to intermingle their funds. So you have ten inputs and ten outputs, and now there's some plausible deniability added because you don't know which particular one of the ten any given output corresponds to. But you do know it belongs to one of the ten, which is still significant information. And, most importantly, the vast majority of Bitcoiners do not use tumbling services.

With mining, however, you are intermingling with the activities of an entire mining pool. It is WAAAY harder to trace. Let's say I want to launder 1,000 BTC, and I have a sympathetic mining pool that will launder it for me. So I sign a 1,000 BTC transaction that gives it all away as a transaction fee, and they include it in their next mined block, eating the full bonus.

Then, separately, either before or after, and possibly far separated in time chronologically, they issue a series of transactions to a set of separate virgin receiving addresses I have created that total up to, say, 999 BTC (they keep 1 BTC as their mixing fee). As a key point, these transactions do NOT spend the output of the 1,000 BTC reward block, but rather, block generation rewards from previous blocks they've mined. They are indistinguishable from standard mining reward payouts, which any pool goes through a huge number of every day.

Those 999 BTC I now have spread across my addresses are way more anonymized than anything I could get with a traditional mixing pool.

<comment><USER12> This does not serve as a tumbling mechanism because the participants aren't peers. The coins went all one direction from source to many destinations. If those many destinations don't, in turn, pay the source back in some way you've just lost the money not laundered it.

<comment><USER11> I don't understand your objection. The mechanism I explained works to launder and obscure the auditable trail of Bitcoin. All I figure is that you're pointing out some there is some risk inherent in the mining pool simply walking away with the money. OK, sure. There's lots of trust involved in the Bitcoin ecosystem. Every time I buy something on the Internet with Bitcoin I'm trusting the retailer to send me what I ordered rather than walking away with my money. Every time I transfer BTC to an exchange in order to sell it I'm similarly trusting that they won't instead simply screw me over.

<comment><USER12> No, you're not describing something like A (typical tumbling) is risky, and B (paid back by miners) is better but with somewhat more risk.

A is I give you a million dollars, you give me the deed on your house. There is risk, there is trust involved, but we both are peers and bare equivalent risk.

B is I give a small portion of a million dollars to hundreds or thousands of people and ask that they pay a new account some large portion of it.

B is 100% risk. It is in fact guaranteed not to work in the aggregate. The problem is that none of the individual miners have a stake, as I said they are not peers. In fact it's worse then that, they would incur unnecessary risk of their own to payback the money rather than just keep it because of the danger of being implicated in a money laundering scheme.

With tumbling every participant shares risk equally since every participant puts funds into the system. In your scenario weather it's 10 miners or 10000 miners NONE of them are putting up any money at the same time, AND you must trust every single individual.

It simply doesn't work. It is not a lauding scheme of any kind.

<comment><USER11> I think you are misunderstanding how mining pools work. It's only the pool operator that needs to know the valuable fee transaction in order to launder Bitcoin via block rewards. The individual miners that are in the pool are just hashing over a hash of the merkle root of all of the transactions that the pool has selected, along with several other fields. More details here: [https://en.bitcoin.it/wiki/Block_hashing_algorithm](https://en.bitcoin.it/wiki/Block_hashing_algorithm)

The individual miners don't know, and have no control over, the transactions in the tree that they are hashing. The only person you need to trust is the person in charge of the pool. So this part is wrong:

> In fact it's worse then that, they would incur unnecessary risk of their own > to payback the money rather than just keep it because of the danger of being > implicated in a money laundering scheme.

The miners have no option to pay back or keep the money. They just submit valid hashes of what is essentially nonsense to them (other hashes), and get paid out for doing so. They have no control over the mining pool operator, no control over what they're hashing, and no way of defecting other than by withholding valid hashes, which is disincentivized because it costs them money.

To use an example, AntPool is currently sitting at ~30% of the network hash rate. That works out to about 50 blocks per day, more than enough to do lots of laundering if they were so inclined. If I had, say, 1,000 BTC I wanted to launder, all I would have to trust is the main technical person at AntPool. I'd give them fifty different transactions, each with a block fee of 20 BTC, and they could launder it over a day, then give me back most of that 1,000 BTC in transactions to unrelated addresses from unrelated sources at their leisure. I literally only have to trust a single person at AntPool to do this -- I don't understand where you think these thousands of other people come in. It's certainly not doomed to fail.

The only real risk I can see is that a lot of mining pools (but not all) include transaction fees in the block reward bonus to be distributed to miners, after the mining pool rake is taken anyway. You'd simply have to calculate the fees differently. Currently miners might be paid out for, say, 95% of the value of a total block transaction fee summing up to around ~0.25-0.5 BTC. You'd continue paying that out for normal transaction fees, but then also add in, say, 1% of non-P2P transaction fees (the money-laundering ones), with another 1% being taken by the pool and the other 98% ultimately going back to the source in untraceable transactions. This would actually create a lot of incentive to use the pool that is doing the money laundering, because they'd be paying out more per found block since they have a second income stream!

<comment><USER12> I do know how mining pools work. One could indeed do what you are saying.

What I am saying, however, is that one wouldn't.

It does not make any sense economically or in terms of risk of arrest.

Either you have pissed off miners ("Hey! What happen to all the money from that fee?"), or they are all collaborating which means "grand conspiracy".

Without the miners participation you have an easy to trace transaction chain that goes like this: bad guys, suspicions fee transaction, pool operator, new address. Trivial to trace.

In point of fact the fees in this case went to every participating miner. All conceivable cases that lead to any definition of tumbling requires that the actual funds are sent to all the miners. The event horizon argument which is the basis of the article is simply wrong. You seem to agree since you don't make a case for that.

Simply put: __the fee is just as traceable as any transaction __.

The best that could be done to balance the economic motivations and risk in your scenario is to generate pre-signed multi party transactions in advance of the initial fee payment for every minor, perhaps they only become valid once the fee is paid (one of the inputs to the transaction), and only at some point in the future (to obscure the direct relationship). In this case you'd have at least one new transaction from every participating miner creating a large number of outputs that become difficult to trace. Though it is still only one round of tumbling, and so compromising even a single participant would be enough to trace at least the value of that one participants laundering contribution directly to the source.

Even that solution requires a set of completely traceable colluding participants namely the entire set of miners who should have been paid the fees but aren't. And each of them would have to express there intent to collude via the pre-signed transaction _in advance_ of receiving any benefit.

So at absolute best you have a poor quality, high risk, error prone, tumbling / mining service.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> You can see a half-dozen of "mega-fees" on this graph[0]. The public nature of bitcoin transactions is very interesting.

[0] [https://blockchain.info/charts/transaction- fees?timespan=all...](https://blockchain.info/charts/transaction- fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=)

</comment><comment><USER14> Sort of unrelated but,

"According to my calculation, a single Bitcoin transaction uses roughly enough electricity to power 1.57 American households for a day."

[http://motherboard.vice.com/read/bitcoin-is- unsustainable](http://motherboard.vice.com/read/bitcoin-is-unsustainable)

I find this interesting thinking about Bitcoin as a currency. The first cryptographic currency example that I had read, from a cryptography book, didn't involve active power. I'm really surprised that Bitcoin has been able to gain this much popularity with its design. Does this explain how you might be able to lose a household-sized amount of money in a transaction on this network? I don't know, but I think that the blockchain idea might not be the ideal for digital currencies.

<comment><USER15> Each bitcoin block takes 25 BTC (11000 USD at time of writing) worth of electricity to mine, because that is the maximum that the sum total of miners can afford to spend and still break even. Currently it's only possible to fit somewhere around 2000 transactions in each block, because there is a hard- coded limit on the size of a block (1 MiB). So each transaction costs 11000/2000=5.5 USD, which is indeed the approximate value of 1.57 days worth of average per household energy consumption in the US. This is a big reason why it is important that the 1 MiB limit is lifted soon, the artificial restriction on transaction volume pushes the cost per transaction far too high. As a side note, when the block reward halves to 12.5 BTC in a few months, we will either see the value of bitcoin double or the hashrate (and energy consumption) halve - probably a little of both.

<comment><USER16> > So each transaction costs 11000/2000=5.5 USD

No, each transaction costs _at most_ $5.50 USD. You haven't established any lower bound in your calculations. A better approach would be to calculate the average number of hashes required to mine a block and the power efficiency of the latest generation ASIC miners.

Also, for what it's worth, $5 is much cheaper than a Western Union or SWIFT wire transfer so even this upper bound doesn't mean Bitcoin is uneconomical compared to modern banking.

<comment><USER14> Except environmentally, you need to look at the energy footprint of Western Union compared to the network of Bitcoin miners, not the price of electricity or amount of coins awarded.

<comment><USER17> Western Union's energy footprint is no doubt large. Is it larger than the Bitcoin networks? I don't know, but WU has extensive infrastructure in place all over the World, so it's not a simple case of Bitcoin being the only ecologically unsound option of the two.

</comment></comment></comment></comment></comment><comment><USER18> Obviously I am missing something on this. How do you direct the transaction fee to a specific miner? I thought it just went out there for anyone to process. If you can, why don't people just direct all their transaction fees at their own mining operation or a friend they trust?

<comment><USER19> Ordinarily transactions are broadcasted to the entire network for anyone to process. The miner who first finds a solution will get the fee for that transaction.

I think the idea here is that you instead privately give the transaction to only your favoured miner. He will then try to hash it, and if and when he finishes it, he will broadcast the transaction and the solution to the network at the same time.

Ordinarily there would be no advantage to give your transactions privately to just one miner; if you broadcast it publicly there will be many more miners working on it, so it will commit faster. So unless you are deliberately trying to overpay (like here) it would be a waste of money.

<comment><USER11> > I think the idea here is that you instead privately give the transaction to > only your favoured miner. He will then try to hash it, and if and when he > finishes it, he will broadcast the transaction and the solution to the > network at the same time.

That's not really a good description of how this will work. Each miner maintains a transaction pool of transactions that have been broadcasted across the network. Think of it as a priority queue. Transactions are of different sizes and fees, and the miner is trying to maximize their total fee up to the 1 MB block size limit. These transaction pools are largely the same across all miners, with of course some differences owing to time delays and network propagation issues.

So all that would happen in miner tumbling is that the miner maintains its transaction pool as normal, but then additionally adds in the special transaction that it does _not_ rebroadcast. The end result is you end up mining a block that has almost the same transactions in it as any other miner would, except with that one extra special transaction, and a low priority one being bumped.

<comment><USER20> I might be wrong, but I feel you gave a lower-level (more detailed) description of "the idea here is that you instead privately give the transaction to only your favoured miner".

<comment><USER11> The comment I replied to said several things that are wrong. I understand that it was attempting to give a higher-level overview, but it did so in a way that made things inaccurate. Let me break it down.

> Ordinarily transactions are broadcasted to the entire network for anyone to > process.

Process is sort of inaccurate here (it implies mining). Transactions are broadcast across the network in a P2P manner amongst all full Bitcoin nodes, so long as they validate anyway. Miners themselves are running full nodes, and find out about transactions because they come across the P2P network.

> The miner who first finds a solution will get the fee for that transaction.

Miners aren't trying to "find a solution" to transactions. That description isn't accurate. What miners are trying to do is figure out what nonce to insert into a block (which includes a _lot_ of transactions, along with metadata) such that the hash of the entire block is less than some very small target number. Understandably, this takes a large amount of tries, to the point where you have mining pools that distribute ranges of nonces across a large number of workers to pool their effort (i.e. distributed computing).

> I think the idea here is that you instead privately give the transaction to > only your favoured miner.

This part is correct.

> He will then try to hash it

Nope. Transactions are static. They always hash to the same value. What the miner is doing is trying to find a valid block. The miner isn't doing anything to specific transactions other than validating them, which any full node does.

> and if and when he finishes it, he will broadcast the transaction and the > solution to the network at the same time.

Nope. All valid transactions are broadcast by all full nodes as part of the normal P2P operation. What the comment was trying to talk about was broadcasting a valid block. There is no "solution" per se -- there's no guarantee that a nonce even exists that yields a hash below the target for any given set of transactions and block metadata. However, the transaction pool is constantly changing as more transactions are received, so constant churn in the transaction set as well as being able to run through the entire range of nonces each time guarantees that, with enough hashing, you will eventually find a combination that yields a hash that is sufficiently low enough. And then the block is broadcast.

Hope that clears things up.

<comment><USER21> Thank you for this clear explanation, but it leads me to another question (which, I realize, is probably based on a misunderstanding): first the miner finds a valid block that includes the high-reward transaction before the latter is broadcast, then the conspirators broadcast the transaction, followed closely by the valid block including it. But is it not possible that at about the same time, another miner finds a valid block containing one or more of the same transactions used in the special block (though obviously not the so-far private high-reward one) and broadcasts that? If so, then it is my understanding that there will be a race to see which block becomes accepted, and if the block containing the special transaction falls by the wayside, that transaction could be included in another valid block by any miner?

<comment><USER11> > first the miner finds a valid block that includes the high-reward > transaction before the latter is broadcast, then the conspirators broadcast > the transaction, followed closely by the valid block including it.

Negative on the second part. The only reason that the P2P network exists is to (a) get blocks (which all nodes do), and (b) share transactions so that they can be included in blocks. Once a transaction is in a block, that's it, it's on the chain. It isn't transmitted separately. Once a node gets a new block over the P2P network, it validates it, and removes all of the transactions included in it from its transaction pool.

> But is it not possible that at about the same time, another miner finds a > valid block containing one or more of the same transactions used in the > special block (though obviously not the so-far private high-reward one) and > broadcasts that

Yes, conflicts can and do happen (this is called a fork). It's actually quite likely, when you think about it; if blocks are found an average of once every ten minutes, and say it takes a few seconds for the P2P network to transfer the latest 1 MB block to all nodes, then you can have a situation were two mining pools find blocks simultaneously that conflict. The longest chain always wins out, otherwise it's whatever block you mined first. Absent an adversarial situation, the odds of having a fork that lasts even two blocks is so low that it should happen on average well less than once a month.

I want to point out an incorrect understanding in this one particular statement though:

> another miner finds a valid block containing one or more of the same > transactions

Blocks don't conflict because they have the same transactions, they conflict because each block has a parent, and multiple blocks with the same parent is a conflict. Even if two blocks had no duplicate transactions between them at all, if they topologically form anything other than a straight line on the blockchain (i.e. sharing a parent) then they conflict, and only one will win out.

> if the block containing the special transaction falls by the wayside, that > transaction could be included in another valid block by any miner?

Yes, it could be, but I do not believe that the Bitcoin software by default adds transactions to its transaction pool from orphaned blocks. That might be an optimization you could make if you wanted to take advantage of high-fee transactions that end up being orphaned that aren't broadcast to the network before inclusion into a block.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> _" exogeneous enforcement mechanisms."_ \-- Chortle, I really need one of those :-). I had not been aware of how the miners could launder bitcoin, that seems like a pretty big hole you can drive a lot of bitcoin through.

<comment><USER23> The award is recorded and they owe taxes on it. Which probably still leaves room for laundering. But it doesn't really obscure the flow of value all that much, unless they are all doing it and doing it for about the same price.

</comment></comment><comment><USER24> Is MML(miner money laundering) a viable concept? I thought that the transaction blocks were randomly distributed so it would be hard for a launderer to "target" a miner they trust. If someone has a bit more technical insight about whether this makes sense, or is viable I would be interested.

I would also contend that even if it was trivially easy to do, it would probably make more sense to just route transactions to various wallets and then to some exchanges and into other currencies, ect. I don't know if the miner thing makes sense

<comment><USER23> Presumably the high fee transaction could be withheld from the network until the block was mined.

I don't know if that is possible, but if it is it would ensure that a given miner was getting those fees.

<comment><USER25> It is indeed possible to withold a transaction while trying to mine it into a block

But this still doesn't provide 100% certainty that you will collect the transaction fee. You risk that other miners try to orphan the block once it is published (i.e. ignore it and build on the previous one instead) in order to put the transaction in their own block.

<comment><USER26> This is an excellent point. If a block with unusually high fees comes up, you'd be well served to try to re-mine it as long as P(win)^(n+1) * fee > P(win) * mining reward, where n equals the number of blocks after the few was published. If you have a 10% chance of earning a block, you could push on for quite a while.

</comment></comment></comment></comment><comment><USER27> Pretty bad article, but I couldn't find any better. Looks like a solid chunk of the money traces pretty cleanly back to tradeBTC.

I'd really like to find a good tool for exploring the graph of transactions. Most of the funding of the account that lost all the money have a similar pattern where a couple BTC is peeled off at each step and the majority goes forward in the chain till it all pools at 1QgTYzMYqStzZBQx8gguYaJQMjFRbagbh and gets spent. I wonder if thats just what TradeBTC transactions look like.

</comment><comment><USER28> Thanks for the post, I enjoyed the read (haven't read much about bitcoin laundering).

One small nitpick:

> My payment is going to be with newly mined coins, the Bitcoin equivalent of > fresh, crisp dollar bills straight from the Mint.

Coins are minted, bills are printed, so only coins come from the U.S. Mint. Paper bank notes and stamps come straight from the Bureau of Engraving and Printing (way less fun to say though!).

<comment><USER29> Also, you wouldn't want money coming straight from the Bureau because I'm sure the serial numbers would be so incredibly easy to track. For example, your bills have sequential serial numbers, or are clearly from the same batch. Better to have them straight from the Panama Papers.

<comment><USER28> > Better to have them straight from the Panama Papers.

Haha, great point!

</comment></comment></comment><comment><USER30> Wouldn't sending a transaction directly to the miner be more reliable then trying to hide it in the fee? If the goal is to hide your money in the high volume of BTC that a big name miner processes per day, why not just send it straight to their wallet?

From an investigators perspective there is no difference between the two scenarios.

1\. Miner A has received 500 BTC from Suspect B over the past year and may be laundering it.

2\. Miner A has processed 500 BTC in transaction fees from Suspect B over the past year and may be laundering it.

</comment><comment><USER31> Intersting explanation: [http://bitcoin.stackexchange.com/questions/35986/are- the-hug...](http://bitcoin.stackexchange.com/questions/35986/are-the-huge- transaction-fees-mostly-mistakes-or-some-other-market-indicator)

</comment><comment><USER32> Some people say it was an act of money laundering by the pool that mined it.

</comment><comment><USER33> Is Bitcoin suffering from [https://en.wikipedia.org/wiki/Pareto_principle](https://en.wikipedia.org/wiki/Pareto_principle)

</comment><comment><USER34> > Remember that time when you tried to transfer your life savings from one > bank account to another for a small fee, but swapped the fee field with the > total transfer amount field, and ended up losing all your life savings? Of > course you don't.

Of course I don't. I know banks can have terrible design, but I've never seen a 'fee' field on any transfer form. (maybe because I use credit unions?) That bank might as well tell everyone 'please let us eat even more of your money on top of the bogus fees we already charge you'. And don't real banks have regulations preventing mess ups like these?

</comment><comment><USER23> Wouldn't the MML leave lots of traces in the blockchain, a miner collecting unusually high fees over time?

<comment><USER35> I don't think it'd even be that hard. Unless new mined blocks are untraceable (as in, it's impossible to see which fees went to which new coins), then it provides no covering at all. It's the same as sending small amounts from one address to another.

<comment><USER23> There aren't coins as such. The address the fee goes to is given in the block.

<comment><USER35> Exactly. So this accomplishes absolutely nothing. Your identity from address A flows right through to the "fee address".

<comment><USER36> The person with dirty money is paid with the reward of _other_ blocks, not the one with his transaction.

</comment></comment></comment></comment></comment><comment><USER37> I'd definitely keep that amount if I won it through mining. It's really hard swapping `amount` to `fee`, in coding, so I bet that this was a human mistake on sending btc, not coding mistake...

<comment><USER38> I heard that the web interface on the exchange they used has fee and amount fields next to each other and with identical widgets (but different labels), so it's extremely easy to see how a human would make that mistake there.</comment></comment>


Ask HN: Which Framework? Why? - <AUTHOR>

My friend and I were chatting yesterday about how many people start projects on Ruby on Rails just because it's familiar. Also, Ruby on Rails is popular enough that it's easier to find engineers to work/collaborate on your project.<p>Although generic and I understand that each application has its own requirements and therefore technologies will vary, please help me answer the following questions:<p>- If you're building a new web app today, which frameworks, platforms, technologies, etc. would you use? why?<p>- Would you choose a familiar framework that allows you to develop faster (because you're comfortable with it) even though it's not necessarily 100% 'right' for the job?<p>- Would you push your own limit and think outside the box to find a better solution even though introducing new technology to the team could be costly (and possibly unpopular)? <comment><USER2> It doesn't matter, they're all fine. You aren't going to succeed or fail based on the framework choice. Just use whatever you know. The only non agnostic advice is for you to use to use Postgres. Don't use something like Mongo, it's trying to solve problems you don't even have.

</comment><comment><USER3> \- If you're building a new web app today, which frameworks, platforms, technologies, etc. would you use? why?

Backend:

NodeJS - It's nice to have javascript on both the frontend and backend. And NodeJS is FAST.

MongoDB + PostgresSQL - MongoDB for stuff that needs to be fast / fast to build. PostgresSQL for stuff that doesnt fit the document model.

Frontend:

AngularJS - It's either AngularJS or Ember.js, I prefer AngularJS. [http://stackoverflow.com/questions/14395887/what-are- benefit...](http://stackoverflow.com/questions/14395887/what-are-benefits-of- using-backbone-js-vs-ember-js-vs-angular-js)

Yeoman - Generate boilerplate code

Grunt - Compile LESS, Run tests, CSS minification

Bower - Javascript dependencies management

\- Would you choose a familiar framework that allows you to develop faster (because you're comfortable with it) even though it's not necessarily 100% 'right' for the job?

I'd rather choose a new framework, at least if it's a project that I will put serious effort into.

\- Would you push your own limit and think outside the box to find a better solution even though introducing new technology to the team could be costly (and possibly unpopular)?

Yes, I would definitely do it.

That's actually what I'm currently doing at a startup. We're refactoring the current frontend-javascript codebase which is 30 000 lines of code and it's completely unmaintainable, so we're rewriting it in AngularJS

<comment><AUTHOR> "It's either AngularJS or Ember.js" is Backone out of the question for you? how come?

<comment><USER3> First of all, I wouldn't call Backbone a framework. It's more like a library. It's only about 1500 lines of code with lot's of comments.

If you use Backbone, you'll have to reimplement/include other libraries to use the right design-patterns. And this takes time. AngularJS and Ember.js makes these decisions for you which saves alot of time.

<comment><AUTHOR> I wouldn't call it a framework either, was just curious about your opinion on it.

</comment></comment></comment></comment><comment><USER4> My web work these days are personal projects, volunteer work, or small freelance projects; so I am answering from that perspective.

For paid work, generally I stick to what I know -- a LAMP stack and whatever MVC/CMS framework fits the job.

My personal side projects are where I push borders and try to research new solutions. These side projects give me the breadth of knowledge to then be able to say, "hey, X technology will work really well" for work that is more important.

If you're asking for opinions on technologies and frameworks --

\- I did a survey of php frameworks a few years ago and arrived at Kohana. It met my criteria of (1) a lightweight MVC framework, (2) code that is clean/easy to work with (aka not too much "voodoo" going on), (3) useful library of utilities (pagination, etc.), and (4) very configurable URL routing/validation. Developed one small and one medium sized kohana web apps since then and it is a pleasure to work with.

\- When I was still doing web work under salary, we used an internal Zend-like framework which was forced upon all devs. The learning curve was high, it was very convoluted, and kept getting in my way of trying to develop my application. After I got used to the way it worked, it was more bearable, but I wouldn't go back there again. You'd have to modify dozens of files to make the simplest of changes.

\- Very rarely do I write my own libraries or frameworks. There's almost always someone else out there who has already solved at least part of your problem.

\- For simple CMS websites, I use wordpress. I started using wp back when textpattern was still a thing and haven't found any compelling CMS alternatives in php. It does seem to have gotten bloated in recent years. I tried Joomla once and decided I wouldn't go there again. It's very confusing, bloated, and the administration pages are unintuitive.

I'm open to suggestions for alternatives!

</comment><comment><USER5> Pick the right tools for the job. If you're doing an MVP web app, NodeJS, Rails, PHP, Django, ColdFusion (N other frameworks here) will all get it done.

Yes, I said ColdFusion. That thing that was hot the 90's.

This post reminds me that customers don't care what stack you use, as long as it solves their problem: [http://pud.com/post/9582597828/why-must-you-laugh- at-my-back...](http://pud.com/post/9582597828/why-must-you-laugh-at-my-back- end)

</comment><comment><USER6> It doesn't matter. Don't get caught up in the "what's best" HN hype. Don't use technologies that you're not familiar with. Go with what you know or switching costs will be high for your team. Go with a language that has a large supportive community so you can find answers to questions without jumping though hoops.

</comment><comment><AUTHOR> The main point behind this post was to get a sense of what folks are curious about and opinions on different web technologies. I've built production code using various frameworks and platforms and have my own opinions about them. I would love to hear yours. Why did you choose a specific direction on a recent project for example?</comment>


Kai: A plotting library for Common Lisp - <AUTHOR> http://github.com/komi1230/kai <comment><USER2> If I understand the code correctly, this is is lisp code that ultimately generates a json to be fed to the plotly javascript library [1].

That's sort of interesting. I sometimes work on specialized plotting tools for computational mathematics, and I see now that I expect plotting libraries to ultimately boil down to some c backend like libcairo or libpng, or to directly output a format like an svg or ps or pbm or something --- or alternately to be entirely js from start to end.

But upon further reflection, I don't see any reason to keep the worlds of online and offline plotting so completely disjoint.

[1]: [https://plotly.com/javascript/](https://plotly.com/javascript/)

<comment><USER3> Which is best CL library for plot generation ?

<comment><USER4> IDK about best but here's a selection of two: [https://github.com/CodyReichert/awesome- cl#plotting](https://github.com/CodyReichert/awesome-cl#plotting) (both based on Gnuplot)</comment></comment></comment>


Could artificial-womb technology be a tool for women's liberation? - <AUTHOR> https://thenextweb.com/syndication/2020/01/11/could-artificial-womb-technology-be-a-tool-for-womens-liberation/ <comment><AUTHOR> Years ago, my wife wrote a paper for college where she discussed abortion issues. In her summary, she mentioned that the artificial womb would change the meaning of abortion to not include the death of the fetus.</comment>


Don't Credit iMessage for the Texting "Decline" - <AUTHOR> http://www.pcmag.com/article2/0,2817,2412124,00.asp

<comment><USER2> Fail: Pcmag doesn't work in lanscape</comment>


How to Hack an Expensive Camera - pi-rat https://alexhude.github.io/2019/01/24/hacking-leica-m240.html <comment><AUTHOR> Excellent work. Almost forty years ago my first paid job on graduating was clean room reverse engineering a spec of a binary dump of somebody's code. You put me in awe of how well you did this.

As a former chdk user on canon and a Fuji x20 owner I hope somebody carries on your amazing work!

</comment><comment><USER2> Heh, I feel like I need to clarify something. Don't get me wrong, it was not 24/7\. Instead it was occasional work with huge several month long gaps :)

<comment><USER3> If you don't mind me asking, what do you do for a living? Your expertise in this is seriously impressive.

<comment><USER4> He has 15 years of experience as an embedded software dev/security researcher.

Looks like he's worked on a lot of really cool, low level, stuff.

<comment><USER2> Correct, and I have also spent 7 years making Cinema Cameras in Blackmagic Design. This helped a lot with Leica research.

<comment><USER5> You seem to be in Melbourne. Any relation to Felix Hude of Mr. Pumpy fame? I believe he used to teach at RMIT. [http://www.mrpumpy.net/](http://www.mrpumpy.net/)

</comment></comment></comment></comment></comment><comment><USER6> I am absolutely blown away by the dedication of this person. I can't imagine spending so long working on this.

Somewhat unrelated but I wonder if we will make the move to open hardware like we have done with software. Having access to schematics and firmware source does wonders for the reparability and upgradability of hardware.

</comment><comment><USER7> This is crazy, how on earth do you have the patience and persistence to work on something like this??? It took five - six years?

<comment><USER8> This comment is kinda snarky and borderline facetious but man, I can't help but agree. After 10 years hanging around this site if there's anything I've learned it's that I am nowhere fucking near "max geekiness". I couldn't stick with a project like this for 6 hours, let alone 6 years. And yet literally in the last week I've been (gently) ribbed for being nerdy enough to think reading books for pleasure is an acceptable leisure activity.

This is orders of magnitude of geekiness beyond anything I could possibly accomplish, and I mean that in the best possible way. Kudos to the author and thank god for the real nerds.

<comment><USER7> Dude it wasn't meant to be snarky at all. It was literally like wtf how is this even possible.

<comment><USER8> Sorry snarky was the wrong word. But I'm on the same boat!

</comment></comment></comment></comment><comment><USER9> Amazing work, clearly a labor of love. You never know how standardized of an approach embedded developers take depending on the constraints on developers and hardware, I'm glad he lucked out with a lot of the binary resources. I've bookmarked this, it's such a delightful resource.

</comment><comment><USER10> This is why we need open source cameras - so people don't need to spend 6 years reverse engineering and still not getting much out of it

<comment><USER6> This is part of the reason I can't get in to reverse engineering. It takes an incredible amount of time to get a little done when in the same time you probably could have written your own camera firmware. I do remember seeing an open source camera but it was a really high end one and very expensive.

<comment><USER11> > I do remember seeing an open source camera but it was a really high end one > and very expensive.

Might be AXIOM from the Apertus project: [https://www.apertus.org/axiom](https://www.apertus.org/axiom)

<comment><USER10> I really like what they are doing, but they have been working on it for 4 years and have no users. The camera costs 6000 euros and has no internal recording capability.

</comment></comment></comment></comment><comment><USER12> Would you consider doing this for sony cameras? Shit, open a kickstarter for it and you'll get funded in a few days if the word gets out.

There were some initial promising efforts to build the equivalent of Magic Lantern for sony alpha cameras, but it seems to have quietly died.

<comment><USER13> Oh yes. I've got an A7S2 and while I'm pretty satisfied with it in general (especially after jailbreaking it and killing that annoying 29 minute video limit), there are some things that I really miss, mostly related to networking.

Oh and while one can get a full service manual including block diagrams and wiring specs for it on the Internet, if someone knows how to access its bootloader (probably uboot, it runs Linux in any way, with an Android layer on top for the "apps") so that one can experiment without risking a $2000 brick, that would be really really nice ;)

</comment></comment><comment><USER14> "My wife and I always wanted a Leica camera and suddenly we realized that if we didn't buy it now, we will not be able to for a while."

Is this the mindset of "better buy the expensive thing before we can't afford it"? I've seen this expressed before and it's not sound reasoning. If you wouldn't be able to keep that money in a savings account because you know you'd later find other uses of the money to provide better value then you shouldn't be comfortable spending it on a depreciating asset immediately. The only way it makes sense is if you trust your future self's reasoning less than you trust your present self's.

<comment><USER15> I don't think that this is about not having the money at a later stage, but about spending that kind of money when you have other responsibilities (kids) being irresponsible.

<comment><USER16> Right, but it's not like money has an expiration date on it.

If it's going to be irresponsible _then_ , it's probably just as irresponsible _now_ , perhaps not as obviously. ("Better hurry up and make that mistake...")

</comment></comment></comment><comment><USER17> Unfortunately many other vendors encrypts firmware updates, like Panasonic do. I dream to hack Panasonic GH5 and G80 cameras firmware to tune some options.

There is a tool to binary patching Pansonic GH4 and GH2 firmware called Ptool. [https://www.personal-view.com/faqs/ptool/ptool-faq](https://www.personal- view.com/faqs/ptool/ptool-faq) It decrypts encrypted firmware, patch binary and then encrypt again. So you can update firmware via default process.

<comment><USER2> Honestly speaking, encryption never stopped me. Doesn't matter if it is something simple like M9 xor described in this story or fancy AES/HMAC from Canon or Sony. It just makes reversing more complicated and invasive. You have to open body, rip off flash or solder wires somewhere to sniff comms. Unlike Apple, camera vendors are not that paranoid and try to keep firmware unencrypted on flash to reduce the boot time. In other words this is the part when your wife can kill you for bricking the camera :)

</comment></comment><comment><USER18> This is insanely well-written.

<comment><USER19> I couldn't agree more! Even tho I understood the point, a lot of stuff was so foreign but the aricle just drives you and it needs some love not just on techinal part, but also on the writting!

</comment></comment><comment><USER20> Still curious as to what his motivation to reverse engineer this camera was? Extra features? Custom features?

Genuinely curious - seemed missing from the blog post.

<comment><USER2> Actually it is genuine curiosity about how stuff works and constant challenge if I can run my own code on it :D

<comment><USER20> Fair enough! I can relate with plenty of my own side-projects, thanks for sharing yours.

</comment></comment></comment><comment><USER21> Out of curiosity - from a legal perspective, is it fine to publish outcome of reverse engineering? I'm always sceptical before doing so myself.

</comment><comment><USER22> One thing that I learned about reverse engineering is that you can often get very far by just recognizing/guessing what formats and libraries were used by original authors. The article seems to at least partialy confirm this view.

On vocational school we could elect to do long term project instead of practical graduation exam. In my case this involved reverse engineering management protovol used by Merlin Legend PBX in order to port its DOS-based configuration utility (which was in fact emulator of MLX-20L operator phone) to something more modern (and multi-user). One of first things we did was running the binary through strings and ndisasm (I probably still have the hackedup tool to convert MZ EXE to pseudo-COM that could then be read by ndisasm, which was motivated by fact that for various reasons we could not use IDA). What we found out was that it used some weird Unix on DOS emulation layer from AT&T which included Unix-style ncurses and terminal emulation layer.

We tried both to analyze the binary and sniff the communication. At first we thought that disassembling the code would be faster as we had only limited access to the PBX itself and were somehow afraid of bricking the thing. Oneday I just gave up and spent few hours hacking up a way to actually look at the UART data (there were two issues with that: the PBX was somewhat picky about accepted RS232 levels and then slight logistical issue of having preferrably a laptop with two serial ports in early 00's). After we had this ugly mess of wires with four DE9 connectors and active RS232 buffer (powered from adjustable bench supply, needless to say that our advisor was not too thrilled that we decided to connect this thing between somewhat irreplacable PC and still considerably expensive PBX) we found out quite quickly that the actual configuration protocol consisted of XModem for backup/restore, straight ANSI terminal emulation for initial session establishment (and in theory for weird "use PBX as outgoing modem" feature), essentially binary block oriented terminal protocol (think contents of PC text mode framebuffer with one attribute byte for not every character, but block of 8, always sent as whole line) wrapped in weird HDLC subset for the actual interactive configuration and weird handshake reminiscent of OBDII serial protocol to switch between these modes (which probably took the majority of time to reverse engineer).

Interesting aside is that the above mentioned binary block protocol was also used for the UI of almost-ISDN phones that went with the PBX in question. We had access to ISDN protocol analyzer which worked perfectly for normal call flows, but reliably crashed (and not with any kind of meaningful error message, it just overwrote half of its display with random pixels, started ignoring its keypad or otherwise started behaving weirdly in somewhat random manner) any time we did anything more complex. Somehow I think that finding signal that reliably crashes firmware on test equipment which is explicitly designed to debug problems on such interface is achievement in itself :)

</comment><comment><USER23> Very neat, and impressive skills from the author! I wish I could do that myself... I started learning C so there is hope.

</comment><comment><USER24> I was expecting to find the debug mode key combo here in comments, but seems like 8h is not enough time.

</comment><comment><USER25> Amazing writeup, well done!

</comment><comment><USER26> Love this!

</comment><comment><USER27> A little of topic but the reference as a huge list at the bottom is forgivable for print media, but for interactive media, there is no reason for such inefficient method that requires one to click on the reference only to find yourself skimming through a list trying to remember what the number was and once you have found it, great, now you have to find your way back to where you were reading!

Wikipedia's recent reference links are a great of example of how to do reference right.

<comment><USER28> In Safari on iOS you can use the back button of the browser to jump back to where you were on the page before you clicked the link to the reference. You should see if the browser you are using does that as well.

<comment><USER29> This also works in pretty much every other browser I know of.

<comment><USER28> Absolutely :) Named anchors in a page have been around for a long time and I recall that going back from a page internal link would bring you to the place in the page that you were for as long as I can remember.

Would be interesting to know which browser was the first to keep track of scroll position for history entries.

Mosaic was before my time but I wouldn't be completely surprised to learn that even it would store scroll position.</comment></comment></comment></comment>


U.S. Lawmaker Proposes New Criteria for Choosing NSF Grants - <AUTHOR> http://news.sciencemag.org/scienceinsider/2013/04/us-lawmaker-proposes-new-criteri-1.html?ref=hp

<comment><USER2> The Republican War on Science goes on.</comment>


Challenge to Google Books Is Declined by Supreme Court - <AUTHOR> http://www.nytimes.com/2016/04/19/technology/google-books-case.html <comment><AUTHOR> I am extremely pleased by this outcome. Though Google is a for-profit company, the service they bring the world by making those books available for the world to view is outstanding.</comment>