dhx

il y a 6 heuresdiscuss

To add:

The request has not yet been published by GitHub to https://github.com/github/gov-takedowns/tree/master/India/20...

Also not mentioned in the project's GitHub repository yet per https://github.com/search?q=repo%3Apermissionlesstech%2Fbitc...

dhx

il y a 7 heuresdiscuss

AWS's 3 data centres in me-south-1 are:

BAH53 (Manama): https://www.openstreetmap.org/way/1492345589

  An adjoining substation to BAH53 had one of it's two main buildings damaged/destroyed about 2026-07-16 per https://soaratlas.com/maps/asia-damage-to-data-center-power-substation-bahrain-jul-16th-2026-142024

  Then about 2026-07-22 BAH53 itself was damaged/destroyed per https://soaratlas.com/maps/asia-damage-to-amazon-web-services-bahrain-jul-22nd-2026-142112

  Possibly the least defended of the three sites as there is no air/missile defence battery in between this site and Iran.

BAH54 (Zallaq): https://www.openstreetmap.org/way/1359931661

  No media reports about this data centre being attacked previously. Possibly the safest of the three as there are at least two (probably three) air/missile defence batteries in between this site and Iran.

BAH55 (Hamala): https://www.openstreetmap.org/way/956069872

  Apparently the Batelco DC.1 data centre adjoining (and apparently critical to) BAH55 was damaged/destroyed about 2026-04-01 per https://www.bbc.com/news/articles/cgk28nj0lrjo _or_ the adjoining substation to these two facilities was damaged/destroyed -- news articles are hard to follow as to what exactly might have been damaged and the extent of damage caused.

  Middle ground for defence with one or two (maybe three) air/missile defence batteries between this site and Iran, depending on where drones/missiles are launched from.

If these data centres are rebuilt, you'd maybe expect them to be rebuilt in new locations behind existing _permanent_ (and seemingly quite expensive) air/missile defence batteries in Bahrain (https://www.openstreetmap.org/way/1492281507 and https://www.openstreetmap.org/way/1492953902). Based on the permanency of those air/missile defence batteries it doesn't look like the government of Bahrain are expecting things to get safer for data centre hosting in Bahrain any time soon.

dhx

il y a 5 joursdiscuss

See [1] for April 2024 Clickhouse Github activity analysis of the xz backdoor.

I haven't seen anyone write up a proper analysis that includes consideration of:

- GitHub activity (e.g. all API actions on GitHub side including replying to comments) _and_ mailing list activity _and_ other public facing activity all considered together.

- Complexity of public actions e.g. was there a queue of code changes that would have taken 20 hours effort to put together that were all committed at once? Were there any long streaks of high activity where it might reveal how many people were involved?

- Latency of public actions e.g. if an issue was raised by some random person, how long did it take for the attacker to respond, and later resolve/commit a patch? Similar to the complexity of public actions, it might reveal how many people were involved by estimation of the time needed for an experienced developer to fix an issue vs. actual time taken, both in terms of level of effort and duration.

- International dispersement of a team in different timezones with some core hours for collaboration, review and public facing activity.

- Public holidays, country/region-specific work habits, etc--e.g. consideration of "summer holiday" periods or similar common holiday periods, consideration of unusual days of no/low activity versus snow days, power outages, etc which might have been experienced by the attacker.

Distribution of actions from Github indicates the attacker used a 6 day work week excluding Sunday, and almost all activity conducted between UTC 12:00-16:00. Within these 6 days, activity was uneven at 0.5, 1, 1, 1, 1, 0.5 effort per day. There are low activity periods too that line up with summer solstice (southern hemisphere) or winter solstice (northern hemisphere).

There are interesting patterns in the data not yet publicly analysed (I think?) that seemingly would reveal the true location of attackers, particularly because attacker actions are anchored to uncontrollable events such as a known-good contributor (such as Linux distro maintainer) raising a Github issue against a repository and the attacker replying an hour later. For such events with low latency of reply, it'd be well worth considering when a reply was made quickly, and when it wasn't, across a few years of data points.

[1] https://news.ycombinator.com/item?id=39905375

dhx

il y a 10 joursdiscuss

Title is not correct. Microsoft didn't patch a lot of this, they're reporting patches for dependencies that other people patched and Microsoft are inheriting.

For example, Mariner (now branded Azure Linux) is a Microsoft-supported Linux distribution. So in this list of 570 vulnerabilities, Microsoft have reported 100 vulnerabilities inherited from all sorts of open source software projects included in their Azure Linux distribution. The OpenSSH vulnerabilities are described in better detail at https://www.openssh.org/releasenotes.html where it implies 2 vulnerabilities were detected with Swival Security Scanner (using LLMs) and another 6 by other researchers/companies (using undisclosed methods).

