dexen

That's a whataboutist tangent, but let's entertain it for a while.

The copyright law is usually restrictive, in the form of "everything which is not explicitly allowed is forbidden", and some of the openings - like Fair Use - are somewhat contentious. Thus a specially crafted free license is used to make the work legally accessible & reusable in an unambiguous way in such legal environment.

A free license for software is generally used to unambiguously establish the legal status - that simplifies dealing, especially for organizations and professionals. It effectively increases ability to access and re-use the software [1].

A license & copyright information is used to convey authorship and guarantee certain author's rights, like the right to attribution. Some licenses (eg. copyleft) are also used to prevent certain misuses (eg. tivoization), again with aim of increasing availability of the software for access and re-use.

Conversely, releasing into public domain (which is a limited legal concept, not available in certain countries) runs with the risk of somebody else slapping a restrictive license on the code and making it unavailable via legal mechanisms.

Free licensing is not only about improving availability and protecting the author and the reuser, it's also about preventing subsequent yanking of the code via machinations by a 3rd party.

While those concerns are valid and need taking care of, pretty sure they aren't at the stake in the IA vs book authors discussion. They aren't mentioned in the OP either.

>In fact, people here on HN and other communities very much oppose people taking things without permission. I challenge you to demonstrate otherwise with your own repositories.

Ah yes, a challenge to prove a negative. I'll rise to it right after solving the halting problem :^)

While I'm somewhat ambiguous about this IA matter, the example you bring up is rather unconvincing on HN.

I, just like many other fellow users here, publish our code (both end product and tools) to public, and to organizational, Git repositories.

We have structured our work and our contracts with customers to get paid for the services rendered[1], not the number of zeroes & ones (nor files nor LoC nor other incidental artifacts). It's not only doable, it's also the arrangement closest to fair & morally right we have found so far.

--

[1] yes, including some upfront payments where circumstances warrant it

That won't protect you. When your employer is actively signalling and funding support for particular groups or political positions, failure to join in is taken as a political action, and you might get attacked by co-workers for being anti-group or anti-position.

>I'd agree, but de facto is not de jure.

In 2018 there was a decision of a district court[1], subsequently reaffirmed by the Courts of Appeal, that the President's twitter account is a "designated public forum". This was widely reported due to it's "Trump cannot block other users" aspect, but might have interesting bearing here.

--

[1] https://en.wikipedia.org/wiki/Knight_First_Amendment_Institu...

That's a far-fetched hypothesis, bordering on conspiratorial thinking.

A more mundane, realistic -and more common- scenario: due to mistakes made (as noted in OP: downtime, misplaced data files, APIs needlessly changed, etc.,) the responsibility was transferred to another team.

--

[1] https://demainstream.com/

On the one hand, we have matter of privacy - people presumably request the forecast for their present location, or their travel destination. This may be sensitive information, depending on personal circumstances.

On the other hand, we have usability - in the name of security, people got stopped from using a convenient feature. This seems pretty close to the trouble of planned obsolescence, and seems to be a somewhat common trend, of security running counter to usability and hackability (in the DIY sense).

I doubt the whole camera+lidar roof package is anywhere near close; best guess around 10kg (~22lb)

You got the causality dangerously backwards. That's not how policy works.

"The speed limit is commonly set at or below the 85th percentile operating speed (being the speed which no more than 15% of traffic exceeds),", as per [1].

Specifically, speed limits are not set by carefully measuring & modeling conditions on the road by direct application of science; there's no finely tuned measuring aparatus nor advanced math model. Instead we rely on drivers judgement aggregated over time, conditions, and locations. Granted, there are certain notable exceptions: bridges & tunnels where speed limit is also informed by structural constraints, and also fuel consumption reduction policy in cases like the 1973 speed limit.

And yes there are natural parallels to civil disobedience; in some cases limits got raised or lowered upon public pressure.

--

[1] https://en.wikipedia.org/wiki/Speed_limit#Maximum_speed_limi...

Wrong on two separate levels.

First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.

Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.

The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.

If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position.

Yes your page can easily look as if it got only updated with JS after doing a full load+render.

The technology is already in the browser; no need to approximate it with three layers of JS.

Or with session ID in URL. It's a valid mechanism - works reliably, is fast, and doesn't require special support in browsers. Remember the '?PHPSESSID=...' littered all over the early internet? Yeah that one.

Of course there are some caveats, which made cookies win in the end:

* it must be applied to every internal link in the website

* it's equivalent of a "session cookie" (no persistence after browser is closed)

* it's a privacy risk when sharing the URL via copy/paste

* it's subject to 'session fixation' attack (related to the previous caveat)

Presumably the last two could be fixed by an extra HTTP header or special in-browser handling of a designated parameter, similarly to how CORS got handled.

[1] robots https://www.smbc-comics.com/comic/2013-06-05

[2] philosophers https://www.smbc-comics.com/comic/p-bot

Even the good old Qi wireless charging standard does negotiations, tho those aren't secured by any means.

Wireless charging sounds like creating a bright, pulsating "soldiers be hiding here" beacon for any opposing force.

A simple & plausible scenario: a governmental agency requests Facebook conducts a broad surveillance sweep. Facebook resists for obvious reasons, goes to court. Somebody at the middle level of one talks to somebody at the middle level of the other, figure out what the agency really wants - a small, well specified chunk of data - which gets requested separately & promptly delivered. Having gotten enough data now, the agency lets the original, big case falter simply by limiting the efforts and expenditures.

