Issue 914451: Autofill does not respect autocomplete="off" - <AUTHOR> https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c73 <comment><USER2> A few years ago, I left a $1000 tip at the restaurant up the street because Chrome filled out the tip field with my zip code (which thankfully merely defaulted to max $1000 instead). The tip field was off-screen, and the ordering software didn't have a confirmation screen, just a "we just charged your card $X amount" screen, which made my eyes boggle.

EDIT: Looking at the original March 17th, 2015 bug, it would have been at exactly around that time...In fact, checking my emails, this happened on March 18th, 2015. I had ordered from them several times before this with no problems (they used "chownow.com" for their ordering backend).

<comment><USER3> This has a lot of really serious implications. I built a form for a charity that allowed users to buy a subscription but include an additional donation amount. Chrome was sometimes filling that field with the two-digit year. The charity got a lot of complaints and it ruined the trust relationship with the donors who didn't understand what was happening and thought it was intentional.

<comment><USER4> Chrome has other behaviour that I think violates a sort of trust relationship. One of which is that Youtube would ask you "do you want to install Chrome"? Almost as if your current browser is not "what you need to access Youtube". This is especially a problem for elderly people who often use the web but don't really understand how things fit together (the way 5 year olds actually do).

<comment><USER5> > _Almost as if your current browser is not "what you need to access Youtube"_

This is not just confusing. It's intentionally misleading and unethical.

And it doesn't just affect old people, or YouTube wouldn't have come up with it. Lots of young people grew up with computers and understand how to do what they want to do, but they never develop a systematic understanding of what they're using.

It gets worse, though. While we tech-folk know that all modern browsers are supposed to have near-parity, Google optimizes its sites for Chrome, leading to additional confusion for both knowledgeable and lay users.

</comment></comment></comment></comment><comment><USER6> As I had already commented on the issue, it completely breaks Germany's main train ticket selling website:

