Forgot your password?
typodupeerror

Comment Re:Same as it ever was (Score 1) 176

BYD didn't so much chose to not build a factory here as they are blocked from doing so.

Last I heard, the trade policy was set to deter importing cars made in China into the United States. BYD having been blocked from setting up a factory on United States soil and hiring United States residents to produce cars for the United States market is news to me. The interview that Wikipedia cites states only that BYD isn't planning to build in the US or Mexico for the US market, not why that's the case. Searching DuckDuckGo for "is byd blocked from setting up factory in usa" didn't turn up relevant results either.

Comment Re:Same as it ever was (Score 1) 176

Get someone to install a decent charger at home: View it as part of the purchase price of the car, if one even needs it.

So to buy a car, you have to first buy a house, or at least buy out the rest of your lease in favor of somewhere to live whose parking could support a charger.

Find out the office doesn't have a single charger: One would think one would know this before they bought the car.

Consider the case of buying a car and then changing jobs. How practical is it to choose where to work based on whether the office has a charger?

Not to mention that a lot of ICE car drivers aren't rich enough to afford a new car, only a used car. And a lot of ICE car drivers live in the United States, where BYD has chosen not to build a factory, and have an ethical disagreement with the leadership of Tesla.

Comment Re:This is like (Score 2) 47

Yep. OnlyOffice wants their hosting money. They want control. They're the assholes.

Maybe that's true, but I'm not getting that from the summary. What I'm getting is:

  • OnlyOffice spent a decade developing their office code, distributing code that they authored under a modified AGPL license that requires attribution to be preserved.
  • EuroOffice removed the attribution.

If EuroOffice removed attribution requirements only on code that was created by someone else other than OnlyOffice, and did not use the code authored by OnlyOffice, then they're fine. But I think courts have already ruled that the AGPL term about being able to remove conflicting terms applies only to someone other than the author adding those terms, so if they used code authored by OnlyOffice, they may have a problem.

Comment Re:Likely doomed as a species (Score 2, Insightful) 69

Why did with gave the scientific illiterate access to computers? There should be basic physics questionnaire or something before being allowed to use any modern technology, so that we do not have to read politically motivated anti-science comments from uneducated people such as "These guys in 1958 are vastly more convincing than modern climatologists". I mean, even completely ignoring future issues, this nonsense hurts my brain.

Comment The article is about removable media (Score 1) 76

You are correct with respect to their internal storage.

However, say you want to interchange files among several computers using removable media, such as an SD card, USB flash drive, or USB hard drive. One is a Windows PC that prefers NTFS, another a Mac that prefers Apple's FS, and another a Linux PC that prefers ext4. What file system would you use on the drive?

Comment Fictional address (Score 1) 72

The octets of invalid information mark the address as fictional, as opposed to being the live address of a real machine. Telephone subscribers in several area codes started receiving prank phone calls after the 1982 release of "867-5309/Jenny", a song by the band Tommy Tutone containing a live numeric address on the US phone network. This led US TV show producers to start using the 555 (or KLondike 5) exchange, which was largely set aside for fictional use.

Comment Re:An unintended side effect.. (Score 1) 72

The difference is that if the customer is on IPv6, the customer is more likely to have a globally unique address. This means the customer is at least technically capable of forwarding an inbound port across a stateful firewall, provided the ISP doesn't deliberately interfere with port forwarding the way T-Mobile US (a wireless ISP using 5G NR) does with its home Internet service. The TV commercials don't mention that T-Mobile home Internet is an outbound-only service.

Comment Re:This is pretty well done (Score 2) 109

Second, when the EU says you can verify your age without revealing your identity, they seriously mean it. I worked on the ISO 18013-5 mobile driving license standard, and its protocol is the basis for the age verification scheme (18013-5 also supports privacy-preserving age verification).

The spec contradicts itself in various places, with sections saying that the app interacts with the attestation provider only once and that the attestation cannot be reissued, and other sections implying that the attestation gets reissued every three months and that the tokens are single-use.

It also isn't clear about whether they are actually using 18013-5 or are just requiring companies to implement a few tiny fragments of the spec.

I was left more confused after reading the spec than I was before.

Comment Re:Bridge for sale (Score 1) 109

Looks like I spoke too soon. The specification massively contradicts itself. 3.4.2 requires reissuance every three months, and requires that it issue 30 attestations at a time, and that they be single-use.

That part is architecturally correct, though allowing access to only 30 adult sites per three months is dubious. And if getting a new proof requires a new request at some point, then it becomes possible for the trusted list provider, conspiring with the proof of attestation provider, to cross-correlate the timing of requests and unmask a user with high probability.

And then, there's this:

3.4.1 Issuing of Proof of Age batches Since Proof of Age Attestations are designed for single use, the system must support the issuance of attestations in batches. It is recommended that each batch consist of thirty (30) attestations. Since the timestamps in the ValidityInfo structure of the mdoc encoding of a Proof of Age Attestation can provide linkability clues, the Attestation Provider should set these timestamps with a precision that limits the linkability information. For this reason the ISO/IEC 18013-5 recommendation should be followed, i.e., setting the hh, mm and ss information to the same value on each Proof of Age Attestation.

So you still have a value that is potentially usable for tracking across multiple websites. It's just a timestamp. I'm not sure if I'm reading what they're saying correctly. If they mean all 30 in a batch have the same value, this is a disaster. If they mean always set the value to 00:00:00 so you get only one day of precision, that's better than nothing, but when the request comes from an area with low population density, it is still potentially inadequate for anonymization.

I can't make heads or tails of this specification. It contradicts itself in too many places, and it buries you in minutia while lacking a clear overview. It's the kind of spec only a bureaucrat could love, because it is perfect for verifying compliance, but makes it nearly impossible to quickly verify that the spec makes sense. It lacks a section on threat models and how it addresses those threats, which is the first thing I'd expect to see.

At this point, I have no idea whether this protects privacy or not. And that's perhaps more disturbing.

Comment Re:Bridge for sale (Score 2) 109

I sure don't believe the "completely anonymous" part.

It is possible, in theory. But calling this "completely anonymous" is hopelessly naïve, IMO, unless I'm missing something *huge*.

Announcing that this is "technically complete" is laughable. I have not seen a single public white paper on the subject. We should have seen years of back and forth between academics, crypto experts, operational security experts, privacy experts, and other groups, as they all tear apart the design over and over again until it is refined into something that actually provides the claimed anonymity.

The lack of this public discourse leads me to the inevitable conclusion that it almost certainly provides the illusion of protecting privacy, while in fact massively violating it to a greater degree than ever before.

And sure enough, I started skimming the technical specification, skipped the whole first section, which was mostly justification, and almost immediately found a fatal flaw.

Unless I'm missing something, this is a show-stopper, and points to the entire architecture being fundamentally unusable:

2.2.3 Revocation and Re-Issuance

In its current form, the solution does not support revocation or re-issuance. Adding support for these features would introduce additional complexity, which could hinder the rapid adoption of the solution.

What this means is that a user gets a magic token that proves that the person is of a particular age, then submits that token to sites for verification. Here's a list of problems with that approach:

  • The same attestation is sent to every site. So the fingerprint of that certificate becomes the *ULTIMATE* tracking cookie. Every adult website will effectively know who you are. They won't know precisely who you are, but they will be able to correlate activity across sites, target ads to your specific behavior across multiple sites, etc.
  • It is impossible to regenerate that token, so once your privacy has been thoroughly raped and random websites are showing you adds for hardcore porn, you can never turn it off.
  • As soon as you pay for anything with any of those adult sites, your identity is now known, and can be correlated with your activity across all adult sites.

Using the words "privacy rape" to describe this technology is not nearly a strong enough statement, but it is the strongest phrasing I could come up with.

Protects anonymity, my ass.

About the only good thing that can be said about this is that because they didn't specify minimum requirements for storage protection, chances are it will get hacked in the first week, and a few adult users' attestations will show up on the dark web and will get used by a few million underage users' devices, making it useless as proof of age, and hopefully resulting in the folks who thought this approach was adequate quickly shutting it down.

Like I said, give us a public comment process, articles published in multiple reputable journals, etc. and in five to ten years, this will be ready. It's not ready. It's not close. It's not even in the right ballpark.

For this to be completely anonymous, it must not be possible for a government actor with control over infrastructure to perform timing attacks on anonymity, e.g. user requests auth token from government, government knows who that user is, government sees unencrypted DNS request to porn side ten seconds earlier, correlates the requests.

Doing this correctly is genuinely really, really hard. You need:

  • A different token sent to every site, with no common data that can correlate accesses across multiple sites.
  • No ability to correlate the timing of the user's request for proof and the timing of a user connecting to a website.
  • No ability to correlate the timing of the user's request for proof and the timing of a verification request from a website to the verifying authority.

This starts by the verification authorities outsourcing the verification to the "RP" (relying party). Public keys used to verify the signature. That way, the government entity doing verification does not have any record of verifications to correlate with requests.

This continues with the client queueing up a thousand or so pre-signed certs from the signing authority, and requesting replacement certs on a time-based schedule (once per day, with randomization of the replacement rate, with the client silently discarding excess certs so that you maintain a consistent pool size).

This is a starting point. I'm not saying that these things are sufficient, just that they are necessary.

Slashdot Top Deals

Live within your income, even if you have to borrow to do so. -- Josh Billings

Working...