That's not even conspiracy, that's just a bunch of people figuring out how to quickly get done with their mundane responsibilities. #BanalityOfEvil

Of course; a tiger keeps hidden and attacks humans from behind.

Jokes aside, your fable is excellent and I hope to use it in the future.

Other than that, I have no useful answer beyond re-iterating my earlier assertion: the media was always bad. Now we can see it better than before.

Perhaps the tiger was a red herring all along. There just might be a fat cat getting fatter in the city hall that we were too distracted to pay attention to.

Going by those excellent charts[1], there were two distinct "kinks" in intensity of change; around 2000 and around 2015.

>the internet

The best explainer I've seen thus far is that loading articles with keywords improves searchability and readership metrics. My far fetched hypothesis is that it is a side effect of the present form of search - dominated by one vertical that has strayed far, far away from the original Page Rank idea.

--

[1] use of progressive keywords in newspapers, a thread https://twitter.com/ZachG932/status/1133441085118853120

[1.1] more terms, NYT https://i.imgur.com/CZfsLsk.jpg

>I don't think there are any sources lately that you can trust 100%.

That is exactly backwards. The journalism never was truthful; instead it was full of lies by omission, manipulation to push a narrative, and plain mistakes made in the rush to be the first to publish.

What changed[1] is the seasoned staff is now largely gone and replaced with low-paid youth fresh off of the school. It's through the lacking experience and missing professionalism that the mask slips, and we now get to see how the sausage is made.

Paradoxically now that we get to see how bad it gets at times, the spotty trustworthiness becomes a known quantity, and so we can handle it better.

--

[1] aside of the amusing tools like "NewsDiffs" (https://twitter.com/newsdiffs), or https://archive.is/

Perhaps because it's laying out a mundane case, rather than making bombastic claims...

AI might be best put to use for finding loopholes. In formal specifications, in legal documents, in laws... you name it.

The required process change is reasonably straightforward; instead of presuming an answer given by AI is useful as a solution to the given problem, take it as an indicator of a loophole in problem specification and see if one can be closed up.

Don't be overly discouraged :-)

I have a reliable (if a bit ugly) implementation in under 3kb of sparse PHP OOP code. Yes it took a few hours to iron out the last kinks, and one extra refactor to free up a mistakenly bound variable. It might have helped that it was the first version I implemented, thus no need to match impedance of older interface.

On the plus side, the signing is designed as self-contained, and neither implementation nor API calls spill to too many parts of request handling.

>you have to read the doc a dozen times before you can successfully implement it

Very much so - it does require a small 'eureka' moment. It's hard to put your finger on what exactly makes it hard to get right the first time around. At the very least it is written from a somewhat peculiar viewpoint.

Fortunately the primitives used are common enough to be available in typical standard libraries.

Having said that, competition both puts some pressure to improve more, and also explores some alternative, possibly better, avenues. Historical example: Firefox was significantly better than IE 6 / 7 / 8, and yet ended up improving much more in the course of competing vis a vis Chrome.

All in all, a staunch-and-fair competitor is good to have.

>How would that even work? The adblocking process has full access to whatever's being passed through it, and therefore it can eavesdrop or tamper (eg. inject malicious js) with the contents.

A web browser is so much more than just the network traffic. Consider the mouse & keyboard input, the browsing history, the cache, the security credential store, the connection to display, GPU, USB and Bluetooth devices, microphones & cameras... the list goes on. This includes ability to read and write local files, start new processes, compile and run code. And then there are other HTTP user agents, like automatic software update tools.

Most of this functionality shouldn't be needed by, nor accessible to, an ad blocker.

Lastly, you could put much stricter resource usage limits (CPU time, operating memory) on an adblocking process than on a web browser, thwarting whole classes of resource exhausting attacks.

>only worse because it only works locally

You can apply varying levels of restricting any net traffic not passing through the adblock, up to and including dropping any such traffic. Ability to ad-filter HTTP traffic of an email client, RSS reader (i know, 2020) and similar user agents would be good.

With a bit more advanced setup, you could also completely cut off the adblock process from accessing any files or any other resources related to the browser, further nailing down security.

Sure, it is possible to have similar (or equivalent) setup for browser plugins, but it requires some special engineering done in the browser - and in that scenario no other apps benefit from the protection. Let's not forget there's many more crucial HTTP user agents than just the web browser.

Excellent. I'm glad to see uBlock Origin getting some much needed competition, and a good take on Chrome's adblocking downgrade.

>Transparent HTTP/HTTPS proxy for Windows, Linux and macOS.

Not so great. Getting HTTP/1 right is hard, getting SSL right is hard, integration is quite hard just as well. And then there's HTTP/2, and WebSockets and other protocols. Possible results of failure: connection reset, encryption downgrade attack, malicious script injection, credentials stealing, browsing history stealing, XSS, SSL spoofing, IDN homograph attack. Sadly Chrome seems to leave no better option at this point.

OTOH, in the longer run it makes sense for ad blockers & similar tools to be ran as a wholly separate process, offering one more layer of separation.

Back at my earlier workplace we used EAN-13s as product serial numbers. Generally in customer service we used the last 5 digits, with the leading ones being implied by product model.

The Russian T14 Armata[1] is a strong nod in that direction. The turret is unmanned and fully automatic; the crew of 3 is hosted in a well protected capsule in the front hull.

This ensures both low top weight & visibility, just as well as improved survivability for the crew.

--

[1] https://en.wikipedia.org/wiki/T-14_Armata