vaduz

It might not be intentional to break the site experience for adblock users - but there is a number of sites that has implemented link tracking in a way that overrides the normal click (though sometimes not keypress) events, to let the tracking code do its thing. If the tracking code is blocked or fails to load, that means a lot of actions break.

Best part? Trying to convince the operators of such sites that users they cannot see in their "analytics solution" are worth fixing their site for is not exactly a straightfoward job - from their narrow view, these users simply do not exist, because the tracking does not show them!

> allowlist/denylist

As of now, it is called whitelist/blacklist in PiHole [0]. Maybe it will change, maybe it will not, but there is already a place to fight that battle [1] and it is not HN.

[0] https://docs.pi-hole.net/guides/misc/whitelist-blacklist/

[1] https://github.com/pi-hole/AdminLTE/issues/1448

Whilst I agree - and fervently hope we won't have to live in such a world - I thought the same about the API copyrightability and that one is not exactly going the reasonable way at the moment.

H&K has an US trademark consisting of just "MP5" in relation to a ton of things (though not video games!) so they could at least try make a case out of it not being purely nominative use and tie AB in court, if they wished. It would be PR suicide, but still, not the most stupid thing they have done.

Isn't it just to double-plus-ensure that no one "accidentally" uses a name that ActivisionBlizzard did not license from the appropriate gun manufacturer?

I.e. It has little to do with profanity but a lot to prevent someone from making screnshot of a loadout with a gun that looks like MP5, is named by them as "MP5 whatever" and behaves like an MP5 in some type of legal action?

Excluding sole traders and cooperatives (and sometimes even including those, as the easiest way to lose friends is said to be to go into business together), it is entirely natural for the company and coworkers not to trust each other, not fully, as the goals and incentives of the company are not the same as goals and incentives of the employees. Your goal isn't likely to be to subordinate your life entirely to what the company wants, in a cult-like manner, with no regard for any other priorities like family, friends or personal growth - thus at the very least the kernel of mistrust always remains.

Some companies just manage to mask it better or tone it down to a level that if felt to be acceptable.

It's not so much that it is more aligned with profitability per se, but the fact that each modification you put in the part of the device controlling the radio also needs said approval before being used to transmit - and FCC has been tightening the enforcement of that. It has been on HN before [0]...

Usual caveats about Part 15 vs Part 97 use apply.

[0] https://news.ycombinator.com/item?id=11267443

Source available, at best, not open source. Licence is missing in both the code and in the terms page [0] unless I am going blind.

Edit: if I am going blind, I am not the only one [1]

[0] https://www.mozilla.org/en-US/about/legal/terms/firefox-rela... [1] https://github.com/mozilla/fx-private-relay/issues/773

> I presume you're meaning the HAN that the meter uses to update the in home display. As far as I'm aware this is securely encrypted. Whether it'll stand the test of time who knows (let's face it WEP and friends certainly didn't), but the same logic could be applied to the WiFi network your router is creating.

Yup, I do mean the HAN - and the way CAD including IHD connect to it. It may be based on ZigBee, but it modifies the protocol to add its own authorisation and encryption prototypes. They may have sound basis as of today but given the precedent (GSM/UMTS encryption, WEP, WPA, but also Infineon cryptographic corprocessor failures), the custom modifications to ZigBee and a couple of other deviations from usual practices I would consider it almost a certainty that within the lifetime of the device the protocol will be broken or bypassed. The question is how and when, not if.

Let me put it this way: I would be pleasantly surprised if it is otherwise, as that would be the exception, not the rule.

> Difference being that the data going over the HAN is likely to be a constant stream of values meaning it doesn't leak much information unless you can decrypt it. Someone able to passively observe that local network can almost certainly observe your WiFi transmissions, which will be much more variable - little to no activity when you aren't home, and lots of activity when you're streaming a movie.

Most of the equipment I have is wired (optical or copper), including supposedly mobile devices ([0]) and the ones that aren't are not a good indicator of presence (roughly constant data stream). It's a different story if one was to bring an IMSI catcher, of course - but there is only so much you can do and still participate in the modern world.

As a side note: I admit I may be biased as the meter location would preclude any IHD from being in range of HAN (5 reinforced concrete slabs away for electric, worse for gas), has problems with GSM connectivity for the same reasons and has dubious physical security against anyone who posseses a high tech tool known as "screwdriver" or "knife". The fallback procedure that UK suppliers have for this situation is "read the meter like a dumb meter" [sic!] until the supposed "alternative HAN solution" is in place. I know it puts me in the 3.5% minority of households, but still it rankles.

[0] This is normally where I go on a rant about flagship Pixel USB-C powered phones being unable to charge and use network adapter at the same time due to incomplete implementation on the phone side - one or the other. Older micro-usb models could do both as long USB-OTG was supported. iOS devices have no such issue, but they have other ones.