[https://i.imgur.com/BjYTgSn.png](https://i.imgur.com/BjYTgSn.png)

They have tagged the field as autocomplete=off but Chrome just doesn't care.

Also see this linked issue where they collected valid use cases for autocomplete=off. They just seem to ignore 452 use cases (I can't comment on the quality of them, I did not read any).

[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

<comment><USER7> Imo, valid use case for autocomplete=off is "the developer of webapp wants it".

Literally that and nothing more.

<comment><USER8> It's called "user agent", not "developer's agent". We'd be in a terrible situation if the browsers just followed developer's whims. Cf. popup blocking.

<comment><USER9> Dismissing the above use cases as "developer's whims" is the fundamental issue most people here are taking with these decisions.

I think we can all agree that browser behavior should not be left solely up to the developer and is not a black and white issue. Nobody here is arguing that. We are arguing for following a guideline that makes sense. This is why we have the w3c, an organization that attempts to weigh the needs of user, developers, and browser maintainers.

<comment><USER10> The issue is that the browser is supposed to be the meeting place for negotiating between developer and user preferences. Its job is to take into account preferences of both sides, and render the site accordingly. _Not_ to be a third party at the negotiating table. Breaking agreed standard in a way that can't be overridden by the user? Browsers should never do that.

<comment><USER11> In this case, it can be overridden by the user, just not the developer :)

<comment><USER12> Not really if the user is non-technical and doesn't even know they'd have to override it.

<comment><USER13> "this website has asked us to NOT autofill your saved info.

if you would like to autofill the form anyway click"

i made it a little terse, but there has to be a way to make it succinct and human readable.

<comment><USER12> I think this could still be confusing as enough users will likely have no idea who "us" is in that message - if they understand the difference between browser and website at all. It could also be confusing if the website already provided its own autocompletion via JS: The user would get a message that autocomplete is turned off while they see that it seems to be right there.

But I think in general, some kind of prompt or override would work. I absolutely agree that if a user _wants_ to use the browser autocomplete functionality, they should have an option to do so. I have no understanding for websites that just want to disable autocomplete without replacement.

However the concerns seemed to be about autocomplete being incorrect or conflicting with application-provided lists. I can see how that leads to frustration and confusion with users.

The Chrome team seems to trust its algorithm to an amount where they don't seem to find it necessary to deal with incorrect results - a view which doesn't match reality apparently.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> This has turned into a sad chicken-race between Google and developers, with lots of innovative workarounds on Stackoverflow.

Their tactic of overruling web developers doesn't work, it only make things more complicated for everyone, since many of the workarounds have other negative side-effects.

[https://stackoverflow.com/questions/12374442/chrome- ignores-...](https://stackoverflow.com/questions/12374442/chrome-ignores- autocomplete-off)

        ## Example 1

        For a reliable workaround, you can add this code to your layout page:

        <div style="display: none;">
         <input type="text" id="PreventChromeAutocomplete"
          name="PreventChromeAutocomplete" autocomplete="address-level4" />
        </div>

        Chrome respects autocomplete=off only when there is at least
        one other input element in the form with any other autocomplete value.

        ## Example 2

        Simply make your input readonly, and on focus, remove it. This is a very
        simple approach and browsers will not populate readonly inputs.
        Therefore, this method is accepted and will never be overwritten by
        future browser updates.

        <input type="text" onfocus="this.removeAttribute('readonly');" readonly />

        Style your input accordingly so that it does not look like a readonly input.

        ## Example 3

        Tell Chrome that this is a new password input and it won't provide
        old ones as autocomplete suggestions:
        <input type="password" name="password" autocomplete="new-password">

<comment><USER15> I think it mentioned chrome is even now ignoring 'display:none' and 'visibility:hidden' declarations so those workarounds no longer work either.

<comment><USER16> Great! :( Now I need to recheck to see if an autocomplete bug has reappeared where it thinks an email address field is a username field in a change password UI and autocompletes the email address with the username from the login page.

Sigh!

<comment><USER15> I feel your pain - sorry you have to deal with it. I'm working on a client data management app and I'm having issues _everywhere_ with this. It's been an open ticket on Jira for _months_!

</comment></comment></comment></comment><comment><USER17> Setting aside the merits/lack-thereof of this particular decision, Chromium ignoring established web standards like this is especially dangerous as we're trending towards a world where 1) Chromium itself powers the most popular browser in the world by an increasingly unhealthy margin, and 2) even competing browsers are increasingly becoming skins on top of Chromium.

We are becoming more and more reliant on the developers of Chromium to be steadfast stewards of the standardization process. Their massive influence means that any deviation from actual web standards on their part will inevitably create a new and conflicting de-facto standard that will create decades of lasting damage and irreversible tech debt for the entire web (eventually leading to a repeat of the IE6 dark ages).

Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.

<comment><USER18> Strictly speaking, Chrome is not ignoring a web standard, since the standard does not require this behavior (no "MUST" keyword).

<comment><USER15> Well they _are_ ignoring hundreds if not thousands of developers which is the main issue at this point.

<comment><USER19> By ignoring "hundreds if not thousands of developers" they are respecting the wishes of millions of end-users that don't want the site owner to decide what they can and can't autofill.

Obviously a simple boolean is the wrong design here. But can you suggest a better one?

<comment><USER20> I don't think "millions of end-users" want broken websites because now another developer (Google) gets to decide what's correct (instead of the web dev).

A better solution could be to just behave reasonably by default but allow the user to re-enable auto-fill with a single click.

</comment></comment></comment></comment></comment><comment><USER21> Because other people here are throwing in their frustrations, I will at least add that on the flip side I have been frustrated by sites that attempt to disable autofill for illegitimate reasons, like attempting to disallow password managers. I think I understand where this is coming from.

On the other hand, I, too, have been bit by this at least once, in the past. I think it was easier to just disable it at that time, but IIRC, the solution we landed on was to not use form controls at all but switch said text controls over to use content-editable elements. In our case it made sense, since it was not a form at all. My memory could be a bit hazy here, though.

(I do not work on Chrome or use Chrome at home, but as disclosure I do currently work at Google.)

<comment><USER22> I think we need a way to disable features only for those developers that abuse them. Like uMatrix but built-in and with rules being supplied automatically as ad blocking lists are.

You autocomplete=off a password field? That attribute won't have an effect on your site anymore.

You auto-play videos when the user doesn't expect it? What videos? The web doesn't support videos – as far as you are concerned.

Scroll hijacking? I hope you used progressive enhancement because you just lost your Javascript privileges.

<comment><USER16> Can we have a reliable cross-browser way to say "this is a change password field, so don't autocomplete it" and "this is an email address field not a username field, so don't autocomplete it with the login username"?

<comment><USER23> The autocomplete="new-password" (or autocomplete="off" or even autocomplete="some-random-nonsense") method is supposed to be doing that according to the spec. It is ignored by browser developers probably due to abuse. Additionally, all of those also trigger the prompt to save the password. For a password change form, that is the right thing to do, for many others it is not.

I'd very much like to see a way to disable that save prompt too, especially in user management screens. When I create a new user, I want neither my own password to be autofilled, nor do I want to overwrite my saved password with theirs.

</comment></comment></comment></comment><comment><USER24> I ran into this last week (with LastPass, not Chrome - this seems to be a common practice):

I have a form where users enter information about their suppliers (I make restaurant management software). This includes a field for the contact email address, which LastPass was autofilling the email address the user used to log in. This happened silently, quickly enough that users wouldn't notice it on page transition, and would _overwrite the initial value_. Even with autocomplete=off.

This was a DATA LOSS bug - users would load the page, make a few changes, save, and not notice that they'd lost the email address they'd stored for the supplier. Fortunately LP has a method to force disabling of autofill (data- lpignore=on), but this could have all been avoided if they'd _followed the spec I was relying on_. I still don't know if some other password manager, maybe built in to Firefox or something, will make the same mistake, haven't had time to check yet.

<comment><USER25> The LastPass on is especially horrific because it fills in fields that are already filled, _and it fires a change event_. So if you're auto-saving on a change event, that data is lost as soon as the page is loaded.

<comment><USER26> The entire design of password managers that hijacking the DOM is flawed.

<comment><USER27> A recent LastPass version does not fail gracefully and a lot of my webapps started getting weird console errors from users with LastPass extensions that were trying to unsuccessfully inject into our forms. :/

</comment></comment></comment></comment><comment><USER28> As a user, Chrome's autocomplete went down the drain for me once they started to fill all fields at once. I tried to autocomplete one field and often chrome filled the other fields with unfitting data. This happened so often that I started to manually complete fields even if autocomplete was available. I still miss the good old times[tm] of single-field autocomplete...

(And for the record: As a developer, I have been bitten by Chrome ignoring autocomplete="off" as well.)

<comment><USER29> Yup, I like how FF does it. I basically just do a repeated sequence of:

TAB -> Arrow Down (select one of the previously filled values I've used) -> Enter

When filling a form. Given that sometimes we order things on made up names, it's quite useful no to have that autofilled when we're not wanting to.

</comment></comment><comment><USER30> I guess this will lead to a horrible coding style where instead of having this in the form:

        <input name="email">

We will see stuff like this:

        <input name="16fkr9547kancot944128sddfksdf934998aafccugt75">

Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript.

Just like they already randomise asset filenames to avoid caching.

<comment><USER31> Your comment about randomizing filenames got me thinking. It would be great if we could add a cache key to the HTML element, that way we could cache everything forever with the same filenames and still invalidate things by just making the key being the SHA of the deploy. Too bad that's not a thing.

<comment><USER32> That is a thing already!

[https://developer.mozilla.org/en- US/docs/Web/Security/Subres...](https://developer.mozilla.org/en- US/docs/Web/Security/Subresource_Integrity)

<comment><USER31> Subresource integrity is for ensuring that you got the right file (it fails if you didn't), it doesn't do anything with the cache, unfortunately.

<comment><USER32> Really?

Seems like it would be crazy _not_ to use it for caching.

<comment><USER33> The problems are 1) side channels. Caching those would mean that a malicious script could use timing to find out if the user accessed specific other websites. Also it enables a channel for cross-domain communication. 2) malicious user tracking would not work as well anymore, which would be good but Google probably will not support that. Currently they get all those nice http log entries from sites that only include fonts etc.

<comment><USER34> For sensitive files with known names, you should be able to set that the cache is only valid for requests from the same host website (as the server might decide to send another response when the host is different). That would fix the sidechannel.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

<comment><USER36> This is why form elements should never be hidden _after_ loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app.

Frameworks like React and Vue don't even render the HTML into the DOM until conditions are met so the situation is improving.

Another positive step away from jQuery hackery!

<comment><USER37> If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?

<comment><USER38> Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form.

Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.

</comment></comment></comment></comment><comment><USER9> Curious as to the global business impact this has had. I personally have spent at least a dozen hours debugging forms and trying to disable autocomplete/autofill on my kiosk-based applications. How many development hours collectively have been wasted on this unilateral decision.

I have not been this frustrated since the days of writing css for ie6, and at least back then the devs response was more "sorry its our rendering engine" and not battre just saying GFY seemingly out of disdain.

I try to be as free-market as possible but I sure wish that the w3c had some teeth when it came to things like this.

<comment><USER39> You're not the only one. I remember spending a good two days on it this year for a page where the user puts in their credentials for external integrations.

</comment></comment><comment><USER40> Btw, at [http://google.com](http://google.com), this is what they have for the search field:

<input class="..." maxlength="2048" name="q" type="text" jsaction="..." aria- autocomplete="both" aria-haspopup="false" autocapitalize="off" autocomplete="off" autocorrect="off" role="combobox" spellcheck="false" title="Search" value="" aria-label="Search" data-ved="...">

<comment><USER6> Does anybody have a clue why it does not show up there? The Google team must have done something in order to circumvent what the Chrome team did. Horrible.

</comment></comment><comment><USER41> _Overall, I still believe that neither of the extreme strategies ( "always honor autocomplete=off"_

Is it "extreme" now for a computer to do what the user wants and not what a random Google employee wants? How does this differ from malware?

<comment><USER42> It's also in the spec.

People might not like the spec or it might be incomplete, but adhering to it is a very important part of improving it until it's a good one.

Now I'm no webdev, but I could very well imagine that the spec is _already_ a good one. So the situation might be even worse.

<comment><USER43> The spec only says "should", not "must". Apparently these wingnuts thought that means the spec can be ignored.

<comment><USER44> > _The spec only says "should", not "must". Apparently these wingnuts thought > that means the spec can be ignored._

Not arguing in favor of this particular choice, but yes. That is exactly what "should" means in most cases.

For instance, in RFC 2119: [https://tools.ietf.org/html/rfc2119](https://tools.ietf.org/html/rfc2119)

> SHOULD _This word, or the adjective "_RECOMMENDED _" , mean that there may > exist valid reasons in particular circumstances to ignore a particular item, > but the full implications must be understood and carefully weighed before > choosing a different course._

<comment><USER24> Blanket disregard of a SHOULD directive as a UX decision neither falls under "in particular circumstances" nor indicates that they've "understood and carefully weighed" the consequences.

</comment></comment></comment></comment></comment><comment><USER45> The way I see it, autofill off should mean off and if I click the icon in the address bar to bring up, well, let's call it "quick access to per-site settings" then maybe I could override it for a specific page load or site, like you can Flash, etc.? This per-site configuration is starting to become "normal" given iOS 13 does the same in Safari for permissions, content blocking, automatic reader mode, etc. It would make sense that the default is "follow the HTML5 spec" but you could put a notice in the address bar if you really felt otherwise...?

Safari does a much better job by only filling visible form fields, I think (though it too has a tendency to put my address both in Line 1 and Line 3, which is annoying...).

</comment><comment><USER46> Explanation from the 'rogue Chromium dev' is linked to in comment 19 of this bug: [https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c19)

[https://bugs.chromium.org/p/chromium/issues/detail?id=468153...](https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164)

<comment><USER47> ...which really makes it worse:

1\. Our programming language has an attribute called "autocomplete" with two possible values: "on" and "off"

2\. We will now (without consultation or announcement) simply start ignoring one of those values when you specify it. (and certainly not document the new behaviour!)

3\. Here, I made you a convoluted (and undocumented!) workaround for getting the original behaviour of the attribute back.

I'm not sure which horse these FAANG kids who excel at programming challenges rode in on, but this attitude is RIFE in their product SDK's and API's.

Dijkstra must be spinning in his grave.

<comment><USER48> All that based on an increase in page submissions. Is that the goal of auto- complete?

The research behind the number (25%) is highly dubious, because the video cited as the source doesn't tell how it was done. At all. Ironically, it follows a section on how MDN is documenting the standards, and how that "contribute(s) a lot".

</comment></comment></comment><comment><USER49> Firefox used to ignore autocomplete="off" until relatively recently. I'm sick of sites thinking they know better than me -- like those who don't let me paste in the password field. While I understand the good use cases for this attribute, given the binary choice I would rather have it ignored.

<comment><USER50> That is absolutely stuff that the user needs to be able to override. In fact, anything related to cutting and pasting is not something I think the browser should mess with.

Also: websites that generate a custom login name or password for me so I won't remember it, and then refuse to allow autofill or pasting. Fortunately dev tools are standard on the desktop these days.

(I would really, really like access to dev tools on mobile, though. It's simply necessary to get around some broken websites.)

</comment></comment><comment><USER51> The weird thing is that there's other teams within Google who offer autocomplete libraries that simply don't work because Chrome overlays it's own autocomplete on top.

The maps team seems to have given up on trying to resolve that.

Chrome team have made a judgement that autocomplete is required and no-one - not even other teams within Google are allowed to override that functionality.

It's weird.

<comment><USER43> Google really is the new Microsoft

<comment><USER52> In spirit maybe. But in practice it seems worse.

</comment></comment></comment><comment><USER12> Relevant reply from a Googler seems to be this: [https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66)

by email@example.com

... which doesn't read at all to me like a "rogue dev" and more like a shared sentiment inside the Chrome team that autocomplete=off should be ignored.

At least, if there is a direct spec violation that breaks all kinds of applications and the answer your hear is "oh well, we're working on giving the user more options and improving our algorithm", that's not exactly encouraging.

<comment><AUTHOR> It _is_ a direct spec violation, and it _is_ breaking all kinds of applications.

Look, I get that this capability is _super_ useful on shopping sites, and I rely on it practically every day.

But, I also build enterprise applications, where Chrome simply _would not ever_ understand or know what would be valid choice.

I do, though; I built it. Invoice Numbers / Pre-Validated Travel Dates & Locations / Pre-Validated Locations / Pre-Validated IssueID that are so esoteric, we have built custom autocomplete that provide additional relevant information / Pre-Validated Users where the number of valid "John Smith"s number in the 10s, and additional meta data _must_ be provided to differentiate.

Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. The spec says this is autocomplete=off. Just do that.

</comment></comment><comment><USER53> It's odd that the linked bug report references and complains about W3C specs when browser/HTML specs have been coming from WHATWG for well over ten years now. W3C has ceased publishing HTML with W3C HTML 5.2 in 2017, and has announced an intent to merely publish WHATWG snapshots going forward; so far, I'm not aware of any actual work under this model by W3C.

But OTOH that Chromium interprets form field names heuristically to enable auto-autocomplete is worrying, and reflects poorly on the whole "standardization" process by WHATWG.

<comment><USER54> Indeed. Chrome and Firefox both autocomplete my user name and password into GitHub's new user registration form, even though I already have an account. It's flaky and just asking to be abused.

</comment></comment><comment><USER55> It's really frustrating to have to work around this with hit or miss hidden inputs and such.

So many cases too where auto complete misfires an obliterated forms that had helpful placeholder text.

Just having a user change passwords and auto complete will often put an old saved password in the first field but not the second confirmation password field.

<comment><USER56> > Just having a user change passwords and auto complete will often put an old > saved password in the first field but not the second confirmation password > field.

You can hint to the browser which password you want to autofill with autocomplete="current-password" and autocomplete="new-password"

<comment><USER55> I've found that auto complete still sometimes guesses at what to do in that case depending on what the other fields are. At least it did last time I fought with it.

</comment></comment></comment><comment><USER57> I do not get from where it comes that it is a rogue developer. I have worked in many companies where developers make mistakes. And, it is always the ways of working, giving more priority to features than quality, and similar cultural attributes of the company at fault.

The only time I saw this being a rogue developer was a commit and run done by a guy on his last day.

It is easy to blame one person when actually is a systemic failure that needs to be addressed at the company level.

<comment><USER58> I agree - and in fact, I think accusing this guy of being rogue is an unnecessary direct attack on him/her.

They are just doing their job, and in this case, acting in what they believe is best way for users. Here on HN, it seems most disagree, but that is still no reason to accuse someone of being rogue.

Headline should be "Google Chrome actively ignores HTML5 standard"

<comment><USER59> The standard says "SHOULD", not "MUST".

(Disclosure: I work for Google)

<comment><AUTHOR> Where is this supposed "should"?

From the spec - The autocomplete attribute represents either:

a) autofill expectation mantle

b) autofill anchor mantle

If the input type is "hidden", then it is wearing the "autofill anchor mantle". _IN ALL OTHER CASES_ (emphasis mine) it wears the "autofill expectation mantle"

And what are the rules on "autofill expectation mantle"?

"When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or autofill detail tokens

...

The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; _OR THAT THE DOCUMENT PROVIDES ITS OWN AUTOCOMPLETE MECHANISM AND DOES NOT WANT THE USER AGENT TO PROVIDE AUTOCOMPLETION VALUES_. (emphasis mine)"

Per: [https://html.spec.whatwg.org/multipage/form-control- infrastr...](https://html.spec.whatwg.org/multipage/form-control- infrastructure.html#autofilling-form-controls:-the-autocomplete-attribute)

<comment><USER59> The "should" is in the spec's description of how to interpret "off": "When an element's autofill field name is 'off', the user agent should not remember the control's data, and should not offer past values to the user."

<comment><AUTHOR> So then the crux of the conflict:

In 220.127.116.11.1...

"The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."

In 126.96.36.199.2...

"When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.

NOTE: In addition, when an element's autofill field name is "off", values are reset when traversing the history."

@jeffk - Ok, I now understand _where_ you are getting this interpretation.

I think this is a dangerous interpretation (and perhaps it requires altering the spec to say _must_ ). Again Application developers need a reliable, durable way to tell the UA that a particular field should never be autofilled or autocompleted. How else do you propose we do that, other than following 220.127.116.11.1.

<comment><USER59> My parent was saying Chrome was not compliant with the spec, but SHOULD directives are not mandatory and a User Agent may decide that it would be a worse experience for users to follow them.

Chrome is claiming that enough developers have marked fields as autocomplete=off in user-hostile ways that it shouldn't be respected, while many people here are making the case that conflicts with site-provided autocomplete and other issues push the other direction. That's how to have this discussion, not by pretending this SHOULD is a MUST.

(I don't work on Chrome and don't know any Google-internal anything about this)

</comment></comment></comment></comment></comment></comment></comment><comment><USER60> I run a site with a normal login/password, but which maintains passwords for other systems. It's pretty frustrating when the internal external usernames are autofilled with the username from our site. It confuses the user, suggesting that the username from the external site should be the same as our own.

</comment><comment><USER61> I was using Google Places' address auto-complete on a CRM, and most users loved it. Chrome's behavior completely broke this functionality by overlaying their auto-fill on top of Google Places suggestions, with no sane way to disable it. We decided to stop using address auto-complete and force our customers to type the address fields instead.

Ironically, we were paying Google a few thousand dollars per month for this, so they are not getting our revenue as a direct consequence of Chrome's behavior.

</comment><comment><USER62> I'm not sure who Chrome think they're helping. We get many, many users contacting our support team because of this feature / bug on [https://www.openrent.co.uk](https://www.openrent.co.uk).

It's frustrating, we've used workarounds, which then stop working and reports come flooding in again. It's crazy to me that the Chrome team think this is better for users, and that there isn't a more intelligent workaround for sites abusing autocomplete=off.

<comment><USER63> At some point the alternative will be to implement a custom input control, which will just be awful in all kinds of ways, but it's just as awful to have Chrome think it knows best in some contexts.

</comment></comment><comment><USER51> The Chrome dev team have implemented autocomplete the way they think it should work, not the way web developers want.

You cannot switch off Chrome's handling of autocomplete, thus any other autocomplete implementation will be overwritten by Chrome's handling.

Chrome team feel they know best.

<comment><USER64> They are becoming the Gnome of browsers. The Chrome dev team seem to be getting more and more user hostile.

<comment><USER65> > They are becoming the Gnome of browsers.

What they're becoming is ie6.

</comment></comment></comment><comment><USER66> I would love it if someone explained how 'autocomplete=off' can lead to abuse of some kind. It seems to reduce the potential for security leaks.

<comment><USER67> It causes spec-compliant password managers to not work.

Unfortunately, disabling autocomplete for password fields is an often used form of security-theatre

<comment><USER68> Here's the tricky thing and I don't have a solution that doesn't get abused. I hate that lots of bank do this but I also have a use case for password autocomplete=off. We operate in an industry where shared computer access is very common and the risk of users saving password in browser is real and too high.

As I said don't know what the answer is. I definitely want someone using password manager be able to use them. Using a password manager is a conscious choice with setups involved. Browser's default autocomplete is often not. I don't know how to separate these two out.

<comment><USER69> Isn't it on the people administering those systems to disable autofill on their side?

<comment><USER68> In theory it is. But for most customers (who are small) there's almost no IT department and the average computer literacy is lower than you might think (though improving) so the risk is there. Except for that situation I would happily leave them autofill/save password.

</comment></comment></comment></comment></comment><comment><USER70> Bad that chrome developers don't practice web development enough to know the use cases where ignoring autocomplete=off breaks the application.

</comment><comment><USER71> Or line of business applications which (when rendered with Chrome) wants me to pick from my credit cards when I enter a certain field which has nothing to do with credit cards. I think it depends on the field name, but there seems to be a very loose correlation.

</comment><comment><USER72> Another reason to abandon ship and switch to Firefox.

</comment><comment><USER73> With the new direction chrome is going I wouldn't mind putting "works best on anything but Chrome" on my next web project.

<comment><USER74> I was thinking the same, websites should just have a big popup somewhere saying that the website might not work on Google Chrome, because it is W3C compliant and Google Chrome doesn't implement W3C standards, whith links to download alternatives browsers.

<comment><USER75> Please go read the spec, you will find that Chrome is perfectly compliant with it regarding the autocomplete attribute handling.

</comment></comment></comment><comment><USER76> The submitted title was heavily editorialized:

"Rogue Chromium dev lead ignores W3C 'autocomplete' spec; frustrates Internet"

</comment><comment><USER77> > This causes some problems, e.g. in <input type="text" name="name">, the > "name" can refer to different concepts (a person's name or the name of a > spare part).

Maybe I need context, but I don't understand why they're trying to 'guess' context around 'name' and trying to autofill something - either a spare part or a person's name.

Doesn't "name='name'" indicate that it should refill with the previously filled value of field named 'named' on that same page/document/url? Why are they trying to add algorithmic complexity on to already existing stuff?

<input --chrome-type="name"/>

This might make more sense, no? Let chrome try to determine a 'name' based on whatever logic they want.

</comment><comment><USER78> There's a major security flaw with auto-fill when it comes to passwords. Sure, it's hidden on screen, but you only have to change the password box's type, so it isn't "type='password'" and it is revealed. This only takes a matter of seconds.

Chrome should remove the password if there is any attempt to change that form object.

This flaw has been there for years, it's actually handy if I'm not sure what the password is.

<comment><USER79> Is this really an issue? Presumably anyone with access to the browser can acces saved passwords anyways; the censoring only prevents onlookers from reading it.

<comment><USER80> Actually on Windows at least Chrome asks for a password when trying to view all passwords. So it isn't _that_ easy.

</comment></comment></comment><comment><USER81> >>> \- How to trigger the hiding? - right mouse button menu or (more likely) something in the drop down? where would we put that? ...

Mobiles notoriously don't have mouse buttons, so any UI relying on right-click will not be usable there.

It's odd that Google is considering mouse-based workarounds in all considered solutions, as if unaware of that. or maybe Chromium is only the desktop browser?

</comment><comment><USER82> This position seems at odds with a recently opened WHATWG issue.

[https://github.com/whatwg/html/issues/4986](https://github.com/whatwg/html/issues/4986)

</comment><comment><USER83> > if you add an <input type="hidden" autocomplete="username" > name="does_not_matter" value="{the actual username}"> before your current- > password and new-password fields, Chrome should get it right

I can't believe that this suggested hack is coming from google.

[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c63)

</comment><comment><USER84> > Comment 66 by firstname.lastname@example.com on Tue, Oct 8, 2019, 3:48 AM CDT (5 days > ago) \- Overall, I still believe that neither of the extreme strategies > ("always honor autocomplete=off" and "never honor autocomplete=off") are > good

[https://bugs.chromium.org/p/chromium/issues/detail?id=914451...](https://bugs.chromium.org/p/chromium/issues/detail?id=914451#c66)

We're in for the Long haul on this one.

</comment><comment><USER85> Discussion about a demo of the issue...

[https://news.ycombinator.com/item?id=13329525](https://news.ycombinator.com/item?id=13329525)

</comment><comment><USER86> If you look at the chrome sources you can find this flag:

const char kAutofillOffNoServerDataDescription[] = "Disables Autofill for fields with autocomplete off that have no " "crowd-sourced evidence that Autofill would be helpful.";

So, at least in a company, this should work to avoid autocomplete making corporate apps unusable.

another thing that seems to work for me, is adding role="combobox" along with autocomplete="off"

</comment><comment><USER87> I guess this bug is the real reason why I turned off auto-fill in the browser a while ago, because it acted weird a lot of times.

</comment><comment><USER86> So far this combinations seems to be working for me

role="combobox" autocomplete="off"

</comment><comment> asdf-asdf-asdf title is wrong, the spec is not ignored. spec says: " When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user. "

please note that it uses "should", not "must". these words have precise definition in specs, see RFC2119:

" SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. "

one may argue whether chrome has valid reasons or not, but saying they ignore it is incorrect.

<comment><USER88> > [...] there may exist valid reasons in _particular_ circumstances [...]

(Emphasis mine.)

Is it really spec compliant when the "particular" circumstance is all of them?

</comment></comment><comment><USER64> Previously closed as WONTFIX: [https://bugs.chromium.org/p/chromium/issues/detail?id=468153](https://bugs.chromium.org/p/chromium/issues/detail?id=468153)

<comment><USER64> Later they filed:

[https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

</comment></comment><comment><USER89> Does Chromium not have anyone doing QA or acceptance criteria? A rogue dev lead could make whatever feature they want, but there should be a robust process of testing by many people before the feature makes it in to a production build.

</comment><comment><USER90> I hat to fight with browser autocomplete in Kibana main search bar. On the other hand I guess it is the same as right mouse button - I don't allow any site to capture that event since some abuse it.

</comment><comment><USER91> A rare example where an editorialized HN post title is appreciated. Bravo!

</comment><comment><USER92> Just stop using Chrome. There are good (even better) alternatives.

</comment><comment><USER93> I use autocomplete="x" and it seems to work for my apps.

Both Twilio and NameCheap seem to have login that defeat autocomplete in a nice way. Haven't investigate their tricks

</comment><comment><USER94> > This has turned into a sad tit-for-tat between developers and Chrome, where > no-one is winning.

Not the kind of relationship you want to build with an army of advocates

</comment><comment><USER95> I love the edited title of this post. It reflects accurately the reality of the situation. Hey, battre, hi there! You are famous now!

</comment><comment><USER96> I wrote a Medium article on how to actually turn it off 3 years ago that consistently gets about 500 views a week to this day.

</comment><comment><USER97> I wonder what kind of engine overhaul Chrome is doing to cause all of these strange breakages.

</comment><comment><USER98> This also screws with notion to the point where I've largely stopped using it at all

</comment><comment><USER99> We're Google, we don't have to respect the spec.

</comment><comment><USER100> As a developer this can be fixed by using unique field names.

</comment><comment><USER101> Is "ignoring the specification" an extreme, now?

Are we seriously expected to entertain this mess?

So glad I switched to Firefox all those years ago.

<comment><USER74> Google slaves came to downvote you after someone said this on their internal chat lol.

</comment></comment><comment><AUTHOR> There was a time when IE was the dominant browser, and happily did whatever they wanted to.

That was arguably better, because at least they acted predictably. Chrome has been continually altering how autocomplete is handled in the last 5 or 6 major releases

<comment><USER102> They acted predictably by never updating IE and letting it stagnate. Hard to see how that is better in any meaningful way.

<comment><USER103> You still had a choice, nowadays being a Web Developer is almost a synonym for Chrome Developer and it was the IE hatting crowd that made it happen.

<comment> yoz-y Except Chrome is still far below the user-base of IE in its heyday. And the most "valuable" users are all on mobile Safari. So it still makes sense to at least test with that.

<comment><USER104> "the most "valuable" users are all on mobile Safari"

Not at all, as only 20% of the people using mobile browsers at all, are using Safari.

<comment><USER105> To be accurate: Safari has 20% of mobile browser marketshare. And 5% of desktop browser marketshare. So globally they are <20%

</comment></comment></comment></comment></comment></comment><comment><USER106> Thank you chrome, for recognizing that the USER is what matters, not the website developer. Websites started blocking legitimate uses of autocomplete, and that makes the web less secure. As a user I sincerely hope that "autocomplete=off" dies just like the blink tag, as it is user hostile.</comment>


Are Submissions private? - <AUTHOR>

I have just posted a link. I personally can see it in the newest page. However, if I am using another user (or anonymous) I cannot see the link. What's happening? Is there some approval process to be able to post for hacker news? <comment><USER2> I speak with no inside knowledge ...

There are sites that have been determined to be an excellent predictor of low quality. Sometimes these sites have good articles, but overall, the judgement has been that it is better simply to mark all submissions from those sites as DOA.

From [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) :

        Please don't post on HN to ask or tell us
        something (e.g. to ask us questions about
        Y Combinator, or to ask or complain about
        moderation). If you want to say something
        to us, please send it to firstname.lastname@example.com

</comment><comment><USER3> There isn't an approval process, but the submissions of wix.com are getting marked as dead. Ask email@example.com (which you can see a link to at the bottom of the page marked "Support") for questions of this sort.

</comment><comment><USER4> Turn on showdead and it will appear.</comment>


Ask HN: Partial Aorta Artery Repair - <AUTHOR> HNers are some of the brightest sparks around. I am hoping that one of you might be informed enough to shed some light on this issue.
My daughter's mother has a tumour that is growing, slowly, in and around her aorta. She has been to doctors. Surgery for a tissue sample won't happen from fear of life-threatening damage to the aorta.
As such, they cannot determine the type of tumour. Consequently, chemo and other forms of therapy (including surgical) are off the list.
From "New Materials and Technologies for Healthcare" (2012), I've read that, "The repair of the aortic artery using stem cells to regenerate the diseased section would be an important step but is far from being a clinical procedure."
What other researchers or medical facilities are seeking effective treatment of (potentially cancerous) aorta artery tumours?
What other treatment options are available? <comment><USER2> Given the severity (significant), and speed (relatively slow), I'd get a second opinion from a (different?) top-tier medical facility.

Sometimes doctors just don't know what they need to know in order to best treat a condition, and they're not good at polling the competition (though many try). It's up to the motivated patient to fill that gap, though it's probably a long shot.

The aorta moves, constantly, making any kind of characterization or manipulation nearly impossible without stopping it, running the risk that it may not start up again. No doctor in their right mind would risk killing their patient for test results that aren't urgently needed. The patient staying alive is the goal.

Some tumors stop growing all on their own, and there may be decades of functionality left in spite of the growth.

When the heart ends up limping along from occluded flow, running a bypass would seem like a commonly-performed procedure. That may not be applicable but the death rate for a coronary bypass for a patient under 65 (presumably like your baby mama) is under 1 percent. Maybe things aren't as dire as they seem.

</comment><comment><USER3> MD here. Something is odd. If it's big enough to be tumor-like it's big enough to be biopsied.

If it's small, they can just watch it on serial CT scans. If it's growing, they can put her on bypass and replace that section of her aorta. Not as easy as it sounds, but still usually possible.

Repair with stem cells is very different than curing a tumor.

In complex, atypical cases the answer is always to go to a large teaching institution.

<comment><AUTHOR> Thank you so much!

Any institutions you would recommend?

</comment></comment><comment><USER4> Ask the doctors if the Guardant 360 test could help. [https://www.guardanthealth.com/guardant360/](https://www.guardanthealth.com/guardant360/)

It is a blood test that can determine genetic mutations in the tumor that may help identify it.

<comment><AUTHOR> That's a great idea, I shall pass it along.

Thank you.</comment></comment>


New social network links ex-terrorists and victims - <AUTHOR> http://www.againstviolentextremism.org/

<comment><USER2> How does this service screen new members?</comment>


It's Time to Fix Subversion Merge - <AUTHOR> http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It-s-Time-to-Fix-Subversion-Merge.aspx <comment><USER2> This is a good write-up on how to build this, but it should be stated if you've grown beyond what subversion can do you should switch your repository over to Git or something with more advanced functionality built in.

<comment><USER3> There's always 2 choices: Fix it, or replace it.

I think there's a good case for fixing Subversion. It's very easy to use (except for merging!) and it's got good adoption.

Git is harder to understand and use, but obviously merging is miraculously easy with it.

SVN took me about 10 minutes to learn. Git took me a week to grok the basics, and months to learn the finer points.

If I had to pick one of the 2 to train a new coder in, I'd pick SVN... If it had merging done well.

<comment><USER4> This comment on the original post is interesting: "Fixing svn is a lot of work. You could instead write a wrapper around git-svn to make it look like svn. The wrapper can enforce a centralized workflow. The user should not be able to tell the difference."

It's a neat idea. After all, which is easier: to fix the inner workings of SVN, or to provide a more SVN-like interface to Git?

<comment><USER3> That's a good point, too. It shouldn't be that hard to restrict Git's features to a subset that is easy to learn and pretty much foolproof. (Foolproof meaning you wouldn't need to dig into the advanced features.)

I wonder if someone has already tried to do this? It suddenly seems so obvious.

</comment></comment></comment></comment><comment><USER5> If I recall correct, one of the lead devs of SVN has stated he is fine with svn merge as-is.

I strongly recommend migrating to hg or git if possible.

<comment><USER6> I'm using for my hobby project git, very slow learner, and it keeps me thinking if we decide to replace Perforce (P4) with git - how we are going to explain to people how it works - most of the people using it are actually not software engineers, but artists, producers, animators, etc.

Then how much HDD space we should allocate, after knowing that Perforce's own DB is in dozen terabytes.

How efficient git is with binary data. How would the team react when software engineers would work with git for the source, and the rest P4/SVN? You can't label the depot at once...

So there is probably plenty yet for SVN/P4/etc to be used. I myself fancy being cool and using git, but it's only for my hobby yet - I haven't heard of anyone using it at large in any big game development studio...

<comment><USER7> With git you only really need to care about 5-6 commands for basic usage. For more advanced stuff you could also use a GUI; for mac there are plenty of tools that are really polished.

<comment><USER6> That's fine, but the concept of intermediate storage (index) is not very easy to explain to an artist. Some of them still don't grasp all of P4, and P4 is very simple and easy - with changelists.

<comment><USER5> git commit -a -m "blaaaa"

or (my favorite!)

hg commit -m "blaaaa"

At least, that's how I do it!

</comment></comment></comment></comment></comment><comment><USER8> Complaining about Subversion merge is like complaining about how your Apple IIe can no longer use modern software. Subversion and the Apple IIe are outdated and should be migrated away from.

</comment><comment><USER9> It's time to let SVN die and switch to git.

</comment><comment><USER10> use git -> fixed

</comment><comment><USER11> use HG -> fixed</comment>


Biomedical companies bleed 500k horseshoe crabs a year - <AUTHOR> http://www.popularmechanics.com/science/health/a26038/the-blood-of-the-crab/ <comment><USER2> I found a few interesting facts during the first 10 minutes or so of googling this:

1\. Bled crabs die at higher than reported rates (Closer to 20%-25% than the reported ~10%-15%)

2\. Bled crabs are back at full blood capacity in a week, and usually fully functional within 2-3 months.

3\. This crab blood is seriously important to modern medicine (duh?, but hey its nice to have confirmation)

4\. Population numbers are all guesses, and I couldn't find a number which I'd be willing to bet on. Low number was ~600k (mature crabs) high number was several million.

5\. Losing blood and being thrown back into the ocean is an order of magnitude better than being chopped up and used as bait.

6\. A huge number of these crabs get chopped up and used as bait. They're valued at ~$2 each, as bait :(

7\. These crabs lay upwards of 50k eggs per season, per female. A specific bird, the Red Knot, which doesn't seem to doesn't have magic medicinally valuable blood shows up and treats the eggs like an all you can eat buffet.

8\. The Red Knot population has been on the rebound, thanks to conservation efforts revolving around the horseshoe crab, and the expanded food supply that offers.

Enough other people have gone over the various moral issues with this, and I don't think I'd be able to add much there. To me, the whole situation seems trivial to solve, via enhanced conservation efforts, and heavily reduced bait harvesting. Probably wouldn't hurt to make a few Red Knot omelettes too. Bleed + Release > Bait harvest/baby crab genocide via bird.

</comment><comment><USER3> The idea that this isn't "fishing" because they're tossed back afterward is really beyond me. Seems about equivalent to chopping the fin off a shark and then dumping what remains into the water to bleed out and die.

With proper regulation, it seems possible this could be done somewhat humanely— particularly if the draw from any one crab was strictly limited, and their time out of water was also very limited. Eg, if the facilities were right on board the boat, so it would out and back in all within in the span of a few hours.

<comment><USER4> > The idea that this isn't "fishing" because they're tossed back afterward is > really beyond me. Seems about equivalent to chopping the fin off a shark and > then dumping what remains into the water to bleed out and die.

I guess I'm missing something, how is this in any way comparable to that? They're not cutting off a piece of the crab, just drawing some blood and putting them back. Why would they bleed out and die? Do humans bleed out and die after drawing blood?

<comment><USER5> > Do humans bleed out and die after drawing blood?

If you take a third of it, then throw them in the woods to fend for themselves, some definitely will.

<comment><USER6> Almost all will die without medical care.

Class III Hemorrhage involves loss of 30-40% of circulating blood volume. The patient's blood pressure drops, the heart rate increases, peripheral hypoperfusion (shock), such as capillary refill worsens, and the mental status worsens. Fluid resuscitation with crystalloid and blood transfusion are usually necessary.

</comment></comment></comment></comment><comment><USER7> >While several companies have come up with synthetic alternatives for detecting the presence of endotoxins in vaccines, medicine, and medical instruments, LAL is still the only test that has received FDA approval.

I wish they would have elaborated on this. Are the alternatives known to be inferior at this time, or are they promising, but stuck in the long, complicated approval process?

<comment><USER8> The common sense answer is that an alternative which was inferior would never be developed to the point of submission for FDA approval, as it would not be viable to take to market.

<comment><USER9> But the article says the crab blood costs $14,000 per quart - if something works "well enough" and can be made synthetically, certainly it could be used in some cases due to the cost alone.

For example, consider if there is a simple case where the test is _not_ administered at all today in some cases, due to the cost. (Use your imagination.) In that case "good enough" to quickly administer for a quick read, might well be a very low threshold indeed! Who says "good enough to administer" must be "the best level in existence"?

<comment><USER10> > "well enough"

This is the medical field. There is no well enough.

Even modeling for cancer detection we do 95% and medical device they do 99% confidence interval IIRC. And with model, we choose sensitivity over specificity. We rather accidentally diagnosed them with cancer over accidentally say they don't have cancer when they do.

Also FDA might have a bar what well enough is, and it could high enough that other companies cannot pass it.

<comment><USER9> What makes you think I thought "good enough" means 55% or 60% efficient, or whatever you object to? Good enough might mean 99% of the time.

You said it yourself!

>Even modeling for cancer detection we do 95% and medical device they do 99% confidence interval IIRC

So, in these applications, 95% and 99% respectively is the meaning of good enough.

So to put these in crab terms: maybe the crabs do it at 99.99% (3.89 sigma) and the synthetic they want to push through is only 99%, only 2.5 sigma.

So I am saying 99% can be good enough in some contexts - just as you've said.

Especially if it costs thousands to do it a la crab.

It doesn't have to be _better_ than the crabs' blood to be _good enough._

</comment></comment></comment></comment></comment><comment><USER11> There is a great little startup in the EU working to biosynthesize LAL:

[http://sothicbio.science/](http://sothicbio.science/)

It's a RebelBio (née IndieBio EU) company.

<comment><USER12> Will the synthetic enzyme be a direct substitute in the standard LAL enzyme chain? Or will it be an alternative reaction like Lonza's PyroGene?

</comment></comment><comment><USER13> >Biomedical/pharmaceutical companies are reluctant to devote time and resources to qualify an alternative method as they are concerned that regulators will not accept the alternative method. However, the pharmacopeia publications include chapters that directly address what is needed to qualify an alternative method so that it will be acceptable by regulators.

Classic chicken and egg problem here. These companies don't want to invest in the lengthy regulatory approval process because they aren't sure they'll pass so progress on these alternative methods gets stalled, thus ensuring they look sub-optimal on paper, so the perceived risk level is probably higher than it should be.

Considering there are two alternatives here, one involving synthetically cloning DNA and the other simply using human blood, I can probably see why industry is slow to move off the crab blood process. The former is most likely much more expensive and patent encumbered, while the later involves harvesting humans instead of crabs. Human blood is needed for transfusions and has a high demand, so it makes sense to just use animal blood for endotoxin testing.

[1][http://www.horseshoecrab.org/med/alternatives.html](http://www.horseshoecrab.org/med/alternatives.html)

<comment><USER14> could the blood not be taken from the dead? Blood is already drained in the embalming process. I'm guessing it'd need consent similar to organ donation though.

<comment><USER13> Most people die quietly in hospice or at home, not in the ER, so there's a logistical problem here. Red blood cells start dying in minutes after host death, so you don't have a lot of time on your hands in common scenarios. Biologically, you want healthy blood full of red blood cells not blood low on red blood cells and full of white blood cells which can cause complications.

The dead also can't answer questions about their illness history. There's a lot of legwork with blood that organs don't typically require.

<comment><USER15> The Russians did some research into cadaveric blood transfusions.

The blood is still usable for several hours after clinical death.

I'm not sure about the suitability of using blood from old, sick and/or heavily medicated people.

</comment></comment></comment></comment><comment><USER16> I'm not exactly sure why, but this makes me feel sadder than capturing and butchering meat in the modern not very humane way.

Just seeing these crabs with a history stretching back into ancient times, strapped in and needles inserted into them looks so awful. I don't want to believe it's considered acceptable practice in the modern era to do such things, regardless of its medical benefits.

<comment><USER6> I agree with you. Just as bad is what's known as Bile Bears. Humanity has a ways to go with treatment of sentient creatures. Intelligence or species is not the predicate with which we should dole out misery. Ability to feel pain is the only thing that matters. And far too many of the creatures we put through screaming existences are too close to our own hearts...conscious feelers. That's all we really are beneath it all. Do onto others as you desire onto yourself.

[https://en.wikipedia.org/wiki/Bile_bear](https://en.wikipedia.org/wiki/Bile_bear)

<comment><USER17> I don't think it's even close ethically to torturing a bear. You know people boil crabs alive all the time, right?

<comment><USER18> I don't think this is a particularly good point to make. You're saying that since X happened and since X is worse than Y, we shouldn't care about Y.

There's been school shootings so single murders don't matter?

There were so many more deaths in world war two than in world war one, so WWI doesn't matter?

And this is ignoring the fact that your "worse" claim was based on your own personal ethics which is, at best, subjective.

<comment><USER19> People have a finite amount of time and energy. How do you choose what to prioritize if not by saying that some things are worse than others? They didn't say that some things don't matter, just that it doesn't come close ethically.

</comment></comment></comment></comment></comment><comment><USER20> Has anyone who is raising ethical concerns of this been around a horseshoe crab? They are essentially large insects. Killing a cockroach because it was in your house is objectively worse. It was just bugging you. This is saving human lives.

<comment><USER21> I think the main concern is that they might go extinct.

(Regarding the cockroach - don't Americans have the right to shoot _human_ tresspassers? The crab on the other hand is plucked out of water which is its own home. This is not to say I'm against the practice - I'm not, unless the crab might go extinct.)

<comment><USER22> > don't Americans have the right to shoot human tresspassers?

That's a complicated question, but quite often "no" for mere trespass; the actual laws vary by state.

<comment><USER23> What about "stand your ground" and "castle" doctrines?

<comment><USER24> Both of these require active threats.

"Stand your ground" laws just mean there is no duty(law) to seek retreat above all else before actively defending yourself.

"Castle", in California, simply means that if an intruder has bypassed a control (picked a lock, broke a window, etc) to gain entry then one can proceed on the assumption that they are there to do grave bodily harm. (And thus act accordingly.)

<comment><USER25> > Both of these require active threats.

Close... they require the person standing-ground to perceive a threat. The laws do vary state-by-state, but they tend to be universally broad.

"For example, Michigan's stand-your-ground law, MCL 780.972, provides that "[a]n individual who has not or is not engaged in the commission of a crime at the time he or she uses deadly force may use deadly force against another individual anywhere he or she has the legal right to be with no duty to retreat if ... [t]he individual honestly and reasonably believes that the use of deadly force is necessary to prevent" the imminent death, great bodily harm, or sexual assault of himself or another individual."

* Stand-your-ground law - Wikipedia || [https://en.wikipedia.org/wiki/Stand-your-ground_law](https://en.wikipedia.org/wiki/Stand-your-ground_law)

According to this, if I thought someone was a habitual sex offender, I think I'd be within my right to sniper him from a mile off... so... clearly that's a stretch... but it has been stretched pretty thin before.

* Joe Horn and Five Years with the Texas Castle Doctrine - The Texas Observer || [https://www.texasobserver.org/joe-horn-and-castle-doctrine-s...](https://www.texasobserver.org/joe-horn-and-castle-doctrine-shootings-in-texas/)

> It's not that he wanted to shoot the intruders next door, he said, "but if I > go out there to see what the hell's going on, what choice am I going to > have?" The dispatcher told him again to wait for the police, not to go > outside with his shotgun, that nobody needed to die for stealing.

> Horn was unconvinced. "The laws have been changed…since September the first, > and I have a right to protect myself," Horn said. "I ain't gonna let them > get away with this shit. I'm sorry, this ain't right, buddy … They got a bag > of loot … Here it goes buddy, you hear the shotgun clicking and I'm going."

> "Move, you're dead," he told the men, then he fired three times, killing > both men, and returned to the phone in his house.

> "I had no choice, they came in the front yard with me, man, I had no > choice," he told the dispatcher. Police arrived seconds later. Horn wasn't > arrested, nor was he indicted by a grand jury that later considered the > case.

</comment></comment></comment></comment></comment></comment><comment><USER26> It may be small consolation, that in the mid term, only humans can prevent meteor strikes from re-extincting everything on this planet. 99 percent of every species that has ever existed is permanently extinct. That being said, I'd love to maintain or grow biodiversity, for it's where we will learn the most tricks to help ourselves in the mid term.

Thus, if it helps humans a bit, in the long run, it could help all the life on this planet. Also, these guys are working on the problem [https://rebelbio.co/sothic-bioscience-saving-human-lives- and...](https://rebelbio.co/sothic-bioscience-saving-human-lives-and-the- horseshoe-crab-with-artificial-blue-blood/)

<comment><USER27> But what does it matter? The only reason biodiversity is important is because it creates a better environment for all life on the planet, including us. There's no cosmic benefit to life existing on Earth, or at all. If humans weren't around to stop a meteor from wiping all life off the planet what would it matter?

<comment><USER26> Human consciousness is the most rare and important "thing" in the universe. We also invented "mattering." Thus, all things that matter, do so, because we're here.

Nihilism is not only unproductive, it feels bad too. Upgrade to utilitarianism with a strong personal/local bias. Or, if you're a nice guy, utilitarianism in general.

<comment><USER28> Just because it feels bad to you(doesn't feel bad to me), that doesn't have any effect on the validity of that perspective. Of course human consciousness is important to humans, as you pointed out. Did we invent "mattering"? I guess that depends on if you can actually invent an idea, and if there is intelligent life elsewhere. Utilitarianism might be more useful at the societal level, but that still doesn't have any bearing on whether or not an individual position of nihilism is wrong. It might be a good idea that people have views that are incorrect about the environment that result in more biodiversity(though I would guess that biodiversity has diminishing returns), yet not attributing a mystical value to nature can prevent us from wasting our time and resources because our judgment is clouded. There's nothing unproductive about that.

</comment></comment></comment></comment><comment><USER29> One thing not mentioned in the article is the impact horseshoe crab farming has had on the Red Knot. PBS made a really interesting documentary about it, I would highly recommend you check it out.

[https://www.youtube.com/watch?v=zGMLuEsvHAw](https://www.youtube.com/watch?v=zGMLuEsvHAw)

<comment><USER30> Is the impact positive or negative? It seems like farming the crabs would solve the problem.

</comment></comment><comment><USER31> The relevant limulus proteins can be expressed in vitro. [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5302069/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5302069/)

<comment><USER32> It looks like (very much like insulin production in vitro) the proteins involved here are highly modified after translation. Some proteins are usable right after they are produced by the ribosome, some require extensive modification to be useful. It looks like Factor-C [1] needs substantial posttranslational by machinery that is not present to the organisms commonly used for industrial protein production. So not only do you have to produce the protein synthetically, but you also have to produce the modification machinery synthetically.

An additional challenge is that the readout is at the bottom of a signal- amplified cascade [2]. And that cascade magnifies any error you have at the top (which is where that finicky Factor-C lives). Older synthetic assays read- out straight from activation of that first signal from Factor-C. This paper tries to recreate a portion of the cascade before reading out a result. But that now means you not only need to produce the Factor-C, the machinery to ensure Factor-C is properly produced, but you also need at least a few of the downstream components as well. So now you have a multi-component synthetic system - with all the grinding through the search-space and tuning that comes from having to optimize a multi-component biological system in vitro.

That's a pretty complicated problem. The paper just came out less then two months ago, and concludes, "The present study supports the future production of recombinant reagents that do not require the use of natural resources". We're on the right track, but it seems this is actually a tricky problem.

[1] (Factor-C protein) [http://www.uniprot.org/uniprot/P28175](http://www.uniprot.org/uniprot/P28175)

[2] (Coagulation Cascade) [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5302069/figure/...](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5302069/figure/fig1-1753425916681074/)

</comment></comment><comment><USER33> \- Christian Schafmeister spyroligomer effort (a dsl to design protein tools to craft proteins IIUC)

\- Woods, Rondelez, Schabanel dna tiles computing (turing complete molecular computing)

We're not far from being able to leave nature alone .. let's help these guys.

</comment><comment><USER14> could LAL not be created using recombinant DNA? We already produce insulin this way, and I can only assume that LAL is a protein. I'm guessing you couldn't use e. coli as the host though, given the protein's purpose.

</comment><comment><USER34> By mimicing industry the study is working uphill. The more direct approach would be to bleed and study a captive population. Bleed some already captive aquarium crabs. Then you can see exactly what happens when you return them to thier home tanks. That should answer some fundimental mortality and movement questions in days, if not hours. (Good luck finding a legit aquarium willing to let its animals participate.)

They also focus too much on the bleeding. What matters is how many die from both the bleeding and the handling. The "control group" should be wild and uncaught animals.

<comment><USER35> One of the problems with your approach is that many industry groups have used "Well, this study doesn't exactly mimic field conditions, so it's not valid..." in the past.

<comment><USER34> That assumes that we are looking to answer the entire question. I'd babystep towards that by first answering some basics. I want to know how much blood you can take and how long before the animal fully recovers. That can be better done in an aquarium setting with animals who are well-observed before and after. If draining a quart out of each captive animal kills 30%, that is a huge red flag without the hassle of radio tagging.

I remember reading an interesting article about bleeding squirrels to study their relationship with snakes (through blood one can tell if they have every been bitten by a venomous snake). Squirrels don't have much blood. So the scientists determined that they needed a caged recovery period with free food/water, and a shot of antibiotics, before being returned. Maybe too these crabs.

</comment></comment></comment><comment><USER4> Lots of people are saying this is absolutely awful but I really don't get it.

> There are currently no quotas on how many crabs one can bleed because > biomedical laboratories drain only a third of the crab's blood, then put > them back into the water, alive.

If it's just a needle insertion, why is this such a big deal? The crabs shouldn't be bleeding after, and I don't see why they would be very damaged.

It's saving human lives. I don't think it's ridiculous to say that human lives are worth more than some momentary discomfort for crabs.

<comment><USER36> > I don't think it's ridiculous to say that human lives are worth more than > some momentary discomfort for crabs.

Well: says the human.

<comment><USER37> You're right, people would never accept a regime where humans were drained of some of their blood in order to give other humans medical treatment with that blood.

<comment><USER38> Well, it's OK if it's voluntary. But that gets murky for prisoners, who arguably can't freely decline.

<comment><USER39> Even setting aside statistics about various communicable diseases, prejudice would make use of prisoner blood a tenuous thing.

(I mean beliefs about prisoners being "bad" or "tainted" or whatever and people not wanting to receive their blood)

<comment><USER40> Few whole-blood transfusions occur in a setting where the patient can inquire in detail as to provenance.

<comment><USER39> Of course. That doesn't mean people wouldn't react to news about blood being collected in prisons.

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> Interesting article. Never heard any of this before.

I am ever so slightly skeptical.

I wouldn't be surprised if this while article was a fabrication created as some social experiment to test was people will believe. "We bleed 1/3 of the blood out of HUNDREDS OF THOUSANDS of horseshoe crabs then put them back in the wild... and you have never heard about it or seen it happen."

This article just sets off my radar is a particular "April Fool's!" kind of way. Can't put my finger on it.

<comment><USER42> Just wanted to say I have heard of this going back a few years. Skepticism is good but I didn't think there was anything overt in the article that raised red flags. Let's please not brush this off. There are tons of niche markets and industries and practices that you don't hear about. Anyone who has worked at a large company knows just how many hidden markets there are for all sorts of random shit. You just have to pay attention.

</comment></comment><comment><USER43> Take take take, don't give back. The earth isn't concerned with our human antics - it just responds in kind. We are bringing our own demise

</comment><comment><USER25> > There are currently no quotas on how many crabs one can bleed because > biomedical laboratories drain only a third of the crab's blood, then put > them back into the water, alive. But no one really knows what happens to the > crabs once they're slipped back into the sea. Do they survive? Are they ever > the same?

Seems like it'd be easy enough to figure out if they are surviving or not, and seems like we could make adjustments to how much blood is drained based on the weight of the crab if we are killing them (or drain more blood so we kill fewer of them). How hard is it to glue an RFID tag on each one and dump them into a football field sized enclosure with a net wall around it?

Or maybe we release them into a nutrient rich tank full of their favorite food before we release them back into the wild? The equivalent of giving them a juice box after a blood draw?

Now... as for cruelty... yup, it's pretty barbaric sounding. I don't know how to weight this against human suffering they are helping to avert. I'm certain that if we were smaller than them, they just eat us and not think twice about it. Nice we have evolved to the point where we care about other types of life, isn't it? No clue how to measure human vs crab life, but I have to think that human life is a bit more valuable -- at least to other humans.

Presumably this blood draining procedure has gone through a medical ethics review?

<comment><USER44> > Presumably this blood draining procedure has gone through a medical ethics > review?

There's no IRB because it's not funded research, just harvesting resources from animals.

When it comes to farming, there are no federal laws governing treatment of farmed animals, and most states exempt farmed animals from anti-cruelty laws. I doubt this would actually be categorized as farming, so there's likely no regulations around it.

</comment></comment><comment><USER6> F'ed up if you ask me. Imagine that being done to you by an alien species.

<comment><USER45> How is this anywhere close to the same as Alien species using humans? We differentiate treatment by intelligence of species for a good reason. We allow courts to deal with the subtleties of what is considered cruel and unusual punishment for humans as well from this rational perspective, allowing certain degrees depending on context.

I'm against whales and dolphins being kept in small area confinement. But I could hardly care about a crab being bled.

The only concern is on the survivability of the species and the effect on the greater ecosystem.

This is very rational and I don't see anything morally wrong with it. Nor do the vast majority of other scientists. Many of whom know much more about the species than I do.

The end result is we have a unique way to test for bacteria in a variety of applications that at most save lives, or at a minimum vastly improve the quality.

> Their distinctive blue blood is used to detect dangerous Gram-negative > bacteria such as E. coli in injectable drugs such as insulin, implantable > medical devices such as knee replacements, and hospital instruments such as > scalpels and IVs.

<comment><USER6> At least kill the f'kin things if you are gonna drain them of their blood. Seems like its just a poor excuse to say 'we didnt kill them..they are just fine! *drops crab back into water with half of its blood supply'

Based on what I read, these crabs are basically given a death sentence. I'd rather them be killed and harvested than bloodsucked tortured and thrown back into a predator ecosystem where they are too delirious and pretty much get butchered by whatever's out there.

<comment><USER46> It isn't a death sentence: the overwhelming majority survive, and even go through the process again. If they killed them outright the species would go extinct. Of those two options, this is the environmentally friendly one.

<comment><USER47> However I wonder at what point we're affecting their ability to mate, reproduce, etc..

<comment><USER48> While reading the article I was wondering, would things be better if they only bled the male horseshoe crabs? In mammals you theoretically need fewer healthy males than females to successfully produce the next generation. However, since horseshoe crabs fertilize the eggs once they have been laid, I'm not sure whether the same population dynamic is at play.

</comment></comment></comment></comment></comment></comment><comment><USER49> Can horseshoe crabs actually feel pain? I thought their nervious systems were too simple for that, ergo there's practically no ethical concerns with doing whatever you want to them, as long as it doesn't lead to genocide.

<comment><USER50> Probably they can. Pain detection evolved so organisms can avoid damaging their bodies. There's no reason to think that doesn't apply to crabs.

<comment><USER51> i think this is the most logical answer. i would imagine pain appeared very early in a common ancestor as its effect on survival is absolutely immense</comment></comment></comment>


Bitcoin Sidechains - <AUTHOR> http://avc.com/2014/10/sidechains/ <comment><USER3> This is not really a new idea.

If you take this a bit broader, you could not just link other crypto currencies to Bitcoin, but can use it to timestamp any types of data. For example, in mid-2013 I created a "public ledger" service based on Bitcoin: [https://vog.github.io/bitcoinproof/](https://vog.github.io/bitcoinproof/) (HN discussion: [https://news.ycombinator.com/item?id=5796935](https://news.ycombinator.com/item?id=5796935)).

And even that wasn't really new. It dates back to forum entries and similar projects from 2011 and possibly earlier.

So while I like the basic idea of Sidechains, I don't like their presentation in the article as something totally new, without giving any credit to the history they build upon.

<comment><USER4> Prior related invention in 2012 by my co-founder: [https://bitcointalk.org/index.php?topic=91843.0](https://bitcointalk.org/index.php?topic=91843.0)

Limitations of this side-chains:

\- Can't use proof-of-stake

\- It requires many changes in the Bitcoin reference client

\- It's not very clear if you can increase the frequency of blocks in the side-chain

<comment><USER5> Can you please explain why PoS is incompatible with sidechains?

<comment><USER6> IANA blockchain expert, but this is my understanding:

You need to be able to show a "proof" to the bitcoin main network that the coins are being transferred back to the bitcoin blockchain. This proof needs to be hard to generate, which pretty much makes POW mandatory.

<comment><USER7> Do you know if that's 1) "must use POW for the transaction that burns the sidecoins", 2) "must have proof of enough total work in the sidechain atop the block in question", or 3) "must only have POW blocks in the sidechain"? Superficially, 2 seems most likely.

</comment></comment></comment></comment></comment><comment><USER8> This is a great, yet simple, explanation of sidechains: [http://gendal.wordpress.com/2014/10/26/a-simple- explanation-...](http://gendal.wordpress.com/2014/10/26/a-simple-explanation- of-bitcoin-sidechains/)

</comment><comment><USER9> I don't understand how sidechains will be economically feasible given there is no monetary incentive for anyone to work on a sidechain, as opposed to an alt- coin, where speculators "invest" in X new currency and early adopters (aka. developers) benefit.

<comment><USER10> Sure, if you consider pump-and-dump scams to be the baseline then any honest business doesn't look economically feasible.

</comment></comment><comment><USER11> I'm curious what this means for Ethereum. Although admittedly I've never really understood what Ethereum was planning to do. But I assumed it was the same idea as sidechains?

<comment><USER6> It's very hard to know whether sidechains will help or hurt ethereum... You could put an ethereum clone in a sidechain, although there'd be downsides to this... It's hard to know how mining would work for such a chain, it would have to work differently than either bitcoin or ethereum mining ("merge mining" alone won't work due to the fact that ethereum has 50x the block rate as bitcoin) and sidechains have extra mining costs that need to be obtained somehow (such as through a "wealth tax" on unused accounts).

On the other side, ethereum itself could host bitcoin sidechains as contracts, adding value to the ethereum network.

My own best guess is that sidechains will be a net positive for ethereum adoption, but a net negative for the ethereum currency market cap.

<comment><USER12> > My own best guess is that sidechains will be a net positive for ethereum > adoption, but a net negative for the ethereum currency market cap.

I don't see how adoption and market cap can go in opposite directions.

<comment><USER6> Contracts will pull in bitcoin using sidechains, but "gas" will use the ether currency. Ether market cap would decrease because the coins aren't locked down in contracts, but in active circulation.

Basically, it means you're decoupling the "store of value" and "medium of exchange" aspects of money, using bitcoin to "hold value" and ether to do the rest.

</comment></comment></comment></comment><comment><USER13> Couldn't agree more. I would add that the many cryptocurrencies that have been created since Bitcoin (Litecoin, Dogecoin, Peercoin, etc.) are evidence of _widespread unmet demand_ for sidechains, which fulfill the need for cryptocurrencies that:

* have global mining infrastructure, liquidity, and network effects comparable to Bitcoin; and

* allow for fail-fast, iterative, distributed experimentation, which is necessary for rapid innovation.

A lot of people want this!

</comment><comment><USER14> Step through this with me...

I've got 5 Bitcoins. I transfer all of them to a brand new sidechain for an initial 50 Sidecoins. This Sidecoin sidechain has a different block reward. Let's say 3 weeks go by. Now there are 10,000 total Sidecoins. Let's say I've got 2,000 of those Sidecoins. How do I convert them back to Bitcoins? Can I only transfer 50 back? Can I transfer all 2,000 back? What are they worth in Bitcoin now?

\---

jdmichal's response:

You freeze your 2000 Sidecoins. That is then converted into some number of Bitcoins, the conversion of which is entirely dependent on how the Sidecoins work. (Likely the ratio of the number of Bitcoins dedicated to the sidechain to the number of existant Sidecoins.) A transaction is then submitted to the main chain, submitting the required proofs that you have frozen / destroyed the appropriate amount of Sidecoins to unfreeze a number of Bitcoins.

If the number of Bitcoins trying to be created exceeds the number committed to the sidechain, the transaction will fail. Otherwise, it will succeed.

\---

So the main Bitcoin network needs to be aware of and to be able to analyze the entire Sidecoin sidechain?

So if only a total of 5 Bitcoin were ever sent/frozen to the sidechain, then only 5 Bitcoin can ever be retrieved/unlocked?

So when the Sidecoin sidechain was first created each Sidecoin was worth 0.1 Bitcoin. So after three weeks there are now 10,000 Sidecoins, each worth 0.0005 Bitcoin? Is this a general rule for sidechains? Why did you say "likely"? Is that because none of the details of sidechains have been worked out?

Transactions on sidechains are mined in to blocks, right? So if someone mined 8,000 Sidecoins of those 10,000, they've now got 4 Bitcoin? If someone then sent/froze an additional 5 Bitcoin to the Sidecoin sidechain, then that would generate 10,000 new Sidechains?

So the incentives to mine Sidecoins would correspond to the total number of Bitcoin that has been sent to the sidechain? If 5 Bitcoin were only ever sent to Sidecoin, then all the mining in the world could only ever lead to a total of 5 Bitcoins?

So for Sidecoins to be economically viable and therefor functional, someone would need to be constantly injecting Bitcoin in to the sidechain, right?

<comment><USER15> > So if only a total of 5 Bitcoin were ever sent/frozen to the sidechain, then > only 5 Bitcoin can ever be retrieved/unlocked?

Yes; anything else would be madness. (If you got back less than 5btc, it would be a huge tax on any usage of creation of sidechains; if you got back more than 5btc, well, there's gonna be problems.)

> So for Sidecoins to be economically viable and therefor functional, someone > would need to be constantly injecting Bitcoin in to the sidechain, right?

Yeah, assuming the sidecoins aren't being used up by miners somewhere. You have to pay for the security somehow; miners aren't charities - <USER2> transaction fees have to come from somewhere. In Bitcoin, the transaction fees currently come in the form of inflation+transaction fees, but probably different sidechains will pick different forms of payment depending on their goals.

<comment><USER14> I'm not sure what you mean by "assuming the sidecoins aren't being used up by miners somewhere". Could you go in to detail?

What do you mean by "different sidechains picking different forms of payment?".

Doesn't all of this basically guarantee that the mining rewards of Sidecoin need to be exactly matched to Bitcoin? If so, what's the point of sidechains at all?

</comment></comment></comment><comment><USER16> [http://www.blockstream.com/sidechains.pdf](http://www.blockstream.com/sidechains.pdf)

</comment><comment><USER17> How do sidechains affect the security of Bitcoin and/or the sidechains themselves? Will Bitcoin open itself to a much wider range of attacks once it accepts sidechains? Will the sidechains be inherently much less secure than Bitcoin's blockchain?

<comment><USER8> The security of Bitcoin itself/the blockchain won't change at all if the functionality for sidechains is implemented.

However, the sidechains themselves (and the Bitcoins pegged to them) will only be as secure or vulnerable as their implementation and usage is. The security of a sidechain, is as far as I'm aware, the exact same as it would be if the sidechain was an independent altcoin.

<comment><USER6> It is correct on first order that Bitcoins is isolated from bugs in sidechains. However, a good case can be made that sidechains could lead to more mining centralization, which is always the elephant in the room with Bitcoin.

<comment><USER8> Wouldn't it be the exact same centralization situation if the sidechains in question instead were developed as altcoins? The altcoins/sidecoins that use merge-mining may lead to centralization while the ones that do seperate mining probably won't?

Or is there any difference?

<comment><USER6> The problem is that bitcoin mining has very slim margins now, and if sidechains happen, "mining difficulty" will go even hight and mining sidechains will be pretty much be mandatory for ROI.

However, mining many sidechains requires significant computing resources.

</comment></comment></comment></comment></comment><comment><USER18> Are there any clients that support 0 BTC transactions?

<comment><USER19> No. This is to prevent DoS attacks on the network. Each transaction must include a fee.

<comment><USER20> Transactions are not required to include a fee. Zero fee transactions are fine, and will make it into blocks rather quickly if they have a sufficiently high priority (input age).

The DoS prevention measures are enacted by the enforcing the dust limit (min transaction relay fee), based on the cost to the network to spend the coins.

</comment></comment></comment><comment><USER21> I really don't get what's the big fuss about sidechains. It's a totally obvious next step in blockchain technology. The implementation is what's important.

</comment><comment><USER22> An acute interest in blockchain-based securities trading led to my modifying a short Python script that would label fractions of a bitcoin as company stock. This was years ago, but I've kept watching for developments in this space ever since. I was convinced someone would eventually do it better.

Sidechains have been on my radar for about six months. What you should know about sidechains is it's being developed by a company called Blockstream, and that it faces real security challenges compared to other approaches. Sidechains is seemingly marketing itself as a panacaea to everything Bitcoin wants to do but can't. However, for me, this has always meant blockchain-based stock trading. I personally doubt Bitcoin needs faster block times or ring signatures for additional privacy. In my opinion, sidechains and Blockstream is mostly a Bitcoin 2.0 startup.

The fact is, you can send BTC to Havelock.com today, which is a shady off- chain Bitcoin stock exhange. Everyone is perfectly capable of depositing BTC at Havelock or a futures exchange. Your money may get stolen, or the site may suddenly close its doors. Problems such as this are what sidechains, and other projects some of which I'll delve into below, are attempting to solve. That is:

1\. There is nascent demand for Bitcoin stock trading, futures, options and derivatives.

2\. Off-chain service operators who provide these services today too often steal the money.

3\. Off-chain services are forced to operate in the clear to develop trust in the marketplace, under their real identities, which invites regulators to shut them down.

Open Transactions (OT) is competing with sidechains to solve this. Specifically, OT voting pools prevent off-chain service operators from stealing all the money. Since they can't steal the money, services like Havelock.com could safely operate over Tor, and it wouldn't matter as much who was behind the website.

With OT, you can use basic web development skills to launch a trustless Bitcoin stock exchange platform without restriction. The only downside is users still ultimately need to trust the web service developers not to be corrupt, which is a sticking point. Society isn't ready to trust stock and futures exchanges operating over Tor for example, because there would be too much room for games. You could launch clearnet services with OT integration, though, it's just that you couldn't do anything innovative without the SEC shutting you down.

Sidechains at its core solves the service operator trust issue, but it has new trust issues of its own doing. The basic idea of sidechains is, instead of creating Havelock.com, you bake Havelock.com into a blockchain, and then you would peg that new blockchain to Bitcoin's blockchain so that Bitcoiners can use your service without having to buy an altcoin. Compared to OT, it's quite frankly rocket science, which is a downside. In addition, sidechains don't share Bitcoin's security model, so they may actually offer less security than a traditional web service with OT integration.

51% attacking Bitcoin doesn't allow you to steal BTC. But with sidechains, from what I understand, 51% attacking _does_ allow you to steal BTC. [1]

As much as I want sidechains to work, I'm not convinced Bitcoin miners are altruistic, which is a hand-wavey assumption Blockstream makes about sidechain security. They think Bitcoin miners won't attack sidechains because the miners will know they make more money over the long term by being honest. We have heard this before about large mining pools in Bitcoin. We've been told a desire to maximize long term profits is the reason no Bitcoin mining pool would ever exceed 51% of the network, but GHash.io has proven this theory definitively false.

As such, I'm relegating sidechains to the same place in my heart as Open Transactions. I'm waiting to see both approaches launch before I'm convinced you don't need something like Counterparty to do a blockchain-based NASDAQ or Intrade. [2]

[1]: [https://pay.reddit.com/r/Bitcoin/comments/2k01du/peter_todd_...](https://pay.reddit.com/r/Bitcoin/comments/2k01du/peter_todd_on_twitter_the_sidechains_paper_is/clgpjpx)

[2]: [http://www.wired.com/2014/10/overstock-com-assembles- coders-...](http://www.wired.com/2014/10/overstock-com-assembles-coders-build- bitcoin-like-stock-market/)</comment>


Launch every day of the week - <AUTHOR> http://seancollins.biz/

<comment><AUTHOR> Please let me know if you have any feedback!</comment>