As an example of one of the OpenSSH vulnerabilites CVE-2026-59996 which is attributed to Swival Security Scanner, Swival have published the output of their automated vulnerability detection report at https://github.com/Swival/security-audits/blob/main/openssh/...

dhx

il y a 16 joursdiscuss

If demographics are a problem for chipmaking in China, then it's good to compare against key chipmaking countries.

To compare, 2024 (UN) fertility rates (highest-lowest):[1]

  US:     1.62
  Japan:  1.23
  China:  1.02
  ROC:    0.86
  ROK:    0.75 (where an increase to 0.8 in 2025 was cause for celebration, as is a predicted increase to 0.85 by mid 2026)[2]

Alternatively (and perhaps accounting for migration etc), UN 2024 forecasts population differences in these countries between 2024-2050 as:[3]

  US:    +10%
  Japan: -16%
  China:  -8%
  ROC:    -6%
  ROK:   -12%

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

[2] https://www.chosun.com/english/national-en/2026/01/24/IVHGRT...

[3] https://en.wikipedia.org/wiki/List_of_countries_by_past_and_...

dhx

il y a 17 joursdiscuss

My key point you are avoiding with personal attacks is:

If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)?

--

The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203.

The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448.

[1] https://www.iana.org/assignments/tls-parameters/tls-paramete...

[2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2

[3] https://www.rfc-editor.org/info/rfc7748/#section-5

dhx

il y a 17 joursdiscuss

It looks like recent Tenda hardware/firmware is encrypted per below examples, making it harder to audit.

binwalk US_AC10V6.0si_V16.03.62.09_multi_TDE01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x436999A39FECA649

binwalk US_BE12ProV1.0mt_V16.03.66.23_TD01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x81235B7D4130B6AB

The third attempt I tried was unencrypted, and possibly reveals the problem exists on another model this CVE doesn't list as affected:

binwalk US_W18EV2_kf_V16.01.0.20\(4766\)_HighPower\ \(1\).bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  64            0x40            uImage header, header size: 64 bytes, header CRC: 0x95335734, created: 2026-06-16 09:09:35, image size: 2159135 bytes, Data Address: 0x80100000, Entry Point: 0x805F41C0, data CRC: 0x5ABEDB00, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Tenda Linux-4.14.90"
  128           0x80            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6947248 bytes
  2159263       0x20F29F        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 8971644 bytes, 847 inodes, blocksize: 1048576 bytes, created: 2026-06-16 08:53:20

Inside is /squashfs-root/webroot_ro/default_ac.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)
  sys.guest.username=guest
  sys.guest.password=Z3Vlc3Q=  (ed: base64 decoded: guest)

And /squashfs-root/webroot_ro/default_router.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)

From what I can see quickly (I haven't looked hard), "sys.rzadmin.password" is only referenced from the login() function of /bin/httpd in the context of retrieving a value. This value is retrieved and compared before the error message "login err: password is wrong." is emitted. I can't find any other reference to code in any part of the firmware that may allow a user to change the default value of "sys.rzadmin.password".

Also for fun there is a function imsd_upload_log_v1 in /bin/imsd that collects SSIDs, MACs, IP addresses, sys.admin.username, sys.rzadmin.username, timezone, and another function imsd_remote_pwd_get in /bin/imsd that retrieves sys.admin.password. Related library /lib/lubucapi.so also looks like a fun binary to inspect more closely as it contains a command set that seemingly allows either cloud management of Tenda routers and/or remote debugging, and possibly is why imsd_remote_pwd_get exists in /bin/imsd

dhx

il y a 17 joursdiscuss

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1]

But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance.

The draft MLKEM IKEv2 RFC[2] has the same problem.

Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive:

Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret."

To include side channel resistance, for example:

Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values."

Some further examples of RFCs which do care about specifying side channel resistance:

RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3]

RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4]

(this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance)

[1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4

[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...

[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3

[4] https://www.rfc-editor.org/info/rfc9941/#section-4

dhx

il y a 17 joursdiscuss

The draft considers FIPS 203 to be normative. Therefore FIPS 203 forms part of this draft. You can't implement this draft without first implementing FIPS 203.

FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.

[1] https://news.ycombinator.com/item?id=48811887

dhx

il y a 17 joursdiscuss

To point out some positive examples of what RFCs should include:

RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1]

RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2]

By contrast, this proposed RFC for MLKEM provides a single encouragement:

"[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3]

It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC.

When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself:

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4]

