niftich

This complaint is real cute, but the trite answer is that this is how things have worked for a long time. Awareness of it is spreads for a while whenever high-profile events receive media and blog coverage, and perhaps the exploitability of this has increased compared to several years ago when products that opened up various HTTP-accessible servers were less common (or secured by obscurity).

This isn't necessarily an excuse to not explore mitigations through consensus in future browser behavior -- after all, that process of loose but eventual consensus of incremental UX and airquote "security" improvements is how SOP and CORS and C-S-P came about [1] and the cookie saga evolves [2][3].

But consider that legitimate uses of cross-domain requests to localhost exist (e.g. an OAuth callback endpoint), while also keeping in mind that users from all walks of life are, perhaps unbeknownst to them, are managing LANs of computing devices running dozens of servers, often with modern encryption such that communications between the program and the remote server are becoming harder to intercept and oversee, and lack a comprehensive capability to monitor, analyze, blacklist, whitelist, or snipe traffic in a way that's not cumbersome or borderline user-hostile. Such is the world where we've arrived. Etching away on one or two widely deployed corners of it won't fix the overall landscape, even if it may significantly reduce the change of "drive-by" exploitation through websites accessed through commonly used browsers.

[1] https://news.ycombinator.com/item?id=12408328#12408680 [2] https://news.ycombinator.com/item?id=13689697#13691022 [3] https://news.ycombinator.com/item?id=19853090#19855518

It's a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity / actualization ladder. Once you look, you see this everywhere, and not just in IT but with any sort of design exercise or institutional process, any complex system that's full of Chesterton's fences, and people will either evolve to debate their rationale from a position of experience, or be selected (or self-selected) away into fresh environments where the novelty and discovery-until-discouragement can begin again.

It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre.

History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout.

A blockchain would work but is not necessary, and such a scheme would just pushes the storage and computational burden of the bookkeeping onto other users of the same chain. It still wouldn't help you if no provider were willing to honor your entitlement, which is what's going on here. You could achieve the same effect, and have a very similar set of failure modes, with digital signatures and emailing product keys or QR codes or whatnot into people's emails.

A few months ago, news broke that UltraViolet [1] would shut down. It was a meta-DRM scheme that, for all practical purposes, was equivalent to a mapping of 'Email Address' -> 'Set of Entitlements'. Various motion picture rightsholders and digital media-serving providers integrated with it, so your rights could be imported and exported into their central list and grow over time. Although the service cost money to run, its decommissioning and the aftermath of your entitlements is a question of political will, and not a question of any technical reality. Vudu is one of the very few providers through whom you can bridge your rights over to its competitor-turned-replacement, Disney's Movies Anywhere.

If there were the political will to do so, the damn hashmap of rights could've transferred directly, but it didn't. Altering the storage scheme would've altered the basic economics of UltraViolet's hosting, but it's not an armor against studio after studio withdrawing from issuing and honoring such rights, as it actually happened.

[1] https://en.wikipedia.org/wiki/UltraViolet_(system)

FWIW the iPod didn't really beat deep-pocket Sony's cassette Walkman or MiniDisc per se, it beat the uneven and dizzyingly wide field of onboard-storage digital audio players, from thumbdrive-looking sticks that only held a couple songs, to full-blown Creative and iRiver HDD players on which you could conceivably carry your entire collection, but whose device UX, song-copying computer-side UX, and resilience were bested by Apple. It also came at a time when portable CD players that could play a CD-R full of MP3s or WMAs were widely available, and were a popular incremental upgrade for those who were already used to burning their own CDs.

With suddenly dozens of ways to enjoy portable audio, Sony was hurt by the fall of the MiniDisc. Less so in the world of CD players, but in the the world of digital audio players, they were just another poorly-differentiated manufacturer. Songs were decoupled from their original hardcopy and became files one could manage on a computer, and the UX of moving these tracks onto portable playback devices was starting to matter.

Actors like Real, Microsoft, Apple, MusicMatch, and NullSoft were in this space, and their interests didn't necessarily align with the interests of audio player makers. Apple initially partnered with MusicMatch when the iPod launched to have a file management story on Windows, before they shipped iTunes.