> What uses are you talking about?

> As far as I understand it suppliers are generally more than happy for you to use more of their electrons and don't particularly care what you use them for.

In the UK the law differentiates "domestic customers" using services for domestic purpose (this part is important, commercial use is is excluded!) and, "non-domestic" which includes all others. Domestic customers get to have a fuel price cap and lower climate charge levy thanks to that (though caveats apply, as it does not include "green deals" and fixed terms) but "non-domestic" users do not.

Of course you are right: the suppliers would indeed be more than happy to suply you as much of their electrons as you could obtain - at the business rates, not domestic, ideally at one where caps don't apply.

Take this little innocous line from the British Gas (Centrica) standard rate T&Cs:

    Supply and supplying: The gas or electricity (or both) we provide, or what we do to provide them. The supply is for you to use entirely or mainly for domestic purposes

There is a reason for it - a significant enough jump in energy use (say, if you want to charge an EV or put up a multi-GPU bitcoin miner) does trigger an investigation. EV users get a to select a preferential rate [1], suspected commercial users are asked to move to business rates (or show why that shouldn't be the case), any detected pot growers get referred to the appropriate police force. The energy company does care - at least so you can pay it more.

> 'Smart meters'

I agree that the move to more accurate/higher resolution measurement would make it possible to offer pricing that is more reflective of "true cost" - Economy 7 is well known to skew incentives, especially as more and more energy is used outside of traditional "day" hours (and with more and more solar powr in the mix, the overgeneration during the day hours) - but I would not be so optimistic that the consumers are going to be the primary beneficiaries of the change when the dust settles, they never are.

As for privacy, well, there is one substantial additional difference: your bandwidth and internet usage patterns generally have to be monitored by your ISP or internet services you visit, whereas a SMETS2 meter will create a nice new 2.4 Ghz network (and 868 Mhz, if/when it is available), so sooner or later it will be readable by a local attacker, if it isn't already. This is a device that is supposed to last as long as 20 years (though SMETS1 proved this might be a bit optimistic...).

[0] https://www.britishgas.co.uk/GetAQuote/tariff-information/ta... [1] https://www.britishgas.co.uk/GetAQuote/tariff-information/ta...

As long as the profit from operating the mining during high prices is higher than the cost of electricity at high demand times, it is economically rational to continue mining and grow demand to use the "excess" capacity that is provided in the grid.

In China it in particular it is seen as an easy way to convert coal to money, as one of the other commenters already linked [1] (which is also economically responsible, given the looming deadlines due to international agreements, but also disastrous to the climate at large).

Also, not to put too fine a point at it, neither Chinese nor US bitcoin miner server farms (mines?) have been found to be using particularly clean energy sources [0].

[0] https://digiconomist.net/bitcoin-energy-consumption/ [1] https://news.ycombinator.com/item?id=25881601

> > The OS should define a stable format for the OS to install, update and uninstall these files

> Like .deb and .rpm?

It's ironic that the common complaint about these two formats (especially .deb [0]!) is that they are too stable and rigid...

[0] https://lwn.net/Articles/789449/

> I would be very scared if the electrical utility company started looking at what i'm using the electrons for, and start disallowing certain types of uses for their electrons.

The energy companies already do disallow certain types of use for "their electrons" (check your contract, seriously - domestic users are forbidden from certain uses) and with the advent of accurate monitoring thanks to 'smart meters' are able to enforce that much more easily.

It's a nice post, but it is a shame that the author does not mention certain current controversy [0] where Bitcoin Core has crumpled like a wet paper bag under a thread of lawsuit by one Craig Steven Wright - one that he played a key role in [1].

The PR to revert that change is still open and locked [2] so I can only imagine what kind of direct messages he would be receiving - I doubt many of them would be what one would consider 'nice'. Not to mention any of it when stepping back seems a little incredulous.

[0] https://news.ycombinator.com/item?id=25858901

[1] https://github.com/bitcoin-core/bitcoincore.org/pull/740

[2] https://github.com/bitcoin-core/bitcoincore.org/pull/744

The cosmonauts (Russian segment) already tried the tape [0] - it helped, somewhat, but did not fix the problem. Definitely not as advertised...

[0] https://www.spacedaily.com/reports/Air_leak_rate_at_Russias_...

It completes a cycle of heating and cooling every 90 minutes as it orbits. The temperature differential between sunlit/shaded is quite large, so even though it certainly does not heat to +120C / cool down to -100 C as there is just not enough time, it would still put some stress on it.

It enables you to use a token that is portable and removable, which TPM2 chips are not. This has an advantage that it can be carried and secured separately, even if the device has to go into insecure storage like a hotel safe. You need to trust your FIDO2/PKCS11 device to be secure, though.

Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not.

It's all about trade-offs and trust.

That's current view on things, which has shifted quite a bit over the decades.

Pre-ICANN, back in in 1994 when Postel wrote RFC 1591 [0], there were only 5 domains used for global use (.com, .net, .org, .edu, .int), two special US-only domains (.gov, .mil) and the rest were ccTLDs. InterNic has been the primary registry these days, and it also operated the gTLDs of .com, .net, .edu directly, so it had commercial interest for the country-code delegations to stay local - this perceived conflict was one of the reasons why ICANN was eventually formed to take over the general oversight, and the first topic it had to tackle - before even being properly funded! - was the emergence of some countries that did sell their ccTLDs to other parties, especially as WIPO had some words to say in 'concern' over the bidding war around .tv and insisted that ccTLDs that operate as "open" should apply the same global rules as gTLDs [1] and some purchasers in the simlar sales proved "not to have local community support" and/or "not operated [ccTLD] in public interest" [2]

Even after the ICANN was formed, in the transition period the some of the MOU documents ccTLD registrar sent to ICANN used to contain a phrase which was clearly copied from an earlier era (phrase bears a little differences in spelling, but always using something like "meet the needs of the Local Internet Community"):

   [ccTLD manager] supports the concept of industry self regulation in the internet and therefore is also supportive of ICANN as the organization that performs the IANA function and consequently assures that this concept can work for benefit of all Internet stakeholders. At the same time to preserve this concept we believe that the policy and structure of the [ccTLD], *as any ccTLD, should be operated at a local level, to meet the needs of the Local Internet Community* within the framework of the relevant local laws. 

Check out e.g. UK exchange of letters from 2006 [3] for an example.

That being said - all of the above is only a bit of historical interest, as by now it is accepted that it is ok to operate ccTLD which accepts registrations from anywhere should your country wish it, as long as global rules are adhered to (to prevent stuff like "cocacola.cx") and there has been some clarification on the policies to make custom gTLDs a possibility.

[0] https://tools.ietf.org/html/rfc1591

[1] https://www.wipo.int/amc/en/processes/process1/report/finalr...

[2] https://archive.icann.org/en/cctlds/gac-statements-concernin...

[3] https://www.icann.org/en/about/agreements/cctlds/uk/nominet-...

> Tuvalu uses that domain as a significant source of income (Tuvalu is really really small) it is quite likely those domains are legally bought

Whilst true, it depends on a circular argument that the domain name registrant has a significant business presence in Tuvalu by virtue of paying for the domain, thus being entitled to a regional registration in the country in the first place (you could substitute Tuvalu by Tokelau and a bunch of others which make selling the domain to non-local entities, see it nicely visualized here [0]).

It used to really raise some hackles at ICANN and InterNic back in the day, but nowadays, after the gTLD floodgates have been opened - no one really cares anymore about the old regional rules.

[0] https://s3-eu-west-1.amazonaws.com/nominet-prod/wp-content/u...

> [..] take the ideas into modern times with things like a “Camp Auschwitz - Staff” sweater

This one sadly becomes quite ironically hilarious when you realise that a significant portion of the "staff" was made out units of prisoners themselves... In other words, anyone who wears a sweater like that has no damn clue what he is talking about.

> Actually, they are explicitly specified as ASCII

They are not, only new headers added after RFC 7320 are ASCII, pre-existing ones may contain high-bit characters which implementations compliant with 7230 version of HTTP/1.1 SHOULD not parse. They stopped short from making it a MUST so that applications compliant with RFC 2616 (where they were to be treated as ISO-8859-1!) was allowed. Or, more simply, they stopped themselves from making RFC 7230 describe new, incompatible HTTP/1.2.

https://tools.ietf.org/html/rfc7230#section-3.2.4

RFC 2616 OCTETs are defined as "<any 8-bit sequence of data>" quote unquote, nothing is said about their value beign opaque.

      TEXT           = <any OCTET except CTLs,
                        but including LWS>

IETF rewrote the productions not to use TEXT, but stopped short from banning the old behaviour.

So, for instance, where 2616 states: Reason-Phrase = <TEXT, excluding CR, LF> And 7230 has: reason-phrase = ( HTAB / SP / VCHAR / obs-text )

It is making sure that any application that conforms to 2616 still conforms to 7230 by not making it illegal (MUST) to parse obs-text... Just something you SHOULD not not do. They are simply making it so any new header added is defined as SP / VCHAR only (quoted, possibly).

There are sequences in ISO-8859-1 that will cause UTF8 application to balk if they are read without conversion - sometimes in a part that is well away from the input itself.

A common example "órny", part of a number of Polish place and personal names. ISO 8859-1 (and -2, and others) form would be F3 72 6E 79. UTF-8 treats F3 as a start of a 4 byte sequence where each subsequent character is in 80 - BF range (as specified in RFC 3629):

   UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                 %xF4 %x80-8F 2( UTF8-tail )
   UTF8-tail   = %x80-BF

This nicely causes an exception in both Java and Python, for instance, if they were to do what Go does here - and there is nothing anyone from adding an X- header to the request or response to try just that.

RFC 7230 makes it a point not to make it a MUST as that would make unknown number of existing applications non-compliant with HTTP/1.1-as-redefined. They are free to treat the incoming headers as ISO-8859-1 8bit instead of dropping to 7bit US-ASCII.

The reasoning on this is a bit circular: it was "used by nobody" because Google did not use it, because it had a static pin in both Chromium-based browsers and in Mozilla [0], resulting in high success rate in tests (they note it in their blog post that very high sucess rate is reported if static pins are on, but very low if they are ignored). There is also the problem that MS and Apple never bothered to implement it.

They had a chance to go forward and implement HPKP protocol in parallel with CT, they didn't. They had a chance to go with other proposals - e.g. checking the CAA records (a proposal they themselves have made in the deprecation post, especially as CA certs are also well-known and pinned), they didn't. They chose an option that works best for Google (and by extension: Facebook, Dropbox, etc), but not so much for everyone else.

This means is there is no way to spot a mis-issued certificate before it has been used - and you need to trust that the specific CA that issues it both adheres to transparency (pinky promise!) and obeys CAA (also, pinky promise - LetsEncrypt got in hot water when it didn't). That is: unless you are Google or Dropbox or Twitter - then your browser will actually save you from connecting to any counterfeit site, as that is what was important for Google.

End result? Privacy is enhanced if you are lucky enough to be on the list of statically pinned sites (see my parent comment, and see the Mozilla version as well), everyone else only gets more transparency, but not stronger privacy.

[0] https://hg.mozilla.org/mozilla-central/file/tip/security/man...

> So you're opposed to TLS strengthening measures like certificate transparency? Because i think its pretty good for privacy.

Considering that the cost of getting CT was the removal of RFC 7469 HTTP-based PKP "dynamic pins" (aka HPKP), I am not sure if there was a net benefit to privacy - without hate or love for Google.

I can't fail to notice that intent to removal was to also remove "static pins" (i.e. pins harcoded into the browser) after CT requirement for all certificates was implemented [0], Chrome started checking CT for new certificates [1] and CA Forum has limited the maximum validity of certificates issued to 39 months (2016) -> 825 days (2018) -> 398 days (2020) [2] (which means pretty much all certs from 2017 would have been reissued by now!), yet static pins for certain "favoured" organisations remain in the Chromium code [3].

That list of favoured orgs? Google, Tor project, Twitter, Dropbox, Facebook, Spideroak, Yahoo and Swehack.

CT is great for transparency and tracking rogue certs - but privacy could have used a stronger model than current blind trust in the CAs (and only acting afterwards if the trust proves misplaced).

[0] https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr...

[1] https://chromium.googlesource.com/chromium/src/+/master/net/...

[2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

[3] https://raw.githubusercontent.com/chromium/chromium/master/n...

Not quite accurate - Google is not the only party in this. Apple, Mozilla, Microsoft and Google formed their own group (WHATWG) that effectively took over the development of a number of standards - HTML and DOM included [0] - and follow and implement those, with W3 ratifying them ex post facto (or not, who cares?).

Google definitely plays a big role in this, but the others should not be left off the hook.

[0] https://spec.whatwg.org/

For many of the basic standards including HTML, WHATWG has already taken over in relevance (thanks, in no small part, on the strong desire by W3C to actually have two interoperable implementations).

WHATWG is a cooperation between Apple, Google, Mozilla, Microsoft as far as control goes.

In this context, Cloudflare is the Subscriber:

1.6.1 Definitions

Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request.

Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.

Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties.

Sure, Cloudflare certainly can request in writing from the CA to revoke the certificate - but in this case the problem was that they did not, right? Your best bet would be to email DigiCert directly under BR 4.9.2 (Who can requst revocation) at revoke@digicert.com [0], citing termination of the contract between you as the Domain Name Registrant and the Subscriber (i.e. 4.9.1.1 pt 4 as mentioned in the parent comment).

[0] https://problemreport.digicert.com/

> > To this they I still can't wrap my head around how can data on an Android phone be considered secure without requiring a long password at boot. Veracrypt style.

> it is considered secure only by Google. Android has DOS style security: an app which has access to storage has access to all your files.

That's true for most full-disk or file-based encryption systems, including VeraCrypt mentioned by GP - as soon as you unlock the given storage, any application that has read access to your storage has access to all your files.

They have only recently (2007) been reintroduced there by importing them from the Poland - Blean Woods have used that as a model for their own import.