The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation.

The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon?

The key missing section of this RFC is perhaps a restriction on its application similar to:

"This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol."

Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls.

[1] https://datatracker.ietf.org/doc/html/rfc5288#section-3

[2] https://datatracker.ietf.org/doc/html/rfc7748#section-5

[3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

dhx

il y a 18 joursdiscuss

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

dhx

il y a 18 joursdiscuss

Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.

For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.

For example:

FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]

NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]

RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]

A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].

A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...

dhx

il y a 18 joursdiscuss

To extend on this good point--

DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.

For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?

See [1] and [2] for answers. Summary: Technology is not ready.

[1] https://dl.acm.org/doi/10.1145/3569420

[2] https://dl.acm.org/doi/10.1145/3779208.3785290

dhx

il y a 19 joursdiscuss

At least in my experience for large retail chains or restaurant chains, hours on their websites are very accurate. I think where Google might benefit from calling to verify hours is, for example, where they've scraped https://schema.org/openingHours from the web page for an independent store, but the website has used an invalid/incorrect format, and some manual human check or clean-up is necessary, but this work would be too time consuming for each of 100,000's of independent stores which exist.

There are cases where a brand might have broken opening hours information such as "Mo- Tu - We 09 00 -4 p m". For alltheplaces.xyz scrapers, a human is often able to make sense of the situation and fix the problem through a few lines of extra code. Contacting the business to get the hours confirmed would only be necessary in very rare cases.

Where it would perhaps make the _most_ sense to contact a business to confirm opening hours is:

1. Ahead of public holidays to confirm planned temporary changes to opening hours. Many brands don't bother to update hours on their websites for such temporary changes, or at least don't list those hours until the week prior, which is usually too late for OSM, ATP, offline maps, etc which would ideally want to know these changes to hours up to a year in advance.

