Hacker News new | past | comments | ask | show | jobs | submit | mo3gut's comments login

Quite right. In fact, those statisticians in the posted article are surely mistaken. We know that using tricks to hide things is sound science.

http://www.realclimate.org/index.php/archives/2009/11/the-cr... http://www.realclimate.org/index.php/archives/2009/11/the-cr...

Since it was sound science in 2009, why would it not be now?


If the "spies" really did "steal" (i.e. copy) an engine design then it seems like a good thing for the world in general. They have helped spread useful knowledge.

Sure, it's bad for the would-be rent-seekers whose plans have been threatened. Why should anyone else care about them?

Thanks China, and keep up the good work!


By "rent-seekers" you mean organizations that have spent billions of dollars to research and prove the tech? As the current top comment represents, if company A spends billions of dollars creating a technology, then company B steals it, company B can sell it for less because they don't have to pay the R&D overhead. Company A falters or dies. The company that actually knew how to advance the field and create new tech suffered. Is that good for the world?

The way it is supposed to work is, company A researches a tech, company b also researches a tech, the best one wins (or more likely they split the market), the competition induces more advances, and eventually the old tech becomes cheap (or free) and widely available as it is supplanted by even newer, better tech.

And yea I know our patent system is broken, etc. But I don't understand how you can have a general principle that the people who created something don't have the right to benefit off of it.


It's amusing that this is hosted by a spyware vendor.


One not on the list is Template::Toolkit. Perhaps it's considered too old-school.

TT is stable, available virtually everywhere and (like perl itself) is well documented and works without fuss.


> assumptions about who is responsible for data security.

The chief assumption appears to be "anyone but the browser vendors". Let us consult the article:

  BeEF
  This, to me, was the most impactful demo
Quite the endorsement. So what's BeEF's angle?

"...examines exploitability within the context of the one open door: the web browser."

There could hardly be a clearer expression of contempt for the browser vendors' offerings. But remember, the "open door" is nothing to do with them, it's all your fault for not serving via HTTPS.

Welcome to Clown World.


Eh, there are two execution contexts here.

1. The web browser executing the injected data stream it receives from the remote computer.

2. Your brain interpreting 'non-executable' instructions as received from your browser.

Browser security has nothing to do with me going to 'xyz.com', which is the trusted website for xyz company, and being fed a MiTM telling me to go to a bad phone number for support.


> Your browser then sends Referer: ...

While I don't doubt dataskydd's good intentions, their advice about referrers is a sign that we live in Clown World.

Yes, your browser's tendency to provide a referrer might well give away information you would prefer it didn't. Unfortunately for you, the browser vendors have chosen to provide browsers that do that.

In a parallel universe it would be obvious that this is a problem (among many) for the browser vendors to address. In Clown World, you are supposed to rely on each and every site providing a special response header.


Just a historical note that I found interesting - it was in fact obvious (to some) already 22 years ago. From RFC 1945 (HTTP/1.0), May 1996, 10.13 Referer [sic]:

"Note: Because the source of a link may be private information or may reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information."

(https://tools.ietf.org/html/rfc1945#section-10.13)

This recommendation was not followed in any meaningful way, but Referrer Policy (https://www.w3.org/TR/referrer-policy/), which supports a whole bunch of different policies and is very easy to implement (and now widely supported), at least makes things slightly better.


It's not an either/or thing at all. The browsers are slowly trying to tighten policies on Referer, but it's a process because there are still some webpages that unfortunately rely on it being sent. (You can force it off, at least in Firefox, if you want to.) The point of this site header is so that sites that don't need Referer to be set can explicitly tell your browser that, protecting you from snooping third parties.


> this is a problem (among many) for the browser vendors to address

I'm guessing the reason others are downvoting you is that Referer Policy is exactly that: it's the attempt of modern browsers to address this problem (a problem that yes, they did create, but the fact they're supporting Referer Policy at all at least shows that the problem was created out of incompetence rather than malice).


Yet they have numerous defenders on this site, all the more peculiar considering those companies' collusion to avoid paying market rates to developers. The preference to be a sharecropper on their plantations is evidently strong, for no very clear reason.

And let us not forget the EU's efforts to support incumbents and deter new entrants, with their complex, vague and punitive regulations. These also receive much approval here; perhaps a fruitful field for study by some enterprising psychologists!


I'd love to see some sources on your claim that they are colluding to avoid paying market rates to developers.




> To me it felt rogue since it had been generated without me knowing nor expecting it

That's understandable. Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS.

The general opinion here seems to be in favour of this practice. So we can look forward to a future where your domain may publish on the web only with the permission of a CA.


> Fastmail do the same, i.e. acquiring certs for their customers' domains without asking or informing, with a view to moving them to HTTPS.

Not sure about the the down-voters, but I was just about to post a 'citation needed' comment dismissing this as crazy talk, and I was surprised to discover it is actually true: https://www.fastmail.com/help/files/secure-website.html


"your data belongs to you"

Not the SSL certificate for your domain, which Fastmail will acquire with or without your prior knowledge or consent, and to which you have no access or control.

https://www.fastmail.com/help/files/secure-website.html


That's for their Files product (which you can use to create a website): https://www.fastmail.com/help/files/website.html

They can't request a certificate unless you already pointed your domain to their servers. So if you're already doing that for HTTP, requesting an ssl cert so they can enable HTTPS on it is a perfectly valid request... especially when browsers are starting to mark all HTTP sites as insecure.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: