Computing desk
< March 20	<< Feb \| March \| Apr >>	March 22 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 21

How do I wrap text around images without putting them in boxes?

maybe even give a bit of space between the image and text as I tried with an image of a white rectangle.

~~https://fictionandfictionalsettingswiki.miraheze.org/wiki/User:DMBFFF~~ (NSFW)

I've spent a fair amount of time trying to get something from b:Editing Wikitext, Wikipedia:Extended image syntax, and meta:Help:Images and other uploaded files, but they don't seem to be helping—but then I'm bit of an illiterate when it comes to Wikitext, HTML, and this mysterious "CSS."

MS WORD is simple. I suppose with a little effort I could learn to do it in OfficeLibre; but wikitext? I'm a bit at my wits end.

I need a rest.

Thanks in advance to any who could help.

DMBFFF (talk) 07:05, 21 March 2020 (UTC)[reply]

I know it's the weekend, but please don't invite people to click random links when they go to unnecesary nudity, or at least warn them first. Andy Dingley (talk) 12:24, 21 March 2020 (UTC)[reply]

Oh yeah, my first link goes to a page that has a near thumb-sized pic of a naked woman on a bar stool drinking what looks like a glass of wine—though it could be grape juice. Many of the links on that page lead back to Wikipedia and the like. My apologies to anyone currently in an office with co-workers or bosses breathing down their necks who risk being fired and/or were traumatized by the porno: maybe if it was a pic of two clothed women punching each other out it'd be more acceptable and SFW. :-/

I guess I'll have to spend another few hours trying to figure it out in my own pathetic amateurish way. Who knows, I might succeed—though it'd doubtful any time soon. Thanks for the finger-wagging—we aren't getting enough of that these days. May we all live well. Have a nice weekend y'all. DMBFFF (talk) 13:56, 21 March 2020 (UTC)[reply]

If anyone's breathing dwn anyone's neck, they'll probably be arrested for not self-isolating. ——SN 54129 14:02, 21 March 2020 (UTC)[reply]

Okay, let's try it this way. Here's an edit of mine in the Wikipedia:Sandbox—and no, there's no nudity, so there shouldn't be any fallen monocles, dropped teacups, or fainting spells. DMBFFF (talk) 17:44, 21 March 2020 (UTC)[reply]

("do I simply have it wrapped around an image that's ~~not~~ next to another image," that is. DMBFFF (talk) 17:50, 21 March 2020 (UTC))[reply]

Temporary measure: I uploaded the same pic but with a white space. It should work for a while. DMBFFF (talk) 01:25, 24 March 2020 (UTC)[reply]

Defending against a replay attack on a garage door opener

Especially in upscale neighborhoods where cars are valuable, a garage door is an important line of defense. In practice, how do wireless garage door openers defend against a replay attack? My thinking is that one could apply a cipher to the current time with a secret key as a way of authentication, but this seems more complex than what seems to fit in my system.--Jasper Deng (talk) 12:22, 21 March 2020 (UTC)[reply]

The simplest solution would be a challenge-response-protocol. After the initial signal, the door transmits a random token to the opener. The opener encrypts it with the shared secret key, and transmits back the result. The door opens if the result matches its own result. The door needs to ensure that tokens are not reused frequently - either by keeping a blacklist, or, more likely, by picking them from a sufficiently large space (256 bits should be pretty good enough ;-). --Stephan Schulz (talk) 12:29, 21 March 2020 (UTC)[reply]

In practice, they don't. They are extremely crude.

Most serious work on this is being done for cars. But even there, even for high-end cars, their security is pretty negligible. We're at a situation now where it's hard to start an engine (the immobilisers are good, they have a strong short-range connection to a device within the key), but very easy to open almost any high-end car, with no knowledge and a gadget bought online (my village has had a couple of plagues of this, where every car on a street has been opened in a night). As some makers move to 'keyless' systems (you only need to bring the key near the car to start it) then even the engine immobilisers have lost their defences.

There's plenty out there on the 'net on all of these: attacks and defences. But in terms of current product quality, they're pretty awful. Replay attacks for one are defeating most. A stronger system is some sort of public key system, where there's a non-transmitted secret in the key, a corresponding one in the lock, and there's a method to stop the same challenge-response being used twice. This can be either a one-time pad (challenges used can't be re-used). Or else it's a real challenge-response system, needing birectional comms, where the lock sends a challenge to the key (could just be a random number as a salt) which the key then encrypts and returns.

This is all solvable, but current commercial offerings for this are weak. Andy Dingley (talk) 12:37, 21 March 2020 (UTC)[reply]

About 20 years ago (sounds like things aren't much better) my opener for the garage door failed (this opened a communal garage under our building), so I had to go to the security company to pay like $30 for a replacement. They didn't take the old one off me, so I took it apart. It was literally a 8-gang DIP switch, a shift register, an oscillator, and some rudimentary RF circuitry. So all it did was, when the button was pushed, continually strobe out a (square?) wave corresponding to the settings of the DIP switch. I think the oscillator was about 50 Hz, so it could "play" the whole pattern a few times a second (I dunno if they was some kind of guard-period surrounding that). It would have been utterly trivial to build a device which could generate all 256 patterns and brute force the trivial keyspace in a minute or two. Add a decent directional antenna, that could be done at a considerable distance (perhaps 100m) and, fitted inside a car, without anything that would visibly arouse suspicion. It was, at best, what Bruce Schneier calls "kid sister cryptography". -- Finlay McWalter··–·Talk 15:34, 21 March 2020 (UTC)[reply]

There is some slightly old discussion about VW Group automotive systems here [1] if anyone is interested. Nil Einne (talk) 09:01, 22 March 2020 (UTC)[reply]

@Jasper Deng: That time-based protocol you describe (where there is RF in only one direction) is pretty much how Time-based One-time Password algorithm works. -- Finlay McWalter··–·Talk 15:37, 21 March 2020 (UTC)[reply]

It's a slightly tricky problem. They don't want to use challenge-response because that compplicates the hardware (have to put a receiver in the remote). They don't want to use TOTP because if you change the remote battery, it loses track of the time and has to be re-sync'd to the car somehow. Rolling codes are the usual approach, but they tend to be simplistic and spoofable. 2601:648:8202:96B0:386A:A40C:EBB1:ACC0 (talk) 18:05, 21 March 2020 (UTC)[reply]

It doesn't help when you are away, but when you are at home, you can lock the garage door opener. Then, it will not respond to a remote, so a replay will not work. I am currently working on a contract with Chamberlain/Nest to include better security. It is propietary, but time to market was at 19 months before covid19 pretty much stopped everything. (I paused to check the following before replying) Right now, Chamberlain has state of door broadcast to smart-home systems. So, you can get an alert or see from an app if your door is open or closed. You can lock it. You can unlock it. So, a replay attack would fail if you went through the trouble of locking the door when you left because it wouldn't listen to a remote. A feature I like is posilock. If it senses the door is being forced open, it pops out the hard locks to make it nearly impossible to open the door without physically ripping the door apart. 97.82.165.112 (talk) 14:53, 23 March 2020 (UTC)[reply]

A book on parallel computing.

Here is a link to Amazon advertising for a book on parallel computer architecture. There are a few terms/comcepts there which I don't understand but need to. I've never seen them before. (1) invasive computing. (2) invasive language constructs (3) Invasive hardware. (4) hybrid application mapping (5) exclusive usage of resources. I would appreciate if someone in the know will explain those concepts to me. Thanks AboutFace 22 (talk) 15:59, 21 March 2020 (UTC)[reply]

"invasive computing" gets lots of search hits; [2] looks promising for explaining what it is. It seems to be a term the authors have invented to describe fine grained dynamic allocation of computing units the way programs now dynamically allocate memory. 2601:648:8202:96B0:386A:A40C:EBB1:ACC0 (talk) 16:10, 21 March 2020 (UTC)[reply]

Invasive computing is a technique for super-parallel (thousands of cores) computing in Germany! So far everything I've seen about it has been German. I was supposed to be at a meeting about it some time this Summer, but thanks to brexit I'm no longer European enough to be trusted with German data, so I've lost that consultancy gig. 8-(

I think this is the canon paper on it: J. Teich, A. Weichslgartner, B. Oechslein and W. Schröder-Preikschat, "Invasive computing - Concepts and overheads," (2012) Proc. Forum on Specification and Design Languages, Vienna, 2012, pp. 217-224

But this: "Invasive Computing—An Overview" J ̈urgen Teich, J ̈org Henkel, Andreas Herkersdorf, Doris Schmitt-Landsiedel,Wolfgang Schr ̈oder-Preikschat and Gregor Snelting is a decent overview by the same author, and others.

The idea is that it's a new resource-management paradigm (sorry!) and model for efficiently allocating lots of fungible computing resources to problems. That much isn't new, but invasive computing is a new and better way to manage this. It uses notions of resource-aware programming, which is an old military idea from the '80s, when projects like Nimrod AEW were failing because they couldn't get enough computer resources to process radar signals and imagery on an aircraft. (In those days it was a question of annotating which parts of a single-threaded or few-threaded program were speed critical or non-interruptible.)

The problem is to run a program in an environment with thousands of small processors, which it has to share with other processes. In the interesting cases, the program processing load is dynamic and unpredictable, so we require a means to change the allocation of processors between processes. This must be self-adaptive (it works stuff out on the fly, it isn't controlled externally) and it must cope with behaviours such as unpredictable failures, or unpredictable growth in the number of processors (we need to put the same programs onto faster computers in the future without having to change them), and the overall system performance might be throttled at times by power or thermal demands. It should also allow migration of programs onto quite different hardware architectures for parallelism (again to make use of future hardware). This is so complicated that a "roadmap" is needed for how to develop it over several years, rather than planning to just do it now in one development phase – it's that big a task.

More specifically, the processor space is conceptualised as "invasible regions" (the size and shape of which can be negotiated according to prioritisations between programs) and for the individual programs to then try to shrink and grow their execution footprint by negotiation with the neighbours (for connectivity reasons, these architectures will favour smaller, denser regions being allocated to the same program, rather than an isolated sparse list of distant processors). This footprint will then go through phases of invasion and retreat as demand (and availability) ebbs and flows. The technique is targetted (deliberately) at all scales of integration between processors from conventional multi-core systems with a few cores through to tightly-coupled processor arrays (TCPA). For TCPAs (which are relatively new and not well dynamically managed by current systems) this invasion and retreat could itself be rapid (compared to processing times) and so the overhead time to manage the invasion and retreat becomes important, which invasive computing also tries to manage, reduce and make predictable.

Overall, the process of building all this will be a long one and will require developments at every level: the management algorithms, the OS, the hardware, but also the application programming languages. What does an invasive-capable program look like? How much change or annotation is needed to give it this ability? How evident will that be to the application coder, because ideally it wouldn't be. Andy Dingley (talk) 20:07, 22 March 2020 (UTC)[reply]