2. To confirm actual dates of permanent store/restaurant closures. Many brands in liquidation tend to fire the website developers (or can't pay them to work) and leave an outdated website online until the final shop or restaurant is closed. Commonly it's only some "CLOSING DOWN SALE LAST DAYS EXTENDED TO FRIDAY" post on social media that informs visitors accurately.

dhx

il y a 19 joursdiscuss

See alltheplaces.xyz for continuously updated straight-from-the-primary-source opening hours of chains of shops and restaurants, public facilities such as libraries, etc. This is probably as accurate as it gets AND you have the confidence of knowing exactly where the data came from (down to the URL) and when it was last checked.

Some OSM contributors go brand-by-brand/operator-by-operator in making sure OSM features have the most up-to-date opening hours added to them from matched ATP features. As such, OSM may be fairly accurate for chains too.

For a standalone shop or restaurant the opening hours situation is usually still better with Google Maps rather than OSM. There aren't enough OSM contributors who care enough to check and maintain opening hours for every shop, restaurant, fuel station, etc.

dhx

il y a 19 joursdiscuss

1. This is largely country-dependent with some governments being quite adamant that address data should be in the public domain, and some governments doing the opposite and selling address databases to private companies for some quick cash, where private companies then sell address lookups for some absurd per-lookup price for the next few decades. Most of the world though is probably just not rich enough to compile, publish and accurately maintain a national address database.

OpenAddresses is perhaps the gold standard for open source address data compilation from government datasets. Note for the future that alltheplaces.xyz (project I contribute to) is looking like it may eventually perform the automatic address data download/extraction/compilation that OpenAddresses currently performs. This has the benefit that in backwards countries, alltheplaces.xyz also obtains some addresses through other means--such as advertised location of international restaurant chains. And quite often, being within +/- 100 address numbers on a road is good enough for navigation. Google Maps obviously crawls addresses from all over the Internet AND has quite a high tolerance for errors, hence will perhaps always seem more complete than OSM.

2. Some further ideas for open source mapping applications trying to determine real time traffic situations:

2a. Use GTFS/GTFS-RT feeds for bus networks to detect real time delays but also to compare planned bus route schedules for different times of the day (different traffic conditions) where buses share the road with the public. There's already a few maps out there that overlay nearby GTFS-RT feeds for the city of interest and usefully provide a visual indication of how well public transport vehicles are currently moving.

2b. alltheplaces.xyz extracts public traffic camera feeds which could be presented to users when they plan/commence a journey as an indication of what lies ahead on the route.

dhx

il y a 21 joursdiscuss

I change that slightly to "Good luck getting an explosive payload."

The difficulty for an attacker is the explosive payload, not the delivery mechanism. If it were easy for an attacker to get an explosive payload there would be car bombs going off every day as an easier delivery mechanism than use of quadcopters.

Thankfully it seems to be relatively easy to prevent people from making explosives, at least outside of warzones in countries with strict border control, because random people don't have a valid reason to buy industrial chemicals or equipment, and especially not chemicals identified as precursors for making explosive compounds. And for plants where such industrial chemicals are legitimately necessary to use, inputs and outputs can be measured, and detection taggants[1] used, and many other security measures, to prevent accidental or deliberate loss of control over such chemicals.

[1] https://en.wikipedia.org/wiki/Taggant#Explosive_taggants

dhx

le mois dernierdiscuss

"Fix this code" should ideally solve entire vulnerability classes, not just spot fix buffer overflows one by one. Thus it may be possible to design an LLM which can solve entire vulnerability classes and remain useful to users, but refuses to reason about specific buffer overflow vulnerabilities or specific race conditions, etc.

For example, "fix this code" on an ageing monolithic C codebase that accepts media files as input and outputs them visually to a display server could:

1. Recreate the software using a modular and loosely coupled architecture rather than monolithic and tightly coupled software architecture. For example, command line argument parser is a separate process, file format parser is a separate process and display server output is a separate process. If new features are added in the future (such as filters for manipulating output) then the architecture supports such additions with ease.

2. Use operating system sandboxing features to restrict what each modular component of the software architecture is permitted to do. Now that the parsers are separate processes, it's easy to pass an open file handle to the file format parser and only permit the process to read the file handle (not write to the file, not open any other file, not read the system clock, not open a new network socket, etc). The worst case impact of a parser bug is now significantly reduced.

3. Convert at least critical components to "safe" programming languages (Rust, Ada, SPARK, etc) which can be used to remove entire classes of bugs--read/write out of bounds, division by zero, numeric overflows, etc. For cryptography code--use a formal mathematical proof language. With a modular and loosely coupled architecture, different programming languages can be used depending on the use case--for example, assembly for video decoding where performance matters most and sandboxing can provide the security guarantee, Rust for implementing multi-threaded servers where race conditions must be avoided and Python for low-criticality user-adjustable code/plugins where ease of use and maintainability is most important.

4. Ensure software components are reproducible during their build.

5. ...etc

However, a prompt of "Are there any buffer overflow bugs in this codebase?" or "Fix the integer overflow vulnerability in add_numbers(x, y)" would be rejected. In the later case, telling the LLM to fix some specific bug in each of function1 through function9999 would force an LLM to reveal whether it thinks a bug exists or not. Responses of "Silly human, that bug doesn't exist in function596" or "Good find human, I've fixed that bug in function596 for you" allows a human to quickly narrow down where the LLM thinks a bug worthy of manual human detection can be found.

dhx

le mois dernierdiscuss

I like that it's non-serious and contains jokes throughout the user interfaces. Reminds me a little of Airline Tycoon's non-serious/joking nature, and Theme Hospital if going further back in time. It makes the game fun rather than a boring simulator some city planner would use for work.

dhx

le mois dernierdiscuss

Contributor for an open source scraper -- https://alltheplaces.xyz/ -- which currently has about 4700 scrapers extracting 40-someting million points of interest.

The project aims to scrape location data and other general information about shops (main use case), postal addresses, restaurants, schools, weather stations, marine buoys, traffic cameras, street trees, whatever someone may decide is worthwhile to add to OpenStreetMap, or use as location data in other projects.

There's a decent community of contributors keeping the scrapers maintained and further expanding the number of points of interest which are extracted.

The opportunity I'd like to work more on (time permitting) is the data scraped by this project I feel is heavily underutilised in other open source/community projects. For example, there's a great opportunity to generate a location map once a week of current locations of international restaurant chains, and upload to Wikimedia Commons where every language Wikipedia would gain a high quality infographic of current locations of a chain's restaurants, etc. As an additional example, time-series data from ATP could be used to update a graph hosted on Wikimedia Commons each week where the graph plots the rise and fall of retail or restaurant chains.

Submissions

Gonjeshke Darand claims cyberattack against Bank Sepah (Iran)

Xz: Can you spot the single character that disabled Linux landlock?

Atlassian says encryption-busting laws threaten jobs

Australian parliament passes encryption laws unamended

[2017] Apple denies existence of Supermicro Malware-infected firmare

Single-decryption EM-based attack reveals private keys from Android phones [pdf]

Cost to store all US phonecalls made in a year in cloud storage

Personality traits that correlate with job engagement

DECENT: Decentralized architecture for enforcing privacy in social networks

STor: Social Network based Anonymous Communication in Tor

comments