The UX of cassettes was very useful for sharing and swapping music or speech, and for resuming where one left off. Because of the linear tape, the cassette's "playback cursor" was stateful and independent from whether the medium was read-only or not. Playback resumed at (nearly) the same spot as it was last stopped, even if moved to a different player. Successor formats didn't have this property.

Interestingly, Sony emulated the auto-resume feature in some Discman CD players, and later it became common in car CD players, but there was no way to maintain playback position after swapping players. Later, MP3 players maintained their own playback state, but getting tracks on or off the device's built-in or removable storage was with file-based interfaces that connected to computers.

This stateful cursor functionality is only returning these days with URLs to media-hosting sites that accept timecode parameters.

The 'Pink' of the phrase "Pink + Purple == Fuchsia" is a reference to Taligent's Pink, and 'Purple' appears [1] to be a reference to 'Project Purple', the effort at Apple that culminated in the release of the iPhone.

[1] https://spectrum.ieee.org/tech-talk/computing/software/a-mod...

In the Mule ecosystem, you use a drag-and-drop flow builder of canned components to build flows that typically ingest events, do something to them, and possibly write someplace. Almost anywhere, you can also inject your custom code.

You deploy these flows in their engine, where they're kept alive. You can self-host the engine, but they also offer it in their cloud.

Then you can choose to frontend it with a HTTP API that you build in their builder, and choose to put it in your organization's private store, or the public store for others to use. There's management dashboards too.

There's hundreds of other products or product combinations that could be described in the same sort of vague language, but MuleSoft ships and supports a particular environment and a particular collection of tools that does it pretty well.

Ultimately, the goal of all of these is the reduction of the effort around every other piece besides the parts that are custom to your unique circumstances.

The following videos from BTCInstrumentation demonstrate this succinctly.

[1] Synchronizing AC generators -- Part 1 (introduction and sync lamps)

[2] Synchronizing AC generators -- Part 2 (strobe light view)

[3] Synchronizing AC generators -- Part 3 (sync and unsync)

[4] Synchronizing AC generators -- Part 4 (phase deviation)

The first video explains all the concepts and shows a sync, but the later videos bring additional conditions and detail.

[1] https://www.youtube.com/watch?v=RGPCIypib5Q [2] https://www.youtube.com/watch?v=sFohkp2aaU4 [3] https://www.youtube.com/watch?v=GRk_qJxaxh8 [4] https://www.youtube.com/watch?v=RT1ySBc-Bls

Good catch, the links in my previous post are not accurate. The correct links for [2][3][4] are:

[2] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2... [3] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2... [4] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2...

The 500 kV lines form the backbone of Argentina's power grid. The drastic fall in power flows shows the massive shedding of load and generating capacity, as presumably plants disconnected from the grid for safety. One can step through the next few hours to see how generation was restarted.

CAMMESA administers the Argentinian electricity market, and they have data on demand [1] and grid flows. Compare the graph of flows on the 500 kV lines from 2019-06-16T07:00 local [2] to one hour later at 08:00 local [3]. For reference, see the prior day too, at 2019-06-15T08:00 local [4].

[1] http://portalweb.cammesa.com/Pages/ADemandas.aspx [2] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2... [3] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2... [4] http://www.cammesa.com/uflujpot.nsf/FlujoW?OpenAgent&Flujo%2...

I don't understand what you're asking in your prior post when you say whether you could "pay someone else". Your carrier makes the agreements about with which others your phone could roam (and with who it can't), and your phone tries among the ones it can, but clearly not among the ones it can't. You continue to pay your bill to your home network. And yes, there are often restrictions with how much you can roam.

That being said, TMo and Sprint are making TMo sites advertise an old Sprint network identifier to Sprint phones, so that Sprint phones don't even think of it as roaming [1]. This is in effect for data only right now, not VoLTE.

[1] https://www.reddit.com/r/Sprint/comments/96lai0/clearwire_b2...

Your phone using a different-besides-your-home network is called 'roaming' and it's not uncommon. For this to happen, your phone needs to know which networks it should try to authenticate against.

A while back, Sprint and T-Mobile announced they'd launch a roaming agreement for LTE that would last for 4 years, and that would be honored even if their merger doesn't go through. According to some people [1] this went into effect in Summer 2018.

[1] https://www.reddit.com/r/Sprint/comments/9548zg/tmobile_data...

Boost is an MVNO that runs off of Sprint's networks today, but the sale of Boost is a commitment [1][2] T-Mobile made as part of their efforts to get the FCC to approve their merger with Sprint, with some very generous terms.

Remember that with LTE, there's no longer a divide between the GSM camp and the CDMA camp; it's the same LTE, although each carrier operates on various bands.

With the merger, and as phone firmwares are updated and incompatible handsets are cycled out, the combined LTE network is compelling. With Boost's current target market of urban youth, the fact most current Boost phones only support the Sprint's CDMA2000 3G and not T-Mobile's GSM-flavored 3G is less of an unfortunate fit than with a more general MVNO.

[1] https://newtmobile.com/wp-content/uploads/2019/05/FCC-Filing... [2] https://web.archive.org/web/*/https://newtmobile.com/wp-cont...

There are large parts of Nevada that could be 'reclaimed' (in the Bureau of Reclamation sense) without too much effort -- just a couple of well-placed dams, berms, and canals. Large parts of the state are in closed basins, from which the water just evaporates anyway, so using it first within the basin would make sense. Extensive projects like this were once the norm, but fell out of favor as the 1970s transitioned into the 1980s, feeling the impact of the environmentalist movement, the opposition of Jimmy Carter, and the failure of the Teton Dam.

Some big urban areas already need to rely on interbasin transfers for their water supply: LA, NYC, San Diego, Mexico City, SLC, Denver. Tunnels for water would actually be a sensible and 'boring' pivot for the Boring Company.

The airline industry embraced point-to-point routing in part because it reduces their costs on inelastic infrastructure on the ground, and allows them to tailor their schedule around demand at the two endpoints rather than on maintaining a network. They pay-as-they-use for airport gates and lessened their spending on hubs.

Fixed-guideway transport infrastructure (trains, busways) and dedicated structures (tunnels, bridges, airports, etc) come with high capex that must be borne by the builder. One advantage of road-based transport over rail-based transport is that the road is already there and will (often) already be built and expanded by the government just to allow private vehicles to come and go -- it's multipurpose -- while any other mode of transport requires this infrastructure to be purpose-built and maintained for the transport mode itself. That costs.

Cryptome is a classic source on topics like this [1]. As for what a landing station looks from the inside, Ars Technica had an excellent series [2] on submarine cables in 2016.

[1] http://cryptome.org/eyeball/cable/cable-eyeball.htm [2] https://arstechnica.com/information-technology/2016/05/how-t...

On the HN thread on Troy's last post about this, I said [1]:

"Big sites can get by with DV because people trust big sites by fiat, just by mental associations they already have to a URL. There's no benefit to Facebook having an EV cert, because literally everyone who'd want to visit Facebook knows Facebook's URL. User error about entering credentials on the wrong site -- accidentally due to typosquatting, or through leading such as phishing -- is better mitigated in other ways: multi-factor authentication (especially unproxiable such as U2F); not by making the high-profile site pay thousands of dollars for a text string in green, when there's users who fall victim to phishing from bizarre domains too."

Ultimately, this is a bad example to show that EV is pointless. The biggest benefit of EV is as a flawed signal of legitimacy [1] for sites whose URLs aren't widely known and get a fair amount of first-time visitors: web presence for real-life service businesses, specialized payment portals accessed through redirects, and the like.

This is because people's mental model of the trust that EV confers is broken. People typically care about whether the site they arrived at was the one they were intending to visit, which the computer can't possibly know without additional input, but EV has attained a role of serving as a flawed signal of such, because the browser bar said something that doesn't look alarmingly different.

EV formalizes the vetting between legal entity and domain name, so it translates okay to entities that are firmly anchored in meatspace. But all of this chaining is trust in people's heads is done by names and strings, and experiments like stripe.ian.sh prove [2] why it's fallible. Nonetheless, EV effectively allows one extra indirection between (1) the name of the business as people refer and recognize it, and (2) the domain name that's likely correct, than DV does -- and some operators and some visitors benefit from this indirection, when the URL doesn't roll off the tongue.

[1] https://news.ycombinator.com/item?id=18010961#18011914 [2] https://news.ycombinator.com/item?id=15904513#15909273

You as the client try to GET /my-receipts/20190512-1 from Fancy Receipt Scanning Service, and content-negotiate with an Accept header to "text/plain" or "image/gif" (e.g. to get a plain copy or a scan). There's no agreed-upon way of communicating links in plain text or GIF, so Fancy Receipt Scanning Service can't serve you a GIF scan of your receipt that links to a product page for every item you bought.

If you accepted "text/html", it could have served HTML that embedded these links within the response body, but you didn't accept "text/html".

It can choose to send links as headers, if it still wishes to communicate links.

The answer is in the part that says "it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats".

In HTTP, URLs locate a 'resource'. Then you and the server do content negotiation, implicit and/or explicit, to select a 'resource representation'. Think of these as different formats for the same conceptual thing identified by the URL. Some formats like HTML can support hypermedia that can have embedded links. Some, like 'text/plain' or 'image/gif', can't.

Link headers allow links from the current resource to other resources to be communicated even if the chosen representation can't communicate links in its body.

The state of the art for web APIs, for better or for worse, is ones where you send and receive 'untyped' JSON (served as application/json), endpoint URLs have version numbers in them, and POST GET PUT DELETE mostly map to CRUD. Some extra flourish is sprinkled on top, not to improve functionality, but to chase the mood of the times or to make your code-generator (like Swagger/OpenAPI) work.

The article appears to start with a very similar assumption, and proposes use of URLs within resource representations instead of bare foreign-key IDs. I don't think the article can be accused of systematic ignorance of 'standard practices' or failing to perform "cursory bibliographical research"; stuff like HAL and JSON-LD are far from standard practice.

This series may benefit from a quick comparison of API design schools, comparing ways to express the a similar domain model in various styles, but it also seems to be trying not to get bogged down and dispense some prescriptive advice (instead of, say, overwhelm and despair).

FWIW, RFC 8288 was preceded [1] by RFC 5988, and RFC 5988 [2] says in its section '1. Introduction':

"A means of indicating the relationships between resources on the Web, as well as indicating the type of those relationships, has been available for some time in HTML [W3C.REC-html401-19991224], and more recently in Atom [RFC4287]. These mechanisms, although conceptually similar, are separately specified. However, links between resources need not be format specific; it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats."

"To this end, this document defines a framework for typed links that isn't specific to a particular serialisation or application. It does so by redefining the link relation registry established by Atom to have a broader domain, and adding to it the relations that are defined by HTML."

[1] https://tools.ietf.org/html/rfc8288 [2] https://tools.ietf.org/html/rfc5988

The article's recommendations don't achieve HATEOAS, because even though the foreign-key IDs are replaced with URLs, they're not actually links because they don't specify an explicit relationship.

Instead, the relationship between the response document and the URL's target is implicit, probably guessed from the naming of the key or maybe noted in the response document's definition.

The point of HATEOAS is that a client who understands the meaning of certain link relations (aka "rels"), such as ones in the IANA registry [1], can interact with these referred-to resources using the Standard Interface (of GET, POST, PUT, etc).

Only in the section where the article talks about ways to express links in JSON do link relations appear.

[1] https://www.iana.org/assignments/link-relations/link-relatio...

The US patent applications in the above list resolve to the following five:

https://patents.google.com/patent/US20160234144A1/ This one seems to be about specifying a Mimetype paramater that tries to describe the cost of image transformations requested in the target file, so that clients who know they can't perform those transformations can pick a different file.

https://patents.google.com/patent/US20160232939A1/ Seems to be about image sequences and specifying such a concept with coherent metadata in the container.

https://patents.google.com/patent/US20150193494A1/ This seems to talk about the myriad ways that ISOBMFF can assert metadata about data elements within, but there aren't always good ways to ensure the metadata points back to a specific data element. This talks about ways of figuring out whether such loosely-floating metadata in the container is still valid for data items; they also propose using checksums to figure out if the data items changed.

https://patents.google.com/patent/US20180146225A1/ This is a fancy restatement of P-frames for still images, leaving open the possibility that later frames also 'enhance' the first image in various ways e.g. upscale resolution and others.

https://patents.google.com/patent/US20140314148A1/ This defines signalling to allow putting all the I-frames at the start, and all the P-frames at the end.

Your statement that "Nokia has licensed their HEIF patents under royalty-free terms" is not true, because the license-in-question's [1] grant is "to, use, run, modify (in a way that still complies with the Specification), and copy the Software within the Licensed Field."

Licensed Field is defined to be: "(...) the non-commercial purposes of evaluation, testing and academic research in each non-commercial case to use, run, modify (in a way that still complies with the Specification) and copy the Software to (a) generate, using one or more encoded pictures as inputs, a file complying with the Specification and including the one or more encoded pictures that were given as inputs; and/or (b) read a file complying with the Specification, resulting into one or more encoded pictures included in the file as outputs."

It is pretty clear from this reading that their patent grant is for non-commercial evaluation, testing and academic research only.

[1] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

MPEG tells [1] rightsholders to file Patent Statement and Licensing Declarations to ISO/IEC. ISO/IEC maintains [6] a spreadsheet of received documents and the relevant standards that they concern. Examining that spreadsheet, I found four declarations that concerned the HEIF standard, all four submitted by Nokia Technologies Oy. These documents [2][3][4][5] provide references to patents approved or pending.

The patent or patent application numbers, in order of their appearance in these documents:

AU 2014255577, CA 2909566, CN 201480034418.2, EP 14785343.6, IN 6931/CHENP/2015, KR 2015-7032685, RU 2015146961, US 14/254120, US 14/617266, WO PCT/FI2016/050063, US 14/618650, WO PCT/FI2016/050064, GB 1418114.3, WO PCT/FI2015/050671, WO PCT/FI2014/050582, US 14/583332, PCT/FI2014/051052, PCT PCT/FI2016/050381, US 15/578288

This is where I'd start.

Sources:

[1] https://mpeg.chiariglione.org/patents [2] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [3] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [4] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [5] https://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770... [6] https://www.iso.org/iso-standards-and-patents.html

Given the current direction of the industry, the most likely candidate for this in the not-so-distant future is HEIF, which has support for an image-sequence [1].

HEIF is an ISOBMFF (aka Quicktime/MP4 container)-derived container format for images, image sequences, and transformations. Its most visible use right now is Apple Live Photos, but various use-cases exist [2]. OS and application support is increasing.

Work is ongoing on defining AV1-encoded frames as a payload in HEIF [3].

[1] https://nokiatech.github.io/heif/technical.html [2] https://nokiatech.github.io/heif/examples.html [2] https://aomediacodec.github.io/av1-avif/#av1-image-sequence

Chrome didn't support it until 2017 [1], with the release of Chrome 59 [2].

[1] https://news.ycombinator.com/item?id=13871809 [2] https://www.chromestatus.com/feature/6691520493125632

Spring is a collection of frameworks that impose their own structure and control flow so that one can focus on the parts of the design that are unique to one's situation. The Go language and standard library and the Go community have a very different mindset on delegation, structure, and control flow, so frameworks in the style of Spring or Rails aren't as widely used or popular.

Go has also long based their packaging around the idea that locations of source code and the identity of a package are strongly bound. This meant that random github-hosted libraries were easy to pull in, but it also meant that people did pull in all sorts of random github-hosted libraries. In Java programming, it's more common to use a modest number of high-quality libraries and frameworks (which may, in fairness, have a lot of transitive dependencies), but not as common as it is in Go or Node to use a large number of direct dependencies sourced from all over the web.

AV1 is an open and free format, but if people really wanted to replace GIFs they could've done it with H.264 or VP9 or VP8.

Notwithstanding any issues about video codec support in browsers, GIFs will continue to have value until browser-vendors, spec-writers, and webmasters accidentally or deliberately coalesce around a sane ruleset for embedded motion picture completely devoid of audio.

Today, browser-makers have concerns about which videos to autoplay, webmasters' tools for specifying "muted" videos have been unreliable. GIFs completely sidestep that conversation, because GIFs cannot contain audio, and will always autoplay.

This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6].

The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in.

This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF.

[1] https://www.microsoft.com/en-us/research/publication/atlanti... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=795346 [3] https://github.com/mozmark/SameDomain-cookies/blob/master/sa... [4] http://homakov.blogspot.com/2013/02/rethinking-cookies-origi... [5] https://tools.ietf.org/html/draft-west-first-party-cookies-0... [6] https://news.ycombinator.com/item?id=13689697#13691022